we still need atlas terrain in T3D

#61 @Tom, Wow, GTA always seemed to be bigger than that. If a map size like that could be achieved in Torque its probably a lot more than most people would need anyhow for reasons cited by several people here.

Another important detail, I had observed when I had stopped playing Asheron's Call and started World of Warcraft (which I no longer play) is the player movement speed. World of Warcraft has a much slower player speed than characters made in Asheron's Call, thereby making Wow seem huge. Asheron's Call on the other hand, you can make characters that could easily whiz past a flying character in Wow as though they were standing still and still took a long time to run from one corner of the world to the other. They pulled that off back in 1998 (and still going strong), but the level of detail for the terrain was lacking. But, by limiting player speed you can get the perception of a world being bigger than it really is. GTA San Andreas had the view start to blur when you were in a fast car moving at top speed, not that you were going that much faster than the cars you passed up.

#62 Pat++

#63 FYI.

So i ported over the old Barricade demo from TGEA 1.8 which used Atlas to Torque 3D with the new TerrainBlock code.

That was a 8km x 8km terrain generated from a 4096 height map with 8 material layers. When baked over in Atlas it uses one static 4096 texture with baked in lightmap and one detail texture for rendering.

Converting it over to Torque 3D with TerrainBlock i chose to use a 2048 texture which surprisingly has a higher geometric detail that the terrain in Atlas. We're also using 8 realtime material layers each with detail maps, normal maps, parallax, etc.

It seems to perform better in Basic Lighting in Torque 3D than it does in TGEA 1.8 with Atlas.

With sun shadow rendering disabled, but Advanced Lighting enabled it performs the same as TGEA.

With full shadows it renders at around 80 to 120 fps where TGEA without any dynamic lighting or shadowing is 150 to 250fps.

All in all its been a good test with excellent results and is helping me focus my efforts while we wrap up Torque 3D.

#64 DOUBLE POST

#65

Quote:It seems to perform better in Basic Lighting in Torque 3D than it does in TGEA 1.9 with Atlas.

Hmmm... tell me more about that... ;)

#66 @Manoel - Just a typo... i corrected it.

#67 Out of purely competition information for GG and perhaps a good place to get some nice idea's (and also as someone asked for me to post another cheap engine that supports streaming terrain) i would like to point you to Esenthel Engine.

For 1 person making it, its actually quite amazing and cheap (streaming terrain is alot of work in it self to manage and create, kudos for that).

Also, he has some mad paralax map shader, well actually he has generally some nice shaders going :)

But, userbase/help for Torque3D is still higher, and i like it :)

PS. only posting this as its not against the rules, and i find it interesting to compare tech :)

#68
Some nice looking stuff there and the artwork to present it is surprisingly decent.

#69 I just wanted to say that many government agencies require terrains that are 100km x 100km. It is big business and if Torque 3D can handle terrains this size then companies that use Torque 3D will benefit ten fold.

I work for a company that uses the Torque game engine for government agencies. Game engines are the future for training the military and government agencies. It's a huge market.

#70 @Philip - Agreed with you on several points. I worked for a DOD contractor in Florida before I joined this company. They were also using TGEA for training simulations, such as National Guard ops and emergency first responder systems. There are almost always the same set of required or highly suggested features these applications could benefit from:

1. Huge terrains
2. AAR (After Action Replay)
3. DIS/HLA
4. Integrated testing, especially those that adhere to popular standards and can communicate with a database
5. Stat tracking for performance

There are more, but those were the ones that were the highest priority for my previous project. For Torque 3D, 1 and 2 are available out of the box with some tweaking and understanding of the systems. As for 100x100km terrain, any sim with those capabilities almost always sacrificed detail for performance and fidelity. I could generate a 100x100km terrain in Torque 3D, just see this thread.

#71 So after reading all this....a thought...yes I dare to think outside the box!
If I wanted to make a huge world, I would not think in just x,y but also in z.
How high can you go in T3D? Is there a limit also? I would make huge number of levels straight up! Anyway that's my 2 cents worth.

#72 @Jim - Its the same floating point limits... around 10,000 units in any direction from 0,0,0 you'll start to get precision problems.

#73 This is one of the topics that really interests me, so I'm always happy to rant about it. Instead of doing that today, I'll present the half-assed singleplayer scripted solution!

You'll need 6 triggers, massive vis range, a flying vehicle that's decently fast, 0 gravity, and a small moon object (sphere). Half the size of Earth's moon is good I believe.

Think pacman; everytime you pass 10,000 units you want to warp to -10,000 on that axis. Place your triggers as big walls forming a cube around your central zone, and make them decently thick so your fast vehicle won't totally miss them by warping over them in a tick.

That's the first half. The second is that we don't want to feel like we're covering the same ground, so everytime we warp the player's ship +20k units, we need to warp the entire world (in this case just 1 obj - the moon) back -20k units (or the reverse if we warp the player -20k units).

That's it. Fly around your giant object in your massively increased space environment. Add a couple other spheres to the scene to get an idea of the scale you're working with now. Once you've seen how aweshomely shuper shweet this effect is, think about how absolutely boring the game based on it might be, and decide whether your game actually needs it.

If you fly too far away from any of your objects, they'll go outside the max positional range (upper/lower limits of F32) and the whole thing will explode, but that wasn't the point. You have a good solid million units of space you can work with now, though things will get messier when you have more than 2-3 environment objects and AI ships.

This is mostly just for fun, though I suppose you might be able to make a singleplayer game that uses this trick. My optimal solution uses page values each representing 20k cube units of actual space, and keeps all the objects on the server inside the 10k pos value limit, warping back and forth like pacman. Then we lie to clients, telling them the real position of their control object and relative, page-based positions of everything else, totally de-scoping it before it goes more than max F32 units from the CO. Finally, collisions and the like are edited to skip objects in other pages even if they're occupying the same "real" space on the server (unless they're very near opposide edges of the page).

I'd love to take some time someday and really make this happen, I don't feel like it's entirely outside of my ability range, but it's not high enough up on my list of needed features to get me to spend the significant amount of time it would take to fully implement. A game needs to be fun and functional at small scales before it's worth bringing up to massive scale, and that massive scale adds a whole new design challenge. That said, position paging would be useful for more than giant real-scale space sims; obviously you'd also need something like this to fully take advantage of huge or paged terrains, or to make a decent flight sim, but anything involving the terrain and this system probably is out of my league.