Unreal Sun Temple Reference Scene

[WickedInsignia]

Godot version

4.0 Stable

System information

Windows 11, Nvidia RTX4070ti, AMD Ryzen7700x

Issue description

This is the Unreal Engine 4 Sun Temple example ported to Godot 4, utilizing files provided by Nvidia and donated by Epic Games.
It's a good showcase of a scene that combines interior & exterior lighting and modular assets. Most importantly though: Godot really struggles with this environment.
This scene is exceptionally clean in UE4, and it employs heavy use of repetitive modular meshes. This is a very common environment asset pipeline and something Godot should aim to accommodate.

Changes:

• Unreal Engine 4 and Godot are very different engines. Some of the textures present in the Unreal version also aren't provided with Nvidia's version so naturally they will appear quite different. Regardless of this the scene is lit as closely to the Unreal version as possible.
• A Blender file of the environment is provided as a ground-truth reference.
• The skybox's brightness is best-guess in both files. Godot uses Nits, while Unreal & Blender use arbitrary brightness values for skies. They're matched based on apparent indirect light contribution but aren't exact. The Unreal version also uses spotlights to fake more skylight than would occur naturally, these have not been included in the Godot and Blender files.
• The sun and lamps share the same difference in brightness between all 3 versions. The Unreal version uses 20 Lux for the sun and 37 lumens for the lamps. This was much too dark for Godot to handle, so the ratio has been used instead based on a sun brightness of 100,000 lux. This is inexact in Blender since it uses Watts, which won't convert precisely even if the ratio is correct. It still appears roughly correct here though.
• Sun has been changed to white to match the Unreal version.
• All normal maps have been converted to OpenGL PNGs.
• Nvidia's file comes with manually unwrapped lightmap UVs. These have been used instead of allowing Godot to unwrap automatically, which produced worse bake results.
• The original meshes used split hard edges. These have been merged to reduce vertex count, with the appropriate edges marked as sharp instead.
• Texture roughness is different and uses complicated node setups in the Unreal version, so the ground appears considerably less slick in the Blender and Godot versions.

Issues:

As mentioned, Godot really struggles to resolve this scene's GI adequately. Here are my observations:

• None of the lighting solutions handled overlapping modular geometry very well. The walls are reasonably thick but the abundance of overlaps posed a challenge.
• LightmapGI produced the most usable results, but exhibits noticeable leaking even with a high texel density.
• SDFGI is virtually unsuable in this scenario, leaking far too much even with Occlusion active.
• VoxelGI was also unusable, never reaping an appropriate result even with high subdivisions.
  Here are some comparisons for reference. In all cases SSAO and SSR are active, and reflection probes are used in the LightmapGI shots:

LightmapGI was the most usable GI solution but exhibited a lot of leaking, such as in this first hallway. The walls are adequately thick and should be overlapping enough to properly obscure any exterior light:

Leaks also occurred in places that were otherwise manifold and absolutely no light should have been able to pass through. This ceiling has many leaks on the inside, even though the exterior is completely sealed. The leaks persisted at 2x the texel density and with Ultra quality bakes. This behavior isn't consistent with other lightmappers I've used, which handle even the thinnest manifold walls without leaks:

Steps to reproduce

N/A

Minimal reproduction project

Download the Godot project file HERE
Download the Blender file HERE

If all textures appear pink when the Blender file is opened, simply go to File > External Data > Find Missing Files and navigate to the Texture directory.

[yosoyfreeman]

Wow! this must have been a lot of porting work. Thank you!

I spend some minutes fixing some lights and set up a real time GI config I was not expecting SDFGI to works this great. Here are my results:

I'm quite impressed by how this looks and how easy was to set up. What troubled did you have with sdfgi?

[WickedInsignia]

@yosoyfreeman I didn't use shadows for the omni lights since they rack up performance cost on that light type (as they would in any engine tbh) and aren't practical in a game when no shadows will usually do. The Unreal version used no shadows for the omnis either, so I just followed their example.

SDFGI shows skylight leaking between many of the meshes on the closest cascade (visible in your examples on the ceiling, ground and ledges), and then leaks profusely on cascades further away. There's also quite a bit of noise, with random bright splotches appearing on the larger walls that aren't properly averaged away.
Sometimes it can look nice in beauty shots, but it falls apart once you put a player and a moving camera in there. Regardless of how you tune it, moving the camera through the space will cause the GI to very visibly transition from bright to dark with leaks and splotches.
This is a nice result! Although ultimately hiding the issues with fog and dynamic shadows that aren't always practical in real-world use.

[yosoyfreeman]

Hi @WickedInsignia , you are totally right about performance cost. I didn't change them cause i wanted to keep close to the original setup, but in the case of not using shadows for those crucial elements a really open spotlight would work better in this particular scene. Fog was used just to add volumetric detail that unreal have by default. It is not hiding nothing :)

The patches on the first image and second on the ceiling are not leaking but light coming from the back windows. The scene also used 1 light probe for the first statue and nothing more.

Anyway, i tweaked the settings and the results all close to perfect now, even the construction of the scene have paper thin walls which are usually not a great idea. fixing a bit the walls would fix the minor issues left.

It looks really cool in movement too!

https://imgur.com/a/K4nBvTV

That said, the current SDFGI implementation have two big problems:

• the blending betweens cascades is not good.

• SDFGI produces artifacts until is fully updated. This is killer bug in my opinion, it produces terrible visual artifacts until the camera moves. I think it should wait to update until it is processed. a lag spike while manipulating settings or creating the info for the first time is better.

Edit: Some pictures of the scene with this config:

(The white points above there are the shadow cascades, not leaking)

[unfa]

Maybe it'd make sense to create a camera flyby animation and render out a sequence in the movie maker mode to benchmark the visual quality in motion?

[yosoyfreeman]

i never touched the new movie maker and i don't have a powerful pc to do a good 4K render, but if someone is willing to i can finish tweaking some things and share it.

It is not perfect, as i said, demonstration scenes are created specifically to showcase the strong points of an engine and hide the weak ones. I would not use walls so thin, but i think is a fair use case tho show pros and cons. It may help devs to improve SDFGI.

[unfa]

I could try and make a camera flyby animation - I did this for Liblast already so I have figured out the quirks of doing a good one.
I don't think it has to be 4K or super high quality.

[WickedInsignia]

@yosoyfreeman You have the reflection probes turned on in both the screenshots and video, which mask SDFGI entirely. I noticed you've increased the range on the omni lights well beyond the original spec too, the specular can be seen through the walls. The lights in the original file are tuned to avoid that.
That's all fine, but the issues I brought up are regarding original spec and when SDFGI is used in a way that you can actually see it.
With SDFGI tuned to the same spec and using the original settings with reflection probes turned off, I get the following results. I used default normal + probe bias though, since your settings there produced more leaks:

If I increase the omni light ranges similar to what you have, the leaks and splotches persist:

[WickedInsignia]

If anyone intends to test this scene with SDFGI, please turn the reflection probes off OR set their Ambient Mode to disabled. SDFGI has no effect with them on.
This scene was ported to test its limits and help improve the existing solutions. If you want something pretty that works well as-is to showcase what Godot is capable of, please use the Bistro scene.

[jcostello]

I tested the scene as well. I can confirm that SDFGI and VoxelGI are completetly unusables in this scene. LightmapGI with ReflectionProbes works really well. I put it to x4 in each Mesh and the leaks are reduced a lot. x8 should fix them all. In the future this will be posible globally in the Lightmap itself.

Lightmap still the best GI solution and should be improved a bit more (bug fixed and feature completed)

[WickedInsignia]

My experiences too. Unfortunately larger texel densities bloat the file sizes. x8 would fix everything, but it's also a huge memory resource and not practical when it's just being used for GI.
With the leaks improved (which shouldn't really be happening anyway, as expressed by existing bug reports) LightmapGI should be a good solution at default settings.

UE5's Lumen handles this scene just fine, but that's expected and it's also much heavier than SDFGI. It goes to show that an SDFGI-style solution can work though.

[yosoyfreeman]

If anyone intends to test this scene with SDFGI, please turn the reflection probes off. SDFGI has no effect with them on. This scene was ported to test its limits and help improve the existing solutions. If you want something pretty that works well as-is to showcase what Godot is capable of, please use the Bistro scene.

Just to clarify so people don't get confused: Reflection probes will not disable SDFGI effect if you set up them correctly as stated in the documentation. In this case, the ambient light parameter must be disabled so they only contribute as a static source of reflections to improve SDFGI.

Edit: First image without reflection probes, second one with them. Both using SDFGI.

The default normal and probe bias prioritize slopes over leaking. As described in the documentation, lower values will produce less leaking.

Default values vs my values. The default ones produces way more leaking. Look at the center pillar, there is a gap with the defaults, not with my settings.

[WickedInsignia]

@yosoyfreeman I've amended my comments to reflect this ambient mode exception, but that's not the way your second set of screenshots above were set up. There doesn't seem to be any SDFGI influence in those shots or the video at all.

This is a reference scene where SDFGI objectively has issues. It's not helpful to spam screenshots where the probes are set to nullify SDFGI entirely among a multitude of changes (sun direction, skybox and light range) and then suggest you fixed it. That defeats the purpose of this body of work.
It's totally fine to do your own thing with this file, but let's please try to keep it on the default config here. That's the configuration everybody has access to and can test/validate.

[yosoyfreeman]

Hi @WickedInsignia, you were right about the radius of the lights which were basically exploding light around everywhere. You are also correct about the fact that SDFGI have issues as I myself stated in my showcases. I also reduced the intensity and used 2 cascades if i remember well to force at least 30-35 meters on the first cascade and used physical blocker to prevent leaking. The results, tho, have low frequency in terms of detail.

I'm not spamming anything. I'm just sharing my results the same way you did. I been experimenting with this tools since the firsts pre alphas and just pointed about Reflection probes and bias correct usage.

I never claimed to have fixed nothing and already explained that didn't make any change that hides nothing. I just moved the sun to create a more balanced composition of the scene. The skybox is untouched.

But anyway, here is the project with your default sun and lights settings with the exception of the two big lights that i kept shadows on. I think we can both agree that the results are still way nicer than you described as unusable.

Grabacion.de.pantalla.desde.2023-03-30.14-14-56_compressed.1.mp4

As i understood, (Correct me if I'm wrong) the purpose of this body of work is to test the behaviour and limitations of lighting methods in 3D scenes, especially complex ones like this in a way than can be used to improve them in the future. Now, for us to being able to do that we need to push for the limits of the technology. Is with that purpose that i took the time to do my test and share the results and the tweaks needed to push the SDFGI further and find the break point.

As you may understand, i don't have an interest in hiding problems that affect us all.

Here is the project so anybody can look at it or do whatever they feel with it:

Download the scene: https://mega.nz/file/K50lxDSI#yy0R5pNMlmOITC_ykDicevnzGkmHagw5QVdvgSGENYU

Note: SSIL randomly generates artifacts. I have to investigate that deeper.

Quick approach to the scene: use the SDFGI as a low frecuency GI detail and a reduced range and doubled intensity of SSIL to simulate high frequency detail. Some reflection probes were added to the scene (adding more accurate ones would improve the results ). Used Volumetric fog to simulate a subtle light scattering.

Mayor problems: While trying to get more detailed, high frequency detail from SDFGI the lack of control make it noise and unstable. The extra detail ends up reading as noise as the camera moves. This is inherent to the design of the feature: The cascade number, the first cascade and the maximum distance are tied.

My personal recommendation: The problem here is one of usability. I can guess that those settings being tied was a design choice to keep a complex system simple and get to the "One click solution" Godot philosophy, but this causes serious problems in practice.

Just as one would do with shadows, you need to be able to tweak resolution and cascade distance independently. You don't want to gain detail when you are at literal centimeters away from a surface. You want to maintain most of the detail on the first cascades and exponentially reduce it far away. Cascades should be configurable manually and detail and distance should not be tied.

[WickedInsignia]

Most of that has already been explored with bug reports and proposals. If you want to help, please pursue reports that address issues that haven’t been identified.
Installing blockers to prevent leaks as you’ve done doesn’t resolve the core issues with SDFGI. I’m absolutely aware that a nice result can be achieved with additional geo/edits but that’s not the point of this project, and you don’t have any authority to determine that it should be.

This is becoming patronising and I kindly ask you to please give it a rest.

[yosoyfreeman]

This is becoming patronising and I kindly ask you to please give it a rest.

Sure! I already explained what it needed to.

[WickedInsignia]

Apologies for the abrasive turn this took, everyone. Just to explain in more depth:

• This project wasn't designed to "be fixed" artistically. Additional geo and world adjustments will reap better results, but that doesn't resolve the core issues with Godot's GI. Other engines have no problem with this environment as-is, so it's presented here in that state to assist development. That may not have been clear to some.
• Similarly, SDFGI adjustments may reap better results but that was tested extensively on my side. Without world/geo adjustments, SDFGI did not produce conventionally usable results.
• You're entirely welcome to do whatever you want with this project within the bounds of the Sun Temple license employed by Nvidia. You're also entirely welcome to show your work here.
• I understand and appreciate the desire to be helpful, but I don't appreciate misleading info that suggests the issues being observed are simply because I don't know how to tune the settings, or because I misunderstand the purpose of my own project.
• I've put my best effort into faithfully reproducing the Unreal project while creating a reliable comparison between the Blender and Godot versions. If a better testing standard can be achieved than the format I've presented, I absolutely welcome improvements and suggestions.

Thanks for your patience and please enjoy playing around with this project!

[unfa]

Thanks for clearing it up. I think what took place was a misunderstanding. Possibly a language barrier issue as well? We all want to improve Godot :)

If it'd be useful for evaluating the results in motion I could contribute a camera flyby feature for creating reproducible, easily comparable footage and evaluating changes that will be done to SDFGI.

Maybe a few static cameras and a script to export screenshots from them would be useful as well?

Let me know if I can be of help.

[WickedInsignia]

A flyby cam would be great! So many of SDFGI's issues are talked about but can't be shown adequately with stills. Any tools to better help evaluate and provide records of issues/bugs/whatever are absolutely valuable.

[WickedInsignia]

I do believe there was miscommunication there with YoSoy. I could've done a better job in explaining the goals of this project and accepting contributions outside of those goals, even if the reliability was a little shaky. You're completely right, everyone's here to support Godot and has good intent.
Hopefully they continue experimenting with Godot and enjoying these projects.

[unfa]

Well, it just so happens that me and Yo Soy Freeman are working together on a game made with Godot, so I'm pretty sure that's going to be the case :)

[yosoyfreeman]

Hi there @WickedInsignia I'm totally sure this must been a misunderstanding. Just to clarify, i was not implying in any way that you did a bad work. In fact i praised it heavily and made sure to credit your awesome contribution in mastodon where i have my little community and any other place i published my results. I'm being totally sincere about that and I'm sorry i don't understand how i transmitted you the opposite feeling.

My intention was not to nullify your claims. I was just trying to show that even when using it following strictly the recommendations made by the dev's (Mostly Reduzio in this case) about trying to compensate leaking with bigger walls do NOT works as it should. I believe that lots of the time the dev's in charge of a specific technology don't have too much time sometimes, so i wanted to avoid the situation in which they see it quickly, say that we try thicker walls and we have to wait until the next time they see it. I'm very sincere too when i say being misleading or hiding problems was not my intention as the entirety of my Godot contributions are based on finding and reporting problems and suggesting design changes for usability. What i do is finding problems, not hide them.

Let me say again to be extremely clear: Thanks for your work, for your time and for contributing to this community.

Misunderstandings happens, I myself find human communication a complex task sometimes so i probably responsible in that part. No hard feelings at all from me and i hope we can keep working for the good of us all.

Hope this is more clear now, cause i think you did really useful work here and making you feel like i don't find value there is something that saddens me at a personal level.

[WickedInsignia]

No worries at all @yosoyfreeman and thanks for explaining all of that. I'll admit I was a little fizzed out yesterday, and none of that should have fallen on you. I felt something had gone awry when reading this all back, and I apologize.

I did mean it yesterday when I said the most productive course of action would be to follow up with bug reports and proposals though! I've been pursuing a lot of them myself. Remember to check if they haven't already been reported (I'm sure you'd be vigilant enough to ensure this already) and I don't think the exhaustive testing/validating you're keen to do would be wasted.
If you do any more work with this project I'm sure the contributors here would love to see what else is possible, with the disclaimer that changes have been made of course 😉 .
Thanks again and I'm glad we could iron that out!

[yosoyfreeman]

I see, i been working hard on the game with Unfa and didn't knew they were proposals already. I thought this was the test project to making them so i think that is the point in which we didn't match.

Happy to solve this in a good manner and sorry again for making you feel bad. I'll try to be less machine like cause i think i sometimes get read as sarcastic when I'm not haha

Thank you again in general.

[shmolyneaux]

Hi Folks,

I thought I could help out by creating a comparison video for UE4/Godot.

I rendered the same fly through in each. Github's file size limit is only 10MB, so please excuse the encoding artifacts.

The only change I made to the Godot project was to enable MSAA 8x. I'm happy to make more comparison videos if there is something specific you want to look at or if there are other Godot settings to tweak.

unreal_godot_comparison.mp4

[jcostello]

Hi Folks,

I thought I could help out by creating a comparison video for UE4/Godot.

I rendered the same fly through in each. Github's file size limit is only 10MB, so please excuse the encoding artifacts.

The only change I made to the Godot project was to enable MSAA 8x. I'm happy to make more comparison videos if there is something specific you want to look at or if there are other Godot settings to tweak.

Really nice work. It helps a lot.

If is not much to ask can you do the inverse path so we can see the other part of each render? Also a fiew splitview images for each engine will be apreciated

[lander-vr]

Besides quality-of-life and workflow related critiques, which are well addressed in @WickedInsignia's proposals, the lightmapper currently still suffers from light leakage ( #87815), and denoising often leads to seams/artifacts. These issues are particularly prevalent with modular environments, as shown by earlier comments in this post too, and in my opinion these are the biggest issues with the lightmapper at the moment.

Once those issues are fixed, I'm confident achieving high-fidelity arch-viz type environments would be entirely feasible, those require very clean high resolution light bakes.

Non ideal workflows can be lived with (though, don't get me wrong, they are hugely important to resolve), but unreasonable light-leakage or denoising artifacts will actively prevent a clean result from being achievable, and it isn't often possible, let alone ideal, for an artist to work around those issues.

[jcostello]

#87815 and the issue with the create image method to allow to bake bigger levels should be fixed to have a decent lightmapper to work with

[yosimba2000]

The modular one is a really bad issue. I'm forced to design my level in Blender, then Boolean or re-create areas that are made of modular units as one big mesh to avoid seams between tiles.

The developer of Bakery for Unity said he was developing a light baker for Godot, not sure what the progress is on that, though.

[jcostello]

The modular one is a really bad issue. I'm forced to design my level in Blender, then Boolean or re-create areas that are made of modular units as one big mesh to avoid seams between tiles.

The developer of Bakery for Unity said he was developing a light baker for Godot, not sure what the progress is on that, though.

Where did you read that?

[yosimba2000]

The modular one is a really bad issue. I'm forced to design my level in Blender, then Boolean or re-create areas that are made of modular units as one big mesh to avoid seams between tiles.
The developer of Bakery for Unity said he was developing a light baker for Godot, not sure what the progress is on that, though.

Where did you read that?

He mentioned it on his Twitter: https://twitter.com/guycalledfrank/status/1701992867973997020

Also it's on his Discord devlog, but no new updates beyond what was provided.
https://discord.gg/hky3CFsU

[WickedInsignia]

That isn't confirmation that he is working on it, just looking into it. Curbing some expectations before we all get too excited ;)
Many of the responses to THIS THREAD are quite informative and should set the expectations around popular Unity plugins coming to Godot.

In short it's not guaranteed. A robust in-engine solution would be best, rather than relying on a possible paid solution.

[jcostello]

He mentioned it on his Twitter: https://twitter.com/guycalledfrank/status/1701992867973997020

Seems that he is not longer working on it

[yosimba2000]

Even baking in Blender has seam issues when using the denoiser. And you wouldn't get light probes in the game anyway if you did that.

Maybe it'd be best to migrate to another engine for now if we really need functional light baking?

[WickedInsignia]

Even baking in Blender has seam issues when using the denoiser. And you wouldn't get light probes in the game anyway if you did that.

There's a (supposedly quite capable) lightmapping addon available for Blender HERE.
Bakery in Unity retains probe baking as a separate step to baking the lightmap. If this was the same in Godot, a user could load in an external lightmap and then bake probes via Godot's lightmapper. The optimal solution would be a sufficiently functional lightmapper in Godot however.

[patwork]

Maybe it'd be best to migrate to another engine for now if we really need functional light baking?

Unity has problems with seams too. seam stitching

I also believe that baking lightprobes shoud be a separate process from baking lightmaps, especially when projects like LightmapProbeGrid exists.

[WickedInsignia]

Unity has problems with seams too.

To my understanding most lightmappers experience this problem.
Unity is an altogether far more practical and usable solution though, with the benefit of seam stitching to resolve this.
Unfortunately no amount of seam stitching will fix Godot's core trace, the fact light leaks through closed geo, the poor usability workflow and the limitation of baking to only one uncompressed image.

Baked GI is still a reliable and important technique used commonly today, it's disappointing that more care hasn't been taken with Godot's solution and those capable of improving it have focused elsewhere on more experimental techniques.
The only other option is HDDAGI which is artifact-prone, requires fully realtime lights and screenspace effects and was just pushed out to 4.4 at the earliest.

I hope the discussion here isn't dismissed by core team members as some sort of entitlement. Features which could actually help artists and have been successfully implemented elsewhere for over two decades are being neglected. I strongly believe these should have been developed to a robust state before prioritizing other unproven techniques (one of which is being deprecated and the other replaced).

[lander-vr]

I also would like to chip in to vouch for the light-mapper getting some more love before other solutions are prioritized. It's currently in a state where it's not feasible to get reliable and solid results due to artifacts, inconsistencies between separated geometry, leakage, among issues shown in this thread.

Building the light-mapper into a robust GI solution seems to me to be the most straightforward way right now to push the envelope of 3D graphics in Godot. It would be hugely beneficial for both high-end graphics and mobile platforms, thus affecting a very wide range of users and projects.

Dynamic solutions such as HDDAGI are very very nice to have, impressive, and definitely useful in many scenarios, but ultimately they come with visual and performance tradeoffs for which there is no viable alternative at the moment. We shouldn't forget that so many games over the years, small and large alike, have utilized baked GI and static lighting to get the most bang-for-buck.

I understand that with tech like RTGI and Lumen having become popular it is very enticing to offer a dynamic GI counterpart for these in Godot, but baked GI remains extremely relevant. Taking the visual fidelity it offers for the performance cost in mind, it still takes the cake.

[patwork]

There is some hope: https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aopen+lightmapgi

There should be some way to support the people who are working on these topics. Unfortunately, looking at godot-proposals it looks like the majority of users are voting for another way to expand gdscript. My guess is that there are still too many people using Godot as a platform to learn programming rather than a game development engine.

[WickedInsignia]

Features related to the art pipeline in Godot seem to be sidelined for a few reasons:

• Primarily hobbyist and indie-focused userbase which tends towards a focus on gameplay/scripting rather than art assets and fidelity. That's not to say this is a problem of any sort, it's just a data-point. I'd throw your last point in a similar basket to this too.
• Most (if not all) of Godot's core team originates from a programming background and have little to no formal experience in art pipelines. Again, this is presented here simply as a data-point and not intended to smear.
• Major features implemented without seeking informed feedback first or referencing successful efforts in other engines. This leads to a constant reinventing of the wheel by people who've never driven on a road before and judging by some of the discussions here, presume they have the knowledge of those who have.
• The art/asset pipeline in Godot is generally underutilized and untested, with most tests amounting to greybox programmer art.

These are difficult points to work around as an art-focused contributor and have led to some unfortunate headbutting. Some are just the nature of things, while some others could certainly be acknowledged and improved.

[patwork]

But there are also cases such as this: #62987

• created Jul 13, 2022
• looking good
• looks amazing so far
• ...
• Aug 23, 2022
• looks great!
• Sep 8, 2022
• I'm happy with the changes
• ...
• Sep 24, 2023
• This PR is getting older
• Hi, as much as I'd like to get this PR merged myself, I'm afraid that I don't really have time right now
• salvageable label on Sep 24, 2023

1 approval
3 pending reviewers

[lander-vr]

Unfortunately, looking at godot-proposals it looks like the majority of users are voting for another way to expand gdscript.

It's important to note that one feature being in development doesn't necessarily negate another feature also being in development. Additionally, GDScript-land is a different territory of the engine and would likely have different contributors working on it than those working on 3D rendering features like the lightmapper.
In the end, priorities must be made, and I can't really say I disagree with the rendering priorities seeing what Dario and Clay have been working on these past months. And besides the votes, the issues we're highlighting in this thread also contribute to how prioritization decisions are made and hopefully is able to put the lightmapper higher up on their radar.

Regarding @WickedInsignia's points, I agree that particularly on the art-side of the engine, from a UX and workflow standpoint it does seem that certain features lacked feedback from people who have a decent amount of experience with using those (or similar) features and the workflows that surround them. As an artist at least this seems very noticeable.

It seems that if there was a better feedback loop with experienced users in the early stages of a feature, a lot of time could potentially be saved down the line. This is still tricky though, because reaching unanimity on things is generally impossible.
Additionally, with Godot being general purpose, it's a tricky balance between catering to individuals and teams. That said, as a generalist I'm of the opinion that features in specialized software such as game engines and tools shouldn't compromise in functionality purely for the sake of usability, good UI and good documentation (such as Godot's exemplary docs) guides any user through using a feature and getting a basic understanding of a feature they're not initially familiar with.

In Blender this early feedback loop is tackled for a large part through their dogfooding based development model in collaboration with the Blender Studio, so they gain direct feedback from experienced individuals. While I know there was a dogfooding initiative started through W4games last year, besides the announcement article I haven't been successful in finding any other news or developments regarding this.

[WickedInsignia]

While I know there was a dogfooding initiative started through W4games last year, besides the announcement article I haven't been successful in finding any other news or developments regarding this.

It should also be noted that the efforts so far seem to be basic 2D games well within the scope of what Godot can easily achieve. A driving force behind Blender's dogfooding projects is that they push the engine and aim for quality, while keeping the scope manageable for a small team.
It's obvious this initiative has provided huge benefits to Blender. It's one of the reasons I began porting over demo scenes of a reasonable quality that would push Godot's capabilities. I don't have the resources of something like W4 games however and don't feel inclined to continue for reasons that shouldn't be a mystery to many at this point.

[jcostello]

IDK what should be a good step to follow to catapult this. Maybe to create a robust proposal for lightmap workflow and try to get as many attention as posible. Tho Godot bureaucracy makes things harder to implemement.

Take for example the issue with #54679

The fix for issue has been spotted but the "no one wants to fix it" argument was raised.

Some road to implement and fix things should be implemented in things like a lightmapper that has to work from A to Z

[dsnopek]

Lots of work has been done on lightmaps for Godot 4.3! There certainly is lots more to do, and it'd be great if it improved faster, but support for lightmaps hasn't been totally stagnant.

Take for example the issue with #54679

The fix for issue has been spotted but the "one wants to fix it" argument was raised.

I don't know if it fixes that issue or not, but the title of that issue is "Vulkan: Crash when baking lightmaps with LightmapGI if the resulting image is too large (due to CowData using 32-bit ints)", and in Godot 4.3 CowData now uses 64-bit ints (see PR 86730). So, even if that issue isn't fixed yet, a large roadblock has been removed.

[WickedInsignia]

So, even if that issue isn't fixed yet, a large roadblock has been removed.

Thanks for the clarification here, it's easy to forget that implementing features usually isn't as simple as "just add the thing." Sometimes Godot's backend simply isn't capable of it and a bunch of different improvements need to be made before that feature is viable.
The issue I'm experiencing is that the limitations of the current groundwork aren't defined very well and Godot's capabilities are commonly lauded in official channels, which sets unrealistically high user expectations. Secondly there's no public-facing roadmap/prioritization to let users know what groundwork needs to be done before a feature can be worked on.

There could be 5 things that need to happen before lightmapping can improve, but we're sort of left here guessing whether it's technical limitations or simply mismanagement. Contributors aren't left with many options when calls to improve communication are dismissed entirely by lead devs.

[AttackButton]

This discussion shares many similarities with the Godot Jolt thread. On one hand, Godot 4 was launched with GDScript and the production workflow in the best possible stage. On the other hand, the physics engine and rendering are currently underperforming.

Contributors are doing their best with the time they have, but despite the influx of funds, Juan continues to take on the work himself instead of hiring experts.

[patwork]

Contributors are doing their best with the time they have, but despite the influx of funds, Juan continues to take on the work himself instead of hiring experts.

That's not quite true, as several experts are sponsored by W4Games.

The bigger problem is the time it takes for PR to be accepted for master. At the moment we have over 2366 PRs of which 2080 are awaiting review. Some of them have been hanging around for several years and certainly their authors have long since lost interest in them.

[WickedInsignia]

Contributors are doing their best with the time they have, but despite the influx of funds, Juan continues to take on the work himself instead of hiring experts.

He's publicly expressed a desire to take a crack at lightmapping. My experience suggests any intent to hire someone would be shelved as a result.

That's not quite true, as several experts are sponsored by W4Games.

That doesn't negate AttackButton's point. What they hire people to work on will almost certainly take Juan's desires into account as co-founder and co-CEO.

Some of them have been hanging around for several years and certainly their authors have long since lost interest in them.

This is a frustratingly demotivating problem. Without any form of public-facing prioritization or roadmapping (sensing a theme yet?) it's difficult to gauge just what is being prioritized, where work is most needed, and when one can expect their work to be merged.
One example of the issues caused by this: I was working hard for a while to test and identify bugs with VoxelGI. Apparently it will be deprecated completely for HDDAGI but I only gleaned that info through comments from Juan on his personal Twitter and the odd comment on Github.
I've mostly thrown in the towel on proposals and reports, since there's nothing formal to gauge how dispensable my work is.

[MurderVeggie]

Okay, let the Community Manager intercept here. We will close this thread, as it (once again) derails too much from the original post, but do not take that as us squashing conversations that are certainly important to have - this simply is not the right space for them.

That being said, to address a few basic things directly: you will be happy to hear that internally, we are currently re-structuring the entire production process as you know it. Not only to speed up development and create feedback pipelines, but also to fix some core legacy issues raised here. One of them will be a roadmap. Give us time to discuss details before going public with them however, we need to do this right and with care.

[clayjohn]

Also to clarify, the technical issues raised in this thread are already being tracked by other bug reports which are aggregated in the LightmapGI tracker issue: #56033

We can't take action on a bug report that is literally hundreds of comments that are mostly arguing about unrelated things. A lot of this discussion is valuable (and to me, interesting). But this isn't the right place to have it. Getting so far off topic has turned this from a place to identify specific problems with this specific reference scene to place to vent frustration. Let's refocus our discussions on the particular bug reports for particular problems that need solving. That way contributors can more efficiently identify and fix issues.