Terrain dammage!

#21 The method Melv mentions, and DRS has implemented is fine.. Ive done it that way myself before (storing a change list, sort of a modifier stack for the arty types!). Its actually quite efficient if you use a simple point + radius effect modifier.

Thing is, once youve done that, you can start doing all manner of funky stuff. For instance, you could actually generate your terrain ON THE FLY, or at mission startup. Think of using more than just dents.. erosions, edge detectors etc.

I.e. generate a random seed, send that to all clients, have each on take a base heightfield (i.e. flat landscape) and then deform it based on the modifier list (way way way faster than sending a landscape).

Boom! you got a new random landscape.

If it werent for the fact that we required complete destructability in 3D (i.e. you can blow caverns into hills) we'd have probably ended up with that.

Lightings and issue. But that could probably be setup to work over frames fairly easily.

Blending could be way way way faster too.

Ah, its all fun. Me? i remove my landscape altogether.. 300fps anyone? :))

Phil.

#22 Hey Phil -
OK, you just revealed one of the unique points to TZ - both pre-generated terrain levels, and randomly generated terrains. :-) So much for that idea bein' a secret ;-) I had never seen anyone do randomly generated deformable 3D terrain before - thought it would be pretty danged unique. (Of course I say that, and someone is gonna point me to a game that already did it :-)

#23 Hey Melv,
If you do give this a go, by all means post something the rest of us can play with. I for one really LIKE the idea. For a good example of how much this enhances gameplay, take a look at 'Treadmarks', which uses the same LOD algorithm for terrain rendering as Torque and is network multiplayer.

Just my 2 cents worth...

#24 Deformable terrian is at least 60% of the gameplay of TreadMarks, and it would almost be required for a full fledged battlefield simulator.

#25 Okay,

Here's the deal. I'll get people started on this but realistically I've not got the time to work on anything other than our game. I'd like to help all you nice folks where I can so I started putting together a demo object that'll do the job but I ended up stopping last night because I didn't have the energy to go through how exactly the height-map is updated on the terrain.

I know you can use setHeight but there seems to be some other method of updating the height-field display. I need to investigate the terrain editor object to see how it's done but I'm not going to get the time to do this for at least a week or so now, so if any of you know the steps involved in updating the terrain height on-screen then I can pretty much send out what I've got so far to the community to finish off.

The object I've got is only a demonstration but you can target a point/area for deformation and it communicates directly to the clients this information for the client-side object to actually do the deformation. The only problem is that there seems to be other steps involved after you change the terrain data-set height.

If no-one knows then I will finish it off myself next weekend. :)

- Melv.

#26 Here's an idea I thought of while thinking of how I could apply such a code snippet to a game: Sometimes, you may not want your terrain to be destroyed in certain places(ie, right next to a building, where it would expose the underside of the building and leave players wondering why the thing isn't falling into the crater).

Wouldn't it be nice to have a sort-of "deformation mask" that masks out the locations of buildings and such where you don't want terrain deformed because of loss of immersion? It could work like an alpha map, and the brush, when applied to the mask and the heightfield, would only be applied to the part of the terrain that is able to be deformed. This also opens the possibility of a deformation map that could determine the "deformability" of a certain piece of land.

Let's face it, a grenade on the beach will make a nice hole, but throw it onto a slab of bedrock, and all you do is chip it. And if you want to do battlefield simulators, it would add to the realism if you could only bulldoze dirt and not solid rock.

I don't think it would make too much of a hit on performance at all, if you're applying brushes to heightfields on servers. It'll just be another image operation as far as the app is concerned, wouldn't it? I'm not that deep into TGE myself, but I've done plenty of heightfield work, and it shouldn't be all that bad, and it conforms with the modifier-stack way of doing the terrain deforms.

#27 Melv,

I lived in that section of code for quite a while working on TerrainManager. If you run into any strangeness drop me a line if I can help I will, some of that code is non-intuative.