Physics parts have been taking a huge chunk of a game I’m working for, around 1053 megabytes.
Aren’t they unanchored parts, because I just anchored everything and didn’t reduce the memory usage?
4 Likes
This is the space that is needed to store the physics datastructures. They are mostly organized as a spatial octree where every instance in the world registers itself in the buckets in that octree that it occupies in your world. Big/many parts over a large region will lead to a very large PhysicsParts because the octree will be very large / many references will be held in the octree. You can reduce its memory cost by downsizing any giant parts in your world, or reducing the amount of parts overall, or lowering collision fidelity, etc.
You don’t see a drop in memory between anchoring and unanchoring because the octree still needs to be filled in both situations, since things can hit your anchored geometry. (It’s probably still better to anchor and not have large things move about as much since this will lead to the spatial octree needing to be updated which may be performance-expensive if many large parts are involved.)
16 Likes
Do meshes affect this too? My map has huge islands, although made from parts and gap filling.
If it is an object that has geometry that can be collided with (regardless of whether CanCollide is set) then it will have physics data.
3 Likes
Ah, thank you very much!
I thought it was confirmed that making something non-collidable removes much of the physics strain, is this not the case?
Could you link to the post you’re referring to?
It was well over a year ago, pretty sure @zeuxcg mentioned it in a reply on one of his rendering updates.
I made complex market stalls and put an invisible brick around as the collision box because of this reason.
1 Like
This thread is about physics memory usage, not about physics step performance, so what you are referring to seems unrelated.
2 Likes
Yep, was replying to your comment, not the OP.