TGEA unlimited terrain equal to unlimited mission size?

#1 Not in stock (well depending on your definition of many).

Elaborating
-------------------------------------
Paging is not done in stock, you'd have to whip something up yourself, as I understand it atlas has the necessary capability to store things other than the terrain in it (provided you find a means to get it in there).

Mission loading is a moot question as paging would keep it from increasing excessively.

Then, you've got floating point precision to deal with.

In regards to how do you fill all that space, I don't know, how do you want to fill the space?

#2 I read in some forums post of people making huge worlds in TSE, i am desing some games and some questions bring to me, how i can populate a huge world without monstrous pc's?, mission loading times etc... only a huge terrain with a few trees is good maybe for a flight simulator...

...or a real mission in TSE is equal to TGE limit by the poly count?

#3 Ummm, you may need to correct me if I'm assuming wrong (as I don't bother thinking too hard about bad grammar and misspellings) but:

How can you populate a huge world without requiring monstrous hardware?

That depends entirely on what you're doing. If you plan for performance than you shouldn't have too much of a problem. On the other hand if you think you can slap in a few hundred DIFs without LODs, use twelve dozen 20K+ polygon DTS shapes, and have a particle system dropping 100,000 raindrops, then you're going to require some monstrous hardware.

TSE will perform far better than TGE on MODERN HARDWARE. TGE will perform better on older hardware. Both engines are geared for different platform qualities. You should already be able to get this info by reading the product information for TSE(TGEA) as well as TGE.

--------------------------------------------------

Based on the questions that you're asking, I would NOT suggest that you use TSE (Technically its called TGEA)

#4 By "monster machines," I'm thinking he might have meant "entities that spawn monsters." Meaning, games like Dynasty Warriors that have thousands of enemies populating the map without obvious spawning.

I don't know a ton about this subject, but I know the general theory of how the Serious Sam games pulled it off. (Though that game did make use of explicit spawning to keep the gameplay rapid.) Basically, the engine was built from the ground with huge mobs of enemies in mind. Each type of monster was stored in memory once, and then it would draw like 100 copies of the same monster in different poses. In order for this to work, all relevant models and animations had to be loaded into RAM simultaneously, which meant that the main cause of slowdown was not number of enemies or the number of polygons, but the footprint of all the art assets currently being accessed at any given time.

Now, I am new to Torque, and I have no idea if Torque is optimized/can be optimized for this type of performance. But it stands to reason that it might be. It is a next-gen engine, after all, and those are usually pretty good at processing instances of objects.

Assuming Torque can rapidly blit hundreds of clones of the same monster to the screen, then you'd probably still need to make some changes in code to make it appear as if the entire level is entirely populated by thousands of enemies all of the time. Basically, anything that can't be seen by the player, outside of range, hidden by fog, etc, you'd want to abstract away its behavior somewhat.

If Torque already does this, or there's a community-built extention to do it, color me hella impressed.

And yes, you'd need a next-gen computer to play a next-gen game with next-gen mobs in it, regardless of how optimized the code may or may not be.

#5 Thats not really what he means.

Basically you can make a 64x64 huge ass map. However can TGEA support filling that large of an area with objects, because im sure a 64x64km map with nothing in it is boring.

#6 In The Repopulation we have some 8km x 8km zones, and what I did was to split the map into regions, which are basically like trigger areas. We spawned monsters on demand as players moved into an area, and when noone had been in a region for 2 minutes, we despawned them. So long as you don't have players populating the majority of your map at one time, that approach works fine. It wouldn't do you much good if you had players in all areas.

#7 Yah unfortunately for multilayer games its probably still better to use legacy maps.

#8 When he said:

"...how i can populate a huge world without monstrous pc's..."

I think he meant pc's = player character's, as in HUGE player characters that can traverse the entirety of the hugeness

but

it also did look like he meant heavy duty personal computer.

I hope TGEA can create worlds as HUGE as EVE online mmo :)

#9 We he said "...how i can populate a huge world without monstrous pc's..." I think he meant pc's=probable cause...he wanted a monstrous amount of Probable Cause... ;)

#10 Javier Canon "Hi, i read that with Atlas you can have a very big terrain (ex. 512km x 512km), but how you fill all these space?, you can fill with many buildings, trees, objects, etc?"

You will have a difficult time filling that much space with content for players to do.
512km x 512km is utterly gigantic space.. Imagine a Universe, Black Holes, Solar systems, Planets, and for each
of those in the universe, you can add distance between, layout of solar systems, entire planets atmosphere, entire planets ecology, entire Planets life forms and all that goes with each life form... Point being.. If you can fathom doing all this content for players to interact with and you have the resources to actually fill a 512km x 512km mission area.. then your name is Blizzard, SOE, or GOD.. that amount of space can be handled as a max per mission purposely to allow you all the freedom you need to add content to each mission area.

TGEA will handle all that content too. Each client will ever see a small fraction of it at any given time. The server for the game will not draw what the client doesn't see ( for single player games ), and, The server doesn't draw anything for each client on a LAN or MMO type Game.. thats left for the client to do.

The client can handle all the content because the clients Player Character will have limited vision distance ( thats something you will code into your game ).

I think you should be more concerned about being able to fill such a gargantuan area with enough content then worrying if a clients Personal Computer can handle it.

Javier Canon "TSE have a memory manager for paging the objects in the world?"

TSE = TGEA. ( TSE was old name of same engine ).
TGEA takes care of the grunt work so all you need to do is focus on content, playability and fun.
You shouldn't need to code or change memory management for the engine unless you have a specific need that the engine wouldn't do already. And, if your second question here is just another way of asking the same first question.. then: Limit your clients Player character visual distance so the client cannot see to infinity and you'll have no issue at all with paging objects since the object will be rendered when they will be visible for the player.

Javier Canon "If i put many objects, the mission loading dont increment too much?"
There are techniques for limiting the "Lighting Mission" wait time.
One being that lights and lighting are added to the Art object at the time of conception and before the art object is released for use or exported.
Scenery can have baked in shadow to give a visual effect of being lighted.
And, Lighting Mission is done only once.. thats when the game is started or each mission loaded.
so from that point after Lighting mission is completed and the Player remains in the games mission area, then death to the player does not cause a full relight of the mission.

One other thing you can consider doing:
If you plan to have thousands of objects that are each lighted with special effects and such, you can make the mission area smaller, make the Player character smaller, make all the game objects smaller, and share strategically placed lighting to illuminate many areas with fewer lights.
The concept is shrink the Player Character and all world objects to smaller sizes. then share strategically placed Lights to illuminate more area.
Doing this will of course increase your work load.. you'll have to resize Constructor brushes, Textures, Mission area, etc.. but ultimately when completed you'll be able to reduce load time for content and Lighting Mission times are reduced.
You'll have the visual appeal you seek, with all the content you can muster up and still maintain fast load times.

Sure hope i didn't confuse this thread. It just struct a nerve and i felt compelled to reply since it happens to relate to something I have been working on myself among other things.

#11 Now it's been stated that TGEA supports maps of 512km by 512km, what is the largest known made map ever been done?

The reason I'm asking is I'm looking at planet scale maps for my game (not to the actual scale, but larger than 512km by 512km would be wanted). Yes I know it'll take ages to fill, but luckly for me most planets I plan to make have large (very large open areas of seas or deserts), there are a few that will take time to populate with plant life and the such.

I'm also planning space regions too, but only on a small scale.

Looking forward to replies to the question of whats the largest known map.

#12 I was under the impression that terrain paging was built in I must have read the description horribly wrong when I decided to make the purchase(it was one of the main factors)

#13

Quote:It is a next-gen engine, after all, and those are usually pretty good at processing instances of objects.

Define next-gen. In terms of performance, I've found very poor performance in TGEA, especially with dynamic lights, dynamic shadows, and object processing as a whole. Deferred rendering solves the first problem, and cascaded shadow mapping resolves the quality of shadows, but object processing is still an issue.

What it really comes down to is not as much polygon count, but number of draw calls. Hence why rendering about 50 dts trees as separate static shape objects sends your fps down to 5, while rendering them through some sort of replicator/batched renderer will keep performance high.

Seriously, if you want an immersive game world with thousands of objects, be prepared to look into rendering and processing code. Stock Torque will not provide you with suitable code, though the majority of problems can be fixed by simple code changes.

#14

Quote:
Now it's been stated that TGEA supports maps of 512km by 512km, what is the largest known made map ever been done?

This isn't really practical for several reasons. At around the 100km mark, you'd have lost so much precision already it won't be very useful to continue much further without implementing instanced areas or local coordinate systems.