I haven’t found any yet, but I’m currently working on it.
No, it’s an evolved plugin that includes a lot more than just the basic three data types; it mainly focuses on generating data.
This is actually a benefit for data streaming, as it allows us to see raw performance.
I’m not entirely sure what you mean by .res data in this context. Does it contain specific data types that need to be handled?
add_child() can be quite expensive. What kind of data size are we talking about here? Until I actually build and test it, it’s just speculation on my end.
The engine has to rebuild the BVH when scene tree changes. I think adding a child scene with a pre processed BVH is the fastest way to add a group to the BVH. But i doubt thats the bottleneck game breaking flaw in Scene chunk loading.
The dramatic drop in FPS when the scene gets added might be the conversion of meshes and textures and upload to GPU.
I just wouldnt want to use Godot so much without the scene tree and script.
If you are loading .res data into Nodes then they could be changed, they could all be editable, then the mesh or texture that just loaded fills the empty position.
I utilized AI to generate headers and print lines. However, I decided against using it for the entire project, as it tends to struggle and repeat the same errors.
I’m still wondering what you meant, because this particular streaming module doesn’t have a ‘scene’ option.
You can have multiple instances of a streaming node, but each one needs a separate .db file.
Month one is over, and I’m calling it a day on this research and prototyping phase.
Honestly, using AI for the module was a mess.
I dealt with endless header compilation errors, mostly because the AI kept generating bad class names and non-existent file paths.
Since this is just the start, it makes total sense to jump ship to Unreal—it already has these issues solved and comes with ZenServer, Lumen, and Nanite out of the box.
Good luck to the rest of the team!
And to everyone who warned me at the start: yep, you were completely right.
I wrapped this up by focusing on Unreal Engine, since it just makes obvious sense to use the built-in tools they already provide.
Please don’t let this stop you, though! You can absolutely continue the topic—others might have the drive to put in the work, create plugins or modules, and improve streaming performance in future Godot games.
In that case, I’ll limit myself to a brief comment. What matters isn’t how you load content, but what. We start with small lots and small maps, gradually expanding them. It’s just a good idea to think about the practical application of such plugins—what do players and developers need: an empty, endlessly repetitive space, or a rich, vibrant world? And who will make this world rich? The Witcher 3, for example, isn’t actually an infinite world at all — “Dragons live here” — remember?
Godot is evolving. I’ve noticed a strange pattern — when we really need something for a project, it appears in the next version. So there’s reason to believe that when we really need a very large space, support for it will be implemented in the engine.
I also use Unreal engine but I’ve got large sections of a game done in Godot so I am continuing to explore and develop. I don’t have such a big issue with loading different maps if I need to because I think games try to cram too much into a large open world and they aren’t really all that large.
A lot of things are transferable from Godot to Unreal, but theres also a lot that isn’t.
The UI in Unreal is a lot like the one in Godot …
Probably the best thing to do is purchase a terrain landscape tool like Brushify and get a couple of the relatively cheap brushify addons. The new mesh terrain looks great and perhaps Brushify doesnt work with the mesh terrain. I did see that video the other day, and i’m impressed by the synthetic modifiers.
