Links gamefromscratch.com/godot-new-global-illumination-system-hddagi/ ----------------------------------------------------------------------------------------------------------- *Support* : www.patreon.com/gamefromscratch *GameDev News* : gamefromscratch.com *GameDev Tutorials* : devga.me *Discord* : discord.com/invite/R7tUVbD *Twitter* : twitter.com/gamefromscratch ----------------------------------------------------------------------------------------------------------- The assets used in this video are available in this Humble Bundle (ends Friday, Dec 15th!): www.humblebundle.com/software/best-synty-game-dev-assets-remix-encore-software?partner=gamefromscratch
To clarify, HDDAGI is meant to resolve SDFGI's flaws (such as stutter on fast camera movement) by superseding it with a more efficient approach. This means there won't be 4 GI solutions in parallel in Godot: we'll go from SDFGI/VoxelGI/LightmapGI to DynamicGI/VoxelGI/LightmapGI.
sdfgi has significant performance issues when moving the camera (cascade stuttering). the biggest performance difference will never come from still shots, just keep this in mind with future testing going forward.
On top of that, the areas that are supposed to be pitch black in sdfgi stops being so if you move far away enough. I hope this new system will solve that issue as well.
The staircase to the right of the wall you showed around 6:48 explains everything, especially down the left wall. It makes absolutely no sense for a yellowish light to fall on that wall in the game. Thank you both.
In my opinion, Godot is really close to become the absolute no-nonsense engine for indie developers. It offers complete freedom, lightness and intuitive conventions (most of the time). But they need to fix issues like these quickly now, since the release of 4.0 it has gotten attention. Thankfully, the Godot team seems to understand what needs to be done.
didnt show at first, but the new solution looks alot better, plus the performance while orbiting around in the scene is slightly more smooth than before, looks good honestly
@@addmixswitched to linux, some files got corrupted, fixed the corruptions. waiting until I get the energy back so I can redo audio files and make a new map. so going pretty well, how about you?
@@whoeverofhowevermanyYou're not wrong, haha. But I think it's telling how psyche modifies perspective like a lens over an image. In this case, bend the top of the H inward and form an A. Then HDDAGI becomes ADDAGI which is not too far from ADAGIO. Human brains look for patterns / symbols / representations they already know instead of reanalyzing things objectively because this is often a faster method to produce results... But it is messy and gets out of control very quickly. This doesn't feel dissimilar to how LLM's hallucinate TBH.
Compared to SDFGI, HDAGI actually looks usable and “good enough” for a professional project. The light bleed just made the old system very ugly. Simply not having light bleed makes this look very usable. Maybe not UE5 levels of global illumination. But I would be curious how this system performs compared to UE5 Lumen.
Not even close to Lumen but it's also not developed for that purpose. Lumen equivalent or closer for higher quality GI is planned for later next year (or later if it gets pushed due to some other issues ;)). Right now this is meant as a GI which should work with killing performance on a wide variety of HW producing decent results (it uses sort of a voxel approach it seems from the github discussion) while Lumen is meant for high end for most. It will take some time but hopefully it will resolve the major issues the SDFGI had.
@@user-mc4rr9fe6y I don't think it is (?). It does use SDF as part of the process, the screenspace GI I think is separate you can choose lumen or the screenspace GI though they might also use screen space for stuff in lumen too, it's a hybdrid of different techniques from ray tracing, SD and ??? depending on what your HW supports and what doesn't and such.
@yourmajesty9025 I like it :). It's not something you can build your game around if you target wider audience but it's really nice when you can have it so you go the usual route with lightmaps and higher settings with Lumen.
To me the biggest weakness of SDFGI is its inability to handle dynamic light occluders in the GI properly. This apparently still doesn't solve that. (I see that in the pull request Juan has put 'Dynamic Object Support' as a planned future feature, but considering he said the same thing about SDFGI and now that algorithm is just being fully abandoned, I'm not exactly overwhelmed with confidence that it'll ever happen with HDDAGI.)
In fairness to Juan, SDFGI only came in Godot 4.0. Because this seems to be better in most ways, there's little reason to go back and implement dynamic light occluders in SDFGI.
7:13 As far as I know bias is a technique in raytracing where the renderer prioritizes pixels which require more iterations to achieve a low noise level. Basically using more processing time where it makes the biggest difference for quality. I don't know enough about global illumination in games to say for sure if this is it though.
What I really need is for Godot's 3D performance to be at least comparable to Unity. It's okay for Desktop PC, but on anything weaker the differences in performance become extremely noticeable. Even a simple scene can crank out the Steam Deck's power usage to over 20 Watts. I'm not sure why this disparity exists, but right now making a standalone VR game for example, is practically impossible.
Because Godot is built by a bunch of hobby devs getting paid by donation money who have never worked on any actual games. Check their history, the biggest games Godot devs have ever worked on were very small games. Which is why Godot is great for small games... but absolute crap for anything else. It isn't just the renderer that is subpar, it is the whole Godot structure.
@@lillybytewell, the source code is right there for you to improve with your evidently superior skills in the case you allow yourself to deal with mere mortals.
I mean I agree with LillyByte here although it's a bit harsh, like there's a reason it's not even brought up as comparison when discussing gamedev for larger MMO games, sponsored social/gacha mobile games, or anything where you'd want to collaborate on one project with over like 60 people. Sure, Godot might eventually get there thanks to people contributing, but the truth is that currently it's subpar for anything outside of indie and startup-studio game development. You have to retrain/hire all engineers for a new language and yet only get an equal or worse result currently. Similar reasons to why Blender is rarely used for big-budget movies (only experimental vfx studios seem to use it, and only for personally or crowd-funded films usually), and Krita is never used for drawing professionally.
I could see the difference immediately. It's what we call more "idealized" lighting, there's gradial separation inside regions that need the Detail in them brought out ... like how the "painterly" style contrast is thrown around but this achieves it with hierarchical _Maths_
I'm happy to see the devs/Juan focus on lower end hardware instead of just flair (and thus higher end hardware), whilst still allowing for flair as much as possible. Don't get me wrong Godot 4 can look gorgeous, but I don't think it should ever try to compete with an heavy hitter like UE for example. I can run a complex game (Disinfection and some other projects) on 10 year old hardware with good frames, whilst also being able to crank up things a lot on higher end hardware on the fly. It's so flexible and I love it.
Reduz (Godot dev leading this new GI) said in the PR that it might actually get into 4.3 if he gets constant feedback and some support. They have it tagged 4.x because he can't promise it'll be in 4.3, but if everything goes well it should be.
I'm doing a VR art project and I choose unreal cause the quality of lighting is really important in my case. But I keep my eyes open on godot, cause I hope some time I can switch to godot cause deep down I love godot more.
all of Godot's global illumination features don't work: VoxelGI - no shadows SDFGI - huge light leaking between cascades (past ~8 meters) lightmap - tons of glitches I'm skeptical this one will work..
You need to understand concept of "trade-off": en.wikipedia.org/wiki/Trade-off Only global illumination system that renders image correctly is unbiased path tracing with enough number of rays, and that is very slow. So there is also trade-off. Understand that these are tools, you need choose right tool to right situation, use them correctly and tweak your scene.
@@gruntaxeman3740 His point was that these tools are NEVER the right tool. They have fundamental flaws that would wreak havoc on any art direction and pose a constant distracting for the player. So in the end all you can do well in Godot is write your own lighting solution or settle for bad 2000s lighting. You cannot look at the flaws he explained and handwave them as "tradeoffs". There's nothing to trade here, these are just dealbreakers full stop.
Seems like a speako at 1:07. I believe Mike meant Godot 4.3, not Godot 5.3. (Though it would be awesome if he was making predictions a whole version out, haha)
The framerate looked the same on both solutions. It would need a less cluttered scene for a more precise comparison. But overall they appear to have the same results in general.
The author of the video showed an interesting pattern that occurs in stable versions of Godot - if you increase the load, the FPS will drop, but if you return the values back, the performance (FPS) will not change. Why is this happening?
I would prefer that existing GI solution for Godot actually work instead of a new one, like Lightmap GI that is unusable right now due bugs on probe system.
Lightmap got a number of fixes in 4.2 so there's hope, I actually am not even sure if all of them made it into 4.2 because at some point there were talks about some getting pushed into 4.3 but I don't know for sure how it worked out.
ปีที่แล้ว
Well... The LightmapProbes are still 100% broken on 4.2... This is bad because we get good GI on static objects but on moving objects the illumination flashes so much that hurt the eyes
Your asset link is the same as the HDDA Development Branch link on your page. Please fix. I see you have the link above in the Description... So I was able to get it.
This honestly just reeks of project mismanagement. Was SDFGI just stuffed in to sell people on 4.0? Thats a profoundly cynical and inefficient approach to open source defelopment. I want Godot to succeed, because the games industry desperately needs more things that aren't controlled by giant companies, but everything I've seen since I started following it suggests it's not being managed by someone who knows what they want it to be. This is the second bit of lighting tinkering they've spent time on, meanwhile the engine is still a chore to get assets into and work with them (especially 3D assets that are complex and likely to change), some workflows like themes are still a mess, and the 3D tools haven't seen enough meaningful updates to move Godot beyond "you can do 3D if you want to, but this is a 2D engine". I'm generally a "get what you give" guy when it comes to open source devs, and thus give them slack in regards to clapping back at people who come in with entitled demands, but the lead dev seems fond of dismissing constructive criticism like some one has insulted him and I've seen him insist that no one is controling the direction of Godot which honestly makes me scared for its future.
Agree. The biggest problem I see in Godot is lack of vision. I'm much more excited about Bevy in the long run for that reason alone - even though it lacks many features and is still in development, it has a 'benevolent dictator' (cart) who decides the direction and has some clear goals for the engine and its features - e.g. whether you agree with that or not, they will never have a core-supported scripting language (though it'd be possible with plugins). The engine has strong momentum as well and is seeing increased number of contributors
Godot and its community isn't really built off of people solely controlling the direction of Godot. Its contributors and users do. HDDAGI was discovered to be a better version of SDFGI that not only looked better but performs better in tests, so it only makes sense (to me at least) that SDFGI was replaced by HDDAGI. I haven't experienced many workflow bugs or hinderances, only one comes to mind. All my assets are easy to import, and with stuff like the Unidot importer now in the asset store(?) It was easy for me to import unity assets as well. I was literally just able to open a unity project, take what I wanted and export it as a Unitypackage, and it imported perfectly. If you have issues PLEASE submit them as a bug, or if you have suggestions submit those as well! As I said, the People decide the direction of Godot. We have project roadmaps for 4.3 and beyond.
Godot 4.2 just released and they already have a 4.3 build? W/E, I do hope they make this GI feature usuable in a real game. It seems to be ok for low res generation. I generally find Godot's 3D lighting kind of crap, with the diffuse having banded colors.
Did you think they'd work on new features in 4/2 when it's already released or what? Yeah obviously they're starting the 4.3 build now that 4.2 is done
@@TurtleKwitty I think they should be perfecting 4.2, before even thinking of 4.3. The .# is usually additional small features. and the .#.# is the bug fixing; but it can be w/e you imagine I guess. It was just surprising they already had a new build already available to download. It's not a big deal. I pretty much have given up on game dev.
@@rremnar 4.2.x and 4.3 (currently just master) are separate branches, but yeah, not a lot is going on for 4.2.x. this new build is not The 4.3 btw, just particular commit of its branch, and not in upstream
Very nice breakdown. I've added a comment on the PR as well showing my findings on a simple scene. Anyone have any idea what's causing the light bleed? On interiors its pretty bad. I think if the light bleeding can get fully under control, this is a super impressive and widely applicable GI algorithm.
@happygofishing hopefully not and if it does then godot developers can fix it since they are mostly in control how rendering & compute pipelines are compiled.
I don't know what to think about it. In one hand I trully belive that the project leaders have a vision and there's a reason why they do what they do. In other hand I'm under the impression that they start/restart too many things at the same time, and before the functionality is polished, they throw it out and start a whole new solution for the same problem. Like having sdfgi and voxelgi, and none being optimal. On top of that they throw out the bullet physics to implement their own, just to throw it out again, and then just to embrace Jolt. Don't get me wrong, I Hope hddagi is as awesome as it sounds, I'm just worried in general. As I said, they may have a reason. I love Godot and would like to see it growing. Cheers
This is actually is a result of fixes for SDFGI. SDFGI turned out to have some unfixable issues thus the search to replace these parts with something different and this lead to a different technique altogether - right now it still uses parts of SDFGI though that will change in upcoming days/weeks/months as the development progresses. I don't think even the devs were that happy but when you hit a static roadblock sometimes you just have to go back and take a different turn ;).
SDFGI and voxels are intended for different scenarios. One isn't a replacement for the other. It's better to think as Godot having one solution for open environments and one for closed environments and they're improving the one for open environments
@@padre_putativo_suscriptor Actually I strongly disagree: A custom solution isn't always superior than something that is proven to work by for example the industry. You don't have to reinvent the wheel every time you do something. There is a reason that you for example don't write a custom game/ physics engine when you want to make game but rely on a premade engine. Sure, if you or your company have the resources to deal with a custom solution and everything that comes with it, go ahead. But custom solutions always come with the problem of not only creating and implementing them, but also maintaining and supporting them. This is the exact problem we are seeing with Godot Physics: The person who made it jumped ship and now works on something else, while what they left over with Godot Physics is a broken and bad performing mess. Had they just used a premade physics engine like Jolt, they wouldn't have to worry about maintaining the physics engine itself, but just about it working in the engine. Also: What do you mean by "Everything is logical, not random and disorganized like Unity tends to be.". Never has the Godot team published a roadmap of how they are going to proceed with developing the renderer (or their physics engine, or GDScript). Sure Juan is sharing some progress on his twitter and there are some blog posts from time to time, but all of this is following no clear direction and path to finally getting the renderer up to par with Unity or Unreal (I mean not feature wise, but "it just works" and quality wise).
I just wanted to thank you guys for the replies. I think this is quite a broad topic to elucidate in a comment section on TH-cam but i appreciate the effort. I've even learned something new today. Hahah Anyways, I think i didn't express myself correctly when I compared voxelgi and sdfgi. But the core of what I wanted to say is that, some times I just have the impression that things are abandoned before completion successively. This puts me off a little, but as an expectator I can only trust and hope for the best. Thanks again, cheers!
1:10 A Godot 5.3 feature? You have been doing some slips of the tongue lately. Are you well? I imagine you might be overworked with how on point you game development related news are
If only Blender and godot devs worked together and decided to implement Godot renderer into Blender to replace eevee. Now eevee is fine for what it is, but it chokes on heavier scenes, textures and light bleed is still awful. And it detracts resources from improving things like texture painting, baking, multires performance, sculpt layers, refining new hair system. Well it's not going to happen. I know.
So, instead of releasing deferred rendering, they're reinventing the wheel as they did with GDScript (Python clone), custom physics engine, occlusion culling system (which was thrown out just to be rewritten again)? F*ck this shit.
gdscripts is totally different language. it doesn't have garbage collector which is important in scripting language for games, also it is better integrated with godot than python would ever be. only thing that is simular is the syntax. modifying python to work as well as gdscripts would've taken more work than creating gdscript.
Is this really community driven, cause I always see that Reduz guy doing things on his own, prolly the reason why the engine is not good for 3D in comparison. Don't keep up with things godot, so maybe I'm wrong with the assumptions.
I'll give you the two sides: In his defence: It's pretty hard to get experienced graphics programmers that work on this type of stuff, because not only they are few, but also very coveted by big studios. Hard to convince one to work for free or an inferior salary in a open source engine. Like the guy or not, the project dependents on him On the other side: You are kinda right, the guy is known for being resilient to feedback, so the few times some experts tried to help, they first had to spend a lot time convincing him. Some prevailed and the engine got better for it, the other's not
That's the case with the vast majority of free open source software, it's not uncommon for popular open source software to be run by a single guy. There are more people than just Reduz but he is by far the one doing most of the work, usually other people just add small things to it, or small fixes. Even blender is like this, the blender foundation does all the job, the community barely adds to it and when they do they often charge for it, you go to the blender marketplace and you will see people charging for addons under the GPL (General Public License) and acting as if they own all the rights to it, I expect it to be even worse with godot when a official paid store is open because the license actually allows people to charge for it.
Everything these core guys do they first discuss with other core developers. Clay John is the leader of that graphics team so it's up to him to decide. Further global illumination improvements have been planned sice the release of 4.0 and it's not like there are dozens of people with graphics expertise lining up to work on this project so it's the area in which reduz has the most knowledge.
I'm sorry but the entire godot's rendering system needs a complete overhaul. Godot also needs engineers who really know about rendering. There's something off with how godot renders. Compared to other open source engines like stride or flax, godot's rendering system is just inferior.
I’m honestly curious what’s wrong with it. I’m weighing it as an option. The 3d doesn’t need to be perfect. But “good enough” would be good, especially with all the other benefits.
Unity are going to give us some bugs, tell us about HDRP (trash pipeline should discontinued and all focus on URP) hairlines and ocean shaders... they have lost the fucking plot.
And just like when a bunch of professional rendering devs told Juan SDFGI was a really bad idea [which is was[... they are also telling Juan this one is a really bad idea. As I said, Juan takes your donation money while he does nothing but remake broken wheels over and over and over. Just another GI system other engines don't touch because they already tried it a thousand ways and it doesn't work, lol. Making a pretty scene is easy... but "Where's the rest of the game?" It will not perform at scale and has fundamental problems in motion-- which is why other engines don't use it.
Links
gamefromscratch.com/godot-new-global-illumination-system-hddagi/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
-----------------------------------------------------------------------------------------------------------
The assets used in this video are available in this Humble Bundle (ends Friday, Dec 15th!):
www.humblebundle.com/software/best-synty-game-dev-assets-remix-encore-software?partner=gamefromscratch
To clarify, HDDAGI is meant to resolve SDFGI's flaws (such as stutter on fast camera movement) by superseding it with a more efficient approach. This means there won't be 4 GI solutions in parallel in Godot: we'll go from SDFGI/VoxelGI/LightmapGI to DynamicGI/VoxelGI/LightmapGI.
sdfgi has significant performance issues when moving the camera (cascade stuttering). the biggest performance difference will never come from still shots, just keep this in mind with future testing going forward.
On top of that, the areas that are supposed to be pitch black in sdfgi stops being so if you move far away enough. I hope this new system will solve that issue as well.
The staircase to the right of the wall you showed around 6:48 explains everything, especially down the left wall. It makes absolutely no sense for a yellowish light to fall on that wall in the game. Thank you both.
In my opinion, Godot is really close to become the absolute no-nonsense engine for indie developers. It offers complete freedom, lightness and intuitive conventions (most of the time). But they need to fix issues like these quickly now, since the release of 4.0 it has gotten attention. Thankfully, the Godot team seems to understand what needs to be done.
didnt show at first, but the new solution looks alot better, plus the performance while orbiting around in the scene is slightly more smooth than before, looks good honestly
How's your game going?
@@addmixswitched to linux, some files got corrupted, fixed the corruptions.
waiting until I get the energy back so I can redo audio files and make a new map.
so going pretty well, how about you?
I can't help but read HDDAGI as "Adagio" (the Italian musical term for slow music) although HDDAGI is "Prestíssimo" compared to SDFGI
or Ahegao
The human psyche tells us constantly in little things like this how unreliable it is
I love learning cool things from cultures! Thank you for this!
Adagio? ...that's a bit *dramatic* don't you think? _(internet disclaimer: this is a pun)_
@@whoeverofhowevermanyYou're not wrong, haha. But I think it's telling how psyche modifies perspective like a lens over an image. In this case, bend the top of the H inward and form an A. Then HDDAGI becomes ADDAGI which is not too far from ADAGIO. Human brains look for patterns / symbols / representations they already know instead of reanalyzing things objectively because this is often a faster method to produce results... But it is messy and gets out of control very quickly. This doesn't feel dissimilar to how LLM's hallucinate TBH.
Compared to SDFGI, HDAGI actually looks usable and “good enough” for a professional project. The light bleed just made the old system very ugly. Simply not having light bleed makes this look very usable. Maybe not UE5 levels of global illumination. But I would be curious how this system performs compared to UE5 Lumen.
Not even close to Lumen but it's also not developed for that purpose. Lumen equivalent or closer for higher quality GI is planned for later next year (or later if it gets pushed due to some other issues ;)). Right now this is meant as a GI which should work with killing performance on a wide variety of HW producing decent results (it uses sort of a voxel approach it seems from the github discussion) while Lumen is meant for high end for most.
It will take some time but hopefully it will resolve the major issues the SDFGI had.
@@ViktorsJournal And also that this is still in bug hunt progress , and need’s more battle test to make it look as good as possible
Isnt lumen like sdfgi and screenspace combined or smth
But just cranked into infinity
@@user-mc4rr9fe6y I don't think it is (?). It does use SDF as part of the process, the screenspace GI I think is separate you can choose lumen or the screenspace GI though they might also use screen space for stuff in lumen too, it's a hybdrid of different techniques from ray tracing, SD and ??? depending on what your HW supports and what doesn't and such.
@yourmajesty9025 I like it :). It's not something you can build your game around if you target wider audience but it's really nice when you can have it so you go the usual route with lightmaps and higher settings with Lumen.
1:09 Godot 5.3? Damn, I know we're Waiting for Godot but damn, I ain't think we were gonna be waiting THAT LONG
Im pretty sure he meant to say 4.3
@@benjamindreyer9884 I know, I was joking. That's why I said "Waiting for Godot"
@@JdThe65th lmao. Im slow
To me the biggest weakness of SDFGI is its inability to handle dynamic light occluders in the GI properly. This apparently still doesn't solve that.
(I see that in the pull request Juan has put 'Dynamic Object Support' as a planned future feature, but considering he said the same thing about SDFGI and now that algorithm is just being fully abandoned, I'm not exactly overwhelmed with confidence that it'll ever happen with HDDAGI.)
In fairness to Juan, SDFGI only came in Godot 4.0. Because this seems to be better in most ways, there's little reason to go back and implement dynamic light occluders in SDFGI.
The cascades look a lot cleaner, I like this change! Will it support more platforms? Quest VR support would be crazy
Nice. SDFGI has a LOT of light leak. This replacement should fix the issues.
7:13 As far as I know bias is a technique in raytracing where the renderer prioritizes pixels which require more iterations to achieve a low noise level. Basically using more processing time where it makes the biggest difference for quality. I don't know enough about global illumination in games to say for sure if this is it though.
Biasing on this context is to prevent self-shadowing. I think you're referring to adaptive sampling.
Always awesome to hear that updates are on the way
What I really need is for Godot's 3D performance to be at least comparable to Unity. It's okay for Desktop PC, but on anything weaker the differences in performance become extremely noticeable. Even a simple scene can crank out the Steam Deck's power usage to over 20 Watts. I'm not sure why this disparity exists, but right now making a standalone VR game for example, is practically impossible.
Well... good news then... ;)
gamefromscratch.com/godot-google-and-the-forge-partner-to-improve-vulkan-support/
Because Godot is built by a bunch of hobby devs getting paid by donation money who have never worked on any actual games. Check their history, the biggest games Godot devs have ever worked on were very small games. Which is why Godot is great for small games... but absolute crap for anything else. It isn't just the renderer that is subpar, it is the whole Godot structure.
@@lillybyte Bro is mad he can't make performant code...
@@lillybytewell, the source code is right there for you to improve with your evidently superior skills in the case you allow yourself to deal with mere mortals.
I mean I agree with LillyByte here although it's a bit harsh, like there's a reason it's not even brought up as comparison when discussing gamedev for larger MMO games, sponsored social/gacha mobile games, or anything where you'd want to collaborate on one project with over like 60 people. Sure, Godot might eventually get there thanks to people contributing, but the truth is that currently it's subpar for anything outside of indie and startup-studio game development. You have to retrain/hire all engineers for a new language and yet only get an equal or worse result currently.
Similar reasons to why Blender is rarely used for big-budget movies (only experimental vfx studios seem to use it, and only for personally or crowd-funded films usually), and Krita is never used for drawing professionally.
I could see the difference immediately. It's what we call more "idealized" lighting, there's gradial separation inside regions that need the Detail in them brought out ... like how the "painterly" style contrast is thrown around but this achieves it with hierarchical _Maths_
I'm happy to see the devs/Juan focus on lower end hardware instead of just flair (and thus higher end hardware), whilst still allowing for flair as much as possible. Don't get me wrong Godot 4 can look gorgeous, but I don't think it should ever try to compete with an heavy hitter like UE for example.
I can run a complex game (Disinfection and some other projects) on 10 year old hardware with good frames, whilst also being able to crank up things a lot on higher end hardware on the fly. It's so flexible and I love it.
It might not ship in 4.3 even as an experimental feature. They have not tagged the PR with specific version yet.
Reduz (Godot dev leading this new GI) said in the PR that it might actually get into 4.3 if he gets constant feedback and some support. They have it tagged 4.x because he can't promise it'll be in 4.3, but if everything goes well it should be.
And that one of the reason i am testing it a lot, mainly performance, tesr but to help. @@PopCar
update: still visible cascade transitions and such, not usable for production.
So ummm, we're fked.
When trying to report Nsfw bots, it says "internal error occurred"
found your comment
Wait ..
What...
I have bots on this channel?
I always thought my audience just had extremely nice asses and loved to show them off.
@@gamefromscratch *assets. We have nice assets.
@@gamefromscratch🤨📸
I'm doing a VR art project and I choose unreal cause the quality of lighting is really important in my case. But I keep my eyes open on godot, cause I hope some time I can switch to godot cause deep down I love godot more.
all of Godot's global illumination features don't work:
VoxelGI - no shadows
SDFGI - huge light leaking between cascades (past ~8 meters)
lightmap - tons of glitches
I'm skeptical this one will work..
tho they present it as production ready, misleading people to say the least.
You need to understand concept of "trade-off": en.wikipedia.org/wiki/Trade-off
Only global illumination system that renders image correctly is unbiased path tracing with enough number of rays, and that is very slow. So there is also trade-off.
Understand that these are tools, you need choose right tool to right situation, use them correctly and tweak your scene.
You also forgot GiProbes, ambient light, fill lights, SSIL...
@@gruntaxeman3740 His point was that these tools are NEVER the right tool. They have fundamental flaws that would wreak havoc on any art direction and pose a constant distracting for the player. So in the end all you can do well in Godot is write your own lighting solution or settle for bad 2000s lighting. You cannot look at the flaws he explained and handwave them as "tradeoffs". There's nothing to trade here, these are just dealbreakers full stop.
Seems like a speako at 1:07. I believe Mike meant Godot 4.3, not Godot 5.3. (Though it would be awesome if he was making predictions a whole version out, haha)
The framerate looked the same on both solutions. It would need a less cluttered scene for a more precise comparison. But overall they appear to have the same results in general.
The shadows and dark areas are SO much better with the new system. Wonderful!
1:07 5.3?? Damn, we had to wait so long for 4.0. I probably won't see it in my lifetime.
I think he meant to say 4.3
He mean 4.3 ;-)
We will have 5.3 in 5-6 years, probably xD
The author of the video showed an interesting pattern that occurs in stable versions of Godot - if you increase the load, the FPS will drop, but if you return the values back, the performance (FPS) will not change. Why is this happening?
This may be caused by memory leak.
Something tells me Juan really likes testing rendering techniques.
he's the rendering guy mainly, so, that's kinda his job
And something another hints me he loves gathering money in all ways he can. W4 Games investitions weren't enough.
Another GI system? Keep em coming.
My only issue with this is the color getting lost in those signs.
With SDFGI, I get like 40 fps with just 6 boxes in my scene and here the fps is in the hundreds :( Sigh, my PC is becoming a potato little by little.
I sincerely wonder when it's going to be a good time to start learning Godot with how fast it's changing.
yesterday
This feels like a few months where Blender really exploded in popularity and features.
I would prefer that existing GI solution for Godot actually work instead of a new one, like Lightmap GI that is unusable right now due bugs on probe system.
Lightmap got a number of fixes in 4.2 so there's hope, I actually am not even sure if all of them made it into 4.2 because at some point there were talks about some getting pushed into 4.3 but I don't know for sure how it worked out.
Well... The LightmapProbes are still 100% broken on 4.2... This is bad because we get good GI on static objects but on moving objects the illumination flashes so much that hurt the eyes
@ I don't know your config but I don't have issues with flashing on the other hand I have issues with shadows it creates :D.
@@ViktorsJournal I made a demo with the light probes inconsistency, its on issue 82642 in Godot GitHub (For some reason I can't post links here)
Sounds awesome, faster and prettier, what
else could you wish for, from an update
to the renderer?
Your asset link is the same as the HDDA Development Branch link on your page. Please fix.
I see you have the link above in the Description... So I was able to get it.
Oops, fixed, thanks.
This honestly just reeks of project mismanagement. Was SDFGI just stuffed in to sell people on 4.0? Thats a profoundly cynical and inefficient approach to open source defelopment.
I want Godot to succeed, because the games industry desperately needs more things that aren't controlled by giant companies, but everything I've seen since I started following it suggests it's not being managed by someone who knows what they want it to be. This is the second bit of lighting tinkering they've spent time on, meanwhile the engine is still a chore to get assets into and work with them (especially 3D assets that are complex and likely to change), some workflows like themes are still a mess, and the 3D tools haven't seen enough meaningful updates to move Godot beyond "you can do 3D if you want to, but this is a 2D engine". I'm generally a "get what you give" guy when it comes to open source devs, and thus give them slack in regards to clapping back at people who come in with entitled demands, but the lead dev seems fond of dismissing constructive criticism like some one has insulted him and I've seen him insist that no one is controling the direction of Godot which honestly makes me scared for its future.
Agree. The biggest problem I see in Godot is lack of vision. I'm much more excited about Bevy in the long run for that reason alone - even though it lacks many features and is still in development, it has a 'benevolent dictator' (cart) who decides the direction and has some clear goals for the engine and its features - e.g. whether you agree with that or not, they will never have a core-supported scripting language (though it'd be possible with plugins). The engine has strong momentum as well and is seeing increased number of contributors
Godot and its community isn't really built off of people solely controlling the direction of Godot. Its contributors and users do.
HDDAGI was discovered to be a better version of SDFGI that not only looked better but performs better in tests, so it only makes sense (to me at least) that SDFGI was replaced by HDDAGI.
I haven't experienced many workflow bugs or hinderances, only one comes to mind. All my assets are easy to import, and with stuff like the Unidot importer now in the asset store(?) It was easy for me to import unity assets as well. I was literally just able to open a unity project, take what I wanted and export it as a Unitypackage, and it imported perfectly. If you have issues PLEASE submit them as a bug, or if you have suggestions submit those as well! As I said, the People decide the direction of Godot. We have project roadmaps for 4.3 and beyond.
Godot 4.2 just released and they already have a 4.3 build? W/E, I do hope they make this GI feature usuable in a real game. It seems to be ok for low res generation. I generally find Godot's 3D lighting kind of crap, with the diffuse having banded colors.
Did you enable debanding in the project settings?
@Calinou I love your work! Appreciate all your efforts mate
Did you think they'd work on new features in 4/2 when it's already released or what? Yeah obviously they're starting the 4.3 build now that 4.2 is done
@@TurtleKwitty I think they should be perfecting 4.2, before even thinking of 4.3. The .# is usually additional small features. and the .#.# is the bug fixing; but it can be w/e you imagine I guess. It was just surprising they already had a new build already available to download. It's not a big deal. I pretty much have given up on game dev.
@@rremnar 4.2.x and 4.3 (currently just master) are separate branches, but yeah, not a lot is going on for 4.2.x. this new build is not The 4.3 btw, just particular commit of its branch, and not in upstream
Very nice breakdown. I've added a comment on the PR as well showing my findings on a simple scene. Anyone have any idea what's causing the light bleed? On interiors its pretty bad. I think if the light bleeding can get fully under control, this is a super impressive and widely applicable GI algorithm.
Interesting stuff.
D3d12 backend has been merged
cant wait for constant frame stutter!
@happygofishing hopefully not and if it does then godot developers can fix it since they are mostly in control how rendering & compute pipelines are compiled.
I'm still yet to play a non stuttering DX12 game. @@alexanderstreng4265
I don't know what to think about it. In one hand I trully belive that the project leaders have a vision and there's a reason why they do what they do.
In other hand I'm under the impression that they start/restart too many things at the same time, and before the functionality is polished, they throw it out and start a whole new solution for the same problem.
Like having sdfgi and voxelgi, and none being optimal. On top of that they throw out the bullet physics to implement their own, just to throw it out again, and then just to embrace Jolt.
Don't get me wrong, I Hope hddagi is as awesome as it sounds, I'm just worried in general.
As I said, they may have a reason. I love Godot and would like to see it growing.
Cheers
This is actually is a result of fixes for SDFGI. SDFGI turned out to have some unfixable issues thus the search to replace these parts with something different and this lead to a different technique altogether - right now it still uses parts of SDFGI though that will change in upcoming days/weeks/months as the development progresses. I don't think even the devs were that happy but when you hit a static roadblock sometimes you just have to go back and take a different turn ;).
SDFGI and voxels are intended for different scenarios. One isn't a replacement for the other. It's better to think as Godot having one solution for open environments and one for closed environments and they're improving the one for open environments
@@padre_putativo_suscriptor Actually I strongly disagree: A custom solution isn't always superior than something that is proven to work by for example the industry. You don't have to reinvent the wheel every time you do something. There is a reason that you for example don't write a custom game/ physics engine when you want to make game but rely on a premade engine.
Sure, if you or your company have the resources to deal with a custom solution and everything that comes with it, go ahead. But custom solutions always come with the problem of not only creating and implementing them, but also maintaining and supporting them. This is the exact problem we are seeing with Godot Physics:
The person who made it jumped ship and now works on something else, while what they left over with Godot Physics is a broken and bad performing mess. Had they just used a premade physics engine like Jolt, they wouldn't have to worry about maintaining the physics engine itself, but just about it working in the engine.
Also: What do you mean by "Everything is logical, not random and disorganized like Unity tends to be.". Never has the Godot team published a roadmap of how they are going to proceed with developing the renderer (or their physics engine, or GDScript). Sure Juan is sharing some progress on his twitter and there are some blog posts from time to time, but all of this is following no clear direction and path to finally getting the renderer up to par with Unity or Unreal (I mean not feature wise, but "it just works" and quality wise).
Well while i agree, jolt simply can’t be paid , because it MIT.@@padre_putativo_suscriptor
I just wanted to thank you guys for the replies. I think this is quite a broad topic to elucidate in a comment section on TH-cam but i appreciate the effort. I've even learned something new today. Hahah
Anyways, I think i didn't express myself correctly when I compared voxelgi and sdfgi.
But the core of what I wanted to say is that, some times I just have the impression that things are abandoned before completion successively.
This puts me off a little, but as an expectator I can only trust and hope for the best.
Thanks again, cheers!
Love your videos
I m not even a game dev just open source enthusiast, can't understand anything but just love everything 😂.
Published 3 min ago. 16 likes already. Way to go
What about the raytracing that takes advantage of the RTX
Pretty sure that's nowhere near open source from NVIDIA meaning it will never get added to Godot offcicially.
1:09 Godot 5.3 experimental?! 🤨😂
I dont understand why they constantly keep addinf different GI when the previous ones have flaws. All
You can't gather donations so efficiently, when your engine is production-ready, so you have to reinvent the same things over and over.
So basically dynamic gi is sdfgi which is tuned for better performance 😂.
1:10 A Godot 5.3 feature?
You have been doing some slips of the tongue lately. Are you well? I imagine you might be overworked with how on point you game development related news are
I've been doing slips of the tongue since birth. I'm fine. ;)
Hard disk drive artificial general intelligence...
Interesting concept-
IMHO you should always pick Reinhard or Filmic tone mapping over ACES. Your video is totally underexposed because of Aces luminance attenuation.
where to get 4.3?
Pretty cool feature for photoreal graphic
Not another again...
If only Blender and godot devs worked together and decided to implement Godot renderer into Blender to replace eevee.
Now eevee is fine for what it is, but it chokes on heavier scenes, textures and light bleed is still awful.
And it detracts resources from improving things like texture painting, baking, multires performance, sculpt layers, refining new hair system.
Well it's not going to happen. I know.
5:56 running at 13000 FPS, HDDAGI is nuts 😎
that was before it was turned on
It was 1300 and that was before it was turned on
these gi solution names are getting longer and longer i swear 😭
So, instead of releasing deferred rendering, they're reinventing the wheel as they did with GDScript (Python clone), custom physics engine, occlusion culling system (which was thrown out just to be rewritten again)? F*ck this shit.
gdscripts is totally different language. it doesn't have garbage collector which is important in scripting language for games, also it is better integrated with godot than python would ever be. only thing that is simular is the syntax. modifying python to work as well as gdscripts would've taken more work than creating gdscript.
I love darkness 😎
Yay
WOW!!!!!!!!!!
These acronyms are getting longer and longer...
Is this really community driven, cause I always see that Reduz guy doing things on his own, prolly the reason why the engine is not good for 3D in comparison. Don't keep up with things godot, so maybe I'm wrong with the assumptions.
You are absolutely right. This is Juan's game engine he does things that will hype up his community(his cult)
I'll give you the two sides:
In his defence: It's pretty hard to get experienced graphics programmers that work on this type of stuff, because not only they are few, but also very coveted by big studios. Hard to convince one to work for free or an inferior salary in a open source engine. Like the guy or not, the project dependents on him
On the other side: You are kinda right, the guy is known for being resilient to feedback, so the few times some experts tried to help, they first had to spend a lot time convincing him. Some prevailed and the engine got better for it, the other's not
That's the case with the vast majority of free open source software, it's not uncommon for popular open source software to be run by a single guy.
There are more people than just Reduz but he is by far the one doing most of the work, usually other people just add small things to it, or small fixes.
Even blender is like this, the blender foundation does all the job, the community barely adds to it and when they do they often charge for it, you go to the blender marketplace and you will see people charging for addons under the GPL (General Public License) and acting as if they own all the rights to it, I expect it to be even worse with godot when a official paid store is open because the license actually allows people to charge for it.
Everything these core guys do they first discuss with other core developers. Clay John is the leader of that graphics team so it's up to him to decide. Further global illumination improvements have been planned sice the release of 4.0 and it's not like there are dozens of people with graphics expertise lining up to work on this project so it's the area in which reduz has the most knowledge.
Tbf, if it wasn't for him, the engine would not be 3D capable at all
I'm sorry but the entire godot's rendering system needs a complete overhaul. Godot also needs engineers who really know about rendering. There's something off with how godot renders. Compared to other open source engines like stride or flax, godot's rendering system is just inferior.
So... what's wrong with it?
Explain to me what makes it inferior.
@@UsaraDarkit is bad and ugly and horrible performance
Hey, if you think it needs a overhall, the source code is open.
Good luck :)
edit: minor spelling mistake
I’m honestly curious what’s wrong with it. I’m weighing it as an option. The 3d doesn’t need to be perfect. But “good enough” would be good, especially with all the other benefits.
Lumen > HDRP > URP > Godot
Visually? Yes, performance and art style? No.
This isn't supposed to compete with Lumen, chad.
@@hipflipped replace Lumen with UE5.x
The Godot cult hasn't seen this yet because the comment section wouldn't be having such good critical discussions
Unity are going to give us some bugs, tell us about HDRP (trash pipeline should discontinued and all focus on URP) hairlines and ocean shaders... they have lost the fucking plot.
And just like when a bunch of professional rendering devs told Juan SDFGI was a really bad idea [which is was[... they are also telling Juan this one is a really bad idea. As I said, Juan takes your donation money while he does nothing but remake broken wheels over and over and over. Just another GI system other engines don't touch because they already tried it a thousand ways and it doesn't work, lol. Making a pretty scene is easy... but "Where's the rest of the game?" It will not perform at scale and has fundamental problems in motion-- which is why other engines don't use it.
Incompetence also counts as fraud
Looks more like another bandaid to their renderer than a real solution :/