0
\$\begingroup\$

A naive collision system in 3D RPGs can lead to mobs getting stuck on geometry that they would realistically step over and can be a major nuisance to many players. For most games, the solution is fairly simple: disable collisions on small objects since they don't matter from a gameplay perspective.

This works, but on the assumption that the mobs are all roughly the same size. Introducing more "size categories" from gnome to dragon would require carefully managing collision lists and would likely break on weird corner-cases. The same holds true for nav meshes in 3D games that are mechanically 2D.

Therefore, I'm curious about how one can make an adaptive system to handle collisions automatically.

Constraints & Considerations:

  • We can assume all the relevant geometry is static, allowing the use of acceleration structures.
  • Small object colliders assembled into larger structures should collide as a large structure.
  • The solution should be performant enough to use on a large number of mobs, not just hero characters.
  • The goal is specifically to allow passage depending on mob scale. A solution that results in mobs moving on top of objects instead of passing through them is acceptable, if less desirable.
  • Short obstacles may not be self-contained objects, but part of a larger mesh.
  • The method should work in fully-3D games. "Draping" a navmesh would break for situations involving ledges and interiors.
\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

A possible solution is to use a Signed Distance Field whose resolution is dependent on the mob's scale. Since low resolutions have the effect of smoothing out the geometry, small objects will act like bumps in the ground to walk over.

The problem with this suggestion is that Signed Distance Fields are volumetric, which is less efficient space-wise than surface representations - bloating the game data and eating up RAM for larger worlds. In principle, this could be ameliorated by computing a local SDF on-demand from the triangle mesh, but presupposes a fast mesh->SDF algorithm & implementation. Furthermore, since each mob (or at least size category) will have to compute its own SDF, this has the potential to be very computationally expensive.

Perhaps if the world was described using Constructive Solid Geometry, the SDF could be efficiently computed in parallel. This, however, requires that there is a way to convert the SDF into an optimized mesh appropriate for rendering. Another solution might be to use Truncated Distance Fields, which lacking the sign component, are much faster to compute according to the papers I've read. Sadly, this has the downside of inviting situations where mobs may get stuck inside geometry.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .