Remove terrain?

#1 Based on the pretty in-depth delving into the RTS-SK my team has done, you're not looking at any more effort necessarily with the RTS-SK than you would be with stock 1.3. Some things to watch out for:

1) The mini-map actually (as far as I know) doesn't directly deal with the terrain itself, but with the rendered image of the scene, which includes the terrain. I might be wrong on this, but I think this one actually is the easiest aspect.

2) Selection circles are a rendering pipeline modification, and expect terrain. You'll need to re-work that to be shape focused instead of terrain focused.

3) Part of the net and client (and server for that matter) optimization process was removing all "not really needed for RTS" physics and net updates. GG was able to get rid of a lot of the physics AND net traffic by making the assumption that all RTS Units would be clamped to terrain height by the client, and therefore don't do much at all in the way of Z-axis work, positionally. You'll need to pay heavy attention to RTSUnit.cc, especially processTick(), and implement code to handle your changed assumption.

4) Client side mouse handling, specifically the selection boxes, and selection in general does have a dependency on the object that was collided with by the mouse. You'll need to for sure re-work the user input primative for selecting multiple units for a group, since the activation of the functionality depends on colliding with the terrain. I can't think of anything else script wise that absolutely -requires- terrain (although it is modifiable obviously), except for building placement.

Actually, thinking about this more deeply, you will probably have an issue in general with mouse clicks in the RTSTSCtrl, since the terrain is basically a "catch-all collision" for the mouse. In space, you'll need to somehow model this "last chance collision" when your users click the mouse.

Other than these 4 points, I can't think of anything else off the top of my head. If I do come up with anything else, I'll let you know!

#2 I was jut thinking maybe I can approach this from a different angle. If can can keep the terrain but essentially turn it into a flat plane with a space like texture and no lighting.. hmm

#3 John, we're also contemplating removing the terrain. On the plus side, it should speed up the processing quite a bit. On the negative side, it'll be a nice chunk of changes to be made...

#4 Just curious, why do you think removing the terrain is going to speed up processing quite a bit? Torque's large scale terrain handling is one of the best available, especially for the price.

#5 A scene with just terrain in TGE runs at ~200FPS on my dev system at work. You burn about 20% of frame time to get this, independently of how much tiling and so forth is going on.

Obviously, slower than a plane. :) But still pretty fast.

Why not just comment out the render and collision calls in the TerrainBlock object? Much easier than properly removing it.

#6 If you do disable the terrain (or just take out the collision calls), you'll need to do a bit of work as Stephen describes at the beginning of this thread, point #3.

That would be the hardest part, but even that isn't too rough. To get prototyped as quickly as possible, I'd suggest commenting out the render and collision calls, as Ben says. Then you'll need to change the RTSUnit process tick, (and RTSBuilding, and any other subclasses you've made) and make sure that you're handling z-placement in some way. What you do there will depend on exactly how you want your game space and play to work.

#7 I'm actually thinking I can keep the collision. Make the terrain completely flat and not render it but keep it there for collision. I figured if I keep the collision then i'll have less changes to make and there is no problem with them all being on an invisible flat plane.

#3 and #4 on Stephen's list are actually not a problem if I keep in the collision I found. Its #1 and #2 I need to address though when I take out the rendering. Both issues should be relatively easy to address but I need to get back up to speed on Torque before I can do so :)

#8 The only issue I can see off the top of my head is that you'll want to have your spaceships (or whatever) significantly far away from the terrain so that they never collide with it "accidentally". There may be some altitude restriction issues that pop up based upon that in unusual places--one of the base design assumptions of TGE/TGE+RTSSK is that the world is -really- 2D with a "fractional" 3rd dimension (z axis)--understand please that I mean that from a design perspective, not from an implementation perspective.

Fuzzy difference I know, but for example, you have something along the lines of a max height for flying in the mission file IIRC, as well as only 2048 (again, IIRC) "height levels" with the terrain itself. I can't point to any specific examples, just be on the lookout for unusual situations that may be caused by an altitude/z-axis clamp to a max value.

#9 I guess it depends on if he's keeping a 2D playing field, or if he's doing a true 3D one. If it's a 2D (isometric for example) space RTS it would probably be a great solution to not render the terrain but keep it for other purposes. It seems to me that a lot of the placing and movement functionality is tied to the terrain.

I'm personally moving away from the idea of removing the terrain, since I'll want land sticking out of the water. Initially I was planning on using DIF or DTS shapes for that so maps could be dynamic.

For the prototype I'm just submerging a flat terrain under 1 unit of water.

#10 Im looking for this same feature, to remove terrain, or to make it invisible, so units can still walk on it, but you can only see the sky box (space). So anyone want to work on this with me?

#11 Ok so #3 is complete, took less than a minute, but i think im having trouble with #1, When i remove the terrain from the mission file, it says guicontrol::awaken: failed OnWake. And then it shuts off. So i think something needs to happen to the map hud.
Edit: If the problem is that it needs terrain for map hud to work, then is there a way for me to render the map hud, with no terrain?

#12 Ok so i have #1 and #3 complete, now the camera is set to stay a certain distance from the terrain right? so i need to change this. Im going to try and do this now.

#13 Ok just to let people know, I have removed terrain and it works good.

#14 @Robert

Would you mind explaining in a little more detail how you deleted the terrain? (I am basically trying to use a .dif file at the same height so I have more control over planting one texture image (image of a map of a city) so I don't need to change any of the collision information. Just the non-rendering of the terrain. However I get the same error you got. (guicontrol::awaken: failed OnWake) how do I get around this? Any ideas or anything that could put me in the right direction would be greatly appreciated.

#15 Well the Mini Map needs terrain or you will get a error message. So what I did was to comment out some stuff in maphud.cc, At line 90 comment out rebuildMap();, and line 64 return rebuildMap();
I might have done more than this, I cant remember exactly. Now your units will also need terrain, to fix this you will have to add some sort of static height to your units in RTSUnit.cc, to do this check these forums for a thread i created about Adding Z stuff back in. Stephan was kind enough to help me put something in my project.