Physics and Heightmaps

When I thought that all difficulties with heightmaps was over, I stumbled upon one thing sort of tricky not too long ago. The only point I had left for heightmaps was to add physics to them. This seemed effortless to do as it was fundamentally just a matter of sending the raw heightmap information to the physics engine (newton game dynamics) Nevertheless just as I had carried out this I realized that this was not adequate: the terrain could have several diverse physical properties at various locations (a spot with dirt, one particular with rock, etc).

The point is that in physics simulations you give a material per shape, every material possessing specific properties (friction, etc) and special effects (sounds, etc). The heightmap is counted as a single shape, and as a result it only has a single physics material. This was something I had entirely forgotten. Fortunately, the physics engine supports the assigning of particular properties to each point in the heightmap. Once I located the proper info, it was pretty basic to add this (see here).

Now it was just a matter of adding extra material values to the heightmap (generally just an array of single integers, the id of the physics material at each point). My initial thought was that this could be "painted" on as an additional step, and to be sure I asked Jens what he believed about it. His reaction was that this would be way too a lot perform and wondered if it could not be auto-generated alternatively. We currently had a physics material assigned to every single render material, so the standard information was very easily accessible.

Nonetheless, when I started to pondering about this, I located the actual auto-generation increasingly tricky. How must we establish which of the several blended components to set the physics properties (blending was not feasible)? Also, how do I get this details, considering that the blend textures can saved as compressed textures, into a CPU buffer?

The way we chose to solve the material picking was that the best visible (which means more than a specific limit opacity) blend material constantly sets the physics material. This allows map creators to set priority on materials in terms of physics, by simply placing them at various areas amongst all blend components. For example, if a material like gravel should also have its effects shown no matter what it is blended with, then it must be placed higher up in the list. Whilst currently untested this seem quite nice and can also be tweaked a bit (like having anything else figuring out priority).

The generation of this information was made by rendering the blend textures to an off-screen target and then grabbing the information into regular memory. What this meant is that the GPU would decompress any packed textures for us. This also solved some other issues, like the require to resize the texture according to heightmap resolution. Once the data is grabbed from the GPU it is just a matter to loop by way of it, check values and create to the final buffer.

Difficulty was ultimately solved and physics properties auto-generated!


With this small post I hope to show that there usually is more to a issue than what is visible at first. Also, this shows one more benefit of using standard texture splatting (much more information here), alternatively of megatextures or similar. With the auto-generation of physics, it is significantly easier to produce and update the terrain, one thing very important when you are a tiny team like us.

Would be quite intriguing what other tactics men and women use (or recognized of) for setting up physics properties on terrain!