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.

[WickedInsignia]

That strange noise pattern seems to be gone with physical lights turned off but I'm still getting plenty of leaks at default texel density with the default mesh UVs. Anything much larger than this texel density (7MB EXR) is not terribly efficient for keeping size down in a game so even if larger maps did solve the issue, you'd have to reach a size (beyond 50MB) that just isn't very practical.

Z-fighting shouldn't cause any issues either, it has very little to do with the way light propagates in a scene like this where all the meshes are either overlapping or connected in an airtight way. I moved some meshes around in the hallway to prevent Z-fighting to check and the results were exactly the same. Here's the same location in Unity with a 12MB lightmap bake from Bakery. The exposure has been turned up ludicrously to the point that compression can be seen in the lightmap. This is a diffuse material with no reflections whatsoever:

Same shot from Godot, with standard exposure. This is a 7MB lightmap. This includes reflective materials but they do not interfere with the very obvious leaking:

The problem seems to stem from the fact that Godot's lightmapper does not act appropriately around overlapping geometry. It simply ignores the area where a manifold mesh overlaps with another one and lets light pass through on the surface that is being intersected. This does NOT happen in other mappers: Where meshes intersect, the mapper assumes light cannot penetrate. Here is a shot from inside a pillar that overlaps with another one in Unity (the location is inside the front pillar on the far left side in the shots above). Notice the hard black line, which is where the pillar the camera is inside of intersects with the one slightly in front:

Here's that same location in Godot. The overlap may as well not exist, since light passes straight through across the surface like there's nothing to block it whatsoever:

I'll make a bug report for this soon.

[WickedInsignia]

Anyone involved in the lightmapper development should endeavor to use the mappers available in other major engines along with a raytracer for ground truth comparisons. The Blender file is included with this demo scene for that explicit reason. Many of the issues I can identify are resolved by simply gesturing in Unity's direction. The overlapping issue shown here isn't present with similar settings in the Progressive GPU mapper, and it definitely isn't present in Cycles.

Not suggesting we replicate major packages in their entirety, but lightmappers are a well-worn technology with near-flawless implementations readily available to play with and compare to. I've done many of these tests myself. You don't resolve issues like this by using Godot in isolation without experience with a sufficient reference point of something that does work as intended.

[DarioSamo]

@WickedInsignia One of the most crucial fixes I wanted for dev6 hasn't been merged yet. Think you can give this PR a shot? One of the core fixes is that it will no longer incorrectly boost the result of indirect light if it traces a lot of rays towards backfaces. It sounds like it might be related to the issue you identified.

https://github.com/godotengine/godot/pull/82068

If it's not I can give it a go and try to identify what's going on.

[WickedInsignia]

@DarioSamo It seems to be a separate issue to that PR. The problem isn't the incorrect boosting of indirect light in this case: It's the fact that it doesn't treat airtight meshes as being totally dense on the inside. When two meshes overlap, the mapper seems to draw the hard line between light penetrating through the mesh and light being obscured by the overlapping mesh in the wrong place, allowing light to penetrate further than it should. As an example, here's the corner of a room baked with the new PR. This is at default texel density with High settings and 5 bounces. That piece of wall in the corner is actually a modular pillar mesh that intersects with the walls to the left and right of it, but light is leaking in from the outside on both walls:

Here's what it looks like inside the pillar (you can see the base of the pillar near the bottom). The light is being allowed to travel far into and beyond the entire area that the pillar intersects with the wall:

Here's that same spot at double the texel density with exposure cranked a bit. The leak disappears, but when I looked inside the pillar the light was still allowed to propagate halfway into where the pillar was, even though there was sufficient resolution for it to stop earlier, along with a meter thick wall to the left of it that should've blocked the light entirely:

There's a pretty obvious leak near the ceiling. If we take a look inside that meter-thick wall we see the same issue as before, the light penetrates far beyond where the wall intersects with the ceiling:

In my Unity example two comments above, the area where the pillar intersects with the wall is completely black. Light is simply not being allowed to penetrate inside the pillar at all, so it doesn't illuminate the spot where it intersects with the wall. This same behavior is exhibited in Blender's Cycles, which assumes that light cannot penetrate inside a mesh at all and presumes they're entirely dense.

I do recommend trying this demo scene out yourself to inspect the issues in closer detail. (Also a huge thank you for all the great work you've been doing on the lightmapper lately!)

[DarioSamo]

Thanks for the detailed report, I'm currently finishing up another PR unrelated to light mapping but I can give it a look after that so we can understand this further.

[jcostello]

I was using https://github.com/godotengine/godot/pull/82068 for my test. I still have leaking but not that much. I think the scene has problems by design. I know other engines handle this better but the scene has modeling problems.

@DarioSamo take a look and let me know how can I help you with this

[WickedInsignia]

I think the scene has problems by design. I know other engines handle this better but the scene has modeling problems.

This scene was a mobile benchmark created by the Epic Games team and is a prime example of using repetitive modular meshes with very conservative texture use. The problem isn’t the way it’s made: if other engines handle this well, the discrepancy is Godot itself. 3 other lightmappers (Unity GPU, Unity Bakery, and Unreal) all handle this fine.

There are environment building techniques that Godot handles much better but that doesn’t make this technique wrong; it makes Godot limited. Modular meshes with heavy overlaps is one of the most common techniques used in high-fidelity games today and this example is direct from a studio that has over 20 years experience building high-fidelity games.

Don’t mean to drive the point home too much, but the problem here is how Godot handles a common scenario. Not the model itself.

[DarioSamo]

I've been mostly identifying issues of the lightmapper as they come (I've not been involved in its original development after all and apparently few people have dared to modify it much for about three years), so anything that looks wrong is a good indicator it should be researched to me so we can determine the real cause of the problem. Sometimes it's the lightmapper, and very recently we found a case where the UV2 generator for primitive meshes itself was incorrect.

Hopefully this is a gradual process where it can converge into a correct result as we fix more of the fundamental errors that we've spotted. There's still parts of it I haven't fully parsed yet so any scenario that lets me dig around it some more is fine by me.

[Jamsers]

if other engines handle this well, the discrepancy is Godot itself

Cannot stress this enough, a very simple assertion that holds up regardless of reasons or justifications Godot may have.

Not to mention the unassailable legacy of lightmapping done right in gaming dating back to the freakin 90s: this tech has practically been perfected in 2004. (Half Life 2 anyone?) No modern engine regardless of goals should be failing at this, and it's pretty essential for mobile, web, and VR.

[DarioSamo]

@WickedInsignia I'm inclined to believe the root cause of a lot of the issues are a combination of the UVs and texel size not really working well with each other. However, that might reveal a weakness in Godot's lightmapping process that I discuss at the end.

Just to rule any factors out so I get a very clear version of what is going on with the light leaks, I only enabled the following things:

• Directional light baking as static (so I can tell clearly if a pixel is reaching the light or not).
• Only enabled the directional light.
• No denoiser.
• No indirect bounces.

As you can imagine the result looks fairly boring, but this is as good as it gets to get a clear idea of a binary result of whether a particular pixel of the lightmap is reaching the light or not.

Here's some of what my first impressions of the problems around the scene are.

Very small texture texture atlas

A look at the resulting EXR reveals we have an scenario with a very, very small lightmap for the entire scene. You've mentioned that modifying the texel size seems to fix issues, and it'll be really apparent as to why that happens next.

But safe to say, this will be really hard to work with to get right. Any single pixel is only accounting for its very center as the place to trace from, so I can imagine we're dealing with a situation where pretty much any texel you see is representing an area way bigger than what it should.

Just so we're on the same page, when you turn off the denoiser, it becomes pretty apparent how much heavy lifting the denoiser was doing as each pixel is way larger than what one might think.

I recommend doing this for investigating the issue if you suspect the UV2 or Texel Size might be causing issues, as it makes it more obvious where exactly the pixel is being traced from.

How does it translate to light leaks

The reason I turned everything off is I wanted it to be very obvious where the pixel is tracing from. Godot's lightmapper will write a world position per each pixel being traced which is where it'll check against the light sources.

Panning from left to right, here's how one of the more obvious light leaks in the central room happens.

Here the amount of pixelation makes it fairly obvious where each pixel is being traced from.

The fact the modular mesh doesn't apply any kind of seam to the UV2 here means the effect of each pixel is amplified by a lot, and is likely to get messier the more the result is denoised as there's no binary mask for the lightmapper/denoiser to determine whether something is inside or not (although it'll try to avoid denoising harsh transitions).

There's no good solution here to the problem here: either you accept to get the interior's darkness leaked to the outside (like you can see in the screenshot) or the outside's brightness leaked to the interior. The lightmapper can't make the decision here by itself as you might want either of those results.

There's some spots where it's pretty evident it's picking the light from another pixel close by in the map. The normal of the surface is clearly facing away from the directional light, yet it's getting light from somewhere. This might just be down to a weird UV2 problem.

As a side note, when attempting to bake the original scene you posted, I don't really see the same result even after turning off these lights. Is there something else I'm missing here that you've modified to get that result with the leak? Or am I not looking at the same spot? It seems like your screenshot has worse UV2s than the one I'm testing on.

How we could address it

Seeing the chain of problems here makes it pretty evident as to why the light-mapper is generating a wrong result.

• Modular meshes that can overlap are the enemies of UV2 generation, since unless they implement some form of intersection detection, they'll just assume a surface is continuous. As nice as the end results might seem, game artists are no strangers to having to mess with UV2s manually to get better results or quality out of them. This is a fairly competitive area where there's even commercial plugins sold exclusively just to make good UV2s. Since we're not in the market of telling people to just deal with it as they expect an automatic result that works well, we'll just have to assume the UV2s can be problematic and move on. This is an area separate from the light-mapper itself that might need more work. I'm not clear on whether this imported mesh has retained the UV2s from its original file or is using the Godot-generated ones, which would be good info to have in hand.

• We have very few pixels to work with. The less pixels, the more the errors from not having a UV2 that respects the seams across modular meshes amplifies by orders of magnitude. This explains very well why you've seen the leaks significantly reduced the further the resolution increases. The first step of the Godot lightmapper is to rasterize these meshes using the UV2 into the lightmap of the target resolution. The world position and normal that are used as the origin of the process are stored in this step. Rather than comparing final MB sizes, I suggest taking a look at what actual pixel resolution we're dealing with when comparing the results to something like Unity, as it'd help give a better idea of what texel size difference we're working with.

• The lightmapper isn't considering the fact that one pixel is covering such a large area. It's only concerned about the world position the rasterizer on the previous step took. To make matters worse for indirect bounces, as an optimization measure to avoid tracing the lights again, it'll grab the result of the direct light traced in the first step at the pixel level, which further amplifies any erroneous leaks that might've happened.

I think the last point here is of particular interest. I'm not aware if other lightmappers often change their behavior to account for the fact the pixel represents a larger area than the very center of where it was mapped in the geometry. It might be an interesting countermeasure against the problems this scene presents.

That's pretty much all the info I can provide so far, but sadly no fixes yet as I haven't been able to identify anything that is straight up broken in how the lightmapper works. I can do an experiment of what I mentioned, but I suspect it could cause more problems than it fixes as it could increase the chances of leaks on non-modular meshes.

[DarioSamo]

As a side note, while the pixel density one is a problem, I'll attempt turning off the optimization I mentioned by making the bounces trace the light directly and see if that fixes anything, as that's one area of potential error propagation.

[jcostello]

As a side note, while the pixel density one is a problem, I'll attempt turning off the optimization I mentioned by making the bounces trace the light directly and see if that fixes anything, as that's one area of potential error propagation.

This creates problems? If so, improvements would be welcome, but what do you think to have a toggle option to bake without optimizations (to have precise results maybe?) ?

[DarioSamo]

Well I gave it an honest attempt at fixing the two problems I mentioned. Sadly it doesn't make any actual difference.

• It is possible to make the indirect bounces trace lights directly instead of referencing the direct light texture map. It makes the error propagation slightly less worse but doesn't come close to fixing the leaks at all.

• I came up with a method to grab the surface derivative of the world position and use it as a way to randomize the origin of the point being traced. Again, it doesn't make a difference: as much as I randomize the result around, either it extrapolates an ridiculously big derivative (due to the low texel resolution) to the point it makes it much worse, or it ends up again in one of those situations where half the samples remain inside the temple and the other half outside of it.

I'm skeptical this is the fault of the lightmapping algorithm itself at this point as I don't see any errors when it comes to how it's tracing it. An assumption has to be tested again when comparing to other lightmappers on how Godot's handling this: either the UV2 generation is too broken or the resolution is far too low for the lightmapper to do its job properly. It's hard to come up with a ground truth answer when a single pixel is supposed to represent both the inside and outside in this example with how it's mapped out.

I think my last point of suspicion is if the "Unocclude" step could be causing more harm than good. I've not really parsed what this step does yet but I have my doubts. Once I understand it further I'll see how it can possibly affect this scene.

[jcostello]

I think the scene has too many problems. I doesn't work well with any of the GI methods. I have minor leaks with a good texel resolution (I say good and not optimal because its fairly low).

Anyway, @DarioSamo your attempts are worth to push even if they don't fix the issue? Does improve the lightmapper in any way?

[DarioSamo]

I'm trying to investigate this further and put the directional light towards the problematic area and turned all the lights to static. I didn't realize all the lights were dynamic, which was making this way harder to debug.

Clearly the blocker here is working as intended. I think the results get a little more interesting when you add bounces to the mix (1 bounce, low ray quality, no denoising to make it even more evident).

Some light is somehow managing to get through when it should be hitting all the back-faces and end up with a black result.

This one I can't excuse with the scene being problematic so I'll be taking a look at how it's achieving that.

[DarioSamo]

I'll keep researching this tomorrow, but so far I've found that forcing the ray to be casted alongside the direction of the normal does not produce any indirect bounces as it should on that area. It's when introducing the randomness of the cosine weighted sampling it somehow manages to hit a surface and find light.

The problem here is trying to come up with a way to debug this, but that case I found is suspect enough to warrant more investigation, as it's pretty clear cut that it shouldn't be finding that light from the left side of the pillar as it's inside of the thick wall.

[clayjohn]

I'll keep researching this tomorrow, but so far I've found that forcing the ray to be casted alongside the direction of the normal does not produce any indirect bounces as it should on that area. It's when introducing the randomness of the cosine weighted sampling it somehow manages to hit a surface and find light.

The problem here is trying to come up with a way to debug this, but that case I found is suspect enough to warrant more investigation, as it's pretty clear cut that it shouldn't be finding that light from the left side of the pillar as it's inside of the thick wall.

Do we do any biasing? Perhaps we are accidentally self intersection, or alternatively, if the cosine weighting is wrong, we could be casting rays backwards through the surface and hitting surfaces behind the surface

[WickedInsignia]

Hi @DarioSamo , just going through all the latest comments but you may find this useful: https://ndotl.wordpress.com/2018/08/29/baking-artifact-free-lightmaps/

This is a breakdown from the maker of Bakery, which is remarkable for its mostly artifact-free baking. There might be some info in here that applies to the way Godot's mapper is tackling these issues.

[WickedInsignia]

Just to answer some questions from the most recent discussions:

I recommend doing this for investigating the issue if you suspect the UV2 or Texel Size might be causing issues, as it makes it more obvious where exactly the pixel is being traced from. I tested this at much higher resolutions and leaks persisted. I'll give this another look and compare it to other lightmappers at approximately the same texel density to be sure, but my experiences are generally that Godot just doesn't handle overlapping geometry very well. Bakery handles overlapping geo exceptionally well, so there might be some useful into in the doc I've attached above. It may even be productive to reach out to Mr Frank directly if you're unsure of something he's explaining there.

It's also worth noting that the UVs used in the default Temple file are not generated by Godot: they are the UV2 already unwrapped by Epic themselves using space conservative methods (smaller islands for less crucial areas of a mesh, such as those facing outwards). This has been useful for comparisons with other lightmappers, since it signifies that it doesn't come down to how Godot handles the UV2 unwrap. These will be overwritten if you use Static Lightmaps for illumination on import.

As a side note, when attempting to bake the original scene you posted, I don't really see the same result even after turning off these lights. Is there something else I'm missing here that you've modified to get that result with the leak? I believe that leak was being cause by light from the HDRI or bounce light from the landscape. You don't appear to have any bounces in those screenshots, so there's no light present to leak into that wall.

[DarioSamo]

Hi @DarioSamo , just going through all the latest comments but you may find this useful: https://ndotl.wordpress.com/2018/08/29/baking-artifact-free-lightmaps/

This is a breakdown from the maker of Bakery, which is remarkable for its mostly artifact-free baking. There might be some info in here that applies to the way Godot's mapper is tackling these issues.

Yeah, I've read this in the past and some of the lightmapper code references the techniques found in this post. Whether it implements them all correctly is something I should probably review though so it's handy to give it a fresh look. I was actually attempting some of the techniques that are pointed out there by applying surface derivatives and such but not to much success yet.

It's also worth noting that the UVs used in the default Temple file are not generated by Godot: they are the UV2 already unwrapped by Epic themselves using space conservative methods (smaller islands for less crucial areas of a mesh, such as those facing outwards). This has been useful for comparisons with other lightmappers, since it signifies that it doesn't come down to how Godot handles the UV2 unwrap.

That makes it easier to rule out Godot's own unwrapping for the time being then.

I believe that leak was being cause by light from the HDRI or bounce light from the landscape. You don't appear to have any bounces in those screenshots, so there's no light present to leak into that wall.

That's weird because I'm fairly sure I had bounces in that screenshot in particular. I can't seem to replicate the extreme leaks you showed in your screenshot at all (using my indirect bounces PR FWIW). Although I do see these leaks inside the thick wall, which are pretty suspect that something is going wrong.

At least we have a head start on one thing that is not working as it seemingly should, so I'll start from there and see where that leads us.

[WickedInsignia]

I took some time to compare Godot's baker as of @DarioSamo 's latest PR, Unity Progressive GPU and Bakery directly. The results were pretty enlightening, and paint a slightly different picture of Godot's baker than I initially expected.

Firstly here's the results, starting with all 3 bakers without denoise and with exposures matched. In all cases the end result was 7 512x512 lightmaps per bake, and only a limited section of the temple was baked (the middle room and this hallway). The same UV2 (the one unwrapped by Epic) is used in all bakes:

Godot:

Unity Progressive GPU:

Bakery:

And here's the results with denoising (Open Image Denoise for Progressive and Bakery):

Godot:

Unity Progressive GPU:

Bakery:

Apparently Godot doesn't actually hold up so badly in a more controlled test! Bakery performed the worst to my surprise leak-wise, but had the smoothest noise and best denoising. Unity's Progressive handled leaks the best, with almost no leaking in the hallway before and after denoising. Bright spots here seem to be due to a lack of sufficient UV padding for Unity to avoid leaks (this is somewhat of a known problem with Progressive). Godot's post-denoise results weren't incredible, with some lingering bright spots. This was at a strength of 0.1 though, so I'll have to fiddle with that to see what reaps the best results. Godot's denoising was better than Unity Progressive's, but it's worth pointing out that Gaussian Blurring was off in Unity's settings and would further smooth out the result. The high exposure will also have an effect on how noticeable lingering noise is.

I think what misled me before was that I was judging quality by lightmap filesize, rather than how many maps were created. Both Bakery (1.8MB) and Progressive (2.3MB) resulted in smaller files than Godot (5.5MB). Since lightmaps are usually a major memory concern in games that use them, we might need to look into automatic compression for lightmaps as the other two solutions have.

I also noticed something quite strange regarding the HDRI: Godot treats HDRI's a bit differently to the other bakers. While Bakery and Progressive both responded to the bright reflection off the sea below, Godot did not.

Here you can see a bright spot caused by the sun reflecting off the sea in the HDRI, Unity Progressive:

However this is not present in Godot:

Just thought this was interesting, I may need to drop a bug report for it later.

I'll keep testing with these scene as well, but will be a little preoccupied this weekend and will be taking it easy. For anyone else that wants to have a play around, here's the Godot project. You'll need to add your own lightmap node (optimally use Dario's latest PR from HERE): UnrealSunTemple_Diffuse.zip

Here's the skybox, attached separately to keep size down: SunTemple_Skybox.zip

And here's the FBX files for use in Unity. For reference, I used Unity 2019.4.31f1 in my tests. Remember to match the sun rotation to Godot's sun: UnrealSunTempleDiffuse_FBX.zip

[jcostello]

Here you can see a bright spot caused by the sun reflecting off the sea in the HDRI, Unity Progressive:

You mean that unity handles bounces from surfaces without roughness?

[WickedInsignia]

Here you can see a bright spot caused by the sun reflecting off the sea in the HDRI, Unity Progressive:

You mean that unity handles bounces from surfaces without roughness?

The HDR image that is used for the sky has the sea with the sun’s reflection baked onto it. This bright spot in the skybox is bright enough to cast a sharp light through the window and onto the ceiling, since raytracing/pathtracing treat a HDRI as a light source.

This shows up in Unity and Blender Cycles, but not in Godot.

[jcostello]

@DarioSamo where you using master to test this or the PR of indirect lighting?

[DarioSamo]

In one of those twists of fate, I started doubting everything due to the extremely weird behavior I was getting until I figured I should doubt if trace_ray() itself was working as intended.

I replaced the search in trace_ray() with a linear lookup (which predictably is horribly slow which means I had to cut out almost the entire level to test this). In combination with fixing the fact that the indirect bounces don't trace the lights directly (but rather rely on the texture that might have leaks due to UV2), the leaks are gone entirely in the section I was looking at which is inside the thick wall (ignore the bottom corner as that overlaps with the bottom floor and is tracing the environment).

The thing we're looking at is the left inside of the pillar, which should be incapable of receiving light due to being inside a thick wall.

Indirect Bounces PR

Indirect Bounces PR + Trace Lights on Bounce

Fixes a lot as expected as the UV mapping here causes a significant amount of light to leak inside the wall via the texture. Tracing the lights is way more expensive but produces a far more accurate result.

Indirect Bounces PR + Linear Lookup

This predictably doesn't look too different as it's getting a lot of leaks from tracing the wall next to it, which has leaks due to the texture being stretched.

Indirect Bounces PR + Trace Lights on Bounce + Linear Lookup

The combination of both finally achieves fixing the leaks so light is unable to reach it.

The fact trace_ray() can cause rays to be missed entirely was REALLY unexpected for me. I'll need to study how the lookup structure works and why it might be causing this issue. I can't promise a fix yet. This was really hard to track down and I can imagine it's been causing really unexpected issues elsewhere.

[Calinou]

Since lightmaps are usually a major memory concern in games that use them, we might need to look into automatic compression for lightmaps as the other two solutions have.

This is pending on VRAM compression for HDR textures to be sped up, as it's extremely slow right now (and is therefore not used by default).

Options to save lightmaps as LDR and/or grayscale could be added like in 3.x, but there hasn't been much support for them. When you bake indirect light only and don't have bright emissive materials, LDR can look pretty close to the actual HDR data. The same goes for grayscale if most of your lights and materials aren't highly saturated.

[DarioSamo]

I've been able to fix the trace_ray() behavior by allowing it to continue a few iterations further once it finds a hit. This should have very little performance impact.

That leaves the problem with indirect bounces tracing direct lights. I'm afraid that'll have to be an option as it can have a significant impact on tracing performance... but it is the most accurate option by far if you're dealing with messy UV2s and low resolution.

I'll likely update the indirect bounces PR with the fix for trace_ray() and make it optional to do what I just mentioned.

[DarioSamo]

I got a functional fix for trace_ray() not working (pretty quick thanks to @reduz) as well as an option to use light traces on bounces instead of the texture (which makes the bake take a lot longer as expected). Gonna PR those separately next week. Thanks for the help in debugging this as it was really to identify the tracing itself could actually be broken.

I expect we'll have more things to fix but this is a pretty good find so far.

[WickedInsignia]

I suspected something was wrong even after those tests yesterday and I’m glad you drilled down further to identify a core issue! Thanks for taking the time to investigate. It can be difficult to know something’s off but everything other than what you feel is obviously not working is blamed to be the cause. I understand the urge to entertain every possible scenario though and most of it was productive.

Hopefully with time we can increase the speed on the more accurate algorithm and get these map sizes down with a compression implementation.

[atirut-w]

Godot treats HDRI's a bit differently to the other bakers. While Bakery and Progressive both responded to the bright reflection off the sea below, Godot did not.

Yeah, it seems this is intended according to https://github.com/godotengine/godot-proposals/issues/5266#issuecomment-1634986142

[AttackButton]

Interesting, at 01:26, there is a big difference between u5 and u4 on the walls and especially on the base of the statue. Furthermore, in the u5 the light seems to be better distributed across the rest of the scene.

I would like to compare Godot's new rendering with this video in the future.

[WickedInsignia]

@AttackButton UE5 uses Lumen in that comparison, which is a realtime GI lighting model. Most comparisons here have been against UE4's temple since it utilizes baked lightmaps and reflection probes and represents a high-water-mark for last gen graphics standards that Godot could more realistically achieve. Godot's current and future realtime GI features cannot handle this scene nor stack up to last-gen standards, let alone even remotely approach Lumen's quality benchmark.

Godot doesn't have the manpower nor developer skill to approximate UE5. That's not intended to discredit the core team: UE5 is a cutting-edge engine with high hardware demands and millions to billions in funding. Comparisons between the engines would be functionally useless since UE5 utilizes graphics technology of a quality that Godot's current and upcoming methods cannot match.

I also provided a .blend of the scene as a ground-truth reference. If the aim is to compare against a lighting model that's as physically accurate as possible, a production-grade pathtracer such as Cycles represents the best candidate.

[reduz]

@WickedInsignia

Godot doesn't have the manpower nor developer skill to approximate UE5

Manpower is obviously true, but there are several extremely skilled developers contributing to Godot who disagree with that take, which could also be considered offensive from your part. As a warning, next time be more careful with your words.

In my view, investing in creating something like Lumen is a waste of time. Its extremely expensive both on GPU and disk (needs to save large compressable SDFs), and requires user interaction on the cards side to obtain proper lighting. The only reason Lumen exists is because the current generation of high end consoles (PS5 / XBSX) is terrible at raytracing.

With proper raytracing, there is simply no need for something like Lumen. Raytracing is more efficient than sphere tracing and you don't need cards to obtain lighting information. If you are aiming for PC, as most users use Nvidia, you have decent raytracing support already on the medium/high end. The next generation of consoles will also support raytracing properly.

So, given work on creating a higher quality GPU driven renderer will have to begin at some point (hopefully next year), it makes more sense to simply skip something like Lumen and go fully for raytracing.

[WickedInsignia]

Manpower is obviously true, but there are several extremely skilled developers contributing to Godot who disagree with that take, which could also be considered offensive from your part. As a warning, next time be more careful with your words.

Not a single feature in Godot's rendering pipeline (SSAO, SSIL, SSR, lightmapping, shadows, GI etc.) is capable of the quality seen in UE5, let alone UE4. I'm not being offensive: I'm stating facts based on experience. If you want to be offended by the fact that you simply do not have the manpower, skills and resources to stack up to the efforts of a multi-billion-dollar company, that has nothing to do with me and is entirely down to your own hubris.

You're not going to receive credit from me nor anyone else for something you haven't done but think you might be able to. I would rather be realistic about what can actually be done and have historically assisted in that. When Godot can handle the Temple, has a few high-fidelity AA/AAA titles released and rendering tech that directly competes with UE5, my statement would be untrue and justifiably considered to be offensive.

In my view, investing in creating something like Lumen is a waste of time. Its extremely expensive both on GPU and disk (needs to save large compressable SDFs), and requires user interaction on the cards side to obtain proper lighting. The only reason Lumen exists is because the current generation of high end consoles (PS5 / XBSX) is terrible at raytracing.

You've frequently touted the benefits of using non-RT GI solutions to promote SDFGI/HDDAGI so it sounds a little like you're slandering your own sauce here while missing the point of what Epic developed. RT is considerably non-performant and currently depends on hardware support to operate at a satisfying level. I don't know of any comprehensive RT solutions that run faster and with as much support as software Lumen. There's obvious value to Lumen beyond the fact that PS5/XBSX aren't great at RT. Your own GI solutions have always depended on proxy scenes and probes to be performant and supported. Having such an extreme view of Lumen overall isn't very well-founded considering the circumstances.

To keep this on-topic: none of this is to say that Godot should pursue a Lumen-style solution. Just to point out that Godot simply does not have lighting technology at the quality of what UE4 and UE5 have and reaching UE5's quality isn't resolved by a few "extremely skilled" developers. Being unrealistic about what's feasible with Godot doesn't do devs nor contributors any favors, which is why I responded to AttackButton.

[yosoyfreeman]

With proper raytracing, there is simply no need for something like Lumen. Raytracing is more efficient than sphere tracing and you don't need cards to obtain lighting information. If you are aiming for PC, as most users use Nvidia, you have decent raytracing support already on the medium/high end.

I would like to respectfully point out that there are no medium end GPU with Raytracing, in fact, a lot of "high end" does not support it either. Is extremely expensive technology for a niche of the population and even then, in most cases is not worth the performance drop. Lumen provides a solution to a real problem. Even if you have ray tracing capabilities, you often don't need the burden of processing thousands of rays per frame to achieve quality results neither want to limit your intended artistic vision to people with RayTracing GPU's.

I find Godot approach to GI a Good one. Is interesting, refreshing and i think it will be extremely useful. But i don't think is constructive to tell someone to be more careful with his words to proceed to describe Lumen, a battle tested tool that artist and developers alike find a golden piece of software, as "a waste of time that only exist because ps5/xbox are bad at raytracing" which are way harder words than WickedInsignia has said in here and also empirically untrue. The community does it's best to keep the conversation constructive and i don't think that kind of statements help.

In my humble opinion technology is shared knowledge. We create upon what others created before. We share and learn from each other. It does not need to be a battle.

[reduz]

@WickedInsignia

Not a single feature in Godot's rendering pipeline (SSAO, SSIL, SSR, lightmapping, shadows, GI etc.) is capable of the quality seen in UE5, let alone UE4.

This is not really true. For the low end even UE4 uses really outdated techniques like LPV which look much worse than what is supported by Godot. UE4 has a better lightmapper, though.

For the high end, again It's the high end. UE4 has nice shadows but they use SDFs which are, again, expensive on the storage side, require user effort to customize, etc.

I think the point many of you folks fail to understand is that Godot is not being made for the people with beefy GPUs who want the ultimate graphics quality, or for extracting the maximum performance out of game consoles, or for teams with artists and staff that can tweak settings to the detail to get the best possible visual quality.

Godot rendering code is meant to run in as much hardware as possible, and require the least tweaking and customization possible because its mostly used by small teams. It is not and has never been the intention to go the Unreal route, focusing on high end rendering and lots of artist interaction to obtain the best possible quality.

I do all my development on a Geforce 1650 because this is my baseline. I don't currently care about the beefier GPUs. This is going to change eventually, but only when the low end is satisfied and we make this work as best as possible.

RT is considerably non-performant and currently depends on hardware support to operate at a satisfying level. I don't know of any comprehensive RT solutions that run faster and with as much support as software Lumen.

If you go for path-tracing, then sure, but there are a lot of interesting techniques published that use it in lower end hardware (such as AMD GI, Kajiya, etc). That no game engines currently use it does not mean that they don't exist. Again, hardware support is not a problem. If you are aiming for high end PC today (or eventually next gen consoles).

There is no magical solution that looks great and runs in all hardware. UE5 Lumen runs like shit on low end GPUs or slow SDDs, UE4 LPV runs everywhere, but looks way worse than Godot GI.

[Jamsers]

I would like to respectfully point out that there are no medium end GPU with Raytracing

This is true and it does suck in the interim, but I think it's very safe to assume that "ray tracing" capability will be a common feature set for GPUs/chipsets in the future, even in the mid-low end for example. "RTX Cores" or whatever marketing speak they're called are actually just matrix accelerators, and they're going to continue to become more and more essential because they're required not just for shiny graphics in gaming but for running various ML loads locally on your devices. (can't run everything in the cloud, as much as they would like to) Even AMD is gonna have to figure it out eventually or risk sliding into absolute irrelevance.

So I agree that for supporting console/PC development, it's a far better use of time to jump straight to developing a GPU driven renderer.

I find Godot approach to GI a Good one. Is interesting, refreshing and i think it will be extremely useful.

You don't have to worry about Godot's DynamicGI (SDFGI/HDDAGI) being abandoned or anything like that. DynamicGI is poised to become a good default for mobile platforms, low end, and VR. My view of it is, once enough of its flaws are fixed, and once hardware has advanced enough that it can run even on mobile, that it'll replace lightmapping/reflection cubemaps as a baseline on platforms where there just isn't enough matrix acceleration capacity to do raytracing. So even in the future, don't expect DynamicGI to match Lumen level quality - a better way to think of it is as a more convenient "auto-magic" replacement for lightmapping/reflection cubemaps.

So you'll be subject to the same limitations that lightmapping/reflection cubemaps are subject to now:

• Coarse, low levels of detail
• No micro or even regular scale detail whatsoever
• Only static objects can contribute
• Dynamic objects can only receive but not affect lighting/reflections

But unlike lightmapping/reflection cubemaps, you have several improvements:

• No baking required
• No probe placement required
• Not limited to just static lights anymore (i.e. you can now have dynamic time of day)
• Reflections may still be low detail, but they're perfectly aligned now
• Capturing changes to static geometry at runtime only causes a hitch in rendering, as opposed to being straight up impossible (and there will probably be a way to make it asynchronous, meaning there might not even be a hitch at some point)

These improvements may seem small but they're quite significant. For example, how do you get physically plausible GI and reflections on mobile in a game like Genshin Impact? (big open world with dynamic time of day) The answer, currently, is, you don't. Lightmapping/reflection cubemaps is usually how you do it on mobile but it's out of the picture for Genshin Impact because the size of the map means you'd probably bake a terabyte worth of lightmap data. And even if you solved the storage problem, the time of day is dynamic so unless you pull a Borderlands 3 (where the sun position didn't move through time of day) lightmapping still wouldn't cut it.

DynamicGI would tackle these needs just fine.

[WickedInsignia]

This is not really true. For the low end even UE4 uses really outdated techniques like LPV which look much worse than what is supported by Godot. UE4 has a better lightmapper, though.

For the high end, again It's the high end. UE4 has nice shadows but they use SDFs which are, again, expensive on the storage side, require user effort to customize, etc.

Regardless of whether something is outdated or demanding, UE4 is extracting better visual quality than what Godot can push and earlier titles run perfectly well on even low-grade modern hardware these days, including VR and mobile. Regardless of however modern Godot's techniques are, they are implemented with less visual prowess than UE4's outdated techniques and don't represent a practical solution in the broader game landscape. For a lower-grade example, Unity's fidelity excels when pitted against Godot in all of its render pipelines and graphics featuresets while staying reasonably nimble. You yourself recently mentioned you're not an artist to defer criticism: take it from a AAA Art Director that Godot doesn't compare visually.

It'd also be worth noting that LPV saw little use because UE4's other solutions were extremely robust and allowed for pleasing lighting in large dynamic worlds during a generation when realtime GI was very new. There was little need to develop the technique and Godot was only just getting to grips with modern 3D at the time.

Godot rendering code is meant to run in as much hardware as possible, and require the least tweaking and customization possible because its mostly used by small teams. It is not and has never been the intention to go the Unreal route, focusing on high end rendering and lots of artist interaction to obtain the best possible quality.

That's entirely respectable but your messaging around Godot's purported capabilities and goals has been anything but consistent. Even back in 2016 you expressed that one of Godot's aims was to look better than Unreal, and that 3.0 was very close to that aim. More recent messaging has been just as unrealistic, with the underlying issue that you don't seem particularly aware of how Godot actually compares to the visual fidelity and practicality of other engines. When people experienced with these engines speak up with criticism, you're all too quick to impose that Godot is just as formidable. When the heat becomes too much you seem to shrink into the comfort of "Godot isn't trying to be Unreal/AAA."

I do all my development on a Geforce 1650 because this is my baseline. I don't currently care about the beefier GPUs. This is going to change eventually, but only when the low end is satisfied and we make this work as best as possible.

You've chosen an arbitrary point of low performance that doesn't reflect modern architecture (Around 4% of Steam users own a 1650 and to my knowledge compute architecture fundamentally changed from RTX2000 onwards) and do no comprehensive published bench-marking on new features. Any promises or impressions of performance are dubious at best, and when combined with Godot's lackluster profiling tools make it very difficult to gauge just how performant Godot actually is. This issue is echoed by devs I chat to that have assessed the engine. Aiming for the low-end is admirable but the way you've done it seems superficial and of little actual use to developers adopting the engine.

That no game engines currently use it does not mean that they don't exist.

Not saying they don't exist. They are not comprehensive and not as well-supported. Lumen is a AAA production-ready solution built into a robust engine that runs on console hardware and is currently used in titles (which says a LOT about a technique's validity and usability). I also understand these RT solutions aren't a problem for high-end hardware but your original contention was that Lumen is expensive in comparison.

It's perfectly fine and justifiable to be proud of what's been achieved with Godot, but its rendering does not stack up to Unity/Unreal and if you're committed to the goals you suppose you are, you'd stop raising hairs at anyone that makes the distinction. You seem to have responded purely to fire back at what are ultimately facts expressed by someone with experience. I oppose instilling unrealistic expectations on your userbase, which you have historically done and have been criticized for by contributors. My assertions towards Godot in this thread are in the spirit of mitigating that.

[reduz]

@WickedInsignia

Regardless of however modern Godot's techniques are, they are implemented with less visual prowess than UE4's outdated techniques and don't represent a practical solution in the broader game landscape.

This sentence really does not mean anything, to be honest. We can have a technical discussion of what works better than what, but this statement is subjective and unconstructive, with no actionables that could be inferred.

Even back in 2016 you expressed that one of Godot's aims was to look better than Unreal, and that 3.0 was very close to that aim.

This was 8 years ago and both Godot and Unreal were very different technologies at the time. Just so you understand better this part, Godot development is driven by demand from the current community first.

The current community consists of small developers (with some medium sized studios as of more recently) working with smaller budgets and experienced staff, that aim to publish games that run on a wide variety of the hardware available. As such, the currently priorities is to create rendering technologies that respond to these needs.

Not saying they don't exist. They are not comprehensive and not as well-supported. Lumen is a AAA production-ready solution built into a robust engine that runs on console hardware.

Sure, but as I stated above, our goals are not AAA, and Lumen does not serve the purpose of being hassle-free nor useful for targeting a wide range of hardware.

It's perfectly fine and justifiable to be proud of what's been achieved with Godot, but its rendering does not stack up to Unity/Unreal.

It's not the intention to stack up to Unreal. Regarding Unity, that's a different matter you are just bringing up and I won't go on tangents since it was not related to your original point.

I oppose instilling unrealistic expectations on your userbase, which you have historically done and have been criticized for by contributors.

I think the one who has expectations that do not match with reality is you, otherwise I would not have to explain these things.

[aaronfranke]

You've chosen an arbitrary point of low performance that doesn't reflect modern architecture (Around 4% of Steam users own a 1650 and to my knowledge compute architecture fundamentally changed from RTX2000 onwards)

That doesn't make sense to me. The market share of that exact model of card doesn't matter, there are lots of cards with a similar performance level, including higher-end cards from older generations. The architecture changing in newer gens is irrelevant because a huge amount of users don't have the latest cards and many people choose to not use Nvidia cards. Godot's rendering needs to work on a wide range of devices. Juan's GPU is a mid-range card with medium age. Hating on Juan's perfectly reasonable choice of GPU makes no sense to me.

[reduz]

Folks I very much understand there are many of you that really wish Godot could support the highest end graphics and look amazing and I am among those, but unfortunately there are a lot of things that have to be fixed before this can take place.

While I don't really work much on rendering (other than I will be doing improvements to HDDAGI to fix the shortcomings it has and improve the quality after its merged), there is now an amazingly skilled and dedicated rendering team doing a lot of work to improve Godot on the rendering side.

The problem is that, currently, the main focus is improve performance and loading times, reducing stutter, improving shader compilation times, improving the mobile renderer, getting the engine to run properly on Apple devices, etc, as well as implementing more basic features that are needed.

All these are real world issues that are much more urgent than focusing on improving the current rendering algorithms, which are quite good for the hardware targeted.

Once all this happens (I hope during this year) it will be much more feasible to work on higher end rendering features. I hope you understand right now there are more pressing things that have to be solved.

[AThousandShips]

I think that's the important takeaway about the difference between Godot and these engines, in regards to our resources and potential: They have the resources to work on a lot more individual things and areas that we simply do not have, these are enormously complex areas that require a lot of experience and expertise both on the contributor and the reviewer side, we have to prioritise what to do first, and there the stability and range of support wins out, not to mention that some things would need to be stabilised and improved to be able to move forward to higher quality

[AttackButton]

Sure, but as I stated above, our goals are not AAA

I've made this proposal before. Why not ask the public what they want from the engine? Would they like Godot to be capable of making AAA games? It's definitely something I would like. This "ease of use" thing has been achieved a long time ago; Godot's editor and workflow are at their peak, but the rest is missing.

[reduz]

@AttackButton Letting aside that AAA has not much to do with graphics and is related to games which hundreds of millions in investment, which I can assure you the vast majority of the Godot community does not possess :sweat: . It's not so much about about what users want, since I think pretty much anyone would be happy with support for high end graphics, but about having something that users can use to currently make commercially viable games.

In the market, games with high budget graphics that push the envelope don't only require an engine but large dedicated teams to create the content. Games from smaller/independent studios very rarely (if ever) go this route because its too expensive, hence they focus more on interesting gameplay and/or graphics that look beautiful without having to push the envelope hard, and that it runs in as much hardware as possible.

[AttackButton]

My mistake, I intended to ask whether the public would prefer to focus on a more powerful rendering rather than on one that is optimized to run on the widest range of hardware possible.

[WickedInsignia]

This sentence really does not mean anything, to be honest. We can have a technical discussion of what works better than what, but this statement is subjective and unconstructive, with no actionables that could be inferred.

That's convenient considering you've made many arbitrary quality comparisons between Godot and Unreal yourself with little foundation. Actionables and quality comparisons have been made endlessly by me, many in this very thread. Visual fidelity isn't subjective and I've provided ground-truth comparisons where necessary.

This was 8 years ago and both Godot and Unreal were very different technologies at the time. Just so you understand better this part, Godot development is driven by demand from the current community first.

The current community consists of small developers (with some medium sized studios as of more recently) working with smaller budgets and experienced staff, that aim to publish games that run on a wide variety of the hardware available. As such, the currently priorities is to create rendering technologies that respond to these needs.

That's distinct from what I was highlighting there, which is your inability to properly judge Godot's capabilities in comparison to other engines and your tendency to make unrealistic promises or comparisons. Godot 3.0 wasn't even remotely close to UE4's fidelity and that's far from the only example.

Sure, but as I stated above, our goals are not AAA, and Lumen does not serve the purpose of being hassle-free nor useful for targeting a wide range of hardware.

I was responding to your comparisons with RT and overall downplaying of Lumen. Godot's goals being distinct from that isn't the point. Regardless you've been bouncing between "Godot does X technique better than UE4" and "Sorry Godot doesn't look close to Unreal" whenever it's beneficial to you.

It's not the intention to stack up to Unreal. Regarding Unity, that's a different matter you are just bringing up and I won't go on tangents since it was not related to your original point.

You've made comparisons with Unreal/Unity throughout Godot's history and seem indignant that someone believed Godot doesn't compare positively to them. Unity isn't a whole different tangent, it's another similar point of comparison you've made frequently in the past.

There is a lot of dog-piling here for simply clarifying something to another contributor. You're framing my responses to argue a completely different point or simply moving the goalposts where it's convenient. You don't seem to want constructive criticism: you want me to be wrong. No one who's looking to be constructive does what you're doing here, and considering our history it's clear to myself and others that you're simply here to patronize.

[WickedInsignia]

That doesn't make sense to me. The market share of that exact model of card doesn't matter, there are lots of cards with a similar performance level, including higher-end cards from older generations. The architecture changing in newer gens is irrelevant because a huge amount of users don't have the latest cards and many people choose to not use Nvidia cards. Godot's rendering needs to work on a wide range of devices. Juan's GPU is a mid-range card with medium age. Hating on Juan's perfectly reasonable choice of GPU makes no sense to me.

I was arguing for a wide test-bed of hardware configurations and architectures rather than favoring a single arbitrary point of low-performance. The architecture in newer gen cards very much does matter, since a sizeable chunk of market share still belongs to these cards and GPUs aren't simply a gradually increasing scale of performance. Not to mention that recent technology is important to in-development features that will be used by developers 2-4 years down the road. Juan's choice is arbitrary and singular, not seemingly informed by industry practice, the most-used case (over 20% of users play games on a specific series of integrated cards), the most common architecture, the power most users or console owners have available, or considering the wide net of possible configurations.

I think that's the important takeaway about the difference between Godot and these engines, in regards to our resources and potential:

I seem to have piqued some insecurities with the idea that the skill doesn’t exist within Godot to develop certain solutions. The resources are an important consideration but Epic employs and can afford some of the best engine devs and management in the world. Resources help but the people on their rendering teams are already exceptionally skilled and experienced. Few to none of Godot’s dev team comes from an especially rigorous background or extensive AAA experience. Most people on the rendering side are graduates or hobbyists.

That’s perfectly fine and I’m not trying to put anyone down, but it’s entirely unrealistic to expect UE5-level results from the available skill and amount of accumulated expertise regardless of resource. It’s evident that even core team members realize that and have sought out collaborations to help close that gap. I’m not going to claim I’m James Cameron because I think I could make a film as good as him given the same resources, and I don’t think it does anyone any favors to pretend that the game engine equivalent will happen here. No one on Godot’s team is going to pull AAA cutting-edge magic out of nowhere.

Unfortunately more often than not I've seen formidable talent chased away (such as the dev behind Godot Phyiscs, or the dev that implemented the 4.0 tonemapper). I've even tried to get engine devs I know involved but they refuse specifically because of Juan's attitude and lack of direction. When devs of that caliber aren't actively being chased away, you're more than justified to claim that skill is present.

Folks I very much understand there are many of you that really wish Godot could support the highest end graphics and look amazing and I am among those, but unfortunately there are a lot of things that have to be fixed before this can take place.

That's not what anyone is arguing against here. I pointed out that Godot can't realistically do this and you lurched in here to downplay anything that looked better than Godot and supposing that Godot's solutions are simply superior or more modern, then shifted gears to Godot being less capable when it suited you. You created your own discourse and now you're diffusing yourself. Nothing of value was provided here, unless your goal was to argue with me on points you just agreed with.

[reduz]

@WickedInsignia

Visual fidelity isn't subjective and I've provided ground-truth comparisons where necessary.

But that's the problem in the end, is it not? To you visual fidelity is a "looks good or bad" comparison. To me that is a really obtuse way to see reality. When considering visual fidelity, there are a lot of dimensions you have to take into account:

• How flexible it is (how dynamic, environment size, does it work for indoors?, etc.).
• How complete it is (GI or just radiance?)
• How much effort it takes to achieve.
• In which type of hardware does it run.
• How much resources it takes.

Every time I discussed visual fidelity in the past years or compared with other engines, I did using these metrics, never a "looks better / worse than". You seem to imply that somehow I said something like "Oh, Godot looks better than Unreal and Unity", while that never was the case. I lost count of the times I said that Lumen style solutions or raytrace-based GI will always look better than what Godot offers, but that most of our community prefers whatever we implement runs on low end hardware as priority. The fact you are referencing something that is 8 years old to prove a point kind of supports this on my side.

Maybe you never had to care about the technical side of a game (or never worked in a small team), but Godot community does, and for them ease of use and compatibility is far more important that ultimate visual fidelity.

I pointed out that Godot can't realistically do this and you lurched in here to downplay anything that looked better than Godot and supposing that Godot's solutions are simply superior or more modern, then shifted gears to Godot being less capable when it suited you.

Again, the only one who has unrealistic expectations and that compares things in terms of single "better or worse" dimension is you. I always stated what my goals were.

Unfortunately more often than not I've seen formidable talent chased away

Honestly you don't know the circumstances of specific people because they are not public and involve facts you are not aware of, so as a warning, any accusation here of me chasing away talent I will not take lightly.

[WickedInsignia]

But that's the problem in the end, is it not? To you visual fidelity is a "looks good or bad" comparison.

I used "good or bad" as a shorthand for universally established concepts of visual fidelity. For clarification, by "good" I mean accurate, and by accurate I mean a pathtracer or the way light behaves in the physical world. I'm not referring to anything arbitrary or stylistic.

You seem to imply that somehow I said something like "Oh, Godot looks better than Unreal and Unity"

"UE4 uses really outdated techniques like LPV which look much worse than what is supported by Godot," as one example.

Maybe you never had to care about the technical side of a game (or never worked in a small team), but Godot community does, and for them ease of use and compatibility is far more important that ultimate visual fidelity.

I work as an Art Director on AAA games managing teams of artists as my day job. I've also worked as a lead on television content and as an artist in everything from blockbuster film design studios to small independent animation studios. It's safe to say I'm not talking from inexperience.

Again, the only one who has unrealistic expectations and that compares things in terms of single "better or worse" dimension is you. I always stated what my goals were.

You're saying that but nothing here addresses the inconsistencies I've highlighted. Even your most recent post on engines made with 3rd party dependencies sets up incorrect expectations. There are many 2D & 3D engines that are FOSS, in-house or proprietary and successfully use 3rd party dependencies, some mentioned by people commenting on that post.

One does not need to go looking very far to find inconsistencies in your public output surrounding Godot.

Honestly you don't know the circumstances of specific people because they are not public

I am talking about what has either been said publicly on Github or elsewhere, or expressed to me in confidence. Some individuals have very (1) openly (2), check the highlighted comment) voiced (3) their discontent (4). I don't need to exercise guesswork: people I know directly have been chased away and expressed why in detail. Artists/devs who work in the industry are also generally well-connected, and what's said about the state of Godot either publicly or in confidence between professionals may surprise (or more aptly, should concern) you.

[reduz]

I used "good or bad" as a shorthand for universally established concepts of visual fidelity. For clarification, by "good" I mean accurate, and by accurate I mean a pathtracer or the way light behaves in the physical world. I'm not referring to anything arbitrary or stylistic.

Well, I know, and I made my point about this, so giving up.

"UE4 uses really outdated techniques like LPV which look much worse than what is supported by Godot," as one paraphrased example.

Yes, LPV by far is objectively worse than anything supported by Godot. In fact, very few AAA games made in Unreal to my knowledge used it (if any) and instead either rolled their own solutions or (if not open world) used lightmaps. Epic took until UE5 to add a more modern GI to the engine.

I work as an Art Director on AAA games managing teams of artists as my day job. I've also worked as a lead on television content and as an artist in everything from blockbuster film design studios to small independent animation studios. It's safe to say I'm not talking from inexperience.

This makes it clearer to me where your point of view comes from, so thanks for clarifying this. As I said before, this is not the kind environment Godot is currently aimed at. The reality of smaller studios is very different than the one of AAA ones, and so are the staff technical skillsets.

One does not need to go looking very far to find inconsistencies in your public output surrounding Godot.

TBH there are no inconsistencies, only misunderstandings (and in large part my inability to express properly). I am not a native English speaker either, so I guess if you follow what I write more closely you will notice I have not changed positions much over the years.

I am talking about what has either been said publicly on Github or elsewhere, or expressed to me in confidence.

Well, most of those are not really people who contributed and, on the contribution side, you will see very few FOSS projects close to successful as Godot (over 2k contributors and the amount of pull requests is crazy). Not entirely my merit of course, I am far from the only person who helped shape it as it is today, but IMO I think its a bit ridiculous to argue that the way things are currently done chase away people. It's more the fact that you can never get 100% of potential contributors to adapt to any given development model due to differences. In fact, I am not even in charge of rendering anymore since some years either.