Dynamic Deformable Terrain
Author
[color=#333333]I am looking for a game engine that is open to the public for free or at a payed price that allows for any reasonable way of doing deformable terrain over a network. The closest I have found to this is in udk where one can build a terrain in 3ds, cut it up, and import different chunks into udk, and fracture them. Unfortunately after a few hours work I discovered that this doesn't seem to work too well for what I am trying to do. Can anyone recommend a game engine, or even a rendering engine that supports this? Programming other features into a rendering engine is not an issue for me.
I think the C4 engine has what you need, its Transvoxel™ terrain rendering subsystem seems fairly flexible.
As far as I know, most engines around are stuck in the heightmap approach, which is not flexible enough for arbitrarily deformable terrain.
I don't know for the network however.
At 250 USD or 800 USD, I think C4 is very reasonably priced, the 250 USD version seems to be fully featured.
As far as I know, most engines around are stuck in the heightmap approach, which is not flexible enough for arbitrarily deformable terrain.
I don't know for the network however.
At 250 USD or 800 USD, I think C4 is very reasonably priced, the 250 USD version seems to be fully featured.
Perhaps look for an engine that supports writing your own Geometry shaders?
Seems like tessellating a flat plane and then offsetting the vertices based on a normal map might be your best bet, then you can simply update the normal map as you need to (or if that's too complicated, use a plain heightmap).
Seems like tessellating a flat plane and then offsetting the vertices based on a normal map might be your best bet, then you can simply update the normal map as you need to (or if that's too complicated, use a plain heightmap).
Plane based terrain won't do the trick. Apparently, they want to make something Minecraft-like. I don't know if voxels are the greatest idea either. Personally, I would experiment with a dynamic hierarchy of meta-balls, or something of that sort. For the sake of optimization, you would need a way for the hierarchy to collapse and simplify (both adaptively and structurally). I don't think a purely additive system would be enough, either:
Mass: Additive (more) | Subtractive (less)
Modifier: Filler (affects the existence of mass, addition puts substance, while subtraction makes holes) | Deformer (affects the distribution of mass, addition makes stretched lumps while subtraction makes dimples)
Property: Matter (solid) | Material (spherical texture splats/coloring)
Of course, the biggest problem is dynamically generating the geometry for this. Still, I think alternatives to voxels are definitely worth researching.
Mass: Additive (more) | Subtractive (less)
Modifier: Filler (affects the existence of mass, addition puts substance, while subtraction makes holes) | Deformer (affects the distribution of mass, addition makes stretched lumps while subtraction makes dimples)
Property: Matter (solid) | Material (spherical texture splats/coloring)
Of course, the biggest problem is dynamically generating the geometry for this. Still, I think alternatives to voxels are definitely worth researching.
Ah, the old Minecraft gold rush. I made a voxel-based minecraft clone a while back - made my own renderer for it though, so I can't say if there are any out there that'll let you do it for you.
If not, you might want to consider using a 3D texture sent to a geometry shader. The 3D texture would be the surrounding voxels (only needing maybe a 100x100x100 texture, maybe 256x256x256 at the most of R8_UINT) and the shader builds the vertices from there either using marching cubes or - if you want a cubic world like minecraft - by simply finding empty space and creating faces.
I can't vouch as to whether this would be faster than if it was done on the CPU, but it seems quite separable.
If not, you might want to consider using a 3D texture sent to a geometry shader. The 3D texture would be the surrounding voxels (only needing maybe a 100x100x100 texture, maybe 256x256x256 at the most of R8_UINT) and the shader builds the vertices from there either using marching cubes or - if you want a cubic world like minecraft - by simply finding empty space and creating faces.
I can't vouch as to whether this would be faster than if it was done on the CPU, but it seems quite separable.
Um. The C4 engine will. If not now (they already have implemented real-time meta-balls with their voxel system, but not dynamic terrain yet, although the static voxel terrain is pretty good) it will be implemented soon later. Please read the other responses. 
but if you build your triangles in a shader, how would you do physics with the terrain ?
You can create separate model for your physics.
As a general advice it is good to keep different parts of the program separated such as rendering and physics. Even if it seems wasteful, typically physics APIs use geometrical primitives (such as boxes, cylinders, spheres) or much simplified geometry for collision detection etc. You'll just have to make sure that the two things are synchronized (ie. physical world is approximately same as graphics output).
Cheers!
but if you build your triangles in a shader, how would you do physics with the terrain ?
Well you'd be building the triangles from a 3D texture, essentially that would be the set of voxels that make up your terrain. You could run physics against that, but as kauna said it's probably best to simplify it a little into something more suited for the calculations you want to do.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
