- Forum
- General C++ Programming
- Terrain Deformation
Terrain Deformation
I am creating a terrain deformation program that reacts to gameobjects colliding with the terrain and leaving an impression. For this to work properly I would like to apply a 'height map' of the object's colliding side to allow for unusual shapes to leave accurate deformations.
Does anyone know how to firstly take a 'snap shot' of anything during game play (once a collision has been detected in my case)? for example i know the objects collision point and angle- take an image of the colliding side.
Then how would I go about creating a height map of that image in real time? - to be applied to the surface of the terrain.
I'm doing my project in DX11, but if any ideas come to mind pseudo code would be brilliant.- or any other techniques to get a similar effect.
Many Thanks
Does anyone know how to firstly take a 'snap shot' of anything during game play (once a collision has been detected in my case)? for example i know the objects collision point and angle- take an image of the colliding side.
Then how would I go about creating a height map of that image in real time? - to be applied to the surface of the terrain.
I'm doing my project in DX11, but if any ideas come to mind pseudo code would be brilliant.- or any other techniques to get a similar effect.
Many Thanks
I did something like this. I had a large matrix of vertices. The x and z coordinates of the vertices were static, so you can index into them based on the x z coordinates.
Basically I 1) let the first vertex of the object to hit the terrain sink a certain amount and then 2) just set all of the y coordinates of the terrain in contact with a vertex of the object equal to the y coord of that vertex.
For the second step I iterate over the objects x, z coordinates and if the y coordinate is close enough to the y coordinate of the corresponding terrain vertex, the set them equal.
You can also have how much the object sinks be based on other factors such as the elasticity of the terrain's vertices at that location, the force at which the object hits.
If you want more realistic results, do the compression / depression frame by frame and stop when the energy that went in has dissipated into the collision and so forth.
Having a gigantic matrix of coordinates can however be very slow to render. I had to either the size of the deformable terrain, or just have patches of deformable terrain here and there, and or limit the detail of the terrain.
One of the reasons it's hard to achieve good performance this way is because you have to recalculate your normals every frame, or at least every frame the terrain changes, and then you have to do a buffer data replacement as well.
To solve some of these problems, you break up the terrains vertices into smaller patches and only update the patch/patches that have changed.
I used OpenGL. I have a slow graphics card and it was a bummer because my terrain looked so awesome with ultra high detail, but performance would drop insanely, and I could only support a very small patch of the terrain I wanted.
Basically I 1) let the first vertex of the object to hit the terrain sink a certain amount and then 2) just set all of the y coordinates of the terrain in contact with a vertex of the object equal to the y coord of that vertex.
For the second step I iterate over the objects x, z coordinates and if the y coordinate is close enough to the y coordinate of the corresponding terrain vertex, the set them equal.
You can also have how much the object sinks be based on other factors such as the elasticity of the terrain's vertices at that location, the force at which the object hits.
If you want more realistic results, do the compression / depression frame by frame and stop when the energy that went in has dissipated into the collision and so forth.
Having a gigantic matrix of coordinates can however be very slow to render. I had to either the size of the deformable terrain, or just have patches of deformable terrain here and there, and or limit the detail of the terrain.
One of the reasons it's hard to achieve good performance this way is because you have to recalculate your normals every frame, or at least every frame the terrain changes, and then you have to do a buffer data replacement as well.
To solve some of these problems, you break up the terrains vertices into smaller patches and only update the patch/patches that have changed.
I used OpenGL. I have a slow graphics card and it was a bummer because my terrain looked so awesome with ultra high detail, but performance would drop insanely, and I could only support a very small patch of the terrain I wanted.
Last edited on
Topic archived. No new replies allowed.