Sign up to revive Terrain Manager

#41 Count me in too, though my focus right now in on some GUI/control stuff messing with the terrain code is next on my list.

I've got a copy of Gorpe (I assume it's the most recent one) but I don't seem to have a copy of Terrain Manager (I've found numerous links to the 18 build, but they're all dead). Any possibility of tossing me a copy?

#42 Yes. I have build 18, but I believe you will find that if you have Gorpe the Terrain Manager in the terrain subdirectory is much further along (almost a year further along). However, if you still want a copy e-mail me and we can work out a drop.

#43 Ah, quite right. I have it. No worries. Never really looked for it, I'm afraid. Just always saw it offered separately for download and assumed it was stand alone to some degree, and since Gorpe never seemed to compile properly I've never really dug into it's internals. Wanted to get more familiar with the base engine before messing with something that'd been modified. I'll take a few hours this afternoon to look it over.

Any idea as yet where you fellows are going to start on this?

#44 I can see several major things that need to be addressed

1. Client side paging - I have code I have done for that but it needs to be turned into a generalized solution.

2. Editor issues with reading and writing tiles from a multitile system without them getting out of whack with each other. I mentioned this as a test above for Ben to look out for. Especially when dealing with importing grey scale images this can be tricky. The problem is the 256 greyscale height. The system will try to raise the general terrain level in order to allow a finer grained control of the terrain on the tile. So if one of your terrains starts 500 meters above sea level the system will start for that tile with an assumption of 500 meters as a "zero" height starting point and then scale the rest of the terrain uniquely for 256 units based on how high the terrain for that block goes up from the 500 meter starting point. For multiple tiles you need a system that keeps all the tiles using the same units for all the terrain tiles. This isn't hard to enforce if all the terrain tiles are in memory at once - but generally they aren't - you want to work on one tile or a small group of tiles.

3. A sub-block system to be used for streaming objects to the client. My initial proposal for this was to have objects "tagged" as 1. load when paging, 2.load when tile is entered, or 3.load when you enter sub-block. So you can load larger objects that are visible at a greater distance and avoid having them "pop" into existance. Yet, if sombody has dropped a sword on the terrain a square mile away you don't need to know about that.

4. Waterblocks should have their size dependency fixed. Requiring the water blocks to be size 8 works fine in the standard case, but if you need to alter the terrain sizing the waterblocks will fail.

5. Environmental elements need to be worked out. fxGrass, twReference, localized precipitation, storms, and day and night with a moving sun (or suns) all need work.

6. Lighting information for the terrain tiles. Currently, the torque engine used baked in lighting for the terrain and the lighting information is gathered one time and placed in a file. Terrain manager extended that paradigm to provide lighting and baked in shadows across terrain tiles. The lighting is created when the tiles are first loaded and unless the terrain or some buildings on it are changed the single compile is enough the system will reuse the lighting ".ml" file. However, this system suffers with a large number of tiles where the lighting generation can take hours to complete and requires a vast amount of memory to complete.
So, we need to either eliminate the terrain lighting as it exists and replace it with something else, break the terrain lighting up an embed it into the terrain files and come up with some changes in the editor to fix the lighting. Or come up with a paged lighting system which will do the lighting but not consume all the memory in the system while it is being done. Some of this was done in Gorpe but it was not locked down and tested.

7. Server side paging - needed for larger systems where players will move between servers. The initial system was going to use true zoning - which means you simply teleport to another server. I have code for the simple teleport case - obtained from one of the resources. However, for the "continuous terrain" world scenario there is a lot of information that must be handled smoothly to hand a character or other "objects" off to another server.

#45 I would say that is also the order of difficulty as well. There was some interest in possibly having a system other than the 3x3 terrain block swap system - i.e. a 5x5 swap system for aerial games. However, my tests indicated that the amount of time involved in the swap was proving to be excessively long.

That's a starting list. Much of this stuff might be revisited when TSE comes out. Some things like server handoff could be worked on without focusing on the graphics until TSE terrain is released (remember that according to Ben terrain will not be in the EA - so we will have a wait until the more complete TSE terrain system is ready.

I would say that we start with the paging stuff I wrote and somebody can generalize it. Then we move on to the editor issues and sub-block streaming systems. I would leave waterblock, environmental elements, and terrain lighting information until we can see what TSE brings to the party. If we get that far before TSE has its new terrain we can always begin working on server handoff on the other side.

That's what I think. Anybody want to add or rearrange that as a concept?

#46 @Ben What is the ETA for TSE EA? (Say that fast three times LOL)

#47 I'll let you know when I know.

#48 @Ben Thx
@David Thx

--had to laugh: I had just finished merging terrData into terrManager (close to what you had; although yours is much better!!!) But we were on the same track to make sense of the mess :)

--also noted, up to build19 is considered FILE_VERSION 3; your additions are built on Gorpe with FILE_VERSION 4 --> good idea

--one thought however, to make this "backward" compatible it might be a good idea to allow the infinite terrain block as it is currently (although we have added code to turn off tiling; not using the repeatTerrain parameter exactly)

--I agree it might not be very fruitful to work too extensively on the waterBlock, etc. until we see what TSE has to offer. So I'll put in your paging system to get up to speed with you.

--I would also suggest we start a new thread for Terrain Paging

#49 Agreed. I'll post a bit on Terrain Paging. Its a bit long to put the code in here for it, but as long as I receive requests through this channel and I can verify the person is a torque owner I should be able to make the changes available to anyone who asks using the same method as I did for you.

#50 If it's all in the private forums, only SDK owners can see it, so you can freely post source in this area of the forums...

#51 Cool. Just that these are two really large files and I made a big set of changes. I may still do it though just in pieces to illustrate.... Thanks for the heads up on the ability to post though.

#52 Ben, You're getting slow (J/K)--the TSE is now in the products page!

#53 So, what are the chances that we can get terrain management back into TGE?

I'm using 1.5, and we're trying to build some real life application tools, and need larger terrains, with little/no degradation of quality... so the "classic" fix of adjusting the square size, or model sizes just doesn't work.

I'm personally not overly familiar with the TGE terrain code, so an up to date, or even available, resource for terrain manager/management would be VERY much appreciated... in spite of GGs insistance that it's not needed at all.

thanks

#54 Hmm, this all sounds interesting and I may want to help in the near future, but remain undecided. I have taken a different approach for multiple/seamless terrains using markers. I use a terrain with a blocksize of 8 (sometimes 16). Each terrain may have multiple paths that lead the player "off the map" to another terrain block. Instead of simply using a marker to trigger a level load sequence (i.e. Guild Wars), I have taken it a step further.

Lets say I have a canyon, and this canyon may span across mutliple terrian blocks. Three quarters of the way down the canyon, I have a marker trigger that essentially causes a load level sequence, however, this is done behind the scenes so the player may continue without a loading dialog. The level load is also throttled to a quarter of the allowed bandwidth so as not to lag the player. The idea is that this will load most, if not all data for the next terrain, so by the time you get to the end of the canyon and to the ACTUAL load level sequence, it will only take a few seconds, instead of 20-30 seconds. You can get real creative using this technique and create very large expansive worlds with minimal load time. It is pretty much like the terrain system in Guild Wars only the next terrain loads much quicker.

#55 Hey Trenton,

How much code did you have to modify to get that kind of behavior? That sounds like a pretty nifty solution.

#56 That sounds more like the terrain in Oblivion, for those that haven't played it on a state of the art machine, there is a load time that happens right in the middle of the terrain, it just happens very quickly;) This is the original approach I have been planning on until i find a better method to use. When i take my class on MMO design ill see what resources my school has;)

#57 @Joe
It was a hefty amount of code changing to make the terrains load this way. The biggest issue is it takes a high-quality machine to do the calculations needed for the loading, plus you better have a fast hard drive otherwise it just plain sucks. Kind of like Morrowind and Oblivion, slow as hell if you didn't have a nice computer. I have since scrapped my approach due to the latest release of TGEA with MegaTerrains. I know we are talking about TGE here, but the latest TGEA is exactly what I've wanted for a long time, it is pretty much feature complete for my needs.

@Bobby
For an MMO you could use the MMO Toolkit from mmoworkshop.com. There is a Python TGEA 1.7 patch that will allow you to use the latest TGEA with the toolkit with some minor modification. Absolutely beautiful!

#58 So would I be correct to assume that TGE still has crappy terrain? The kind from the late 90's? The same kind we see in games like Unreal 1? Amazing. Even with a project started nearly 4 years ago. Why is GG still only making their $250 product better, while ignoring one of the most sought after updates to their $150 product? Hm. Sounds fishy to me.

At any rate, I've started work on totally ripping out the piece of junk love child of GG that is the current terrain manager in TGE, and replacing it with AdVantage. So far it looks pretty darn impossible, because GG has some really forward thinking programmers... Obviously that was sarcasm. Basically I got sick of whining about the amazingly high-quality, next-gen terrain in TGE (my GeForce 7600 GS OC can't handle 256x256!), and so decided to fix it myself. Like everyone else does when they pay for something- when it has a crappy feature, they have to fix it themselves! Even if thousands of others have wanted the same thing!

This is honestly the one thing holding me back from supporting GG- the fact that they leave things like this unattended for years, then down the road (read: now) simply say "move on, pay more", instead of supporting older, widely used products. Erm, when was the last update to TGE anyway? Oh, there is one other thing holding me back from saying GG is awesome: pencil. Same price as TGE, and makes TGEA look like... Well. .. Something.

#59 Nathan, you cant support a product forever. TGEA is getting the push now over TGE because its what the majority of developers are moving to (current/next gen engines). TGE is an older engine which makes it almost impossible to "fix a crappy feature" without totally re-writing huge chunks of the engine. If GG really wanted to update TGE's terrain, they more than likely would be adding TGEA's megaterrains in. This is just what I think, so Im not sure if anything is/will be done with TGE.

Honestly, if there is a crappy feature in an engine and you need something different, you should be doing it yourself. But if like you said, '1000' people are asking for it im sure GG would have done something about it if the terrain has been the same since the late 90's...sarcasm..