godotengine
Unreal Sun Temple Reference Scene
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.
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?
@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.
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)
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?
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.
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.
@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:
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.
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)
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.
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.
@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.
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.
https://user-images.githubusercontent.com/64601424/228833812-8a8d4554-9fa0-44f7-a8ab-b174752e0611.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.
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.
This is becoming patronising and I kindly ask you to please give it a rest.
Sure! I already explained what it needed to.
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!
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.
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.
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.
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 :)
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.
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!
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.
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.
https://user-images.githubusercontent.com/3144113/229200289-fae4b78e-e29c-4722-8a23-f8ff733626ac.mp4
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
Here's a video following a similar path backwards.
https://user-images.githubusercontent.com/3144113/229206420-ad46601f-5544-400d-8a6e-6e96331fe2b3.mp4
Here are a couple comparison shots:
Oh, so there's already a camera animation in that scene? :D Maybe there's no need to do another one, though maybe a slower flyby could work better for exposing SDFGI artifacts.
I added the camera animation with an AnimationPlayer in Godot and exported with the new movie mode. In Unreal I added a cinematic with Sequencer and render the animation using that. It wasn't built into the scene.
Godot does a really decent job. How ever, under capture better the shadows and reflection. Shadows are something that could be improved in the lightmapper