Terrain Editor - Editing on more than one axis
by Peter Ryan aka TorQue[MoD] · in Artist Corner · 04/27/2003 (3:38 pm) · 3 replies
Is there some reason why the terrain editor in Torque only allows you to manipulate the terrain on the Z (vertical) axis?
If you were able to manipulate the terrain on an X and Y (horizontal) axis as well, it'd be pretty much like working with clay and the terrain you'd be able to create would be amazing.
Any thoughts on this?
Also, why aren't there any pre-made mapping entities for Torque? Like func_door or ambient_generic?
Isn't there some way that you could simply have the entities in your .map file be transfered over to the Torque engine when you convert the .map to a .dif?
Then all someone would need to do is code the Half-Life entities into the engine and you'd have full .map support in the Torque engine.
Just another thought.
If you were able to manipulate the terrain on an X and Y (horizontal) axis as well, it'd be pretty much like working with clay and the terrain you'd be able to create would be amazing.
Any thoughts on this?
Also, why aren't there any pre-made mapping entities for Torque? Like func_door or ambient_generic?
Isn't there some way that you could simply have the entities in your .map file be transfered over to the Torque engine when you convert the .map to a .dif?
Then all someone would need to do is code the Half-Life entities into the engine and you'd have full .map support in the Torque engine.
Just another thought.
![Peter Ryan aka TorQue[MoD]'s profile picture](http://static.garagegames.com/static/images/theme/blank-user.jpg)
#2
TGE does have pre-made mapping entities. They are defined in the fgd file that comes with map2dif. They are a pretty simple entities though. The interior (dif files) code is not for the weak of heart but with some perseverance someone could add new entities (I just added a new entity recently). Unfortunately, getting the entity into the dif file is the easy part. From there you have to add code to carry out the entities functionality to the rest of the engine and that can be tough depending on the entity.
Another fundamental problem is that in games like Half-Life, Quake 3, or Unreal Tournament the player is always be contained inside the level whereas most TGE interiors are designed as buildings that are viewed and entered/existed from outside. So a straight conversion of maps made with those games in mind are very unlikely to work.
You might then say, "Well I could just do away with the terrain and keep the player contained inside the interior in TGE just like in Half-Life." The problem here is that TGE's interior rendering code is weak compared to a pure bsp based game like Half-Life so the interior is going to run a lot slower. This will limit you to pretty simple Half-Life levels.
Have no fear though, these are exactly the problems that I am working on =) It is going to take some time (many months) before you will start to see much of the results of my efforts but they will come.
04/27/2003 (6:09 pm)
The terrains in Torque are represented as a list of heights for a 2D grid of points that the engine "connects". Since you can't store two heights for the same spot this means you can't have terrain overhang any other terrain. This is done for a number of reasons not the least of which is speed, file size, and memory usage. Arbitruary three dimensional terrain is very expensive to calculate and render and game engines aren't quite to the point of doing it in realtime (you'll see tech demos but very few real engines doing it). I have seen some tricks to get around this basic limitation. The Drakan engine uses a very effective scheme with multiple heightmaps (the 2D list of heights) in the same level to generate some pretty amazing terrains but it can be a pain to edit. Another trick is to use non-terrain geometry (like a model) to fake a piece of terrain with an overhang (like a cave or a cliff).TGE does have pre-made mapping entities. They are defined in the fgd file that comes with map2dif. They are a pretty simple entities though. The interior (dif files) code is not for the weak of heart but with some perseverance someone could add new entities (I just added a new entity recently). Unfortunately, getting the entity into the dif file is the easy part. From there you have to add code to carry out the entities functionality to the rest of the engine and that can be tough depending on the entity.
Another fundamental problem is that in games like Half-Life, Quake 3, or Unreal Tournament the player is always be contained inside the level whereas most TGE interiors are designed as buildings that are viewed and entered/existed from outside. So a straight conversion of maps made with those games in mind are very unlikely to work.
You might then say, "Well I could just do away with the terrain and keep the player contained inside the interior in TGE just like in Half-Life." The problem here is that TGE's interior rendering code is weak compared to a pure bsp based game like Half-Life so the interior is going to run a lot slower. This will limit you to pretty simple Half-Life levels.
Have no fear though, these are exactly the problems that I am working on =) It is going to take some time (many months) before you will start to see much of the results of my efforts but they will come.
#3
I don't know anything about coding, but why is it that having terrain with overhangs etc would effect the speed of the game? Isn't it just a matter of how many polys are rendered at once, not the position those polys are in?
If I were to make similar terrain in Max I'd have the ability to extrude the mesh in different spots etc. but doing so wouldn't increase the number of polys, it simply positions them differently.
I'm not understanding how having more than verticle differences in the terrain would make any difference. Is the terrain in Torque not a regular mesh then?
That might explain why there is no compiling in order to get the mesh to work.
Then again, on that thought, why couldn't you add the ability to edit the terrain on any axis and then render the terrain into a mesh with a CSG stage that divides the terrain into different chunks so the engine can better decide what to render and what not to render.
04/27/2003 (6:31 pm)
Hmmm... I did already thing to use models to create different parts of the terrain that I couldn't create with the Torque editor, but I was just wondering if it would ever be possible to have the ability to edit the terrain on different axis' in game instead of having to make a model and import that.I don't know anything about coding, but why is it that having terrain with overhangs etc would effect the speed of the game? Isn't it just a matter of how many polys are rendered at once, not the position those polys are in?
If I were to make similar terrain in Max I'd have the ability to extrude the mesh in different spots etc. but doing so wouldn't increase the number of polys, it simply positions them differently.
I'm not understanding how having more than verticle differences in the terrain would make any difference. Is the terrain in Torque not a regular mesh then?
That might explain why there is no compiling in order to get the mesh to work.
Then again, on that thought, why couldn't you add the ability to edit the terrain on any axis and then render the terrain into a mesh with a CSG stage that divides the terrain into different chunks so the engine can better decide what to render and what not to render.
Associate Kyle Carter
Other than that, the idea of having func_* support wired in is pretty cool.