8
\$\begingroup\$

In this situation, I have terrain height values I generate procedurally. For rendering, I use the camera's position to generate an appropriate sized height map. For collision, however, I need to have height fields generated in areas where objects may intersect.

My current potential solution, which may be naive, is to iterate over all "awake" physics actors, use their bounds/extents and velocities to generate spheres in which they may reside after a physics update, then generate height values for ranges encompassing clustered groups of actors. Much of that data is likely already calculated by PhysX already, however.

Is there some API, maybe a set of queries, even callbacks from the spatial system, that I could use to predict where terrain height values will be needed?

\$\endgroup\$
  • \$\begingroup\$ Seems to me like you already coded the best solution. Not sure how PhysX works, maybe you can instead have bounding box shaped triggers on your terrain chunks and generate the collision shapes if something enters (triggers) this box. Basically what you are doing but the other way around and with PhysX collision math. \$\endgroup\$ – aeroson Apr 26 '17 at 13:35
0
\$\begingroup\$

If you are generating meshes from your data for rendering you could pass the mesh off to PhysX as a collider Mesh. Meaning that physX and your renderer reference the same object cutting overhead.

\$\endgroup\$
  • 1
    \$\begingroup\$ It's not appropriate to assume that visible terrain is the only terrain objects can collide with. The issue is quickly identifying what range of terrain could be collided with so that collision shapes can be generated for them on-demand. \$\endgroup\$ – Sion Sheevok Jan 21 '14 at 18:28
  • 1
    \$\begingroup\$ en.wikipedia.org/wiki/Octree dividing the world data up into cubes and "slicing" them up where ever you have a free collidable entity you can then make calls to the terrain data within a very small area with very little overhead. Here is an example using quadtrees for 2D particle collision but the concept is the same for Octrees but with an extra dimension. This would also allow for individual free collidable objects to collide with each other. youtube.com/watch?v=fuexOsLOfl0 You can then generate very small colliders from the terrain data near the free collidable objects \$\endgroup\$ – That Homeless Guy Jan 21 '14 at 18:41
  • 1
    \$\begingroup\$ I'm familiar with octrees and spatial partitioning - PhysX is already doing that internally. I need information from PhysX regarding its spatial partitioning system so that I can generate terrain collision shapes where they are necessary because the terrain is procedural. \$\endgroup\$ – Sion Sheevok Jan 21 '14 at 18:46
  • 1
    \$\begingroup\$ You're missing the point. I am generating data for the terrain. I am sampling that data to build a heightfield. I need to predict where terrain data is needed. If there's an object at (-100.0, -100.0), I need to generate terrain near (-100.0, -100.0) before I simulate physics. I also need to generate a region of terrain big enough or else an object may move beyond a region and end up below where the terrain would be if it had been generated in that region. PhysX must already track such information in order to predict potential collisions - I need that information. I don't know if/how to do so. \$\endgroup\$ – Sion Sheevok Jan 21 '14 at 19:58
  • 1
    \$\begingroup\$ That's the work around method I outlined in my question, yes. I'm asking if I can get the work that PhysX has already done, so that I'm not redundantly calculating the same results. I haven't found a way yet, but I'm not that familiar with the PhysX API without licensing. \$\endgroup\$ – Sion Sheevok Jan 21 '14 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.