this is great! I never noticed this node while checking the docs before. And the limitations actually seem more than manageable for simpler environmental objects like grass!
@fabians7807 neither they do for mesh anyway, that's a different component, this is only render optimisation. You can have interaction then pass the data to the mesh instance custom rendering to reflect that
This might sound strange but, on 3D, in many specific circumstances, MeshInstance3D is more performant than MultiMeshInstance3D (as per 4.3). Using LODs, MeshInstance3Ds are able to reduce vertex count. MultiMeshInstance3D isn't able to use LODs properly a d hierarchical MultiMesh isn't a thing (dividing the MultiMesh in different LODs based on render distance). MeshInstance3D is able to use LODs per item, and the same mesh between many MeshInstance3D is still rendered in the same draw call (like MultiMeshInstance3D). I've done some experiments and, as on 4.3 there is no upside to using MultiMeshInstance3D if you are using LODs. Is more performant to use MeshInstance3D and LODs. But at the end of the day "try it yourselves, do your own experiments".
So the y-sorting works for the instances itself when they move towards each other, but what with other objects from tilemaps or scene stuff? for example a sprite2d that is a tree, that is not managed by the multimesh. would the goblins go in front and behind the tree correctly depending on the trees pivot point with y-sorting on? also think about sharing source code when doing such videos.. it helps most people
all mesh instances from a multimeshInstance2D node are the same z index. You can only change the draw order of mesh instances in relation to other instances by moving ids. So you'd need another multimeshinstance2d drawing at another z index to have some instances in front of a tree and behind a tree, because they'd have to be drawn in separate draw calls.
So this doesn't work at all without explaining your custom multi-mesh-manager resource...whatever register_instance is, it does not work with the standard multi-mesh-instance-2d node
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DeepDiveDev/ You’ll also get 20% off an annual premium subscription.
this is great! I never noticed this node while checking the docs before.
And the limitations actually seem more than manageable for simpler environmental objects like grass!
Cool video
The animations while you explain the topi are very smooth
Bro i thought this would have like 800,000 views. Nice video, i subscribed!
it's cool but we can't interact with them though...
we can, just needed adjustment
@ how
That's just a renderer
Collision detection does not work for Multimesh instances.
@fabians7807 neither they do for mesh anyway, that's a different component, this is only render optimisation. You can have interaction then pass the data to the mesh instance custom rendering to reflect that
Next make collision checks on all those goblins! 🎉
This might sound strange but, on 3D, in many specific circumstances, MeshInstance3D is more performant than MultiMeshInstance3D (as per 4.3).
Using LODs, MeshInstance3Ds are able to reduce vertex count. MultiMeshInstance3D isn't able to use LODs properly a d hierarchical MultiMesh isn't a thing (dividing the MultiMesh in different LODs based on render distance). MeshInstance3D is able to use LODs per item, and the same mesh between many MeshInstance3D is still rendered in the same draw call (like MultiMeshInstance3D).
I've done some experiments and, as on 4.3 there is no upside to using MultiMeshInstance3D if you are using LODs. Is more performant to use MeshInstance3D and LODs.
But at the end of the day "try it yourselves, do your own experiments".
So the y-sorting works for the instances itself when they move towards each other, but what with other objects from tilemaps or scene stuff? for example a sprite2d that is a tree, that is not managed by the multimesh. would the goblins go in front and behind the tree correctly depending on the trees pivot point with y-sorting on? also think about sharing source code when doing such videos.. it helps most people
all mesh instances from a multimeshInstance2D node are the same z index. You can only change the draw order of mesh instances in relation to other instances by moving ids. So you'd need another multimeshinstance2d drawing at another z index to have some instances in front of a tree and behind a tree, because they'd have to be drawn in separate draw calls.
@ thats exactly the point where i am. i decided to try that out and if its not good enough to switch completely to the renderingserver.
pro tip, you are better off using viewport texture instead of a vertex shader, or many of them even
So this doesn't work at all without explaining your custom multi-mesh-manager resource...whatever register_instance is, it does not work with the standard multi-mesh-instance-2d node
Hmmm, crispy cat...
why is godot so slow? only 100,000 sprites drops you to 60fps??? really?
bro has an i9-14900k with the gtx 970. No need to flex like that
I'll get a new GPU eventually XD
Bro i am your new subscriber 😊
Thanks for the sub!
open source is the best
Positive y points up in godot
It actually points down surprisingly! It can seem a bit counter-intuitive tbh. for 3D it's probably another story though
This video was a pain to watch in 1x speed.
yeah ive watched too many 1.6x speed podcast tiktoks
can you elaborate on this? Do I talk too slow? too many pauses between sentences? not concise?
@DeepDiveDevelop Honestly?
I don't see any significant issue with your pacing, *personally,* and I watch at x1 speed. It's low filler & *very* clear.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DeepDiveDev/ You’ll also get 20% off an annual premium subscription.