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.
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.
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.
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.
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!
Stencil shadows could really help with rendering, if it's GPU-bound, because they're using CPU. I am waiting to listen why it's unnecesarry and why everyone doesn't need it.
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.
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 )?
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.
@@Blender.Quebec they got 5mil in funding 2 years ago and took 80% into their proprietary company instead of investing into godot development, people were mad about it and still are mad, gtfo
@@KillahMate and this is only the engine. The Witness was developed for 8 mln dollars and its performance is very well for indie game. And yes, it was built upon custom engine.
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).
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 😭
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?
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
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.
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.
After the woke influenced godot im still disappointed! Wokeness destroys everything! Not even saw a public official excuse for the drama! Sry, but going unreal now! Very sad how all open source turns into woke! Debian, too!
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 🥲
![เปิด อาณาจักร หมื่นล้าน "สาระตั้ม" l [Nickynachat]](http://i.ytimg.com/vi/3XE0nPF4YkQ/mqdefault.jpg)
Rim lightning fully implemented on John.
Rim
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
This is what I'm wanting
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.
What an excellent talk. Very glad to hear my sentiments about 3D shortcomings being addressed! Looking forward to see the improvements.
40:25 AMD FSR 3.1 is fully open sourced and available on GPUopen and has been for months.
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
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.
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.
Loving Vertex shading for mobile performance, and FP16 will be BIG! :D Great talk, and hoping to see more like this ^^
wohoo, the talk ive been waiting for
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.
30:00 UGH I WISH IT WAS SOONER , IT WOUDL REALLY HELP.
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.
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!
still hurts not to be able to set stencil and depth write in pipelines 😢
I agree. Also I'm missing custom render buffers.
Stencil shadows could really help with rendering, if it's GPU-bound, because they're using CPU.
I am waiting to listen why it's unnecesarry and why everyone doesn't need it.
great work an talk. We are waiting for AAA projects made with godot, to battle-test it
This could be the most important talk you have had, so far.
godot is going to be so fricking fast once they implement these optimizations, it's all really good
Is going. But well, that's continious state, never ending at all.
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.
This is the one I was waiting on.
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 )?
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.
3:58 there's one big unsolved problem - performance. Of course it gets better with time, but we may die of old age when it gets solved.
Then give them some $ so they can hire more ppl 🎉
@@Blender.Quebec they already have Ramatak, The Mirror and W4 games, gathering millions of dollars. Not even counting Godot Foundation.
@@Blender.Quebec they got 5mil in funding 2 years ago and took 80% into their proprietary company instead of investing into godot development, people were mad about it and still are mad, gtfo
@@Capewearer Millions of dollars is the budget of one medium-sized indie game.
@@KillahMate and this is only the engine. The Witness was developed for 8 mln dollars and its performance is very well for indie game. And yes, it was built upon custom engine.
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
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 😭
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
Never knew that Zucc develops game engines too! What a talented -man- reptiloid!
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.
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.
100th like!
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.
godots renderer has stopped improving
After the woke influenced godot im still disappointed! Wokeness destroys everything! Not even saw a public official excuse for the drama! Sry, but going unreal now! Very sad how all open source turns into woke! Debian, too!
WTF is "woke"?
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 🥲