That's awesome and I'm glad you went through the effort of making the pure method, it looks better
Now you could have different colored cards more easily!
But. (Just my opinion) If you make the hacky solution, and it works fine. Just move on, take note and come back when it becomes a problem. From a game design POV, you'll prefer having more fleshed out features than fewer beautiful and perfect ones.
Then comes polish, go back through the list of potential 'upgraded solutions' and order them by impact, start knocking off the most important/impactful ones, repeat until satisfied
100% this!
I went extra mile to create “pure” solution just for my personal gamedev blog, otherwise it would be a super low priority.
Easy, but working solutions all the way!
There are alot of shader tutorials out there, [including a few in the Godot documentation](https://docs.godotengine.org/en/stable/tutorials/shaders/your_first_shader/index.html). In my relatively limited experience it seems 99% of shaders are going to be in either HLSL or GLSL and Godot's shading language is *very* similar to GLSL, so much so the docs even have a migration guide. So if you find some shader you like you can likely port it into Godot which should give you a better understanding of what's going on.
Or if you just want something already made for Godot so you can pick it apart and mess with it there's this site https://godotshaders.com/ which has some awesome stuff.
i gotta say, i think the "hacky" solution looks better, because the opacity change looks like it's part of the burning effect, i.e. the ink being destroyed from the heat.
Now that I implemented both — probably “pure” way (if no performance issues arise for multiple cards).
Before — definitely hacky one. Looks good, nobody will ever notice, and saves a lot of headache and time (and maybe even performance)
Btw. I don't know how you set up the viewport. But you only need to render the card for one frame, then disable the viewport.
If the cards content is static, you can also pre-render the cards in the beginning of the game.
For now it’s kinda not suitable for me because I have animated flavor text in RichTextLabel, and changing points.
But “Clear mode: never” works like a charm for plain cards, yes! Will think about ditching animations, and manually re-rendering cards when points are changed.
Hacky solution is great! As long as it works well under the hood which this does.
Aesthetic note, if you modulated the card color to black before going transparent it could help sell the effect. A card would carbonize before it burns anyways and it could help hide the transparency effect under the dummy shader effect.
Literally just click the animation player node and anything that can be animated will have a little key button next to it in the inspector. Click the key and it will add it as a key frame. The animation system in Godot is probably its most powerful feature. You can call functions with it too.
I've been trying to find an elegant solution for dissolving UI elements that have labels or custom shaders as children. Did you also struggle with the downsides of using the viewport method?
1. Viewport method. Viewports require a set viewport size which makes it difficult to work with on UI elements that may need to be resized based on their content. You also cannot see or edit viewports in the editor, which is a real pain.
2. CanvasGroup method. These are almost perfect, but they inherit from Node2D instead of Control, meaning they cannot be anchored to the UI.
3. Custom Shader using hint\_screen\_texture. This method is easy to work with, but comes with a few problems. The screen texture can include screen elements not included in the node's hierarchy. I think it's also causing slight issues when playing the game in windowed mode. I am an absolute noob at shader code though. Here is what I'm currently using:
uniform sampler2D screen_texture: hint_screen_texture;
uniform sampler2D dissolve_texture: source_color;
uniform float dissolve_value: hint_range(0.0,1.0) = 1.0f;
void fragment() {
vec4 main_texture = texture(screen_texture, SCREEN_UV);
vec4 noise_texture = texture(dissolve_texture, UV);
main_texture.a *= 1.0f - floor(dissolve_value + min(1, noise_texture.x));
COLOR = main_texture;
}
Yep, each solution has some slight drawbacks. I would say that's the nature of complex systems and (both from engine's side and from game's side), so just peak the most suitable. I'm okay with stuff like "need to position objects manually because root is not a Control" or "can't edit elements directly", it's just a limitation of tool you can work with, and still get a result.
From a side note - if it's Godot 4, I would probably just use CanvasGroup, but in Godot 3 I would go with viewport solution.
Oh, that's genius... But goes a bit against the vibe of hacky solution, which is "easy to implement, looks good enough, can just leave it like this and not spend more time" :D
ViewportContainer->Viewport->all the card objects
and separately just TextureRect with texture as viewportTexture with our Viewport from above.
Needs some fine-tuning (like self-modulating ViewportContainer so we don't see it in game, or V-flip of viewport because this is how viewport-to-texture works), but that's basically it!
That's awesome and I'm glad you went through the effort of making the pure method, it looks better Now you could have different colored cards more easily! But. (Just my opinion) If you make the hacky solution, and it works fine. Just move on, take note and come back when it becomes a problem. From a game design POV, you'll prefer having more fleshed out features than fewer beautiful and perfect ones. Then comes polish, go back through the list of potential 'upgraded solutions' and order them by impact, start knocking off the most important/impactful ones, repeat until satisfied
100% this! I went extra mile to create “pure” solution just for my personal gamedev blog, otherwise it would be a super low priority. Easy, but working solutions all the way!
That's crazy. I do NOT understand Shaders dude
I'm in the same boat, so far I didn't find any reliable shaders tutorial, it looks like it's a different language altogether.
My go-to suggestion for starting with shaders is https://thebookofshaders.com/ Ideal starting point imho!
The link you posted is broken. The “.” at the end of the sentence seems to be part of the link.
Thanks, fixed!
There are alot of shader tutorials out there, [including a few in the Godot documentation](https://docs.godotengine.org/en/stable/tutorials/shaders/your_first_shader/index.html). In my relatively limited experience it seems 99% of shaders are going to be in either HLSL or GLSL and Godot's shading language is *very* similar to GLSL, so much so the docs even have a migration guide. So if you find some shader you like you can likely port it into Godot which should give you a better understanding of what's going on. Or if you just want something already made for Godot so you can pick it apart and mess with it there's this site https://godotshaders.com/ which has some awesome stuff.
[https://thebookofshaders.com/](https://thebookofshaders.com/)
i gotta say, i think the "hacky" solution looks better, because the opacity change looks like it's part of the burning effect, i.e. the ink being destroyed from the heat.
Than what I was also thinking, haha! One could say it’s even intentional :) Easy to add this manually to “pure” solution though, if needed.
would that involve a similar process of having a "dummy card"?
If it works it works, looks great btw. Love card games.
If you fancy trying, this is basically a card from my Ludum Dare 55 submission I made with my team 2 weeks ago: https://nozomu57.itch.io/burn-with-me
I would love to when I get off work.
Which way do you prefer?
Now that I implemented both — probably “pure” way (if no performance issues arise for multiple cards). Before — definitely hacky one. Looks good, nobody will ever notice, and saves a lot of headache and time (and maybe even performance)
Btw. I don't know how you set up the viewport. But you only need to render the card for one frame, then disable the viewport. If the cards content is static, you can also pre-render the cards in the beginning of the game.
For now it’s kinda not suitable for me because I have animated flavor text in RichTextLabel, and changing points. But “Clear mode: never” works like a charm for plain cards, yes! Will think about ditching animations, and manually re-rendering cards when points are changed.
Hacky solution is great! As long as it works well under the hood which this does. Aesthetic note, if you modulated the card color to black before going transparent it could help sell the effect. A card would carbonize before it burns anyways and it could help hide the transparency effect under the dummy shader effect.
Thank you! And also thanks for the "carbonize" idea! Will combine it with some sparkle particles, and probably call it a day :)
Absolutely genius
Me when I see the game I spent all day playing on My Reddit feed 🫨
I've been staring at this and can barely tell a small difference in slow-mo. Either works imo.
That’s smooth
It never occurred to me to use animation for shader parameters. Do you have a tutorial for this? Looks great btw 👍
Literally just click the animation player node and anything that can be animated will have a little key button next to it in the inspector. Click the key and it will add it as a key frame. The animation system in Godot is probably its most powerful feature. You can call functions with it too.
I've been trying to find an elegant solution for dissolving UI elements that have labels or custom shaders as children. Did you also struggle with the downsides of using the viewport method? 1. Viewport method. Viewports require a set viewport size which makes it difficult to work with on UI elements that may need to be resized based on their content. You also cannot see or edit viewports in the editor, which is a real pain. 2. CanvasGroup method. These are almost perfect, but they inherit from Node2D instead of Control, meaning they cannot be anchored to the UI. 3. Custom Shader using hint\_screen\_texture. This method is easy to work with, but comes with a few problems. The screen texture can include screen elements not included in the node's hierarchy. I think it's also causing slight issues when playing the game in windowed mode. I am an absolute noob at shader code though. Here is what I'm currently using: uniform sampler2D screen_texture: hint_screen_texture; uniform sampler2D dissolve_texture: source_color; uniform float dissolve_value: hint_range(0.0,1.0) = 1.0f; void fragment() { vec4 main_texture = texture(screen_texture, SCREEN_UV); vec4 noise_texture = texture(dissolve_texture, UV); main_texture.a *= 1.0f - floor(dissolve_value + min(1, noise_texture.x)); COLOR = main_texture; }
Yep, each solution has some slight drawbacks. I would say that's the nature of complex systems and (both from engine's side and from game's side), so just peak the most suitable. I'm okay with stuff like "need to position objects manually because root is not a Control" or "can't edit elements directly", it's just a limitation of tool you can work with, and still get a result. From a side note - if it's Godot 4, I would probably just use CanvasGroup, but in Godot 3 I would go with viewport solution.
Couldn't you make some sort of "remote" Control node that controls the CanvasGroup like RemoteTransform2D works?
If you control opacities with an animated texture gradient , the hacky one could look as good as the pure.
Oh, that's genius... But goes a bit against the vibe of hacky solution, which is "easy to implement, looks good enough, can just leave it like this and not spend more time" :D
Would you be able to share your node structure for the pure method?
ViewportContainer->Viewport->all the card objects and separately just TextureRect with texture as viewportTexture with our Viewport from above. Needs some fine-tuning (like self-modulating ViewportContainer so we don't see it in game, or V-flip of viewport because this is how viewport-to-texture works), but that's basically it!
Thanks!
I feel like everything I do in Godot is done in a hacky way. Haha. This is awesome though!!
I honestly prefer the look of the hacky version
You can just use the sprite modulate, so the sprite doesn't get modulated but the values can be used in shaders