Thanks for being honest regarding 3d rendering state. 3d rendering and physics (Godot *must* switch to jolt completely) are the priority, so many things to improve. The requirement of having the entire level in VRAM is just a stopper for many applications.
No. Godot shouldn't switch to jolt completely. Stock physics is still great for most projects and jolt causes other problems such as inert process time consumption. Jolt should be optional forever. And I don't think he is right about Godot's 3D status. Honesty does not automatically mean factuality. Fortnite isn't graphically taxing game and Using Godot's LOD features wisely it is really capable to create at least GTA4 sized world with decent graphics (at least better than Fortnite)
well, on my lenovo carbon gen 4 (2016) stock physics with 1 capsule was lagging (non-workably slow) while colliding with 1 cube. :). Jolt went fine. So... slower machines reveal it.
@@thehyper4288 TBF it's not his job to constantly check if something was finally released or not, as that'd take a ton of time when you account for all the things you could be watching out for. And AMD for one has made a fairly bad job of making their public releases known, they focus too much on showcasing the stuff and assume people interested are going to follow them closely for it's eventual availability.
Dariosamo and the rest of the team did a fantastic job with the ubershaders. Seriously its such a huge W and I hope this can be expanded later on to have specialized shaders ready quicker.
35:00 Correction - Modern Nvidia doesn't support FP16, Only AMD and Intel benefit from FP16 atm, since GCN 5.0 which is Vega, to present day for AMD and Alchemist on Intel and for Nvidia it's only on Turing in the Consumer space, as can be found on techpowerup's GPU database so affected lines are: Intel Vulkan compatible IGPUs (most if not all of them) Intel ARC GPUs AMD Vega IGPUs and DGPUs AMD RDNA GPUs (IGPUs and Consoles included!) Nvidia GTX 16 and RTX 20 series, and The Nintendo Switch For RTX 30 and 40 they've ditched Consumer FP16 Boosts. This list is for Desktop, laptop and console, and not mobile
On the subject of lightmap compression, the first thing that comes to mind are the usual Vram compression in the engine already. But what also comes to mind is A technique used in the game homeworld 2 for high rez skyboxes without high rez textures where they use A mesh with points sampled wherever the image has large changes in contrast. I found this on Simon Schreibt's blog recently and ive been meaning to see if I can recreate it, to try when experimenting with what performs well when making assets.
this is the method that blender used to use back in 1.8 its fun, but it looks kinda crap. considering the amount of work that's gone into texture compression since the 90s its probably better to leverage that.
@@Capewearer I mean... that's how it got its name. From the play "Waiting for Godot", where 2 people wait for someone named Godot, who never arrives. Because the devs said it's a fitting metaphor for a game engine, which you will never "finish".
@@Capewearer I mean... Half-Life and Quake had custom engines written exactly for what they needed. If you are developing a game that needs some feature and you choose an engine that doesn't have the feature, that's a bad decision. Even Noita has a custom engine because they needed features they didn't get in off-the-shelf engines.
@@Capewearer I get your point but software development never ends. Kt's a continuous cycle of updating, adapting and adding missing features. They will arrive, just sooner or later.
28:18: please tell why Godot uses a separate shader language? (for cross-platform flexibility?) Is the compiler in Godot just a frontend transpiler to some mainstream shader languages or you have to do also a compiler development work including middle and back end?... // there is hardly a way to keep up with specialized compiler frameworks regarding optimizations (like mlir/llvm).
I see a focus on moving towards temporal effects, is this going to cause ghosting problems like other engines? Because if so then that's not really a direct upgrade from existing implementations if not a downgrade for a lot of people.
About those FP16 at 23:38 What was not completely clear for me is do we need to take care our self not going over that 65504, or will the engine do that for us in the background. And if we need to do it our self, how would that work ( where to look for )?
When writing your own shader, it depends completely on what data you're passing from the rest of your game and the shader itself, so the engine can't handle it other than maybe a build step warning rarely. They will have made those considerations if it might be enabled in certain built-in shaders with exports like on mobile or with compute shaders, I'd imagine though.
the background pipeline stuff+ubershader is huge, for what i'm testing in 4.4 it works great. hopefully now that the pipeline has been reorganized, someone can start working on data streaming and stencils. thanks for the hard work
The entire level in Vram, is the most frustrating limitation for me. I have chosen to focus mostly on the construction of the massive open world game levels im trying to make hoping the means to stream assets eventually becomes A priority. That and collecting knowledge on how open world games are optimized to take as little of that Vram as necessary. Been reading a lot of Simon Schreibt's blog lately. I have heard there is A way to manipulate textures from compute shaders, so there may be A way to load new textures by replacing others in an atlas as new texture data is needed, but making meshes in compute and passing them to the main pipeline is as best I can tell from watching the discord, not possible without going through the CPU first. That and just having trouble getting an understanding of what can and cant be implemented with the new compositor features. Admittedly I haven't read the code, but just by the docs, Basiaan's streams and clays talk last year I got the impression I should be able to do things that would otherwise require A dedicated stencil buffer, but when asking around I get the impression that's not possible. Okay cool. Recently I have been looking into tech art for assets and wanting to know how different asset choices effect render performance, this leads me to looking at Unity's optimization shaders showing things like light overlaps or the cost of your topology with quad overdraw shaders. I know the devs don't want any more built in view shaders because of having to distribute A lot of compiled shader blobs to account for all the variations without killing in engine runtime performance, but I am having trouble getting A handle on if making these things as installable compositor effects is possible. I'm sure there is A path to me being smart enough to understand this, but I dont know where to start aside from just learning how A general rendering pipeline works(the GLSL docs?) and then read the code, which are some big steps from just barely understanding shaders. IDK Ive been trying to learn Godot and wait for it to get good, since 3.3 which isn't that long compared to some of the others, but I'm still frustrated and don't know what else to do.
don't know what your game looks like, but this "oh we need texture streaming" is a very recent problem and so I've never had it. for an open world with terrain, you divide the level into chunks and load them when getting close to their area (this also works for assets like rocks and buildings that are distant) and remove them when far enough, this is what the fallout and skyrim engines do. for closed levels you load a different level when reaching a point, like in source. if your level has buildings, loading the interior of buildings separately means the furniture and stuff that's inside is not present in the outside scene and vice-versa. finally, when using premade assets, you are supposed to edit them by packing textures and adjusting UVs so multiple objects share the same material. and for small objects, reduce their size to the space they occupy in screen. a 4k texture on a bottle is for a first person shooter, not a third person game, because such an small object will not occupy much of the screen, so a 256x256 or 128x128 texture or even smaller is enough. we also do this when objects are distant, when a tree is too far away it is replaced with a cardboard cutout, and a bottle could be replaced with a lower quality version, and this can be made with gdscript. the rest is a problem of *level design* , not technology. we have been designing levels to avoid rendering the entire world for decades now, this also helps with levels with chunks. look at how games add mountains and verticality and tunnels to break the levels into smaller parts that can be visible separately. this also greatly helps with gameplay and worldbuilding and reduces the amount of work that needs to be done.
@@jesusmora9379 I am aware of all of these things as my focus the last few years has been specifically on optimizing for large levels, but I do appreciate your effort to give me so much useful info in one place. My goal is making large scale community driven copyleft games. The approach I am taking is to build multiple large open world levels like city's and forests using mostly the techniques you just mentioned, so that there is lots of room for people to contribute assets that will only need to be be loaded in the building they're working on for example. If I can take the immersive sim approach of making the mechanics have emergent interactions, then setting up A pipeline for contributors to make content fitting those mechanical systems. I feel like I can make it easy for A player to be playing, imagine A cool new sword after picking one up they like but wish was different in some ways, and then contribute A sword they would prefer. For this to work well I have to make systems that allow me to figure out how to best integrate new assets without breaking the existing optimizations, On my list is A tool for using heuristics to decide Hlod clusters for example. Another more important thing on that list and what im currently working on is A bidirectional live proxy based pipline with blender, so that the primary storage form for assets can be res files which is important because of the way resource optimization inevitably makes all of your res files dependent on each other, this modularity is great for performance and also storage as the files are modular, but because they are still files you need to decide ahead of time where the splits will be or just make them all individual and make something to group them on release to avoid reading hundreds of little res files. Anyway thanks again for the advice!
@@nullvoid3545 that is a lot of features for a solo or even indie dev, it's the kind of thing that benefits from a custom engine and not an all-purpose one like godot. it also sounds a lot like an MMO, which is something you are not supposed to do unless you are company with lots and lots of employees and actual programmers, at which point you would just modify the engine's source code. and if you ARE an indie dev, I really hope you are using lower quality assets like low poly and stylized, because trying to work in something like that with assets of a quality that would give you trouble with the engine's rendering is just insanity (or inexperience). anyways good luck with your project.
@@jesusmora9379 I'm less worried about getting A game to market and just focusing on making games easier to make together. Industry's are directly at odds with the value of media, and things like Godot putting the effort into making game dev more accessible not just to create but to share as well is what I aim to spend my time contributing to. That's why I'm so focused on tooling. Godot is great for games of many kinds, but games made collaboratively for the purpose of play is what I want to enable specifically. We will get there when we get there, I have plenty of time.
@@nullvoid3545 TO add on to what jesusmora said, if this goes in the direction of an MMO... "Our goal is making a single large scale game", as in: 2-4 years with a double-digit team of full-time people, has a chance of failure of like, 90% or so. So "My goal is making a single large scale game" already sounds EXTREMELY ambitious. "My goal is making large scale games"... like, MULTIPLE... oh my
Super interesting watch. Love the updates and work ethic on improving Godot. One 2D renderer wish is having more efficient ways to implement or visualize 3D objects in 2D views.
Loved the talk! As someone working in *massive* mobile games, be careful with shader complexity and combinatorial explosion with specialization constants. Outside of Apple, the hardware is still designed for ridiculously small and simple shaders and pipeline compilation, along with its memory usage, can be a royal pain to work around if you can at all. I could wine for hours and hours about how little the mobile GPU companies and the phone manufacturers support moderately old GPU's with driver updates. (It's a complex topic I know, but it boils down to money.) The PC GPU ecosystem, minus custom laptop integrations, is soooooo much better.
7:20 What??? I recently made 4.3 html game and stutter is still persistent? I did not find any new workaround aside from that "showing every object for one frame". Am i tripping or something?
4.3 Stable is actually less stable for me compared to 4.2.2 Issues like #95772 makes using Godot with the compatibility renderer during play-testing a pain in the ass. GPU Particles 2D is a lagfest when changing basic settings on 4.3 compared to 4.2. Web exports are broken on 4.3. Web games literally make the browser unresponsive, at least on machines with basic Vulkan support or rely heavily on OpenGL. I.e Gen 7 and earlier intelHD Graphics Introduction of the Google Angle fallback compatibility renderer downgraded the openGL version from 3.3 to 3.0 which inturn someone pushed a commit for a "blocklist" for machines "without proper support" for OpenGL 3.3 thus causing all the issues I listed above and more minor ones. Unless these issues get addressed since Im primarily a Compatibility Renderer user, im switching to Defold. Yeah, it has less features, but it is stable.
Looking forwards to per-instance uniform variables for 2D shaders. Would unlock a bunch of performance bottlenecks for the games that heavily rely on large amounts of shaded objects, as I've experienced in my own game. Great talk!
Looking at the games I have analyzed, I actually believe that these things will be successful and will even develop further. Last time I analyzed a mobile game called “GSS Match” and I realized that most of the things said will be successful in this game.
Godot has a limit on how far can the camera be. And graphics glitch out when too close or too far. That's because of floating point precision. Why not use INTs or even UINTs? That would allow basically infinite precision and range, with some modifications.
Because ints have far less "precision"? It's gonna glitch out at a value like 0.5 already, which is far from where float precision becomes an issue. NOTE: That was kinda "not even wrong" (en.wikipedia.org/wiki/Not_even_wrong), and hurt a little to write, but was the most succinct explanation I could think of.
What immediately drew my attention at the beginning was the green rim lighting you had. Also, now I'm REALLY confused. I always thought it was Gō-dŏt. I was sure. Then you pronounced it as Gu-doe.
I think officially its like how he pronounced it. Godot comes from the title of the play "Waiting for Godot" by Samuel Beckett, so it will be that pronounciation. However I noticed Juan ponounce it Godot where o is pronounced as in "on" (both "o"s). Most people however misunderstand the name as Go-Dot, which is just wrong. So the correct way is GOD-oh / guh-dow
its an open-source project so, technically its hundreds of people there's like 10-20 people hired full-time but I don't know the exact number their entire rendering team is just Clay John though 😭
Godot 4 and 3d = misconceptions for renderers and physics engines. They should actually throw everything away and do it again. It doesn't make sense and is just unsatisfactory for everyone. They simply didn't know any better back then. But now they should know better and pull the ripcord and think about the future. A render engine with this performance and visuals should be buried
I agree that the decision making in the past for 3D wasnt great. Sometimes it was a head scratcher for me. But I feel like they are on the right track now
@@Kiyuja Unfortunately not. There is a lack of self-reflection. Juan has always been known for his big mouth. Big announcements and then not delivering. Nobody has the courage to say anything against Juan. No matter what area, the deeper you delve into Godot, the more you will notice how bad Godot is. It's OK for 2D. For playing around and learning too. But for serious 3D applications - and I'm not talking about AAA - it's just a big failure.
@@MegaManki and that's the problem: you criticize something and people like you try to defend it by basically saying "f*ck off". How many serious 3D applications have you made with Godot yet? None? Because if you actually did, you would know exactly what the problems are. The whole 3D renderer is a big mess with countless problems, yet it keeps getting ignored because people say "it will get better" over and over again for years without anything happening because of the broken foundation. Some examples: try removing water from a boat (the classic, I know), try implementing outlines for a single object in screen space, try to use GPU tessellation, either through Vulkan directly or compute shaders. Let me know how many lines of the renderer you had to change in order to achieve that. No other major game engine has such deep flaws in their 3D renderer. Even the lesser known ones like Flax or Stride can do all of that easily without adjusting the renderer code. But for some reason you are telling people to "go back to Redot" when they ask for basic features like that? No wonder nothing is changing.
@@MegaManki Please stop, megamanki. behaviours like these are the reason Redot was created to begin with. people voicing their opinions and criticism and you putting them into an opposing enemy camp, just like american politics. it sucks. unlike american politics theyre not trying to take away your identity and strip you of your rights, they are merely hoping for the game engine to get better. there is no need for this divide.
Changing back and forth, fishing for three days and posting on the internet for two days, always unable to grasp the key points of game engines, or possibly intentionally not doing it, is a way for open source software to continuously absorb funds and expand. Create problems, solve problems, and then create and solve problems again, over and over again. In the end, it was discovered that it did not evolve well until we were all old or dead. There are too many gimmicks and one-sided behaviors. I have been learning and using it since 2018, and it has been almost 7 years since then. I used to pay attention to every progress every day, and my passion was intense. During this time, I discovered many low-level problems, all of which stemmed from stubborn biases and the organizer's lack of superiority. But now I am a little tired of it.
It's precisely mentioned, that some people just earn money with such development. That's the style of GNOME foundation - make everything worse, change design just to change design, return the feature just to remove it next year. And don't forget to fund another "socially important" meetings for marginal groups, which of course won't solve the world inequality, but money will be flown into someone's pockets.
@@charlieking7600 I work for the government and this is annoying. They spent huge sums of money for "Awareness". I'm single and have gay friends, bringing me and my team to a fancy hotel to show a half ass slide show won't solve Violence against our partners and Homophobia.
15:52 Rive is awesome for vector art and animation. Adding support for its runtime would supercharge Godot into a 2D and UI animation powerhouse, plus finally adding true vector graphics support. Please consider it 🙏🏻 Incredible talk, healed me and filled me with hope 🥲
I was really excited about the clip_children feature (and the PR to improve it) for similar reasons (I even made 2 simple animations with it). Though it seems performance (particularly w/MSAA) and workflow are issues that may not end up in-scope. ------ With my testing, 3D seems like a better workflow with vertex colors (low poly+can be textureless). The materials (and prospect of unifying them with an import script for a useful general set) are the key here and really help give a nice look/functionality (though issues like transparency overlap I am not sure how to handle). Vertex shading will be a nice option too. I am not the best with Godot or Blender so there are things that I'd like that I'm not sure are possible. Like animated meshes, particularly with grease pencil+geometry nodes. The one thing I tried (Blender visual shader setup for 2 vertex color attributes, one used for glow) didn't seem to import into Godot properly. Though I guess shape keys is a thing, and obviously armatures. EDIT: I guess low-frame animations could definitely work just by animating the visibility of meshes. That might be wonky with collisions, though I don't know if a normal skeletal animations actually apply forces (say from a run animation) or not. ------------------ Comparing to 2D, being fully in-engine almost has some advantages like using an animationplayer for a polygon2d or its vertex colors is super easy... though editing vertex colors in Godot's list editor is more of a pain than Blender's workflow. I almost want to use 2D for the animation+aesthetic (maybe w/a simpler non-clip setup), though with 3D it feels like I've rediscovered something and am fitting new pieces together to make it flow.
@@insomniac_lemon That is a very interesting experience! I also was looking around for alternatives. In the end, for what I need, Godot's built-in 2D bones + animation systems are more that enough. If you want to go further, the DragonBones addon seems like a perfect alternative to Rive. More so because it is already integrated and it seems very well mantained. I think that if Godot had a bit more love put into ironing out the pesky bugs of the bones system, it would be perfect as-is. And for vector graphics, Godot can scale up SVG files before placing them as bitmap images, plus there are some powerful addons that enhance this capability. So perhaps there is no need for vectors at runtime anyway.
@@josu_id well for me, I want the real thing. I don't really see larger bitmaps as a solution, I would sooner try 3D meshes in 2D (or simpler 2D polygons, as I've already said). Or, SVGs as meshes in 3D seems like a thing you can get set up with addons. Even this somewhat defeats the point of bezier curves, so at that point I'm already preferring to manually-make meshes unless I could get NURBS support (or SDF models, there is an old plugin by Zylann but it has a few downsides and it is now unmaintained w/o 4.X support). Godot's textmesh in 4.X is pretty nice especially with unicode characters, though I have not had luck with color unicode via different fonts (NotoColor, Twemoji). That and for normal unicode there seems to be no good way to handle color, I've recolored the entire texmesh with a shader but this is not perfect visually (2nd pass for another material) and it'd really be nice if this could be changed per-word (or even a global per-character list for unicode?)... I'm sure vertex color could probably could added via a shader (unless there is a better way?) but probably not by me any time soon.
Rim lightning fully implemented on John.
Rim
@@GoblinArmyInYourWalls Rim
@@GoblinArmyInYourWalls Rim
@@GoblinArmyInYourWalls Rim
What an excellent talk. Very glad to hear my sentiments about 3D shortcomings being addressed! Looking forward to see the improvements.
10:47 👀 My contribution is mentioned AWESOME! (vertex-shading)
Yooooooooooooo
Thank you for you help!
nice, good old Gouraud Shading!
Thank you! will be interesting to try out for retro style games
Glad streaming is still a priority. VRAM being a hard limit to design your game around is a pain, especially when targeting lower end hardware
Whats also good is people are also making their own custom streaming solutions as well
Thanks for being honest regarding 3d rendering state. 3d rendering and physics (Godot *must* switch to jolt completely) are the priority, so many things to improve. The requirement of having the entire level in VRAM is just a stopper for many applications.
No. Godot shouldn't switch to jolt completely. Stock physics is still great for most projects and jolt causes other problems such as inert process time consumption. Jolt should be optional forever.
And I don't think he is right about Godot's 3D status. Honesty does not automatically mean factuality. Fortnite isn't graphically taxing game and Using Godot's LOD features wisely it is really capable to create at least GTA4 sized world with decent graphics (at least better than Fortnite)
well, on my lenovo carbon gen 4 (2016) stock physics with 1 capsule was lagging (non-workably slow) while colliding with 1 cube. :). Jolt went fine. So... slower machines reveal it.
Jolt dosen't have multiplatform support, sadly that makes it unviable for this engine. Even Rapier does better.
40:25 AMD FSR 3.1 is fully open sourced and available on GPUopen and has been for months.
Holy shit, it's insane how clueless he is
@@thehyper4288 TBF it's not his job to constantly check if something was finally released or not, as that'd take a ton of time when you account for all the things you could be watching out for.
And AMD for one has made a fairly bad job of making their public releases known, they focus too much on showcasing the stuff and assume people interested are going to follow them closely for it's eventual availability.
Great talk! Love all your work on the rendering side!
Dariosamo and the rest of the team did a fantastic job with the ubershaders. Seriously its such a huge W and I hope this can be expanded later on to have specialized shaders ready quicker.
So for faster shader compilation, instead of putting the objects into the scene tree, you have to now put the objects into the scene tree ?
35:00 Correction - Modern Nvidia doesn't support FP16, Only AMD and Intel benefit from FP16 atm, since GCN 5.0 which is Vega, to present day for AMD and Alchemist on Intel and for Nvidia it's only on Turing in the Consumer space, as can be found on techpowerup's GPU database
so affected lines are:
Intel Vulkan compatible IGPUs (most if not all of them)
Intel ARC GPUs
AMD Vega IGPUs and DGPUs
AMD RDNA GPUs (IGPUs and Consoles included!)
Nvidia GTX 16 and RTX 20 series, and The Nintendo Switch
For RTX 30 and 40 they've ditched Consumer FP16 Boosts.
This list is for Desktop, laptop and console, and not mobile
I bet AI researchers were making the most use of them so they enshitified to get greater benefits for the upsell to non consumer cards.
Loving Vertex shading for mobile performance, and FP16 will be BIG! :D Great talk, and hoping to see more like this ^^
30:00 UGH I WISH IT WAS SOONER , IT WOUDL REALLY HELP.
Gadot has grown so much! Hope to see more people using it, after the fiasco of unity this program looks amazing
in Clay John we trust
Lol you made me realize that's his real name.
34:00 is that @Brackeys?
On the subject of lightmap compression, the first thing that comes to mind are the usual Vram compression in the engine already.
But what also comes to mind is A technique used in the game homeworld 2 for high rez skyboxes without high rez textures where they use A mesh with points sampled wherever the image has large changes in contrast.
I found this on Simon Schreibt's blog recently and ive been meaning to see if I can recreate it, to try when experimenting with what performs well when making assets.
this is the method that blender used to use back in 1.8 its fun, but it looks kinda crap. considering the amount of work that's gone into texture compression since the 90s its probably better to leverage that.
wohoo, the talk ive been waiting for
Great talk!
godot is going to be so fricking fast once they implement these optimizations, it's all really good
@@Capewearer I mean... that's how it got its name.
From the play "Waiting for Godot", where 2 people wait for someone named Godot, who never arrives.
Because the devs said it's a fitting metaphor for a game engine, which you will never "finish".
LOL same thing since 2014
@@Capewearer I mean... Half-Life and Quake had custom engines written exactly for what they needed.
If you are developing a game that needs some feature and you choose an engine that doesn't have the feature, that's a bad decision.
Even Noita has a custom engine because they needed features they didn't get in off-the-shelf engines.
@@Capewearer I get your point but software development never ends. Kt's a continuous cycle of updating, adapting and adding missing features. They will arrive, just sooner or later.
Great talk! Godot is just amazing - lightweight, capable, and open source!
still hurts not to be able to set stencil and depth write in pipelines 😢
I agree. Also I'm missing custom render buffers.
28:18: please tell why Godot uses a separate shader language? (for cross-platform flexibility?) Is the compiler in Godot just a frontend transpiler to some mainstream shader languages or you have to do also a compiler development work including middle and back end?... // there is hardly a way to keep up with specialized compiler frameworks regarding optimizations (like mlir/llvm).
GDShader gets translated to glsl when compiling
Great talk! I know nothing about shaders but it was still very interesting!
I see a focus on moving towards temporal effects, is this going to cause ghosting problems like other engines? Because if so then that's not really a direct upgrade from existing implementations if not a downgrade for a lot of people.
About those FP16 at 23:38 What was not completely clear for me is do we need to take care our self not going over that 65504, or will the engine do that for us in the background. And if we need to do it our self, how would that work ( where to look for )?
When writing your own shader, it depends completely on what data you're passing from the rest of your game and the shader itself, so the engine can't handle it other than maybe a build step warning rarely. They will have made those considerations if it might be enabled in certain built-in shaders with exports like on mobile or with compute shaders, I'd imagine though.
The rendering of this video is top notch. I loved the shaders.
great work an talk. We are waiting for AAA projects made with godot, to battle-test it
the background pipeline stuff+ubershader is huge, for what i'm testing in 4.4 it works great. hopefully now that the pipeline has been reorganized, someone can start working on data streaming and stencils.
thanks for the hard work
The entire level in Vram, is the most frustrating limitation for me.
I have chosen to focus mostly on the construction of the massive open world game levels im trying to make hoping the means to stream assets eventually becomes A priority. That and collecting knowledge on how open world games are optimized to take as little of that Vram as necessary.
Been reading a lot of Simon Schreibt's blog lately.
I have heard there is A way to manipulate textures from compute shaders, so there may be A way to load new textures by replacing others in an atlas as new texture data is needed, but making meshes in compute and passing them to the main pipeline is as best I can tell from watching the discord, not possible without going through the CPU first.
That and just having trouble getting an understanding of what can and cant be implemented with the new compositor features.
Admittedly I haven't read the code, but just by the docs, Basiaan's streams and clays talk last year I got the impression I should be able to do things that would otherwise require A dedicated stencil buffer, but when asking around I get the impression that's not possible. Okay cool.
Recently I have been looking into tech art for assets and wanting to know how different asset choices effect render performance, this leads me to looking at Unity's optimization shaders showing things like light overlaps or the cost of your topology with quad overdraw shaders.
I know the devs don't want any more built in view shaders because of having to distribute A lot of compiled shader blobs to account for all the variations without killing in engine runtime performance, but I am having trouble getting A handle on if making these things as installable compositor effects is possible.
I'm sure there is A path to me being smart enough to understand this, but I dont know where to start aside from just learning how A general rendering pipeline works(the GLSL docs?) and then read the code, which are some big steps from just barely understanding shaders.
IDK Ive been trying to learn Godot and wait for it to get good, since 3.3 which isn't that long compared to some of the others, but I'm still frustrated and don't know what else to do.
don't know what your game looks like, but this "oh we need texture streaming" is a very recent problem and so I've never had it.
for an open world with terrain, you divide the level into chunks and load them when getting close to their area (this also works for assets like rocks and buildings that are distant) and remove them when far enough, this is what the fallout and skyrim engines do. for closed levels you load a different level when reaching a point, like in source.
if your level has buildings, loading the interior of buildings separately means the furniture and stuff that's inside is not present in the outside scene and vice-versa.
finally, when using premade assets, you are supposed to edit them by packing textures and adjusting UVs so multiple objects share the same material. and for small objects, reduce their size to the space they occupy in screen. a 4k texture on a bottle is for a first person shooter, not a third person game, because such an small object will not occupy much of the screen, so a 256x256 or 128x128 texture or even smaller is enough. we also do this when objects are distant, when a tree is too far away it is replaced with a cardboard cutout, and a bottle could be replaced with a lower quality version, and this can be made with gdscript.
the rest is a problem of *level design* , not technology. we have been designing levels to avoid rendering the entire world for decades now, this also helps with levels with chunks. look at how games add mountains and verticality and tunnels to break the levels into smaller parts that can be visible separately. this also greatly helps with gameplay and worldbuilding and reduces the amount of work that needs to be done.
@@jesusmora9379 I am aware of all of these things as my focus the last few years has been specifically on optimizing for large levels, but I do appreciate your effort to give me so much useful info in one place.
My goal is making large scale community driven copyleft games.
The approach I am taking is to build multiple large open world levels like city's and forests using mostly the techniques you just mentioned, so that there is lots of room for people to contribute assets that will only need to be be loaded in the building they're working on for example.
If I can take the immersive sim approach of making the mechanics have emergent interactions, then setting up A pipeline for contributors to make content fitting those mechanical systems. I feel like I can make it easy for A player to be playing, imagine A cool new sword after picking one up they like but wish was different in some ways, and then contribute A sword they would prefer.
For this to work well I have to make systems that allow me to figure out how to best integrate new assets without breaking the existing optimizations, On my list is A tool for using heuristics to decide Hlod clusters for example.
Another more important thing on that list and what im currently working on is A bidirectional live proxy based pipline with blender, so that the primary storage form for assets can be res files which is important because of the way resource optimization inevitably makes all of your res files dependent on each other, this modularity is great for performance and also storage as the files are modular, but because they are still files you need to decide ahead of time where the splits will be or just make them all individual and make something to group them on release to avoid reading hundreds of little res files.
Anyway thanks again for the advice!
@@nullvoid3545 that is a lot of features for a solo or even indie dev, it's the kind of thing that benefits from a custom engine and not an all-purpose one like godot. it also sounds a lot like an MMO, which is something you are not supposed to do unless you are company with lots and lots of employees and actual programmers, at which point you would just modify the engine's source code.
and if you ARE an indie dev, I really hope you are using lower quality assets like low poly and stylized, because trying to work in something like that with assets of a quality that would give you trouble with the engine's rendering is just insanity (or inexperience).
anyways good luck with your project.
@@jesusmora9379 I'm less worried about getting A game to market and just focusing on making games easier to make together.
Industry's are directly at odds with the value of media, and things like Godot putting the effort into making game dev more accessible not just to create but to share as well is what I aim to spend my time contributing to.
That's why I'm so focused on tooling.
Godot is great for games of many kinds, but games made collaboratively for the purpose of play is what I want to enable specifically.
We will get there when we get there, I have plenty of time.
@@nullvoid3545 TO add on to what jesusmora said, if this goes in the direction of an MMO...
"Our goal is making a single large scale game", as in: 2-4 years with a double-digit team of full-time people, has a chance of failure of like, 90% or so.
So "My goal is making a single large scale game" already sounds EXTREMELY ambitious.
"My goal is making large scale games"... like, MULTIPLE... oh my
Super interesting watch. Love the updates and work ethic on improving Godot. One 2D renderer wish is having more efficient ways to implement or visualize 3D objects in 2D views.
Loved the talk!
As someone working in *massive* mobile games, be careful with shader complexity and combinatorial explosion with specialization constants. Outside of Apple, the hardware is still designed for ridiculously small and simple shaders and pipeline compilation, along with its memory usage, can be a royal pain to work around if you can at all. I could wine for hours and hours about how little the mobile GPU companies and the phone manufacturers support moderately old GPU's with driver updates. (It's a complex topic I know, but it boils down to money.) The PC GPU ecosystem, minus custom laptop integrations, is soooooo much better.
7:20 What??? I recently made 4.3 html game and stutter is still persistent? I did not find any new workaround aside from that "showing every object for one frame". Am i tripping or something?
This is a 4.4 change
@@Soremwar OHHHHHH. Now i get it, alright then
4.3 Stable is actually less stable for me compared to 4.2.2
Issues like #95772 makes using Godot with the compatibility renderer during play-testing a pain in the ass.
GPU Particles 2D is a lagfest when changing basic settings on 4.3 compared to 4.2.
Web exports are broken on 4.3. Web games literally make the browser unresponsive, at least on machines with basic Vulkan support or rely heavily on OpenGL. I.e Gen 7 and earlier intelHD Graphics
Introduction of the Google Angle fallback compatibility renderer downgraded the openGL version from 3.3 to 3.0 which inturn someone pushed a commit for a "blocklist" for machines "without proper support" for OpenGL 3.3 thus causing all the issues I listed above and more minor ones.
Unless these issues get addressed since Im primarily a Compatibility Renderer user, im switching to Defold. Yeah, it has less features, but it is stable.
Looking forwards to per-instance uniform variables for 2D shaders. Would unlock a bunch of performance bottlenecks for the games that heavily rely on large amounts of shaded objects, as I've experienced in my own game. Great talk!
One type of light which is Missing in Godot is the Area light!
Looking at the games I have analyzed, I actually believe that these things will be successful and will even develop further. Last time I analyzed a mobile game called “GSS Match” and I realized that most of the things said will be successful in this game.
This is the one I was waiting on.
Godot has a limit on how far can the camera be.
And graphics glitch out when too close or too far.
That's because of floating point precision.
Why not use INTs or even UINTs?
That would allow basically infinite precision and range, with some modifications.
Because ints have far less "precision"? It's gonna glitch out at a value like 0.5 already, which is far from where float precision becomes an issue.
NOTE: That was kinda "not even wrong" (en.wikipedia.org/wiki/Not_even_wrong), and hurt a little to write, but was the most succinct explanation I could think of.
Awesome updates 🔥
What immediately drew my attention at the beginning was the green rim lighting you had. Also, now I'm REALLY confused. I always thought it was Gō-dŏt. I was sure. Then you pronounced it as Gu-doe.
I think officially its like how he pronounced it. Godot comes from the title of the play "Waiting for Godot" by Samuel Beckett, so it will be that pronounciation. However I noticed Juan ponounce it Godot where o is pronounced as in "on" (both "o"s). Most people however misunderstand the name as Go-Dot, which is just wrong.
So the correct way is GOD-oh / guh-dow
@@jumpsneak Very interesting. Thanks!
Juan has horrible accent in English, he is definitely not the authority in pronunciation and phonetics.
Rive please.
Rive.
I said Rive right?
Rive please.
how many developers work on godot? It seems like there are like 1 or 2 at best
its an open-source project so, technically its hundreds of people
there's like 10-20 people hired full-time but I don't know the exact number
their entire rendering team is just Clay John though 😭
2745 contributors on github
You can contribute too tbf
100th like!
I swear Americans will make conferences/conventions about literally anything and everything at this point
I guess you are technically correct, since the OG devs of the engine are from Argentina.
Godot 4 and 3d = misconceptions for renderers and physics engines. They should actually throw everything away and do it again. It doesn't make sense and is just unsatisfactory for everyone. They simply didn't know any better back then. But now they should know better and pull the ripcord and think about the future. A render engine with this performance and visuals should be buried
idk Jolt Physics is somewhat alright for me for now tbh
I agree that the decision making in the past for 3D wasnt great. Sometimes it was a head scratcher for me. But I feel like they are on the right track now
@@Kiyuja Unfortunately not. There is a lack of self-reflection. Juan has always been known for his big mouth. Big announcements and then not delivering. Nobody has the courage to say anything against Juan. No matter what area, the deeper you delve into Godot, the more you will notice how bad Godot is. It's OK for 2D. For playing around and learning too. But for serious 3D applications - and I'm not talking about AAA - it's just a big failure.
@@MegaManki and that's the problem: you criticize something and people like you try to defend it by basically saying "f*ck off".
How many serious 3D applications have you made with Godot yet? None? Because if you actually did, you would know exactly what the problems are. The whole 3D renderer is a big mess with countless problems, yet it keeps getting ignored because people say "it will get better" over and over again for years without anything happening because of the broken foundation.
Some examples: try removing water from a boat (the classic, I know), try implementing outlines for a single object in screen space, try to use GPU tessellation, either through Vulkan directly or compute shaders. Let me know how many lines of the renderer you had to change in order to achieve that.
No other major game engine has such deep flaws in their 3D renderer. Even the lesser known ones like Flax or Stride can do all of that easily without adjusting the renderer code. But for some reason you are telling people to "go back to Redot" when they ask for basic features like that? No wonder nothing is changing.
@@MegaManki Please stop, megamanki. behaviours like these are the reason Redot was created to begin with.
people voicing their opinions and criticism and you putting them into an opposing enemy camp, just like american politics. it sucks. unlike american politics theyre not trying to take away your identity and strip you of your rights, they are merely hoping for the game engine to get better. there is no need for this divide.
Never knew that Zucc develops game engines too! What a talented -man- reptiloid!
They're cousins /j
Changing back and forth, fishing for three days and posting on the internet for two days, always unable to grasp the key points of game engines, or possibly intentionally not doing it, is a way for open source software to continuously absorb funds and expand. Create problems, solve problems, and then create and solve problems again, over and over again. In the end, it was discovered that it did not evolve well until we were all old or dead. There are too many gimmicks and one-sided behaviors. I have been learning and using it since 2018, and it has been almost 7 years since then. I used to pay attention to every progress every day, and my passion was intense. During this time, I discovered many low-level problems, all of which stemmed from stubborn biases and the organizer's lack of superiority. But now I am a little tired of it.
It's precisely mentioned, that some people just earn money with such development. That's the style of GNOME foundation - make everything worse, change design just to change design, return the feature just to remove it next year. And don't forget to fund another "socially important" meetings for marginal groups, which of course won't solve the world inequality, but money will be flown into someone's pockets.
@@charlieking7600 I work for the government and this is annoying. They spent huge sums of money for "Awareness". I'm single and have gay friends, bringing me and my team to a fancy hotel to show a half ass slide show won't solve Violence against our partners and Homophobia.
godots renderer has stopped improving
15:52 Rive is awesome for vector art and animation. Adding support for its runtime would supercharge Godot into a 2D and UI animation powerhouse, plus finally adding true vector graphics support. Please consider it 🙏🏻
Incredible talk, healed me and filled me with hope 🥲
I was really excited about the clip_children feature (and the PR to improve it) for similar reasons (I even made 2 simple animations with it). Though it seems performance (particularly w/MSAA) and workflow are issues that may not end up in-scope.
------
With my testing, 3D seems like a better workflow with vertex colors (low poly+can be textureless). The materials (and prospect of unifying them with an import script for a useful general set) are the key here and really help give a nice look/functionality (though issues like transparency overlap I am not sure how to handle). Vertex shading will be a nice option too.
I am not the best with Godot or Blender so there are things that I'd like that I'm not sure are possible. Like animated meshes, particularly with grease pencil+geometry nodes. The one thing I tried (Blender visual shader setup for 2 vertex color attributes, one used for glow) didn't seem to import into Godot properly. Though I guess shape keys is a thing, and obviously armatures.
EDIT: I guess low-frame animations could definitely work just by animating the visibility of meshes. That might be wonky with collisions, though I don't know if a normal skeletal animations actually apply forces (say from a run animation) or not.
------------------
Comparing to 2D, being fully in-engine almost has some advantages like using an animationplayer for a polygon2d or its vertex colors is super easy... though editing vertex colors in Godot's list editor is more of a pain than Blender's workflow.
I almost want to use 2D for the animation+aesthetic (maybe w/a simpler non-clip setup), though with 3D it feels like I've rediscovered something and am fitting new pieces together to make it flow.
@@insomniac_lemon That is a very interesting experience! I also was looking around for alternatives. In the end, for what I need, Godot's built-in 2D bones + animation systems are more that enough. If you want to go further, the DragonBones addon seems like a perfect alternative to Rive. More so because it is already integrated and it seems very well mantained.
I think that if Godot had a bit more love put into ironing out the pesky bugs of the bones system, it would be perfect as-is.
And for vector graphics, Godot can scale up SVG files before placing them as bitmap images, plus there are some powerful addons that enhance this capability. So perhaps there is no need for vectors at runtime anyway.
@@josu_id well for me, I want the real thing. I don't really see larger bitmaps as a solution, I would sooner try 3D meshes in 2D (or simpler 2D polygons, as I've already said).
Or, SVGs as meshes in 3D seems like a thing you can get set up with addons. Even this somewhat defeats the point of bezier curves, so at that point I'm already preferring to manually-make meshes unless I could get NURBS support (or SDF models, there is an old plugin by Zylann but it has a few downsides and it is now unmaintained w/o 4.X support).
Godot's textmesh in 4.X is pretty nice especially with unicode characters, though I have not had luck with color unicode via different fonts (NotoColor, Twemoji). That and for normal unicode there seems to be no good way to handle color, I've recolored the entire texmesh with a shader but this is not perfect visually (2nd pass for another material) and it'd really be nice if this could be changed per-word (or even a global per-character list for unicode?)... I'm sure vertex color could probably could added via a shader (unless there is a better way?) but probably not by me any time soon.