To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/Acerola/ you’ll also get 20% off an annual premium subscription! #ad happy new year
I'm a software engineer that was working with web dev for a few years. Started learning game dev a month ago, and it was the most enjoyment I had in a very long time. Thanks for the great content.
@@WhatEverComesToMlnd My hobby is to collect new hobbies. The problem is the more hobbies I collected in my lifetime, the more stressed I feel because I rarely have time for any of them. I'm quickly attracted, dive in with a lot of energy, use all of my time to do the thing, then I'm good in it but not really good and then I move on with the feeling that I should do it more often again. Learning is not my problem, I have problems getting rid of old hobbies. In reality, I don't do them anymore but since of sunken cost, I have the feeling that I shouldn't abandon them because they are fun and I've already learned so much. Not sure what to do about this.
Godot is also intentionally made for making tooling. There are several features that were added almost exclusively for making tools, like multi window support. Also, the interface side of the engine is made in the engine
so you can make modding tools in godot? like imagine a custom VMF loader (so you can use Godot Editor for making Source maps, just can't compile them i suppose)
I love godot but as an active user I feel like the biggest thing holding the engine back is shaders. Maybe your involvement can somehow lead to them improving the rendering pipeline?
@@BarcelonaMove In what way exactly? Documentation wise? I haven't had much of an issue there at the very least by extrapolating the gdscript property and method names and just attempting to apply that in C# code standards. And debugging is pretty viable as well. Just curious what support issues you've had.
@@BarcelonaMove And don't even get me started on the VR Support for Standalone Devices, i would love to leave Unity behind, but i think it will take many more years until that is a feasible option for professional production...
I wrote a native godot extension in Rust that allowed me to render directly to a render texture within godot with a graphics pipeline I wrote in rust. It worked surprisingly well. I thought it was cool and served a very niche use case I had at work, but did not really see a wider use case until watching this video. The rust backend I used was wgpu, which meant I could write all my pipelines in native rust and use godot as the presentation layer. I imagine there might be some overlap with what you're trying to achieve here. Happy to share code if you read this and think you might find something like this interesting.
Nice, that’s smart. I really like the rapid development speed for gameplay with GDScript but being able to use an extension for an alternative renderer or any high performance / stable part of the code in a proper language like Rust would be the best of both worlds. I never had a Godot project mature enough that I needed native code yet and I found the iteration speed with Swift in Godot to be lacking for stuff like gameplay programming. But for more stable modules or a new renderer, that’s such a cool way to make Godot even better.
I'd personally love to check that out, if only because I've been following Rust's development in the GUI/game space a bit, and this sounds neat. Would this happen to be on Github or something? (But don't feel like you should publish it for my sake, though.)
Moving to an open source engine for your projects is really cool because not only is it free but you're free to do whatever you want with it. Both kinds of free
As a 1/250000 stake holder of Acerola shares, I want my share to be used to keep one two hundred and fifty thousand's of Acerola brain to constantly think of how he is doing a good job. Keep it up !
If that is not feasible, use my share to think of a subway surfers adhd sludge cat just like in your ads. Just keep the cat in your brain at 1/250000 power all the time.
> the year is 2026 > Acerola is now God-Emperor of the Godot shader pipeline > Unity is bankrupt > Unreal is barely scraping by on Fortnite money > they simply cannot compete
If unreal fails it will be due to the declining quality of AAA games, which are too expensive and so they rely on premade assets and code too much to reduce costs. Combine that with poor storytelling due to the game length limitations and you end up with just repetitive multiplayer games.
its super cool hearing these news! godot feels like exciting new ground, and im happy to see more people trying it out (and adopting it). congrats on this year's achievements!
Damn I hope Godot adds an easier way to add compositor effects... working with the vertex and fragment shaders with the built-in editor is SO simple, but going that extra step further really makes it complex.. But I guess that also makes it fun.
By using godot you are contributing to a new era of game dev. Unity might be capable , powerful and popular, but its old, sometimes starting fresh is better than improving.
At most you could say Unity's practices (whether in DX or in business) are archaic, but I don't think it should be discarded just for standing the test of time... With that being said, I ♡ Godot
Ever since I found out about the new compositor API for godot I've been excited to keep sinking my teeth deeper into them. The real pain I had attempting to use them so far has been attempting to understand the vulkan component of setting the pipelines up. I'm incredibly hopeful that referencing your implementations for the vulkan api calls will shed light on a lot of the mystery and confusion I've had so far.
When I moved to working with URP over built in, I initially felt the same, that I much preferred working with shaders in built-in. However after a couple years I don't think I could go back without wanting to boil my head, once I got familiar with URP and over the differences, I started enjoying working with it more than I did with built-in, despite my initial experience, but it took a while to get to that level of comfortability. Admittedly my shaders aren't extremely complex and don't require much access to complex lighting data for example, so I can't judge for myself whether built in or URP has nicer APIs provided. Is there a particular part of URP that you dislike so much? Godot is very interesting, it is lagging behind in a few areas, shaders and graphics mostly, but I can't wait to see where it gets in the future. If nothing else switching to Godot for your projects is a good learning opportunity as well.
I believe @theftking here is referring to SRP as Standard-Render-Pipeline = Built-In-Render-Pipeline, not as in Scriptable-Render-Pipeline. I’m also curious about this.
After recently moving to Godot from Unity myself, I'm very happy with the choice. There's the obvious learning curve of a new tool but working on projects consistently helps mitigate that. Looking forward to seeing how your projects turn out in the future Ace!
That's huge! I was kind of bummed last time I tried to put my hands into rendering stuff in Godot, but now I'll be able to go back into Vulkan madness to do what I want! Also, the Godot reshade project is really cool!
Hello. I have been watching your videos for a while now and I wanted to leave some encouraging comments. Because the work you do is great. And because I already suspect there will be some weirdos in the comments pushing their culture war on you. I generally don't comment unless I feel like I have anything significant to add, and I have very limited experience with shaders so I rarely have anything to add to your videos. But I just want to say this time that I have always appreciated the sheer inspiration your videos give me. Please don't stop doing what you do.
I wonder, did "acerola" come from the fruits name? Acerola Is very popular fruit here in Brazil 🇧🇷. In every video and every time you say it I think about the tiny red fruit. Is it strange?
Nah it's a reference to a vampire character named "Kiss-Shot Acerola-Orion Heart-Under-Blade" (also known as Shinobu) from the Monogatari series, which is a light novel series that has an anime adaptation. Title screens like 0:20 are recreations of the ones seen in the anime.
This is the best news I've heard about 2025 so far. I've been using Godot for my own projects, and starting my journey into shaders with this engine has undoubtedly been a challenge.
I hope one day we can get an Open Source game engine as amazing as Blender is for 3D modeling. Hopefully with talented people like you in the community, Godot can continue trying to work its way towards that goal.
Ok so after watching the video fully, this is actually really fucking cool, especially the export of shaders. Since it will eventually be Open Source, have you considered trying to get it committed to the official release of Godot?
Godot has a policy of not including too specific things in it, like the Terrain3D addon, it's not applicable to everyone, might not receive long term support, and actually makes developing it harder compared to an addon.
GDExtension w/ C++ is always an option as well... but I wonder how much integration beyond the Compositor he would actually benefit from. Sounds like the Compositor might meet all of his needs out of the box, though more approachable access to GLSL support might be helpful for some of us, it might not be for Acerola. I'm looking forward to his impressions as he shares them throughout the upcoming year! In the meantime, I'll be hoping for support for sharing buffers between Compute and Fragment shaders :3
welcome to Godot! I'm beyond excited to have you working with the compositor API!! I've wanted to play with it myself, but I'm still a beginner to graphics APIs, so this new tool of yours will be amazingly helpful for the growth of the engine I think! cant wait for the super cool stuff in 2025 :D
Very happy to see you moving to Godot! Looks like it was a great year, and 2025 looking to be better! I wish you good luck with your project and learning process!
Might be neat to have the image compositor program use a node-based system instead of a list, that way you could just have the graph sit on top of the image which resides permanently in the background (so your eyes can be on both the image and the value-selector area at the same time)
Godot was what got me into programming at 29 years old. That also made me watch your videos because i got really into graphics. Happy to have you in the community.
This is a late christmas gift. You have no idea how excited I am for this. I've been trying to translate your shader work into godot for some time, but I just lack the skill to do so.
this might not be that related to the topic at hand, but your shader project has reminded me of a game i played a while ago called "Carceri". It's a pretty basic 3D colectathon game, but it's main appeal comes in the form of an in-game camera that has a BUNCH of different shader settings that can be applied together for different effects. I'm really not that knowledgable about shader magic myself, but if you'd take a look at it and decide if it'd make for an interesting video I'd love it if you'd explain how each of the shaders the game can use and combine works, especially the more complex ones.
Your channel has been such an awesome find for me this last year. I appreciate that you don't shy away from the math. Way to go with all you've accomplished!
don't know if this has already been said... allowing people to save custom presets for the image editor thing could be really useful if people want to apply the same (or similar) effects on different images
So pumped to see you moving over to Godot! I have implemented a couple of your shaders in Godot, and really enjoy working in it. Looking forward to the new year!
If you like C# have a look at the free and open-source game engine Stride! It has the best shader language that exists (!!!), is faster and has a more flexible high-level rendering pipeline than Godot.
Awesome. I would be happy to see devlogs of your progress re-implementing all those shaders, but I don't know what portion of your audience would want to see that.
I really want to like Godot but I am constantly running into "HUH??? Why doesn't this work" and then either no one online can help or the people that can help are extremely rude, or the help I finally manage to get is literal magic ritual because "Godot just works that way" like absolutely insane editor inconsistency and gltf import nightmare bullshit. Just trying to do BASIC things and hitting walls... But I wanna do FOSS....
Godot on the surface is great, but as soon as you try and make any kind of remotely serious project, its limitations and general shortcomings hit you like a truck. I really wouldn't advise switching to it, especially as a graphics programmer
Godot just isn't mature enough to swap to for the vast majority of people. There was an initial "GODOT HYPE!" period, but otherwise the engine simply isn't mature enough. It also has been in development for quite a while for it to be in the state that it is in.
@@lifeartstudios6207 Im sure its true with any engine to some extent. But godot is particularly bad even with simple things like bringing in assets or working with the editor. Ive had so many instances of features flat out not working, performance sucking for no reason, editor crashes, instances of asset corruption, instances where its just impossible to do what I want (especially from a rendering standpoint) If I had to put it into words, Id say the ratio between its good and bad parts is worse off than any other engines Ive seen. It doesnt offer nearly enough to make its problems justifiable or usable, even for an open source project. Its a relatively basic engine all things considered, theres no excuse. Youd save quite a bit of time in the long run just by making your own engine, even for 3D
I'm a game art student with experience in Unity, Unreal, and Godot, and I have to say that Godot unfortunately has some pretty big UI design flaws that make it difficult to use. When it comes to selecting objects, and multi-selecting especially, it is really unintuitive and at times borderline unusable. There have been a number of times where I had to resort to manually selecting in the hierarchy because selecting through the viewport didn't work. The shader editor, while being good enough at a basic level, is missing some very useful functionality that's practically standard and used all the time in Unity and Unreal. Things like transforming the UVs or configuring backface culling do not have properly implemented functionality. Being unable to customize the UI windows to your preference is also a huge drawback for me. While it is customizable, it's still limited to a number of preset configurations, which means I can't just drag and drop windows to make them the way I want them to be. And as a last point, Godot simply does not work with my laptop's processor. When I run a scene, a lot of the time it does not start, and the only viable solution is to get new hardware. While Godot surely has come a long way, it still has a bit to go before it becomes a viable alternative to me
"Things like transforming the UVs or configuring backface culling do not have properly implemented functionality." what are you talking about? you can literally just do these things
@@wareyathe only thing I can think of is if it's a visual shader (as in the shadergraph alternative) thing? I don't use those so I don't know but yeah they are very much possible in text shaders lol
@@plusonerabbit visual shaders have backface culling as a mode selection in the resource property editor, and UV transforms are done in visual shaders with normal vector math nodes
UX Request. When setting a performance budget, have a visual indicator when you've gone over, but don't stop people from being able to experiment and toggle things. So they can be alerted of the issue, but not forced to deal with it before continuing. Would also be good to have "save states"/checkpoints/snapshots of the settings as you go, so you can quickly toggle between looks when experimenting.
You should also make the tool be able to export the shader arrangement so that: 1. People could share/exchange them 2. A plugin could be made that applies them as a postprocessing filter in games made in Godot
I also moved from Unity after decade+ work exp, for personal projects. But instead Godot I decided to go with own C/C++ engine. Tried "let's make an editor" path about a year ago, went decently well, but not much was done in terms of graphics, and I returned to Unity for some time. About a month ago decided to start again, now with multi graphics API in mind, and beginning with DX11 instead OpenGL. I come up with cool idea - export Unity scene to my engine, and make it work. This way I could see what I'm missing, and I can directly compare performance. Now I'm more or less done with graphics core. - More or less all abstraction are done(Textures, Color Buffers, Shaders, Vertex/Index/Constant buffers, etc) - Own math library (vector2-4, matrix3-4, plane, quaternion, .. mostly taken from my first attempt) - Shader passes and material system + PBR Shading - Optimized draw queue (less shader/material rebind), sorting - Flexible Frustum Culling - Cubemap generation + PBR Convolution generation on GPU - Text rendering system + dev console - Shadow via Shadow Map I'd say "first 90%" of graphics features I need ready, and now I can refactor and start working on physics and scene. Funny enough I already have better visuals and about 5-10x faster runtime. Even without SIMD and cache locality optimizations, so I'm good for now :) P.S. My C++ skill is mid at best. 1st attempt was literally my first experience with C/C++ after C#. Now I'm writing something like "C with classes", since I don't like modern C++ style
5-10x faster runtime? That is huge, i am assuming we are talking about graphical performance? Can you make a comparison of the scene in unity and your own engine?
@ yeah. It’s hard to compare 1 to 1, because of little differences, but whole picture is visible anyway. Unity version uses Built-in Render, most materials with Standard shader, 4 shadow cascade, 1 direct light source, 1 reflection probe, no baked GI, no Batching, linear color space, forward render. In this scenario Render thread is about 2ms. In my engine shaders are different (more similar to UE), obviously different culling and sorting algorithms, plus ACES tonemapping in final blit. My render loop is about 0.2-0.4ms, and can be easily improved further. This difference comes from many factors. Unity is far more flexible, and have more features (they not used in test scene, but support cost something as well), some things are strange, and not very optimized, like screen space shadow cascade blending, instead of blending in forward shaders, excessive intermediate RT and multiple blits ( support for stuff like OnImageRender I believe) Surely custom SRP will have more similar performance, with main difference in Culling
I have literally been waiting for this for months now. I hope you revise some stuff you already went through and how to do them in Godot, because it's so much different than Unity.
I cannot tell you how excited I am to hear this. I've been eyeing the compositor stuff since it first dropped, since it seems perfect for a thing I've been wanting to make, but have been too intimidated by the complexity and lack of organized resources to take the dive. A decent resource showing how it works in practice with examples that you can play with yourself will probably be exactly the push I need to get me over that hump. Can't wait. 🙏
As a Godot user whos been struggling to learn shaders, i am so hype. Been following you since your first FFXIV shaders (at least the first ones i saw) and i look forward to seeing how you take Godot to the next level!
Never in my life have I clicked so fast on a RUclips thumbnail. Now that I'm finally commenting, I'd like to thank you for you amazing work, and I hope you'll be able to continue along that path as long as you want. I can't wait to see what wonders you'll come up with in Godot. Have a nice day!
To be honest, this wasn't much of a surprise. Acerola already mentioned dabbling in the dark arts of Godot and has expressed his dislike of the render pipelines that weren't the built-in. Unity essentially handles the built-in as a deprecated rendering pipeline as they wanna focus on URP and HDRP and later possibly combining the two since a large portion of the pain in Unity comes from there being so many different pipelines for no reason. It really was an inevitability. I just hope the change won't attract the part of the Godot community that drove me away from the engine (the Linux users of game engines if you will).
To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/Acerola/ you’ll also get 20% off an annual premium subscription! #ad
happy new year
Seeing you move to godot sparks so much potential in the engine for me, I'm excited to see all that can be done!
happy new year acerola 🎉🎉🎉
Very classy outfit 👍
I'm a software engineer that was working with web dev for a few years. Started learning game dev a month ago, and it was the most enjoyment I had in a very long time. Thanks for the great content.
@Acerola_t for sharing/exporting: You can export a packed scene that others can import as a node into their project
Learning is not only fun, it's also way cooler than not learning things
Learning is one of my hobbies fr, i love it so much
learning is painful as fuck though and takes the time you could spend reading books or playing video games
@@WhatEverComesToMlnd My hobby is to collect new hobbies. The problem is the more hobbies I collected in my lifetime, the more stressed I feel because I rarely have time for any of them. I'm quickly attracted, dive in with a lot of energy, use all of my time to do the thing, then I'm good in it but not really good and then I move on with the feeling that I should do it more often again. Learning is not my problem, I have problems getting rid of old hobbies. In reality, I don't do them anymore but since of sunken cost, I have the feeling that I shouldn't abandon them because they are fun and I've already learned so much. Not sure what to do about this.
@@gagaxueguzheng Combine hobbies by making a Warhammer calculator or art in Blender etc.
How to learn? I am bad at it.
but acerola...
nice!
your posts have been a great inspiration for the decision to move thanks goat
🍻
You are one of the most inspiring godot and blender users for me and my best friend. Thank you!
we're about to witness even more godot shader magic and visual effects rituals than what you yourself can summon
When I grow up I want to become a passivestar! Both of you doing Godot stuff is honestly great news.
But Acerola... You're unironically building the modern Godot shader library on your own! Doing God's work here man, thanks for the hard work.
There’s an entire site with shaders for Godot.. it’s called ‘Godot shaders’.
Doing God(ot)'s work
@@hundvd_7 both can be true..
@@hundvd_7 beat me to it
@@hundvd_7 Considering it's open source we are all Godot
I look forward to seeing Acerola inevitably contribute directly to the Godot project
The shareholders demand you start taking more pictures
Godot is also intentionally made for making tooling. There are several features that were added almost exclusively for making tools, like multi window support. Also, the interface side of the engine is made in the engine
then they made milti window games like windowkill lol
Yup. There are quite a few tools made with Godot too
@@zeta3341 yea like pixelorama, or material maker, or rpg in a box
The Godot Engine editor being a Godot Engine game itself is the best example
so you can make modding tools in godot? like imagine a custom VMF loader (so you can use Godot Editor for making Source maps, just can't compile them i suppose)
I love godot but as an active user I feel like the biggest thing holding the engine back is shaders. Maybe your involvement can somehow lead to them improving the rendering pipeline?
Also the C# support is terrible to say the least
@@BarcelonaMove In what way exactly? Documentation wise? I haven't had much of an issue there at the very least by extrapolating the gdscript property and method names and just attempting to apply that in C# code standards. And debugging is pretty viable as well. Just curious what support issues you've had.
@@BarcelonaMove And don't even get me started on the VR Support for Standalone Devices, i would love to leave Unity behind, but i think it will take many more years until that is a feasible option for professional production...
@@BarcelonaMoveeverybody says this, but I've had no problems so far with c#
@@DonC876I haven't tested on standalone VR devices yet, but Godot seems to have no issues with my sort of scuffed Quest 3 on Linux setup.
I wrote a native godot extension in Rust that allowed me to render directly to a render texture within godot with a graphics pipeline I wrote in rust.
It worked surprisingly well. I thought it was cool and served a very niche use case I had at work, but did not really see a wider use case until watching this video.
The rust backend I used was wgpu, which meant I could write all my pipelines in native rust and use godot as the presentation layer. I imagine there might be some overlap with what you're trying to achieve here. Happy to share code if you read this and think you might find something like this interesting.
Nice, that’s smart.
I really like the rapid development speed for gameplay with GDScript but being able to use an extension for an alternative renderer or any high performance / stable part of the code in a proper language like Rust would be the best of both worlds. I never had a Godot project mature enough that I needed native code yet and I found the iteration speed with Swift in Godot to be lacking for stuff like gameplay programming. But for more stable modules or a new renderer, that’s such a cool way to make Godot even better.
that is so sick dude
I'd personally love to check that out, if only because I've been following Rust's development in the GUI/game space a bit, and this sounds neat. Would this happen to be on Github or something? (But don't feel like you should publish it for my sake, though.)
Moving to an open source engine for your projects is really cool because not only is it free but you're free to do whatever you want with it. Both kinds of free
gratis AND libre; a fine combination.
As a 1/250000 stake holder of Acerola shares, I want my share to be used to keep one two hundred and fifty thousand's of Acerola brain to constantly think of how he is doing a good job. Keep it up !
If that is not feasible, use my share to think of a subway surfers adhd sludge cat just like in your ads. Just keep the cat in your brain at 1/250000 power all the time.
2nd that
a standalone "shader playground" sounds really cool, can't wait to see what you're cooking up next year!
probably baking
Another internet person I need to add to my list of cool Godot people
We gotta love new people joining the Godot Community :D
> the year is 2026
> Acerola is now God-Emperor of the Godot shader pipeline
> Unity is bankrupt
> Unreal is barely scraping by on Fortnite money
> they simply cannot compete
If unreal fails it will be due to the declining quality of AAA games, which are too expensive and so they rely on premade assets and code too much to reduce costs. Combine that with poor storytelling due to the game length limitations and you end up with just repetitive multiplayer games.
> Half-Life 3 releases along with the Source 2 SDK
@@jesusmora9379 Because of the bad rep, people who make good games will avoid Unreal.
From there, UE will start declining in usage.
"Why I'm Moving To Hazel In 2026" this time next year 😉
so true
2026 is the year of the hazel game engine!1!11
The shareholders express confidence in the management's decision to move to Godot
oh boy! now i can pretend im being productive by watching your videos in the same game engine as you!
its super cool hearing these news! godot feels like exciting new ground, and im happy to see more people trying it out (and adopting it). congrats on this year's achievements!
Damn I hope Godot adds an easier way to add compositor effects... working with the vertex and fragment shaders with the built-in editor is SO simple, but going that extra step further really makes it complex.. But I guess that also makes it fun.
I believe they will eventually, it's just such a new feature its basically still in testing phase.
I don't know who you are, but we welcome you in Foss and Godot
Godot is such a joy to use. Once you get your bearings it doesn't take a tutorial to make anything new, unlike most other engines (in my experience).
By using godot you are contributing to a new era of game dev. Unity might be capable , powerful and popular, but its old, sometimes starting fresh is better than improving.
True
Ehhhhh
This is game engines we're talking
Not getting a job...
Far parallel: restarting VS refactoring.
At most you could say Unity's practices (whether in DX or in business) are archaic, but I don't think it should be discarded just for standing the test of time...
With that being said, I ♡ Godot
@@timlwry Though it can be a tool for quite a few jobs, game development either it be solo or a team, offers an umbrella of jobs.
Unity community losing Acerola is equivalent to jjk sorcerers using Gojo
maybe its the Geto situation though? :x
@@ererbe who is Geto in this situation though? Sebastian League?
meh
Unity forums losing Bgolus would be worse.
Bruh engines don't actually matter what matters is game dev
Ever since I found out about the new compositor API for godot I've been excited to keep sinking my teeth deeper into them. The real pain I had attempting to use them so far has been attempting to understand the vulkan component of setting the pipelines up.
I'm incredibly hopeful that referencing your implementations for the vulkan api calls will shed light on a lot of the mystery and confusion I've had so far.
probably where I'll start too
6:22 Omg, I love Freya Holmér so much, probably my favourite creator now, so cool to know that Acerola watched her content too!
;-;;;
When I moved to working with URP over built in, I initially felt the same, that I much preferred working with shaders in built-in. However after a couple years I don't think I could go back without wanting to boil my head, once I got familiar with URP and over the differences, I started enjoying working with it more than I did with built-in, despite my initial experience, but it took a while to get to that level of comfortability. Admittedly my shaders aren't extremely complex and don't require much access to complex lighting data for example, so I can't judge for myself whether built in or URP has nicer APIs provided. Is there a particular part of URP that you dislike so much?
Godot is very interesting, it is lagging behind in a few areas, shaders and graphics mostly, but I can't wait to see where it gets in the future. If nothing else switching to Godot for your projects is a good learning opportunity as well.
I'm curious as to why writing shaders for URP is so much more unpleasant for you than SRP.
built in is not srp
I believe @theftking here is referring to SRP as Standard-Render-Pipeline = Built-In-Render-Pipeline, not as in Scriptable-Render-Pipeline. I’m also curious about this.
@@Acerola_t yeah I meant "standard render pipeline". In hindsight, it's not a very good acronym for built-in.
After recently moving to Godot from Unity myself, I'm very happy with the choice. There's the obvious learning curve of a new tool but working on projects consistently helps mitigate that. Looking forward to seeing how your projects turn out in the future Ace!
That's huge! I was kind of bummed last time I tried to put my hands into rendering stuff in Godot, but now I'll be able to go back into Vulkan madness to do what I want! Also, the Godot reshade project is really cool!
Seeing this channel pop from 20k subs so fast has been a treat, congrats!
0:20 is this monogatari reference?
whole channel is, even his name
No it's obviously a Jojo reference
@@decmshuh, i somehow just noticed that.
Hello. I have been watching your videos for a while now and I wanted to leave some encouraging comments. Because the work you do is great. And because I already suspect there will be some weirdos in the comments pushing their culture war on you. I generally don't comment unless I feel like I have anything significant to add, and I have very limited experience with shaders so I rarely have anything to add to your videos. But I just want to say this time that I have always appreciated the sheer inspiration your videos give me. Please don't stop doing what you do.
Another day, another W for the Godot community :)
I wonder, did "acerola" come from the fruits name? Acerola Is very popular fruit here in Brazil 🇧🇷. In every video and every time you say it I think about the tiny red fruit. Is it strange?
Nah it's a reference to a vampire character named "Kiss-Shot Acerola-Orion Heart-Under-Blade" (also known as Shinobu) from the Monogatari series, which is a light novel series that has an anime adaptation. Title screens like 0:20 are recreations of the ones seen in the anime.
@VeilStar that's also cute
This is the best news I've heard about 2025 so far. I've been using Godot for my own projects, and starting my journey into shaders with this engine has undoubtedly been a challenge.
as someone who's been building a game in godot and dipping their toes into graphics programming, this is very exciting news!
I hope one day we can get an Open Source game engine as amazing as Blender is for 3D modeling. Hopefully with talented people like you in the community, Godot can continue trying to work its way towards that goal.
Ok so after watching the video fully, this is actually really fucking cool, especially the export of shaders.
Since it will eventually be Open Source, have you considered trying to get it committed to the official release of Godot?
Godot has a policy of not including too specific things in it, like the Terrain3D addon, it's not applicable to everyone, might not receive long term support, and actually makes developing it harder compared to an addon.
GDExtension w/ C++ is always an option as well... but I wonder how much integration beyond the Compositor he would actually benefit from. Sounds like the Compositor might meet all of his needs out of the box, though more approachable access to GLSL support might be helpful for some of us, it might not be for Acerola.
I'm looking forward to his impressions as he shares them throughout the upcoming year!
In the meantime, I'll be hoping for support for sharing buffers between Compute and Fragment shaders :3
welcome to Godot!
I'm beyond excited to have you working with the compositor API!! I've wanted to play with it myself, but I'm still a beginner to graphics APIs, so this new tool of yours will be amazingly helpful for the growth of the engine I think! cant wait for the super cool stuff in 2025 :D
Happy to hear that you are moving to Godot, I'm sure your contributions to the community will be invaluable
Thanks!
Happy New Year Acerola!
Welcome to the Godot club!
ONE OF US; ONE OF US
Glad to hear you're enjoying compositor effects, looking forward to seeing what you create with them :)
Very happy to see you moving to Godot!
Looks like it was a great year, and 2025 looking to be better! I wish you good luck with your project and learning process!
Nice new year gift, thank you Acerola
Welcome to Godot bro, I look forward to learning a ton from you!
Might be neat to have the image compositor program use a node-based system instead of a list, that way you could just have the graph sit on top of the image which resides permanently in the background (so your eyes can be on both the image and the value-selector area at the same time)
Godot was what got me into programming at 29 years old. That also made me watch your videos because i got really into graphics. Happy to have you in the community.
After 6 long years and many many work-hours later, Unity decided to undo the URP / HDRP pipelines and will go back to a unified rendering system...
thank you, godots shader library is a desert
Cool! can't wait to see what more you will make in Godot!
You're so inspiring. I'm happy to hear you'll be joining us on the Godot frontier
also I'm a lighting freak with a weak grasp of the technical side of engines so... I'll be looking forward to seeing what emerges
This is a late christmas gift. You have no idea how excited I am for this. I've been trying to translate your shader work into godot for some time, but I just lack the skill to do so.
this might not be that related to the topic at hand, but your shader project has reminded me of a game i played a while ago called "Carceri". It's a pretty basic 3D colectathon game, but it's main appeal comes in the form of an in-game camera that has a BUNCH of different shader settings that can be applied together for different effects. I'm really not that knowledgable about shader magic myself, but if you'd take a look at it and decide if it'd make for an interesting video I'd love it if you'd explain how each of the shaders the game can use and combine works, especially the more complex ones.
Your channel has been such an awesome find for me this last year. I appreciate that you don't shy away from the math. Way to go with all you've accomplished!
2025 is finally the year of the Godot desktop! wait what
don't know if this has already been said...
allowing people to save custom presets for the image editor thing could be really useful if people want to apply the same (or similar) effects on different images
But Acerola, why do you hate URP?
it was cool meeting you at Siggraph man, props for trying to improve godot!
Lets go yet another banger aceroller video
So pumped to see you moving over to Godot! I have implemented a couple of your shaders in Godot, and really enjoy working in it. Looking forward to the new year!
If you like C# have a look at the free and open-source game engine Stride! It has the best shader language that exists (!!!), is faster and has a more flexible high-level rendering pipeline than Godot.
Also shader hot-reload and composeable image effects are already available.
Major stability issues, though
@@GoblinArmyInYourWalls I didn't know that, my experience was very stable. What did you try and what was unstable? Do you have much experience with?
@tonfilm it might have changed from last year when i tried it, it crashed a lot
Stride is a hot mess.
beyond anything it's really great to know you've been focusing on your health a bit!!!
The goat is once again back and this time BUFFED!
4:08 gotta try that with bro 😊
Awesome. I would be happy to see devlogs of your progress re-implementing all those shaders, but I don't know what portion of your audience would want to see that.
But Acerola... Godot doesn't have AsyncGPUReadback!
it was merged for 4.4 three weeks ago haha
The project looks amazing ! hype to see all the next video about it ;) !
The thrid eye widens.
The tool you're working on sounds fantastically useful! Looking forward to it!
I really want to like Godot but I am constantly running into "HUH??? Why doesn't this work" and then either no one online can help or the people that can help are extremely rude, or the help I finally manage to get is literal magic ritual because "Godot just works that way" like absolutely insane editor inconsistency and gltf import nightmare bullshit. Just trying to do BASIC things and hitting walls... But I wanna do FOSS....
I had the opposite exprience? what's the problem you're getting exactly?
also "Godot is open source!!! Fix it yourself!!!"
What Godot version have you used because most of those UX problems have been fixed in Godot 4 and subsequent releases
@@gostan2718 no one says that.
@@gostan2718 Not even offering to walk you through it or at least pointing you to some tutorial...?
I look like forward to your Godot Wizardry!
Godot on the surface is great, but as soon as you try and make any kind of remotely serious project, its limitations and general shortcomings hit you like a truck. I really wouldn't advise switching to it, especially as a graphics programmer
Godot just isn't mature enough to swap to for the vast majority of people. There was an initial "GODOT HYPE!" period, but otherwise the engine simply isn't mature enough. It also has been in development for quite a while for it to be in the state that it is in.
same with unreal engine tbh
@@lifeartstudios6207 Im sure its true with any engine to some extent. But godot is particularly bad even with simple things like bringing in assets or working with the editor. Ive had so many instances of features flat out not working, performance sucking for no reason, editor crashes, instances of asset corruption, instances where its just impossible to do what I want (especially from a rendering standpoint)
If I had to put it into words, Id say the ratio between its good and bad parts is worse off than any other engines Ive seen. It doesnt offer nearly enough to make its problems justifiable or usable, even for an open source project. Its a relatively basic engine all things considered, theres no excuse. Youd save quite a bit of time in the long run just by making your own engine, even for 3D
1:16 Prototype mentioned. REEEEEEE
I don't think I'll be switching to Godot any time soon, but it'll be fun to see what you cook up now either way
I'm a game art student with experience in Unity, Unreal, and Godot, and I have to say that Godot unfortunately has some pretty big UI design flaws that make it difficult to use. When it comes to selecting objects, and multi-selecting especially, it is really unintuitive and at times borderline unusable. There have been a number of times where I had to resort to manually selecting in the hierarchy because selecting through the viewport didn't work.
The shader editor, while being good enough at a basic level, is missing some very useful functionality that's practically standard and used all the time in Unity and Unreal. Things like transforming the UVs or configuring backface culling do not have properly implemented functionality.
Being unable to customize the UI windows to your preference is also a huge drawback for me. While it is customizable, it's still limited to a number of preset configurations, which means I can't just drag and drop windows to make them the way I want them to be.
And as a last point, Godot simply does not work with my laptop's processor. When I run a scene, a lot of the time it does not start, and the only viable solution is to get new hardware.
While Godot surely has come a long way, it still has a bit to go before it becomes a viable alternative to me
Have you written a report about your crashes? I'm sure they want to target as much hardware as possible
your feedback is great but don't worry, the next flight to a convention will surely fix those problems!
"Things like transforming the UVs or configuring backface culling do not have properly implemented functionality." what are you talking about? you can literally just do these things
@@wareyathe only thing I can think of is if it's a visual shader (as in the shadergraph alternative) thing? I don't use those so I don't know but yeah they are very much possible in text shaders lol
@@plusonerabbit visual shaders have backface culling as a mode selection in the resource property editor, and UV transforms are done in visual shaders with normal vector math nodes
Happy New Year, Acerola!
Let’s go!!!! We got another one!!!!
Looking dapper my dude
Acerola to godot arc is a welcome arc
UX Request. When setting a performance budget, have a visual indicator when you've gone over, but don't stop people from being able to experiment and toggle things. So they can be alerted of the issue, but not forced to deal with it before continuing. Would also be good to have "save states"/checkpoints/snapshots of the settings as you go, so you can quickly toggle between looks when experimenting.
You should also make the tool be able to export the shader arrangement so that:
1. People could share/exchange them
2. A plugin could be made that applies them as a postprocessing filter in games made in Godot
Thank you!
best christmas gift, me and many are lucky to see you switching to godot!
Wah ! Waiting your CRT shaders, it will be awesome !
I also moved from Unity after decade+ work exp, for personal projects. But instead Godot I decided to go with own C/C++ engine.
Tried "let's make an editor" path about a year ago, went decently well, but not much was done in terms of graphics, and I returned to Unity for some time.
About a month ago decided to start again, now with multi graphics API in mind, and beginning with DX11 instead OpenGL. I come up with cool idea - export Unity scene to my engine, and make it work. This way I could see what I'm missing, and I can directly compare performance. Now I'm more or less done with graphics core.
- More or less all abstraction are done(Textures, Color Buffers, Shaders, Vertex/Index/Constant buffers, etc)
- Own math library (vector2-4, matrix3-4, plane, quaternion, .. mostly taken from my first attempt)
- Shader passes and material system + PBR Shading
- Optimized draw queue (less shader/material rebind), sorting
- Flexible Frustum Culling
- Cubemap generation + PBR Convolution generation on GPU
- Text rendering system + dev console
- Shadow via Shadow Map
I'd say "first 90%" of graphics features I need ready, and now I can refactor and start working on physics and scene.
Funny enough I already have better visuals and about 5-10x faster runtime. Even without SIMD and cache locality optimizations, so I'm good for now :)
P.S. My C++ skill is mid at best. 1st attempt was literally my first experience with C/C++ after C#. Now I'm writing something like "C with classes", since I don't like modern C++ style
5-10x faster runtime? That is huge, i am assuming we are talking about graphical performance? Can you make a comparison of the scene in unity and your own engine?
@ yeah. It’s hard to compare 1 to 1, because of little differences, but whole picture is visible anyway. Unity version uses Built-in Render, most materials with Standard shader, 4 shadow cascade, 1 direct light source, 1 reflection probe, no baked GI, no Batching, linear color space, forward render. In this scenario Render thread is about 2ms. In my engine shaders are different (more similar to UE), obviously different culling and sorting algorithms, plus ACES tonemapping in final blit. My render loop is about 0.2-0.4ms, and can be easily improved further.
This difference comes from many factors. Unity is far more flexible, and have more features (they not used in test scene, but support cost something as well), some things are strange, and not very optimized, like screen space shadow cascade blending, instead of blending in forward shaders, excessive intermediate RT and multiple blits ( support for stuff like OnImageRender I believe)
Surely custom SRP will have more similar performance, with main difference in Culling
I have literally been waiting for this for months now. I hope you revise some stuff you already went through and how to do them in Godot, because it's so much different than Unity.
omg i wanted to use your effects on my photography as soon as I saw them, this would be soooo cool :D especially the pixel sorter
welcome to godot gang
I cannot tell you how excited I am to hear this. I've been eyeing the compositor stuff since it first dropped, since it seems perfect for a thing I've been wanting to make, but have been too intimidated by the complexity and lack of organized resources to take the dive.
A decent resource showing how it works in practice with examples that you can play with yourself will probably be exactly the push I need to get me over that hump. Can't wait. 🙏
i will never do anything in game engines or shaders but i watch anyway
Haha me too
As a Godot user whos been struggling to learn shaders, i am so hype. Been following you since your first FFXIV shaders (at least the first ones i saw) and i look forward to seeing how you take Godot to the next level!
Never in my life have I clicked so fast on a RUclips thumbnail.
Now that I'm finally commenting, I'd like to thank you for you amazing work, and I hope you'll be able to continue along that path as long as you want. I can't wait to see what wonders you'll come up with in Godot. Have a nice day!
acerola focusing on godot is the best news I've heard this month, so happy to hear your plans for this tool!
LISAN AL-GHAIB!
Excited to see more of your stuff in the new year! Thanks for a year of great videos!
my day just got better with this news! the godot community grow stronger!!
i cannot express enough how the little wave you do in the beginning of your videos has etched itself into my brain
To be honest, this wasn't much of a surprise. Acerola already mentioned dabbling in the dark arts of Godot and has expressed his dislike of the render pipelines that weren't the built-in. Unity essentially handles the built-in as a deprecated rendering pipeline as they wanna focus on URP and HDRP and later possibly combining the two since a large portion of the pain in Unity comes from there being so many different pipelines for no reason. It really was an inevitability. I just hope the change won't attract the part of the Godot community that drove me away from the engine (the Linux users of game engines if you will).
When you said “Covid” I heard Cooperative Video and wanted that immediately. I’m glad you recovered. Backups are important.
ONE OF US; ONE OF US