we still need atlas terrain in T3D

#41 Most people are thinking in terms of a square world when they think of the precision issue. I'm actually thinking more in terms of an infinite linear world.

The only solution to a linear world (a world that extends infinitely in one direction) is to fix the players position and move the world and objects around them (ala 2D side scroller). This has implications in a multi-player space because not everyone can be the center of the world.

For a client sure, but not for a server.

If you want users to travel indefinitely in one direction, while allowing multiple players to be in different places along that line, you have to create an alternative positioning system.

I agree 64-bit is not the answer. A new system is required, but as I stated previously I believe it is out of the scope of T3D at this stage.

Just something to get people out of the MMO thought. It's not just about streaming terrain, it's about objects all being relative to a fixed point.

At this point it is just discussion of those specific systems, what problems each creates, and what scenarios each supports. I personally haven't thought much about this situation, but now I will.

The ability to support a non-massive multiplayer scenario where the users are not required to be in the same space relative to the same point, is an interesting problem.

#42 Independent of how you do the positioning, as long as you have unrealistically large camera far / near plane ratios, it will always jitter.

#43

Quote:@Manoel -- I understood your explanation and the link you sent the first time, but this makes it clearer, thanks. However it does bring something to mind. If we are dealing with floating point precision and number of digits, does this imply that any number from 10000 to 99999 would have the same precision since they could allocate the same number of digits to the decimal part? And, referring to your example above what magnitude of error can a game withstand before the problem becomes noticeable?

The inaccuracy increases gradually as the magnitude increases. As shown in the tests, its better to avoid getting into the tens of thousands, depending on what you're doing. Physics, as example, is very sensitive to numeric inaccuracies.

#44 Hey I'm the Noob here, but it seems to me that you would just test the inaccuracy in the game loop, if it is beyond some limit then you would set a new reference point, and then translate the relative world around it. In essence you would navigate from "Fix to Fix" moving the Node when necessary. This is what Navigators in the real world have done since the beginning, until GPS. You can also just apply the correction factor to the current render.

#45 "I have been racking my brian to think of a game that has a bigger world that was T3D is capable of and I have yet to think of one. The exclusion to this would be a MMO or something but that is a completely different animal and thing have to be broken up anyway for load balancing purposes.
"

How about Grand Theft Auto: San Andreas or Grand Theft Auto IV. Both are huge worlds but are single player. Worlds like that provide the player with a sense of freedom, you do the missions whenever you want to and are free to explore the world on a whim. The limitation being you have to do so many missions before you gain access to the next island/continent. But it sounds like making worlds like this are impossible with TGEA/T3D judging from the post I see here. :(

#46 @Don
Taking this from another side, it takes quite a huge team and big funding to produce something like GTA and that doesn't really go for indie development anymore--which is still what Torque is developed for.

#47 GTA IV:

• 150 developers + uncertain number of support crew around the globe
• 4 years of development
• Budget estimate: $100 million (biggest in the industry to the date)
• Engine: in-house development.

#48 But their are other types of games that do and will require more than +/- 10,000 units, such as flightsims, RPG's without loading times, huge racing games etc. However it seems like a massive undertaking to overcome this limitation, so unfortunately we are going to have to try and work around it. =[

Unfortunately working around this, trying to make the world bigger within our 10,000 unit limit isnt that easy either. >.<

#49 The GTA games are not as big in size as you think they are.

According to Wikipedia GTA: San Andreas was 36 sqkm in size... thats only a 6x6km map. That does sound hard to believe at first, but take a look at the map...



It really looks plausable for it to be only 6km square. It only feels bigger because you never ever travel a straight feature-less path from one corner to another.

And GTA 4 is smaller in size than GTA:SA.

Oh and here is something really cool.... some one took the time to make a Google map of GTA4 locations using real life NYC.

GTA IV gets Google Mapped

Look at the real life density of NYC vs every game that has ever come out... including GTA4. There is no comparison.

#50 Ok, So can i have some clarification with the terrain blocks.

If we can go from -10,000 to +10,000 (unit wise), we have a 20,000x20,000 unit area to work with ... right?

What is the default scale that torque uses? 1unit = 1meter? So we by default have a 20kmx20km area to work with?

I think the relationship between unit and meters, need to be documented more, as i have looked through the documents, trying to work out how i would go about getting a terrain block to be scaled by 1/2. (in effect, 1 unit = 2 meters).

If its possible we should get some options in the terrainblock, that allow us to set the dimensions of it in meters. (or show somewhere, clearly how many units = 1m). Unfortunately i dont think im being very clear here, if i try and describe the workflow maybe it will help.

1. When i create a mission, i specify how many units makes a meter.

2. Then at the bottom of the screen we can see this scale. (for reference)

3. i then click click on the terrainblock in the scenetree library to create a new terrain block, i then enter its size in units (knowing full well how many units makes a meter), and give it a height map. the terrainblock then automatigicly works out what the squareSize and other values should be from that, in order to stretch the heightmap out to the terrainblock size. (however, we leave the options in their, incase we want further tweaking).

Its just an idea, what do you guys think?

@Tom: very good point btw =]

#51 Nothing in Torque enforces or requires that 1 unit is equal to 1 meter. It is a totally arbitrary standard that most people adopt out of convenience since it maps reasonably well to the upper and lower limits of 32bit floating point.

You could just as easily treat 1 unit as 1 foot or 1 inch or 1 mile (although you would run into the other end of floating point precision issues if you try to treat it as too large) or even as 2 meters.

It is all relative. If you have a half-sized player running around on full sized terrain with half-sized buildings and trees then you'll effectively doubled the 10km x 10km "limit" of the world. There are tradeoffs: If you want your terrain to look as smooth as it does to a "full" sized player then you would need to double the terrain's grid density which can cost on rendering and collision performance. However, there are certainly perfectly acceptable balances to be found.

#52 1 unit == 1 unit. You can have your objects/players/whatever be as much units big/small as you need them to. Kork was 3.2 units tall, I think. The words "meters" doesn't exist in the engine. If your players are all 0.25 units tall and their movement speed and your buildings match their size, you wouldn't be able to tell the difference (the difference being you could have a larger world without accuracy issues).

@Don Bates: a seamless world has *major* technical requirements and is the key feature of any GTA game. Like Tom said, the world isn't actually big enough to hit floating point problems. However it needs a robust resource manager to handle dynamic loading and unloading of assets and LODs in the background. It's entirely possible to do something like this using Torque: you have the source code, you can do whatever you want. What, you wanted it to allow you to reproduce GTA4 out-of-the box? I don't think there's any engine in the market that allows you to do that. Not for 1K, at least.

#53 Never the less, alot of engines started to add streaming terrain and or something similar to support "infinite" large terrains.

They probably dont do it for fun, and im sure it would be a good move for torque aswell.

But, thats probably just easy to say for me :P

And no, theres no engine that can do what GTA4 does for 1k, but then again, GTA4 engine does not cost 1k too.

There is, however, a below 10k$ (indie, team license, 1 project, royalty free) engine that support infinite terrain, and everything you ask for (including something similar to speedtree, good occlusion culling ect), wich could probably be used to recreate GTA4 :P.

We had a go with it, but we felt the engine utilities (editors) was not ready at the stage we tested, so the money could not be raised.

It supports DX9, DX10, DX10.1 and OpenGL, almost weekly updates, so 1k to 10k suttenly does not seem as high anymore in return for what you get (saying this ONLY as a friendly competition advice).

#54 Bo, don't be shy and tell the name anyway =P

I don't think we are forbidden to mention other engines, even competing ones, in cordial discussions (aka: not flame wars or trolling).

I think what has to be made clear is that no product will make your game for you. And most games involves more than building levels and models. I don't think one can make a flight sim in vanilla Unreal Engine 3, as example. Some products are more focused in certain features than others, but there is no "does everything, supports everything" package.

#55
(Sorry in advance for repeating myself again here)

Extending the engine to dynamically page TerrainBlocks in and out as needed isn't really hard. I did that a short while ago. The real problem, I think, is that there is far more to having big worlds than just having the engine page the terrain.

From a programming perspective, what about all the objects on top of the terrain? How do you handle their simulation? Terrain alone isn't even half of the equation.

From an art perspective, how do you populate the area you are creating? For a flight sim, most of the space will be empty, so it's not too hard (on the other hand, you don't need the terrain to be that detailed so you can probably get away with pretty coarse stuff). For first-person stuff, this requires a lot of man effort, though.

Nevertheless, I'm pretty sure that a not too distant future revision of Torque will include new streaming functions. However, I do think this should be something that solves the problem in its entirety rather than just providing a bullet point on the feature list that sounds cool.

#56 @Manoel

The engine i refer too in this case is Unigine (it isnt the only cheap good engine out there with infinite terrain capabilites, but the best at this time imo :P)

While it does say 9980$ for source indie, you then have to pay 29900$ after you have a investor or before release (no time limit).

I consider this still a 9980$ engine, as getting a invester after creating your game is quite easy with a game complete and ready to ship (atleast here in little denmark, by using fonds and such) ofcourse if you game is good :).

Still, its really a bargin for what you get, if only the editors where better (i discusses this with unigine team, and it appears they are hiring people to do new editor).

Still, Unigine aside, this is also excellent 3D engine, im just saying, you dont have to put a whole lot of cash into good engines, and streaming terrain is (apparently by reading the web) something all want these days.

#57 @Rene

You are right, there is ALOT of work involved in adding infinite terrain, as you say wich includes :

» Terrain loading/streaming (heightmap ect) and unloading.
» Object loading/unloading.
» Object handling.
» Reuse of loaded textures, thats reused, removal of unused textures no longer used (you could load all at loadtime, but to keep memory low, you could load/unload as needed).
» Grass and tree's (the spawn at certain textures already in torque could be used for creating that dynamically).
» Occlusion culling, and LOD system
» And alot more...

About objects, you just save it in a database (where tree's, houses ect is supposed to be, and check the database if its in view), thats hard to explain, but we did alot of those things for our mmo emu we did once (unreleased emulator project, for a infinite terrain mmo).

EDIT : Of course at this point, its more important to get a good, bug free engine out of the door, i fully understand that.

#58 @Rene Uh, I was simply providing examples of large non=MMO worlds. I wasn't aware of any limitation to what kind of game you could make with Torque.

Yes Torque is for Indies but can be sold to companies as well (I think). I doubt if a company wants to buy 100 copies of TGEA/T3D that Garage Games would tell them they can't because it's for Indies only. I'm finding out though that the existing terrain system gives you a LOT of terrain to work with, might not need atlas after all.

I think there are more important things for Garage Games to work on at this point than implementing Atlas. Like my trees being sort of transparent, I know it will be fixed sooner or later. The same trees had all kinds of goofy effects when TGEA was in its early stages but after a few updates they looked fine.

#59
@Don
Sorry, I wasn't being too clear in my post. What I meant was that the usual audience of Torque does not have the manpower to make games on that scale. If you want to make a huge game, you not only need the technology but you first and foremost need a huge team to bring all the content together.

For probably 99% percent of all future games on top of Torque 3D that are likely to make it to the finish line, the current terrain solution is exactly the right thing.

#60 I think I commented in an earlier thread that it is critical that the features that Bo, and everyone, is talking about applies not only to terrains, but to all geometry.

It is far more important to get a unified, paging mesh solution working. Terrain, as a heightmap-based solution, has several drawbacks, and any kind of work which was entirely specialized in terrains would need of limited use to a game design which, for example, used a huge series of underground caves. Creating a solution which worked for all mesh data would then solve part of the problem of having objects included in the streaming mesh data. Buildings, trees, rocks, etc could all be in the giant mesh which gets dynamically loaded/unloaded...that includes the terrain.

I just want to make sure that everyone realizes that, while we need to solve the terrain problem, the bigger problem is solving it for ALL meshes, not just terrain meshes.