Game Development Community

dev|Pro Game Development Curriculum

Caves and Vertical Cliffs with TGEA Terrain

by Caylo Gypsyblood · 01/26/2009 (10:00 pm) · 26 comments

Testing the flexibility of TGEA's terrain system I decided to try an old trick i have used on other much more expensive 3D engines.

First test was to see if Torque could use a high map terrain to build vertical cliffs.

home.comcast.net/~porkcow/TerraCliftA1.jpg home.comcast.net/~porkcow/TerraCliftA2.jpg
The cliff face is complete with overhangs, and if one wish placing another terrain map at the top of the cliff also works. I used a 512x512 maga terrain hightmap, cut into 4 normal hightmaps sections.
home.comcast.net/~porkcow/vertClifftest.pngOnce imported into TGEA and I was done painting textures, I rotated the 2 cliff faces and placed them on the 'ground' terrain.


My next test was to make caves useing TGEAs terrain systm.
home.comcast.net/~porkcow/TerraCaveA1.jpg home.comcast.net/~porkcow/TerraCaveA2.jpg
This is accomplished by designing your hightmap, and import it.Paint your textures. Now copy it then flipping it 180 and place it over the 'ground' terrain.

I have used some clumsy voxel terrain implementations and always hated how much time and effort they take. Now Torque allows more then one terrain and allows the level designer to rotate them. The flexibility far exceeds what current voxel terrain can do, and is much easier to work with.

Think of floating islands, deep canyons and arching land bridges!





Page «Previous 1 2
#1
01/26/2009 (10:11 pm)
Hey, that looks quite cool, nice work!
#2
01/26/2009 (10:32 pm)
I remember people doing this in Starsiege: Tribes to make cave missions. :D ... Good times. I don't recall it being done in Tribes 2, though... I guess it must have been a limitation back then.
#3
01/26/2009 (10:53 pm)
Too bad we cant use shader with the terrain. And most the terrain texture paint functions are busted right now.
#4
01/26/2009 (11:15 pm)
i tried to make a world but it just cant work unless i code in gravity or something as you will just fall off the end instead of going all the way around it. it was fun though i already thought of the cliffs and caves the cliffs work fine. the only thing though is when you go to edit the map from inside the engine it's real real hard to do it as it wants to edit it only on one side so you editing in space just about but when it's really editing it on the map which is ether on its side or inside down little hard to work with.
#5
01/26/2009 (11:32 pm)
Ya, you just need to think from a different spatial relationship. Once you get the hang of it, its easy. Just try place the camera Orientation to DOWN viewing the terrain to edit, so if your working on a cliff it looks like a flat normal height plain.
#6
01/26/2009 (11:46 pm)
good point then all you have to do when your done is rotate it to where it needs to be. :P still i would like to be able to make a world and be able to walk all the way around it. when i buy tgea i think that will be my first task even though i don't need it for the first game i am building but it would be fun to play with. i would think someone would of already made a code to be able to do that already so i might look for it first.
#7
01/27/2009 (12:31 am)
Neat stuff man.
#8
01/27/2009 (6:57 am)
Quote:
Too bad we cant use shader with the terrain.

The terrain blender *is* a shader, and the detail pass ontop is also a seperate shader. Finally, the clipmapper which is used in legacy is a shader.

Edit: Oh and those pictures look great.
#9
01/27/2009 (7:23 am)
Thanks Stefan,

Currently I am building a 'quick and dirty' gamed demo to example using terrain blocks as above (and more), but with more real game functions- its a simple quest game to find and collect 'keys' that open access to other parts of the level using much Z space exploration on the cliff and into the caves, sorta a playable tutorial.

I tried to add 'bump mapping' to my terrain paint materials but it did not work. Im still slightly ignorant how the metatarsals work correctly. I hope to use DEFAULT art assets so the mission can be dropped right into a stack SDK example games, with scripts for my fellow Torque users to get started with and show how it can be done. Im hopping the Torque community finds this as valuable as i have and even share there possible expansions on the idea. The more i fiddle with my experiments the more powerful i find it to be. This is the most exciting feature i have seen in Torque for a long time, i hope it don't end up being dumped in T3D. Oh and I have already experimented with importing upto 14 terrain blocks.

One questing, how do i set square Size 2?

Im very excited with this technique as Torque is the first engine i used like this who can render it fast and effective. Lots of fun creative design should branch from the same technique. I already have land bridges and floating land islands that look spectacular!
#10
01/27/2009 (8:57 am)
Great idea! What are the hits on performance? As far as I know the legacy terrain rendering code is not the most optimized piece in the source, and eats up lots of fps compared to ie. Atlas. How does the framerate change in the scene when you add more terrain blocks?

While Atlas should be able to do this by design, I don't know of a terrain editor that is able to export data as a model - one that Atlas would read in without any modifications. So editing Atlas and getting the model into the game is a whole other story.

A problem I see with your approach is that these only work for cliffs alongside your normal terrain.

The screenshots look really cool!
#11
01/27/2009 (9:19 am)
Looks great man, but wouldn't that be easier using Konrad Kiss' Big Cliff Construction kit? I would figure it would be time consuming but you get more leverage over your cave scenes with it vs the flip the terrain thing. Just a thought... Konrad? Is that possible going the route I suggested without a major hit on performance? I haven't tried it, still waiting for the 1.8 release of the BCCK to come out before I can test that idea... again good work.

Will
#12
01/27/2009 (9:32 am)
@Will: I believe that both methods have their pros and cons. The Kit has the chance to look more realistic, probably gives more fps, and its possible to use it anywhere on the terrain. Caylo's method makes for more natural curves and a more "compact" scene under some circumstances. It most likely also does a better job at self-shadowing. It's basically a terrain - dts comparison.
#13
01/27/2009 (9:54 am)
Are you referring to Procedural Shaders? They are different. TSShape and Interiors are pretty much the "only" objects which can use them.

Terrain materials are customized. The old terrain was more simple to work with, and I had no problems getting bumpmapping onto that. But now that we're working with a clipmapper, things are a bit different.

The approach a I took was to clipmap the bump texture of each square, and include it as a secondary texture unit in the shader. Works, but you can notice the framerate difference.
#14
01/27/2009 (10:22 am)
Amazing! Great work! I would like to see running!
#15
01/27/2009 (4:03 pm)
Great idea! What are the hits on performance? On my AMD system i have seen NO speed degrade. It have been noted that 1.8.1 will have terrain optimizations, so that will change everything.

If one wish a level of extra realism use Konrad Kiss' Cliff Construction kit along with terrain vertical cliffs, to add extra protrusions and 'dirty' little details, mix it up.

The most important thing is to think 'outside' the box. Why stop at caves and vertical cliffs? Anyone a fan of Ringworld?

@Stefan, so if i want a bump texture mapping on terrain i would need to add it myself? This is sad, as now a days almost every engine have the ability to bump texture the highmap, 1 of them even allows different normal map per terrain texture. No time in my life right now; but i expect changing the detail texture channel should be rather easy.

EDIT: I will upload some playground mission files with the two above examples. But not for 4 more hours.
#16
01/27/2009 (6:33 pm)
Also something to remember (If it wasn't removed in TGEA) is that terrain also prevents things behind it (hidden from the terrain) from being rendered. Regular DIF and DTS objects do not do this.

Now its possible this changed recently, but if it hasn't then by useing multi terrains like above you could gain some fps.
#17
01/27/2009 (6:47 pm)
@Thomas,

DIFs prevent other DIFs behind it from being rendered. Unless they changed it in TGEA.
#18
01/27/2009 (7:24 pm)
Yes terrain is currently the only render blocker at this time. DIF will only occlude if it is a portal zone. A cleaver programmer could easily plug other occlusion types into SceneGraph::treeTraverseVisit. Long ago i had DIF blocks used to block any rendering behind them (but not the way you are thinking, more a ALL render objects blocker).
#19
01/27/2009 (8:13 pm)
Hey that's a really nice trick and one that I'll probably use - thanks for the tip
#20
01/28/2009 (7:51 am)
Yeah, DIFs currently will not prevent objects and other DIFs behind it from rendering. The only way to do that with a DIF is portal zone the DIF up. Even then it is only going to block stuff inside the DIF that you have portaled. Such as if you have a town of DIF buildings layed out on flat land all of the DIF buildings are going to be rendered regardless if they are behind or infront of another DIF.

Currently only afew things prevent a object from being rendered. That is the view distance (Things placed beyond the max view distance will not be rendered), Things inside of a portal zoned DIF, or things that are hidden by the legacy terrain.

Now I say legacy terrain for a reasion because last time checked Atlas terrain does not use any type of occlusion (this could have changed in 1.7+ but I doubt it).
Page «Previous 1 2