Building Placement and terrain deformation

#1 This might sound stupid, but what if every building were placed on a "fundation" of sorts in the actual model itself? The foundation would always be partially or completely buried, and the top of the foundation would touch the highest part of the terrain that the building is built upon. You'd have to limit the maximum slope that it could be placed on, and it might be hard for units to reach it, but it's the hackiest way I could think of.

#2 Terrain deformation can be used for a wide variety of other reasons as well, and it is quite nice functionality to have. Things like a large catapult missile can make a crater, players can excavate ditches/berms for siege defenses, etc.

Additionally, while what you said works in some ways, it's much more realistic in the game environment to have terrain that can be excavated/built up through villager/peon actions, then to semi-arbitrarily limit what the player can do. At least, that's how we look at it!

#3 HA! This is what I get for not paying close enough attention to the forums. I actually started on something alonge these lines on Teusday, was interrupted by a visit from a friend, then finished roughing it out today. But before you get too excited, it's not all that you are wanting, nor can this implementation be.

What I have done is 90% in script, but is plenty efficient nonetheless. Basically what I made is procedural craters that work real-time across the network. (In fact it is very much server/client specific, care must be exercised when running a listen server) Now it's far from perfect, but it's a good start.

Now for a little background... This started the same way as a lot of things I do, as an extension to some related work. I am working with another team on a racing game, and I wanted a method to use splines to define a nice smooth race track in the terrain. One result of this was that we exposed a console method that allows for setting terrainHeight from script. (The race track/spline stuff will eventually become a resource, but it's pretty heafty, so I am not rushing off to do it any time soon) That part worked out rather well. So here I was with a way to set height from script, and I had been doing so with this project, so the next thing to try using it for was explosion craters. Turns out that the most difficult part was writing the procedure to define the hole.

Now the only net impact my method has, is that a command to client must be sent to each connected client. something like so...
commandToClient( %client, 'DigCrater', %pos, %radius, %depth, %falloff, %splash, Terrain.squareSize );
Everything except the Point3F %pos is a single float.

Now you might have already guessed by now that this method makes no considerations at all for scene relighting, nor terrain texture modification. As it is, it is far too "lite" to accomplish anything of that nature,as it's performed in script. As it it exists, there is really no need to port it into the source code. TS is amazingly efficient, and as it turned out, the procedure took a lot less code then I expected. However, I think it could pretty easily be integrated with whatever setup it is that you got from Robert Brower.

Now there is one big bleeding drawback to it, which is that clients joining after a cratering event has occured do not have the terrain modifications. Since it's procedural, these events can simply be tracked, and all of them sent to new clients when they join, but as I just finished the first draft today I haven't got that far. As a side note, your functionality of creating a level spot for buildings can easily be accomplished with this method.

continued...

#4 And now for some information that you might find usefull. I might end up with my foot in my mouth, meaning I might have some of this wronge, but it's working for me so I shall continue to assume it's right. PLease don't be insulted if some of this is rather simplistic, but there are things that need to be considered when dealing with terrain.

A terrain tile is a grid of 256x256 points (vertexes if you prefer) defining the terrain mesh(65K+ total).
The squareSize of the terrain defines how far apart in torque units the terrain points are. Keep this always in mind, as a squareSize of 8 means that you only get one point every 8 units (meters). This also describes the minimum resolution and detail that you will be able to get out of any terrain deformation. If anyone has ideas for putting a one meter wide pothole in the ground, think again, the only way this would happen is if the terrain tile suddenly grew a whole lot more vertexes then it has.

Another thing I realized is that there is very little point in trying to set height for any position other then a real terrain point location. When I was setting heights at a resolution smaller then the squareSize, the results were unexpectedly undesirable. After adjusting all my code to facilitate the grid resolution, I got the kind of results I wanted.

Now I have run across the terrain spikes you have been describing, but only when attempting to set the height lower then zero. Every height value I have ever pulled from the getHeight code, or put into my setHeight code has corresponeded to real world (so to speak) Z values. IF I set a height to 20, any object sitting on that point will have a position.z value of 20. So I would suggest taking a look at the height on your terrain, because when you set a height to less then zero, it just warps around and sets the height close to the maximum allowed. In fact my scripts are very strict about checking for illegal Z values (I don't go below 1). Now as for the x and y positions, those have to be converted from world space to terrain space.(Or however you would describe it) This is not a huge problem to overcode though, mainly you just have to ensure that your mappers use a minimum terrain height of say 100, which should give a good bit of room to play with.

continued AGAIN....

#5 Had enough of this essay yet? I'll attempt to describe my procedure, just because I rather like it, and none of my team members have been around the last 2 days for me to tell it to. :)

The script makes a parabolic dsih in the ground, with a raised ring around the outside of it to simulate displacement of material, blending the edges into the existing terrain heights to avoid creating any cliffs or straight drop-offs. In essence it accomplishes this by drawing a spline from the center of where you want the crater to the edge, then spinning it around the center point. (In a modeling program this is usually called a Lathe) Of course the code doesn't actually draw any splines, it is much more abstract then that. It finds the grid of terrain points surrounding the crater, processes each one to determine if and to what extent it's height should be modified. This simulates the effect of an explosion, or perhaps a high speed impact from an object traveling straight down. It does not do angled impacts, nor is it scientifically acurate. (You'd have to know the material type and a lot more physics then I do for that). Though I can imagine ways to make non-spherical deformations.
The radius, depth, displacement and and curvature of the central pit can all be specified on the fly. Given the same inputs, both the client and the server get the same results so there is no disagreement as to where the surface actually is.

As I said, I just finished the first draft today, so it's really not ready to slap into a project and use, but I certainly have no problems with sharing it. I'd be glad to help, but when it comes to dynamically texturing the terrain, or any of that other more involved source code work, I won't be much help, I lack much C++ programming ability. And now it's late and time for bed!

#6 @Martin

I know how to change the terrain texture dynamically and am currently (as soon as I find the darn time to squeak it in) looking at Stephen's code for him to see if I can spot anything regarding the height peaks. If you're willing to shoot me your code I'll see what I can do to get the texture change in place (by like replacing it with a "scorched" texture maybe) reblended to the edges of course.

#7 Okay, for those who want to mess with it, grab this file: terDeform.txt

I ported it from script to C++. However, considering the amount of other changes/additions we've made to the terrain files, it wouldn't do much good to include my actual source files, so I broke it down similar to a resource.

#8 @Martin: Once you get that polished up some more, I'd love to use it as one of the procedurally generated deformation objects in our networked terrain deformation resource coming out shortly.

@All: Just an update--I had a breakthrough on this yesterday, and have it now working well for rectangular deformations on a dedicated server-client setup.

Jeff Leigh is working on it as well with tweaks for not only "co-located" (same computer) server-client setups, which are what happens when you play a single player game or host a multiplayer game, but he's got some pretty nifty stuff setup as well for the peons to go ahead and dig out the terrain over time, applying the deformation as it goes.

On my part, I've got it so that when you are placing a building, it will check to make sure that the deformation required to give the building a flat foundation is "sane" (user configurable, and determines basically if it would require any very large changes in terrain altitude nearby), and then apply the deformation if it is sane prior to placing the building.

Jeff and I need to get our tasks coordinated into one file, and clean up/continue to implement some different deformations such as Martin's, but once that's done we'll be passing out the general terrain deformation stuff to TGE owners, plus a special modification to that resource for RTS owners.

I'm pretty excited about this one, it's shaping up quite nicely!

#9 Cool stuff, I haven't had time to play with these yet, but it sounds cool. Terrain deformation is a popular subject, and we'll be interested to see where this goes. :) Anyway, just wanted to quickly pop in and say 'good job' to all involved here. It's always fun to see tough problems get tackled collaboratively.

#10 The resource is just about ready for install testing, so I'm looking for beta testers before I post it to GG.

If you are interested in helping out over the next 2-3 days, and have the RTS-SK (obviously you do if you are reading this), please email me or post here and I'll put you on the beta testers list.

The (and I hate cross-posting, but kit ownership security kind of requires it) background post about the resource is located Here.

#11 An additional use for this could be to create RTS maps on the fly. I imagine it'll take some additonal work to get the lighting right, but you could partially solve that by how you create your art. If the game perspective is top-down, you could put darker textures on one side of a hill, just as you would with a 2D tile-based map.

#12 I've already said so, but I can certainly test it out, for both rts-SK and, uhm , "normal" Torque implementations.

#13 I'll happily beta it as well. Just let us know what kind of feedback you'd like.