Why is legacy terrain still developed?

#1 They serve different purposes.

Altas is for huge terrains that are paged in from disk. Those requirements have the side effect of making Atlas not suited for editing or deformation in realtime.

TerrainBlock is for smaller non-paging terrain. It is perfectly suited for realtime editing and deformation.

#2 Fair enough.

#3 My only gripe with the current version is that the groundcover doesn't work on atlas. Damn nice work on the ground cover BTW, huge improvement there. It should be noted that Atlas had some nice improvements this time through too. I haven't merged yet (still in the playing around phase) so I'm not sure if it's atlas code improvements or if its just that improvements in other areas are benefiting it, but I'm getting a more than double the frame rates on all of my atlas terrains, compared to what I had before. The old terrain water demo would give me 270 fps, now I get about 560. I imported some a custom terrain that used to give me 170 fps in terrain_water_demo and I now received 435.

Personally I'm enjoying Grome's editing capabilities and plan on sticking with Atlas. But I do think the legacy terrain changes are a big improvement over the previous Legacy, and I can see a lot of projects choosing to use it instead of Atlas.

#4 I really hope that at some point, there is an obj to atlas converter to allow for conversion of any subdivided plane (1024x1024, etc.) to be converted, or maybe the format doesn't need to be that strict - i dunno. What I do know is, a "feature" listed of atlas2 was the ability to have overhangs and caves, and I was pretty pissed to find that while this may well be a capability, there's no immediate way to actually use it!

Actually scratch the obj thing, just convert vector displacements (will post example soon).

#5 Alright, vector displacements can't do caves, but it can do overhangs and such, check this out (done in Modo):


The artifacts on the displaced mesh are due to Modo doing some retarded compression/conversion to 8bit.

#6 You might try combining the clipmap class with the polysoup class. You'd get a single large mesh you could put a big texture on. This would be roughly equivalent to what's in idTech4, and if you kept the terrain polycount (<10k polies) low it'd render nice and fast.

Hmm, that's a good idea.

#7 Yep.

QuakeWars uses this LOD-less terrain system. They generate a single terrain mesh optimized to under 32K verts (i assume to make it fit in a single vertex buffer). They can then render the entire terrain in a single draw call.

They then use the "megatexture" clipmap stuff to do all texturing.

Its a good system.

#8 @ Ben: That sounds quite cool actually.

Since I started looking at TGE/TGEA I tried to figure out how our game could be accomplished. It's a single player adventure which not necessarily need huge terrains - but rather small ones with highly detailed textures and a more believable landscape.

If one could get clipmap-stuff to work with polysoup/DTS (for a decent performance) - one could make a model in 3DS Max - with cliffs, overhangs and caves. Then, after some clever UV-unwrapping, export it to zBrush (or just unwrap it there) - where you refine the model some more, texture it (with the ability to project the textures from any direction, paint over seams etc).
Then back to 3DS Max to bake some realistic lightning into the large texture.

What do you think? Crazy and impossible to accomplish?!

#9 @George Rolfe
Atlas is quite capable of overhangs as is.
The problem is the content pipeline.
I just posted a rather large blog in m .plane that thanks to GG's website got chewed up.
Not GG's fault I am sure. My blog may have simple been to big.

Anyway In the process of creating my spherical terrain code that is based on atlas I discovered the the atlas code as is can handle overhangs with no problem but I am not sure about caves.

Basically go here and download my example of TGEA compatible spherical atlas.
The atlas file can be loaded from ANY version of TGEA out of the box( No code modification needed).
While it is for my planet terrain you can see that there are a number of overhangs on the surface.

It was created by projecting from a center point instead of just the z axis like the current content pipeline limits you to.

It is possible to create a obj/3ds/whatever to atlas converter.

#10 Bill Vee brings us the cool once again!

#11 @ Billy: Cool stuff!

Just some things though; even if you could make some overhangs with a different projection of the heightfield you will still end up with stretched textures if you project the it in the same manner as the heightfield? I suppose there is no easy solution for this...except if you could make an export/import for a mesh-format with edited UV-coordinates.

Since I'm no coder, I get stuck in either...

a) My polysoup-mesh (modelled in 3DS Max and with UV-coords edited for no stretching, painted in DeepPaint) would require too large textures (hit the DTS '2048-roof' I think) to keep up the detail.

b) I don't have a clue have to get my UV-edited mesh into Atlas to use this, rather highres texture...supported by clipmapping thus making it possible to have them larger (I guess).

#12 @Tobias
Correct.
UV stretching is because of the current content pipeline.
Each vertex in a atlas file greater than version 140 stores info for UVs and Normals.
The way the built in importer creates a atlas from a heightfield causes the UV stretching.

Not that it is easy to fix this. But it can be done.
I have done experiments on vertical terrain and altered there UVs slightly to reduce the stretching.

#13 Tobias there are 2 ways of dealing with the stretching:

1) Allow conversion of a 3D file with unique UV's (produced in your 3d program of choice)

2) Add X and Y texture projection (would work for blended terrain only) rather than just Z (top down).

#14 @ George: Mmm. You're absolutely right.

@ 1) I guess you mean conversion to Atlas2...since I already have made a go at this (polysoup-DTS, see above) and hit the wall - at least as DTS works now. A DTS/polysoup with clipmap-support may be a path to wander down of course, as mentioned earlier by Ben Garney.

@ 2) I would really see the "new Legacy" (TerrainBlock) support different projection axises per layer...I really like TerrainBlock after more control to the texel-resolution etc. was added. And it's superior to Atlas or externally model your terrain IMO, since it could be altered in the engine.

#15 If one was able to edit Atlas terrain in engine, then there wouldn't really be any need for legacy terrain now would there....

If you take a look at the HTC code which is available in the tools section, you can see that the source is available for an Atlas terrain generator.

I am currently working on making a fully integrated mission editor where you can edit the terrain, and place DTS/DIF objects for Atlas terrains.