Handling large scene in Godot
Вставка
- Опубліковано 25 лип 2024
- So this will be a start point for me to create a system for handling large scene in Godot! I thought to myself lets create and finish one octree system for everything so we don't have to rewrite that in each system separately! Other than this I think one central octree will be much more efficient the several one! by the way in some cases you can create other octree also!
Discord:
/ discord
Twitter:
x.com/mohsenph69
Github:
github.com/mohsenph69/Godot-M...
patreon:
patreon.com/mohsenzare?...
Chapters:
00:00 - the large scene challenge
01:08 - my solution
03:07 - octree implementation
05:14 - how to use this?
08:27 - what are next steps?
I'm fairly new to Godot, coming from unreal. But I'm impressed of how much content talented people are willing to share. I have looked through some of your videos and there is a lot of cool functions, looking forward to more updates.
A spatially partitioned multimesh still has better performance. Divide your scene into a grid, where each cell is a list which contains the positions of each mesh in that cell. Every frame, concatenate the current grid cell, and the 8 cells around you into a list, and send the list into the multimesh.
Esentially, this is faster by precomputing the object distance check
In this case as we have a bunch of monkey head with same mesh yeah it will work better! but in real game we can not create for every single mesh a multi-mesh! sometimes you need one mesh somewhere in your big map and another mesh beside that! you won't create for every single of them a multimesh! And in that case this MOctMesh has better performance! By the way my main goal here to create other things on top of this octree! not just MoctMesh!
Yes, that's a good point!
Please in the future implement light map baking support! This is wonderful and I am in awe of the work you put in! I’m a low level beginner but I am beginning to understand these higher level concepts, I think it would be great to see lightmap baking support for more performance! Thank you sir I subscribed and liked!
Love your work. Please keep sharing, teaching and explaining! Thanks you.
Thanks!! :)
Man Your work is awesome. thanks
Bro this is awesome thanks for doing this!
Thank you!
Each your video is mind-blowing!
Thanks you always! :)
Awesome video. Thanks for sharing!
Thanks for watching!
This is wild, thanks for sharing
Thanks for watching!
My idea has been to use a Multimesh and have some way (waves hands) to find the instance-indexes in an area around the player. Then you set the scale on those instances to zero and replace them with MeshInstances + Colliders. That way you walk-through a field of multis but the things around you are more 'real'.
I also want to place smaller Multimeshes so that they can LOD by themselves as a group and not look too bad; also so they don't take to much time drawing off-screen.
I do wish Godot had more functions built-in, like the quad-tree and so on. Their BVH system is very slow in the editor, so tools suffer.
Another idea I have is to draw, say, a forest with MeshInstances (in the editor) and then have a tool that finds all common meshes across that forest and gathers those into (chunked) Multimeshes. So all the leaves becomes one multimesh, the trunks, etc.
Last idea, sorry: I wish Godot would implement a way to 'enter into' a Multimesh and let me edit (move, scale, rotate, delete, add) instances just like one can with normal meshes. A partial solution for this is a node I made in the Library. Vid here: ua-cam.com/video/jEvUMjBwQQM/v-deo.html
Anyway, thanks for the work you are doing!
The things you explained to me are good! but don't think that multi-mesh is going to solve anything for your! MeshInstance and Multimesh both they have their use cases!
will this be integrated into your terrain plugin (btw i love it, from all the terrain plugins there yours gives the most fps)
Yeah it will be on top of MTerrain
Any suggestion for how increase perfomance when you have a lot of collision shape(enemy) that move to the player?
I rised performace using sphere instead of capsule for collider but it is very limited
What you said depend on Godot physics itself! But yeah using more simple shape will help to gain performance!
This is absolutely amazing! What a fantastic solution for handling large scenes. I do have a couple of questions and would greatly appreciate your clarification. Firstly, can this solution be applied to all types of models and assets in the game, such as foliage, trees, buildings, NPCs, and enemies? Secondly, can it function similarly to asset-streaming, where assets are loaded on-demand based on the player's position? For instance, when the game starts, not all assets are loaded at once; instead, only those within a specific radius around the player are loaded. Asset-streaming is crucial for managing large scenes efficiently, as it reduces initial loading times and optimizes VRAM usage. Thank you in advance for your time and insights!
Hi There! the answer to your question is yes! so let me clarify how all these things you are saying will work!
By now I only implemented a OctMesh node which is similar to meshinstance3D which works on top of Octree!
But you can create any other system you want on top of Octree! As an example you want to create something that load a bunch of stuff as camera get close to that! First you register yourself as a subsystem of octree! you send all of your loader position into octree! and then octree will send you a notification when the camera get close to one of your loader! For example you can say if my loader lod is less than 3 then load all stuff and if it is greater than 4 unload them!
Now this take away the need of constantly checking if camera get close to one of your points! Also Octree will do this stuff really fast!
... By the way about octmesh you can use that for anything you want like enemy-mesh and so ... For vegetation maybe octmesh is not good enough!
Maybe we can create another system on top of octree which create multi-mesh!
But take in account if you are using MTerrain consider using Grass system for anything is possible! Grass in MTerrain has really small data! you an cover an entire terrain with few MB of memory! the only downside of Grass is that you can not set the exact position and rotation of each Mesh!
@@mohsenzare2511 so, for my first question, yes I can use any mesh or asset that want except for the foliage it’s better to use MTerrain’s grass system, this is totally clear, however if I used the grass system I won’t be able to set the rotation and exact position, but can’t I paint the grass and foliage manually? In large open spaces or forests I could add foliage and grass procedurally but in places where I need to place foliage in specific position can’t I paint foliage manually?
@@amirosman8797 Yes You can paint them. There is a grass paint tool! just select the grass and activate paint mode! and paint grass on Terrain where you want!
@@mohsenzare2511 Fantastic, thank you very much for your support and I would really love to see what else you have in store for us
awesome work! I have a question - why use this and not a multimesh? or some variations of multimesh. multimesh as I know acts as a single node/object
Multimesh has some limitation! If you create bunch of meshes with multimesh, Even if you look at one mesh all multimesh should be rendered! But if you create that with MeshInstance if that mesh instance go behind the camera or get further away it will not be rendered! basically MeshInstance render only when camera look at it!
Also with meshinstance we can control much better the LOD level!
Both MeshInstance and Multimesh has different use cases!
@@mohsenzare2511 can't you control where the multimesh population is based on the camera movement at runtime?
Practically no! then you should destroy the entire Multimesh and resend all meshes transform data to GPU again and again! Multimesh usually used when you have one mesh which should be rendered a lot of time! like grass mesh! but for things like enemy mesh, car mesh, statue, doors, walls and ... which they have a lot of vertices in one mesh you better use MeshInstance3D with different LOD level!
@@mohsenzare2511 great explanations! thanks a lot. will a game ever need 1 million enemies, cars, etc?
That's depend on your game! If you don't make an open world game no! But if you make an open world game! if you want to populate that you will need a good system which handle a lot of meshes!
What would be cool is if Godot added some highlevel class that makes using the Render/PhysicsServer easier for normal users. But then again how much data id the RID system using on its own?🤔
Currently in the game im working on, im combining multiple different meshes into 1 mesh using a modified mesh merger plugin. It's okay for a few 1000 meshes but it's cluttered and I'm feeling like I want to change it again
@@Chevifier Unfortunately also with rendering server we don't have a good news! As a testing just create 1 million instance in rendering server! it will take quite a lot RAM! OctMesh will create rendering server instance when the object is in visible range! Now my next step is to create something like this which also remove the node! then we are good to go!
@mohsenzare2511 plane C++ it is then.
Vec3 struct and int id.😅
but Im not sure its possible to create our own renderer yet without recompiling the engine.
Octree are always slower than grid, you can traverse visible grid very efficiently because you only query interval 'scanline' by 'radterizing' the frustrul in the 2d projection of the map. Ie direct query no rejection. If you need 3d query it's as simple as adding a vertical interval clamp after the 2d pass per columns.
Maybe I not understand exactly what you said, but correct me if I am wrong, you mean instead of octree using a grid and see each points belong to which cell? If I am correct, octree itself is also some kind of grid but it is just non uniform! it means less octant for places with no points and more octants for where there are more points! this better specially if we have more points in some part of the space and many empty places at other!
@@mohsenzare2511 it's all the same, BUT octree is great for really sparse distribution, IE vast empty space with very few random elements.
But that's not your case, you have a really dense distribution, grid would be faster, and if you need it hierarchical grid would be the next option.
Octree is also implicit to grid, except you aren't limited by boundaries. Think of it like query ranges you can hash by power of two the position+offset to get a virtual floating octree relative to the offset.
There is a guy making name Geno's on gbadev, who used octree for 3d rendering on GBA, we told him the same, he took him a long time to shift, but it was faster.
Godot itself used an octree until someone refactored it into a hierarchical grid and gained significant speed up.
Grid have a nice lay out, coherent in memory. Octree have level of indirection and jump around the memory.
hardware specs?
Technically Godot 4 is outdated. No HLOD, no ECS
There is no where one million meshes in the scene, there is about 1.000
Godot would break into multiple pieces if you have 1.000.000 meshes showing at the same time. It's not even close. Click bait title
As explained in video only meshes in radius of 200 meter are visible in both method!
Clickbait? What does the title say in your language? Also, a scene with 1000 meshes is large, I think.
Great video, as always.. I love your content specially videos about optimization and c++ 🤍 bad that this doesnt work with lightmap baking, but its still amazing...keep up the great work..