Hi everyone! Do you remember the video about detecting edges using the Sobel operator, which we enhanced by using Gaussian blur? One of the drawbacks of Gaussian blur is that it's somewhat computationally intensive, which can pose some performance issues for our game if we want to apply such an effect in real-time. In this video, I will demonstrate a much faster way to blur our sprite or the entire screen.
This is one of the things I like about Unreal. I can make glass easily in unreal without going into all this technical detail. I can choose to do this kind of extra work in Unreal if I want to go the extra mile, but it's not required.
Godot needs stuff like this to be built-in by default. Glass is a super common thing that devs need to make, and having to do this wastes developer time they could be spending on more important things.
It definitely slows down development needing to find third party solutions for basic tasks. On the other hand, knowing the implementation details means it's easier to tweak things to meet your needs.
The Asset Library is supposed to be a middle ground, but it needs a lot more content and polish before I'd call it ready.
Yeah, I just fundamentally disagree with the approach the Godot team has taken with the project on basic stuff like this. I want the project to succeed beyond Indie, but it never will until it takes stuff like this seriously and integrates it into the engine.
Nobody but an Indie dev or hobbiest is going to want to waste time on this. There's too many other things that need done to make a game to get bogged down by this one thing.
I think water shaders are in the same situation. I can make nice looking water out of the box in Unreal Engine. But to make it interactive water takes a ton of work ontop of that depending on the scope of what you want to achieve, could even be months of work to make good looking interactive water if it includes actually height to the waves and not just normal maps. No way any serious dev team is going to want to go down the road of implementing the water shader under the hood first before they make it interactive.
They'll skip using the engine, and use something else. Unless they're a big enough team with enough resources to have an engine dev team of their own, in which case they weren't very likely to use Godot in the first place.
Well, Godot is a lightweight engine, so it doesn't have almost anything extra built-in. Which is advantageous because the engine itself then takes up negligible space on disk and the editor starts up within seconds, which can't be said for Unreal. But everyone prefers something different, of course. I mainly wanted to show that implementing your own blur effect can be simpler than it might seem at first glance.
I don't prefer something other than Godot. I've used a number of engines now, and I use what I do bcz I have to spend an inordinate amount of extra time doing stuff in Godot that are just blocks in other engines. It's not a good use of my time as an Indie dev. I really enjoyed Godot when I first started making games, but once I got serious about making a commercial game I realized it just didn't have the features I needed. I learned about the missing features from the engine devs themselves when they wrote a post specifically discussing the missing features for AAA games. (Not that I'm trying to make a AAA game). My game is just big enough that level streaming is important for performance.