we still need atlas terrain in T3D

#1 Probably not, atleast not anytime soon (According to GG).

I personally was hoping to them to implement some sort of unified streaming terrain or block loading system (i agree, the limited terrain size limits game creation) - as with any limitation(s).

There's been some talk here and several other places, but so far it seems GG havent any plans on implementing something like this any time soon, sadly.

I, personally, need way bigger map then already here, my plan was to make it with terrain blocks, and parent each of them to the neightbor planes as its isometric perspective (or Orthographic since its 3D).

Plan was to have folder, and name structure to make the blocks like this:

mapidmapblock x,y

10x00.map
10x01.map

Well, similar to this.

But, after checking source, i need to change quite alot to even get close to make it work, simply too much work for me to start at this time.

BTW : With the current occlusion culling, i woudnt recommend larger map(s), as no system would be able to handle it (in my humble oppinion).

#2 It's not possible to use multiple terrain blocks in a single mission file? I have to admit I haven't tried this, but I just assumed you could. This is disappointing if that's the case.

#3 I have a mission with about four or five separate terrain blocks. It's possible.

#4 yes. the multiple terrain blocks works . but it is not a "streaming" terrain which Bo Bjering mentioned. the streaming terrain can be used in a realy very huge map with small memory usage.

#5 We've talked and would love to get streaming terrain into the new terrain system in some fashion, though most people making games don't need terrains larger than the limit of T3D's scaleable terrain system. Huge terrains has always been a feature requested since TGE and in most cases those same people haven't appropriately put enough content into the existing terrain size. The few legitimate cases in which someone would actually properly take advantage of HUGE terrains are very small, so it's hard to justify a -lot- of work on a feature that is only for such a small group of people (Not that it isn't ever on our minds).

#6 How would one implement multiple terrain blocks? What mechanism would be used to unload one block and load the next one?

#7 'new' and 'delete' ?

#8 Well, you could delete the terrains after they're too far... but what about collision with the objects on top of them? Unless you delete those objects as well. A streaming terrain implies a streaming world as well. And a streaming world implies a lot of other subsystems and tradeoffs. In every single commercial game that has seamless worlds, streaming resources is a huge part of the development effort. Even companies like Rockstar, which have lots of experience on the era, need to re-work their streaming tech periodically (not all techniques they used in GTA3 accommodated GTA4's new graphics engine).

I haven't worked in projects with terrains for years. What on them uses the most memory? Heightmap? The vertex buffer? Opacity maps?

#9 I tested with 144 WarriorCamp terrain maps (included in the fps kit).
it take 30 seconds to load and run smooth in the game.
when it reach 255 maps. the game load but the game only have about 2-3 fps.
when it reach 400 maps. the game crash.
my computer have; quad cpu each 2.66 GHz, 6 G ram, nvidia GTX 280

#10 @Pat -- well I appreciate new and delete, but as a beginner, I need a bit more understanding. I mean when I load a new terrain, how do I get all the objects on it loaded as well? How will all the objects on the old terrain get unloaded from memory? Is this what zones would be used for? If so, can anyone point me to a resource on how to implement them? I am at a loss as to how to proceed in terms of increasing my terrain size. At this point, I am only looking for an understanding of what would be necessary, not a step by step guide.

#11 @Steve:

Zoning, how it should work, and all, depends an awful lot on your project. How big you want your world to be? How much persistence you really need between zones?

The mission, as it is, is simply a group object saved to a file. You can, as example, add a bunch of objects to a SimGroup and call .save(%filename) on it to save it to a file. If you exec() that file, it will create those objects again. So, it's a very basic trick you can use to load entire batches of objects in one go. You can also wipe everything inside a SimGroup by using groupName.deleteAllObjects() (but be aware that its not recursive).

So, you could build your world "blocks" and save each one to a different file, then have a "world" mission where you load and unload blocks depending on the player/camera position.

Of course, stalls will happen if you load many objects or a very complex one. The resource manager does not work asynchronously. You could get around that, still only using script, by storing spawn nodes for your objects in your world blocks, instead of the objects themselves. When you load a block, it would only load the spawnpoints, and they you could "spawn" each object one by one over time, starting with the closest ones to the player. This would minimize stalls. Of course you also need to make sure you load objects way before the player can reach them, to avoid pop-ups.

With some work you could make the whole process automatic via scripting. Automatically group objects you place in the mission editor based on their position on the world, and automatically create a spawn node for each one that stores the information needed to re-create the object, and have a function manage loading/unloading of objects in every tick or at every hundred milliseconds or so.

#12 @Manoel -- thanks. At the moment I still have a lot of "leveling up" to do in other aspects of T3D, but somewheres down the line I am sure I will need zones of some type. This gives me a lot to think about, thank you.

#13 Okay, so I wasn't off in assuming you could have multiple terrain blocks. It seemed simple enough.

@Manoel - An interesting take on the concept of zoning. Nice idea.

#14 I was just playing around with "Prototype" the game, and i must admit they are tuff.

Intire Newyork city, hundreds of "npcs" and cars, thousands of buildings, almost no load time on my computer, and it takes up roughtly 400-450mb ram.

now thats impressive :)

About streaming terrain, it could be used in huge outdoor area's, car games, rpg games, sailing/ocean games ect.

Our game, for one, requires HUGE outdoor landscapes, oceans, islands (islands on other maps is ok with a loading screen though, if REALLY nessesary), and a system where you can keep increasing size as you want (expand at will).

While there will be loading screen for entering some of the small maps, there will be 1 or maybe 2-3 huge maps that would need to be "infinity" to keep increasing.

All static objects on such a map should ofcourse not be loaded at loadtime, but simply as it gets into view distance, then load from disk.

Occlusion boxes (zones) should be generated at load time, to only render those boxes in view (infront of camera, at min/max view distance).

Well, just some idea's i been toying around with at home :P

#15 It would be very nice to see terrain tiling/mega terrains available for use without repeating the same terrain block a la Tribes2. If GG really wants to make this engine a bold step forward beyond just another incarnation of TGEA, this is one of the stops that needs to be pulled out. Requiring every game to be either small, or island based will kill immersion if people have to deal with floating blocks of terrain.

#16 I think I should jump in here and mention that huge terrains (ie, larger than the current ~32.768 square km max at a squaresize of 8) aren't really viable for a totally different reason.

The realistic usable area with 32-bit position values is +/- about 15,000 units, or 15km in any direction. After that, position accuracy starts to fail and your objects begin to jitter significantly, especially at NW/NE/SW/SE compass points. Without changing to 64-bit position storage or using a global position paging system, I can't see any real use for terrain larger than the current 4096 resolution.

#17

Quote:(ie, larger than the current ~32.768 square km max at a squaresize of 8)

You realize that isn't a limit of any kind in Torque 3D.

You can happily use a squareSize of 0.1 or 1000.... it just works.

Quick poll... would you guys like to see 'squareSize' be replace with just 'size'? So you would tell it the total terrain size you would like and it does the heightfield to square size computation internally to get you the results you want.

Quote:The realistic usable area

Your absolutely correct about floating point precision being a problem once you get to really far distances from 0,0,0.

Great point.

#18 Yeah, I was just referring to a squaresize of 8 because it's been the Torque default for a long time. It's a decent compromise between detail levels that works well for players on land and vehicles in the air at the same time. I personally use 12 unless I'm expecting to have especially detailed or varied terrain.

I'm inclined to say keep it as squareSize, but that's just because it's what I'm used to. New users might find a size value more intuitive.

*edit: Possibly have both? Whichever one the user changes manually is used to adjust the other, so you could enter squareSize of 10 and the size box will display the new total size of 2,560 (or whatever it is based on your heightmap res), or you can enter 3,000 in size and have it update squareSize to ~11.7.

#19 @Tom, that sounds like a cool addition!

Agree with Todd, both mechanics would be nice. If its a problem, force to select one with an option array.

#20 One thing I would like to point out is that if you want large worlds, 10000 units is about the maximum you want to go out before you really start seeing issues with precision. That is really only 10km x 10km which isnt that much.

What I would recommend for anyone who is looking into having large worlds, would be to request for GG (or go at it yourself) to make some kind of attempt at fixing the large world precision issues. Right now, this issue cancels out any hope of making games with large worlds in 1 mission file.