The terrain engine

#1 The scripting is for all practical purposes REQUIRED. Resign yourself to that, it is there for a good reason. If you want to to do absolutely everything in C++ you are probably not going to be happy with the way the engine is architected, it is tightly coupled to the scripting paradigm.

#2 No, this is not a ROAM implementation. ROAM has some unfortunate latency issues; we used a more execution time consistent proprietary CLOD implementation.

We're also significantly improving the terrain implementation for the Torque Shader Engine to take advantage of modern hardware. Of course, the advantage of the TGE implementation is that it will run on anything. If you want to reach the widest possible audience, it can be nice not to require a GF3 minimum...

The engine is written in C++, so it's pretty easy to integrate with it. You just write code... :) It isn't a stand alone library you code against. You just go in and modify what you need to to make your game. If you like you can rip everything out to have a "clean start", but it's not really very productive to do so - better to analyze what's there.

I guess the thing to bear in mind is that if you want to make a game that will run all over the place, Torque is an excellent toolkit. If you want to perform an exercise in software engineering, then you might want to go play with another engine. :)

#3

Quote:...I find it really hard as a possible purchaser to get info on how to intergrate with the engine using C++ rather than scripting everything. Are there any good tutorials on this from the ground up?

Such information is only availble to Torque licensees, since it reveals the engine internals.

#4 We're also significantly improving the terrain implementation for the Torque Shader Engine to take advantage of modern hardware. Of course, the advantage of the TGE implementation is that it will run on anything. If you want to reach the widest possible audience, it can be nice not to require a GF3 minimum...

If you'll let me hijack this thread for a moment but -- o.O Does that meant aht TSE will contain terrain with more features than TGE? If so, will these be back-ported to TGE? Or will TSE rely upon non-shader versions if the hardware isn't available?

I plan on sticking with TGE right now, because as you state, it's good to support pre-shader cards. But I would like to move to TSE if I can take advantage of the whiz-bang stuff but without requiring players to have the latest and greatest.

Sorry to ask again if this has already been covered to death, but I'm just curious.

#5 Ah ok, that clears things up a bit. I had assumed it was a library, but with a light wrapper for the script type people. Presumably that means that its structured in such a way that to code in C++ there's going to be merge issues trying to keep synced with your changes ;)

Another query is with respect to the networking. I can't find information on what the difference between torque's in built networking and the separate TNL products are? (I've found the TNL website though)

Its such good value anyway, I'll probably pick it up if only to have a poke around and see a working engine with lots of nice features.

Anyway thanks for responding.

#6 David I did see it alluded on another thread that TSE will have a terrain manager which presumably (hopefully?) will allow paging in of terrain chunks on the fly etc. Also I imagine that the CLOD could be implemented in a vertex shader.

Its funny, I spent 2 years messing around with direct 3d and only ever churn out the odd half arsed tech demo, yet I'm finding myself a tad reticent about picking up this well featured engine with a load of good tools. Thats the thing with the rut I'm stuck in, I waste so much time chasing optimal solutions that nothings ever delivered.

#7 Knuth said it best!

#8 Daniel, TNL is the TGE networking broken out as a separate product for use with other engines.

#9 TSE's terrain is a rewrite from TGE's. We are not currently giving out feature lists. It will have some terrain manager like functionality built in. It will be cleaner, nicer code.

If you want to use shaders, you basically need a GF3 or better, which is what we're targeting with TSE's demo. It would of course be possible to get TSE to run on any DX9-compatible card, or you could even write your own renderer and use 8.1 compatible cards or lower. Obviously, the lower you want to go the more game-specific code you're going to have to write and the less you'll be using TSE's forte, which is shaders.

TSE is pretty flexible and powerful but it isn't going to make your game look as good on a GF2 as it does on a 6800. :)

#10 In fact, CLOD cannot be efficiently implemented in a vertex shader. I've seen a few demos, but they've been just that - demos. :) The shader LOD techniques I'm familiar with are tile-based and wasteful of vertex thoroughput.

There will be a basic terrain manager - and the code will be clean, so you'll be able to easily extend it to do things like paging on the fly.

#11 That extensible terrain manager sounds pretty good.

I've never benchmarked the tile based CLOD stuff personally, but presumably the thinking behind it is that whilst you are potentially using a bigger vertex buffer than necessary, the fact you aren't having to lock it and modify more than makes up for it. Have you done a comparison?

I'm going to pick up torque anyway, I'm interested to see how you texture the terrain whilst doing clod (folding vertices causing the obvious texture co-ord probs if using tiling textures). Is it just a giant bit map? Guessing maybe as the only other approach I've seen is texture splatting which isn't particularly friendly on todays hardware.

Anyway thanks for all the info guys. Everyones been really helpful.

#12 Have you all seen this demo? probably have, but just in case
http://users.belgacom.net/gc610902/

#13 TGE does all of its terrain stuff by streaming the geometry to the card. Not the fastest in the world, but like I said, it runs everywhere. (The original terrain tech was developed for Tribes 2, remember.) The new system is a hybrid - uses tiled vertex buffers and dynamic index generation with a subpixel error metric.

#14 @Ben Garney: That works well client side, but are you indexing it server side as well? One of the biggest issues IMO with terrain paging is keeping the client's observed terrain synched with the servers. We need to take into account net latency and transmission period (for updates), and have the client recognize terrain page needs, transmit them to the server, and be prepared for when the player is actually ready to observe the newly paged-in terrain.

Please remember that for those that need terrain paging, the underlying design requirement is the ability of the client to "pre-load" expected terrain from the server and be ready to render it to the client.

#15 I don't really understand what you're talking about. The server is basically going to need to keep all the terrain data loaded at all times - in system memory. It won't be using video memory at all. All my comments above relate to rendering techniques, which don't relate to networking at all.

In theory, you could do networked streaming of terrain; however it is far from a priority for TSE!

#16 And that is why we are trying to pin you down regarding the enhancements to the terrain capabilities of Torque.

Rendering is important, don't get me wrong at all, but for those working on projects that require seamless terrain transitions, the pipeline is much larger than just client-->video. Specifically, the (expected) pipeline is:

database server->game server instantiation (1 or more)->network->client, and transitions across all the obvious and not so obvious boundaries. Currently, with the lack of ability in stock Torque to have more than one terrain block loaded in an application instantiation, and/or (one level higher), the limitation of one "mission" loaded at once is the hurdle we see.

In a nutshell, the "Terrain Manager" that Bryan Turner presented was simply a thin API around the restriction of only having one Terrain Block available in client memory at one time. He provided a framework to allow multiple terrain block/mission blocks to be referenced by the client, giving you the ability to instruct the client to "preload" terrain that was expected to be observed shortly (based on client move prediction, at the user, not network, layer). The Terrain Manager gave you the "awareness" of not only the current block the player was in, but "awareness" (and ability to modify through the editors in a world building mode) of the next block(s) they were -expected- to be within.

This gives you the ability to handle all the disk based loading, object instantiation, and related cpu/network intensive tasks before the player hits the "I need to see it NOW" state, allowing for the concept of "seamless" transition. As the player approaches the boundary between two "missions", the client can prep up to handle the boundary transition with little to no user perceived wait period (no "Loading terrain...Loading Objects...Picking my nose...Done!" period).

I may speak for a minority of one project, but I would suggest that when people here on the boards are talking about "terrain management/paging", this is what they mean--removing the player wait states while maintaining a small(er) "window" of observation on a VERY large game world.

Btw, this quote: "The server is basically going to need to keep all the terrain data loaded at all times - in system memory." Is -never- going to work as an MMOG application architecture. A properly designed server application architecture is going to have the ability to load balance smaller segments of the world across multiple server applications. At least, if they want to handle 1,000+ logins without 22nd century platforms.

Note: I'm glad we're clearing up this term confusion. While it's (slightly) dissapointing to here that TSE isn't going to be working on this area of design/implementation, it -really- made me wonder why a primarily graphics based release was concerned about terrain paging from a world perspective. I'll release my development hounds to get back to work on our application architecture!

#17 Stephen

Although I love your idea, I don't think it's going to be a priority and certainly nothing easy to code. To me that sounds like a major change to the engine.

#18 @Stefan: Aye, you are correct--while it possibly should be an area of future improvement to the Torque SDK, it has nothing to do with TSE, and I'm glad that (at least for me) we cleared that up...now I won't be asking myself daily "when is TSE going to be out so I can move ahead with our world development?" :))

And for what it's worth, yes, it is a pretty huge change to the engine. We've spent more than a month tearing code apart simply to check to see if it's even feasible, much less implementable given the current framework in the next 3 years (it is, but it will be a challenge!).

#19

Quote:Btw, this quote: "The server is basically going to need to keep all the terrain data loaded at all times - in system memory." Is -never- going to work as an MMOG application architecture.

You know, a lot of MMOG games, recent ones even, are still using zones and loading screens. No one seems to mind.

#20 @Stephen: Yeah. And you know, not all games would WANT this either, some game might even need the current system more than the "proposed" one.

@Mark: I don't really know what's wrong with Asherons Call 2.. or if it's just my hardware, but anyway - AC2 uses dynamic loading of most of the stuff, including the terrain. This doesn't always work well at all, and I sometimes find myself missing the old technique of switching zones.