Atlas in Torque3D

#1 Haven't heard of anyone actually doing this, though I have seen the question asked before... I can't say much about how difficult it would be - even between TGEA and T3D the rendering engine has changed dramatically -- however as far as legal issues my understanding would be that as long as you own both engines (and you appear to) you're in the clear as far as merging code between them. I'm sure it's doable, but it sounds like a fairly serious project.

The latest version of Atlas to my knowledge is the one in TGEA 1.8.2, which you should be able to download from your account. Go to your T3D download page and expand the "previous versions" list, every version of TGEA should be in there.

Not trying to discourage you from following this path, but I think it's worth noting that it's quite possible to build some really huge terrains in T3D -- so large that you'll have more of an issue with the floating point physics precision than running out of room on the terrain itself (though from your description I assume you're intending to work around that as well). It's not 100% supported, but many of us have also had a good amount of success with loading multiple terrain blocks into a mission.

#2 What kind of size terrain are you looking to use, aiming for something along the lines of a wow style mmo with seamless continents, or large enough zones where zoning is so infrequent it doesent matter so much ?

Currently with the floating point issues, you can use a 18km x 18km terrain, centered on the 0,0,0 point and not hit any issues with it, and using a 4096 heightmap at 4.5m per pixel hits that fine, and my god thats a lot of landspace anyway.

yeah instead of replying i went and imported a 2048 heightmap at 9 meters per pixel, 18432 meters long along one length, it just took 47 minutes for gideon to run the length of it at his usain bolt speed.


that has about 5 km in view


that one has about 8km in view

so overall, i think with some good smart management of micro terrain and objects, towns, cities etc in the gaps in between, and an adjusted run speed to something thats not so gideon fast.

that terrain as a whole, being nearly 18.5 km on one length, is a total land mass of 342.25km/2. do you need more then that ?

#3 Thanks for the feedback guys and the info about how big terrain sizes can get (a bit of testing).

We are not set on this idea we talked of loading areas or having sections done and loading in other sections. Still unsure how we are going to do it.

I am guessing it won't get any bigger than a state for a while or possibly a continent at most, but I think the long term goal is the earth. Think of it as a Google earth type thing. I can't really go into the details as I am not sure about what is or isn't published, but it is safe to say we are basically implementing or going to implement a global coordinate system inside torque for several moving (controlled) objects. Like I said not sure about details or what I can for sure talk about.

We definitely have a lot of ideas to work around needing a streaming system, but wanted to post early about it. Things like loading in a large area and then when a control object moves to the bounds or close to the bounds and no other control objects are in another section it loads in the new area they are going to. Or keeping track of where everything is and only where the camera is viewing is loaded in and everything else is kept track of in the background. Or just restraining the user to a certain large area and if they want to move into another they have to load it. There are many ideas we have.

I figured that as long as we have TGEA and T3D it would be fine to grab and use, but thanks for the clarification.

I also figured much of the rendering has changed between TGEA and T3D, but there would probably be a lot I could still take form it. At least the render instancing part of it would work a bid differently, but other parts may not. Don't know until I look at it more.

#4 There has been some talk from Tom S. and/or other torque programmers that they would like to do some kind of terrain and asset streaming kind of thing... or some significant support for large/multiple/stitched terrain of some sort... after version 1.1. I have been waiting for this since tgea.

Such a thing gets my vote as a high priority for one of those programming 'sprints' they are talking about doing for version 1.2 and later.

#5 Just encase anyone at GG or otherwise is following this we recently started trying to work with larger environments and ran into some big issues. Much of them come with the editing tools just starting to break down when you are that far out, but also using several terrain blocks just doesn't work well and causes some performance issues.

Also I know previously it was asked how big of an area. Currently we are starting to do missions about 12 kilometers in diameter and I am sure they will only get bigger. Would love to see atlas ported or some good asset and terrain streaming system brought into Torque 3D. Even if it was an add-in or a big release in witch we need to pay to get the update. I know there probably aren't too many people that could use this though so probably not high on the priority list. Just figured I would post some more info and a bit of an update.

#6 i think anyone looking to make a MMO would use it. im positive that WLE would integrate it into our MMO Development Software.

#7 I agree atlases, or compasses, they all add to a game. I would like to see both for T3D, hows that MMO coming Winter?

#8 Lol Greyfort. "Atlas" is the system that was implemented for huge terrains in TGEA (TSE). It was deprecated in T3D.

#9 @Greyfort - We use AFX as a base for our code. As soon as AFX for 1.2 comes out, we will start a port over and then start intergrating all the parts and pieces. We will start testing some basic stuff the beginning of next year. Once we start testing and ill start posting more often in the Blog section.

#10 I've been thinking about researching "flipping" the current scene management to make it camera-centric instead of world-centric. Basically, as has been stated by others elsewhere, if the world moves around the camera instead of the camera moving around in the world the floating point issues would be so far away as to be out of sight. This would also make flight simulators and space combat simulators much easier to build.

Perhaps it would be good to keep the old as well as the new and make it a compile-time option. The main thing is that it would have to have the same interface as the current scene management system in order to prevent a huge refactoring effort.

#11 @Richard - if u changed it to that, how would that affect asset (object) management?

#12 @Paul - None, really - except that you would be doing your streaming far away from the center of your "universe" and would not likely see the event from the player's perspective.

Mainly it's just a way to allow larger world spaces without worrying so much about scale and distance issues and not so much about having large numbers of objects in memory or handling the streaming portion. Though you could add your streaming system to the new scene manager (I would) and have it handle everything in the background behind the normal scene manager interface. Perhaps set up a master "chunk" file that keeps track of terrain/object sets to be loaded by a "chunk manager" that handles streaming of assets as the player nears.

Anyway, just thinking out loud. I guess it's only peripherally related.

#13 @Richard - thats really the only way to implement it imo. just handling the terrain and not the objects and assets would be almost self defeating.

you could almost do a modification of the zones and portals thats available now to help break it up into the chunks thats to be loaded.

I think its VERY related honestly. but like you said, thats just thinking out loud.