02-10-2024, 08:17 AM
(This post was last modified: 03-10-2024, 08:14 AM by josemendez.)
Hi!
Entire colliders. This is done during the broad phase, where contact pairs are determined (particle "A" and collider "X" are close enough to potentially collide). For simple, convex colliders each potential contact pair may spawn a single contact during the narrow phase. For more complex, possibly convex colliders (like terrain or MeshColliders), then a midphase takes place where the pair may spawn multiple contacts against individual features (triangles in the case of MeshColliders).
The origin of the grid depends on the bounding box of all particles.
Obi uses a multilevel 4D grid, where each cell has 4 coordinates: x,y,z and level. The size of cells is different for each level in the grid, cells in level N+1 are twice as big as cells in level N. Colliders are assigned a grid level according to the size of their bounding box, so that each collider overlaps at most 8 cells (or 4 in 2D). It's not really practical to use this information to fine-tune object or solver positioning, as the origin/cell size of the grid may vary depending on both object size and positioning.
We'd be talking about VRAM, since this gets executed on the GPU.
This data gets stored in registers instead of global memory. The problem is not so much memory usage (as in "storage") but performance, as using up more registers increases register pressure: when a thread has run out of registers to store temporary data, it will "spill" data to local memory - which is slightly slower than registers. So the struggle is to use as few registers as possible in order to make data accesses faster, that's why I didn't use 128, 256, or a much larger size.
Creating a few MeshColliders at runtime is the usual way to do scenery collisions (allows for more flexibility in terms of shape, requires less GameObjects and reduces the amount of work in the collision detection broadphase), though if your levels are procedurally created or use a modular approach it might not be easy or even possible. In that case increasing MAX_CONTACTS_PER_SIMPLEX may be the wisest option. I will consider exposing this value in the solver's inspector in upcoming updates, as it makes sense to modify it under specific circumstances.
kind regards,
(27-09-2024, 01:09 PM)Nyphur Wrote: What counts as a potential contact? Is it an entire collider, or a collider vertex, or a face? would boxcolliders, for example, use up fewer potential contacts?
Entire colliders. This is done during the broad phase, where contact pairs are determined (particle "A" and collider "X" are close enough to potentially collide). For simple, convex colliders each potential contact pair may spawn a single contact during the narrow phase. For more complex, possibly convex colliders (like terrain or MeshColliders), then a midphase takes place where the pair may spawn multiple contacts against individual features (triangles in the case of MeshColliders).
(27-09-2024, 01:09 PM)Nyphur Wrote: How does it determine where the grid starts and the size of the grid cells? Is it centered on the Solver, and so should I aim to put the solver in a central location to my level?
The origin of the grid depends on the bounding box of all particles.
Obi uses a multilevel 4D grid, where each cell has 4 coordinates: x,y,z and level. The size of cells is different for each level in the grid, cells in level N+1 are twice as big as cells in level N. Colliders are assigned a grid level according to the size of their bounding box, so that each collider overlaps at most 8 cells (or 4 in 2D). It's not really practical to use this information to fine-tune object or solver positioning, as the origin/cell size of the grid may vary depending on both object size and positioning.
(27-09-2024, 01:09 PM)Nyphur Wrote: Any idea roughly what the memory impact of increasing the contact limit is? And this may be a stupid question but I just want to make sure I'm not getting it wrong, is it storing the data in VRAM or RAM?
We'd be talking about VRAM, since this gets executed on the GPU.
This data gets stored in registers instead of global memory. The problem is not so much memory usage (as in "storage") but performance, as using up more registers increases register pressure: when a thread has run out of registers to store temporary data, it will "spill" data to local memory - which is slightly slower than registers. So the struggle is to use as few registers as possible in order to make data accesses faster, that's why I didn't use 128, 256, or a much larger size.
(27-09-2024, 01:09 PM)Nyphur Wrote: The fact that I've hit this limit probably indicates that I may be taking a less than ideal approach to collisions. In my game I have 1 floor collider that spans the entire map and then the corridors made out of modular walls slotted together, where each wall has an Obi collider, and then there are various objects randomly placed that also have Obi Colliders. They're almost all box colliders, with just a few mesh colliders. Do you have any recommendations for optimal approaches to collision to reduce the number of potential contacts?
Creating a few MeshColliders at runtime is the usual way to do scenery collisions (allows for more flexibility in terms of shape, requires less GameObjects and reduces the amount of work in the collision detection broadphase), though if your levels are procedurally created or use a modular approach it might not be easy or even possible. In that case increasing MAX_CONTACTS_PER_SIMPLEX may be the wisest option. I will consider exposing this value in the solver's inspector in upcoming updates, as it makes sense to modify it under specific circumstances.
kind regards,