Tuesday 25 January 2011

Physics and Heightmaps

When I thought that all problems with heightmaps was over, I stumbled upon something sort of tricky recently. The only thing I had left for heightmaps was to add physics to them. This seemed easy to do as it was basically just a matter of sending the raw heightmap data to the physics engine (newton game dynamics) However just as I had done this I realized that this was not enough: the terrain could have many different physical properties at different places (a spot with dirt, one with rock, etc).

The thing is that in physics simulations you give a material per shape, each material having certain properties (friction, etc) and special effects (sounds, etc). The heightmap is counted as a single shape, and thus it only has a single physics material. This was something I had totally forgotten. Luckily, the physics engine supports the assigning of special properties to each point in the heightmap. Once I found the proper info, it was pretty simple to add this (see here).

Now it was just a matter of adding extra material values to the heightmap (basically just an array of single integers, the id of the physics material at each point). My initial idea was that this could be "painted" on as an extra step, and to be sure I asked Jens what he thought about it. His reaction was that this would be way too much work and wondered if it could not be auto-generated instead. We already had a physics material assigned to each render material, so the basic info was easily accessible.

However, when I started to thinking about this, I found the actual auto-generation increasingly tricky. How should we determine which of the many blended materials to set the physics properties (blending was not possible)? Also, how do I get this information, 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 top visible (meaning over a certain limit opacity) blend material always sets the physics material. This allows map creators to set priority on materials in terms of physics, by simply placing them at different places among all blend materials. For example, if a material like gravel should also have its effects shown no matter what it is blended with, then it should be placed high up in the list. While currently untested this seem pretty nice and can also be tweaked a bit (like having something else determining priority).

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

Problem was finally solved and physics properties auto-generated!

With this little post I hope to show that there often is more to a problem than what is visible at first. Also, this shows another advantage of using normal texture splatting (more info here), instead of megatextures or similar. With the auto-generation of physics, it is much easier to create and update the terrain, something extremely important when you are a small team like us.

Would be very interesting what other techniques people use (or known of) for setting up physics properties on terrain!


  1. Thanks so much for this development blog which I always enjoy to read. It's so detailed, well researched and also provides various references to other papers that you read and learned from.

    Thanks again

    PS: When do you think you can give us some news regarding your next project? e.g. will it be horror related? Survival horror? Hopefully something alike Amnesia because you're definitely the kings in that genre.

  2. -w3sp-:
    Glad you enjoy them!

    Project still super secret I'm afraid, but these posts give at least a super tiny idea of where we are heading ;)

  3. Since you can blend or otherwise combine various textures to create something completely unrelated, are you sure you want physical properties of the terrain to be auto-generated? You can use simple geometry (spheres, boxes) to define areas (and bake?), or create a utility that would let you paint on a minimap. Or combine auto-generation with the power to tweak where required.

    On the grass rendering - I think you can make it a bit more realistic using vertex colors: assign black to the bottom of the blade model, an white to the top, and multiply, to simulate how lower parts receive less light (at least in the dense areas). Pixel shaders should be able to handle it; also, you can probably modify this to take the grass density into account.

  4. I assume this has already crossed your mind, but wouldn't pregenerated property maps be better than calculating them at runtime?
    By keeping the range of values limited (i.e. with a 4bit indexed or intensity texture), the resulting image would not become too large. Also, resolution can be lower than the diffuse map(s).
    The downside is that you need an additional texture unit, of course.

  5. @onitake: I don't think they want the maps to be dynamic - they just want them to be automatically (pre)generated by the editor, based on the materials used on the terrain.

  6. onitake:
    Anonymous is right :)
    We have it all stored in an map as 8bit integers.

  7. Thanks so much for your great games. I recently read that Amnesia was almost cancelled due to lack of funds, and am really glad it was able to be released.

    I hope you guys succeed enough with Amnesia to go on to make plenty more horror games, as yours are some of the best out there. :)

    From an avid gamer,

  8. I know the chances are super slim but is there any hope the team at Frictional Games might make a PSP2 game?

    I think it would be cool to see what you could bring out on the game using the touch screen.

    I think it would be really cool to see some scary games from Frictional Games on the PSP2. So I hope the team thinks about bringing games to the system.

  9. There's a PSP2?! I gotta crawl out of my cave...
    Anyway, I just read about it, now called NGP. Let's see... What could be done with a horror on such a system? I know... Make a really yucky, gory scene and make the player touch it, hahahaha (and that vas an EVIL laughter)!

    Really, though, it would be interesting to see what could be done...

  10. Errata: What could be done with a horror ++GAME++ on such a system?

  11. Off Topic:
    I'm glad I'm not the only one who would like to see you make a non-horror murder mystery. My suggestion is to create a branching story line that can fit multiple characters, then create variations for each character. Each time a player goes through the game, a different scenario is chosen, but with many randomized elements (the exact selection of clues, where they are to be found, who tries to kill you and why, who are the red herrings that the clues come just short of incriminating, what events happen as a result of a certain triggers, etc). The similarity between all the scenarios will keep the player guessing through dozens of play-throughs, thus resulting in great replay value. Also include some mild action. For instance, the detective carries a small revolver that holds 5 bullets on him at all times for self protection. The villain gets desperate to get rid of him before the truth comes out, and tries to kill him in the greenhouse. The result is a small shoot-out with each party only having less than a dozen shots, and little time as the shots are heard and the people of the mansion called the police, picked up their own guns, and are coming to put an end to the disturbance. You can catch or kill the criminal, which may or may not solve the main mystery, or he can escape or even kill you. If he escapes he may be caught immediately be caught if you saw his face, but even if not new clues will become available as any potential witnesses are questioned and the criminal would have trouble with his alibi.

  12. It would certainly be interesting to see a new kind gameplay where you are not given an endless supply of ammo and are not even expected to use the gun more than, like, 3 times in the whole game. And yeah, more often that not, you can't just blast your way through anything that moves without provoking some sort of a reaction from all around you (assuming you are not in an "empty" castle...).


Note: only a member of this blog may post a comment.