Is it possible to make BIG Worlds like in Sacred....

#21 I think I overcomplicated things.

Take a map that is broken into squares (lat/lon). Take a piece of paper with a central square cut out of it that is 9x9 and matches the size of the squares. Move the piece of paper around the map in increments of the square size. The squares (world squares) that are within the hole are the map squares that you load/unload. That way you can have an arbitrarily huge world, but only load a small thumbprint at a time. Unfortunately, pathing across "map squares" can be annoying or lead to strangeness.

#22 The design David puts out is excellent, and is the basis for how many people do this type of thing.

Unfortunately, this is the -easy- part. The hard part comes when you try to start working with cross-boundary scoping, collisions (raycasts), world editing, pathing (if necessary, and as he mentioned), and not the least, managing scoping and your processTick lists in so many regions.

I'm speaking from experience here, hehe--I spent several months trying to get this to work, and while I got to the stage David mentions, it was sloppy as hell, buggy as hell, and when TSE announced massive terrains, I dropped my implementation like a hot potato!

#23 I understood the Concept in the First Place. You called the diffrent Squares:
A,B,C
D,E,F
G,H,I

I would say name them this way:
AA -> AZ
BA -> BZ
.
.
ZA -> ZZ

I think that's the way I will name the World Grid.

Other Questions I have in mind are:
Does TSE has the Terrain Paging by now or will it be Part of the Final Version?
Is TGE required for the use of TSE or is the TSE a whole new Thing?

Sincerly Carl

#24 @Everyone In my previous remark, I was just stating that my prior explaination was based on MY understanding of the Terrain Paging concept, which when put up against the other explaination of the same concept, was obviously (at least to me) wrong.

In short, it appears I screwed up when I stated what terrain paging was.
I was kinda shocked to see how far off my explaination was from the other one.

#25 @Carl: Seamless terrain (note: I have NO indication that TSE accomplishes things the same way we describe here. In fact, I know that it actually pages directly to the video card for some, if not all of the functionality) is the major functionality of milestone 2, which is the current milestone. It's being polished up now, and is expected soon (no, I have no definition of "soon"--if you think the next 3 months, you'll probably be ok).

There is an Early Adopter license for TSE that I think requires TGE, and costs $150. They are separate engines however, it's only the licensing that is "dependent", and that's only for the EA version.

#26 Yup. This is the theory part is simple. The implementation part is extremely hairy.

#27 @Dreamer
I have no idea how Ben is doing terrain paging in TSE. Your idea may be much closer than mine. I was only giving an example of ways I've done it in 2D and have seen it done in 3D (with Irrlict and Ogre and Doom maps).

#28 I now i'm stressing the people but, could someone tell how they think TSE will handle the Terrain (not specificly the Paging) but in General. Even if Terrain Paging as mentioned before is not supported.

Sincerly Carl

#29 TSE Snapshot. Read Brian Ramage and Ben Garney's .plans to find out more.

EDIT:
There's more in the private forums for TGE and TSE, but posting a link to them would be rather worthless since you don't have access to the discussions.

#30 Wow the Snapshot looks really impressing. But it's just "plain " land no trees, vegetation or Towns. When I make Map with nothing but Water then the Map could be really big like in the shot but when it comes to populate the Map with Plants, Trees, Towns etc. how big could the Map then be? I don't want to sound offensive, I just want to get a clue how big the Maps could be with all that stuff.

Sincerly Carl

#31 @Carl I think that would really depend on how you intend to populate, it.
For instance if you use fxShapeReplicator objects for things like that I have had good results in TGE with max map size and 10,000 seperate objects. However if you want finite control over placement, you will probably either have to scale back the number of objects significantly, or reduce your total map size.

BTW I have 1gig of ram, on my test machines, so your milage may very.

#32 Which is why I brought up that seamless/massive terrain is not the complete solution to incredibly large worlds...

#33 @Carl
No offense should be taken since there was nothing offensive in your question.

But you're asking an open-ended question and expecting a finite answer, which is a huge problem because it can be answered any number of ways and most likely won't be answered to your satisfaction because we don't share the same cognitive context.


The terrain snapshots were an example of the terrain enhancements to TSE, and nothing more or less. The dojo demo shows some of the other enhancements to the engine.

As an example of your question, how many buildings and at what level of detail will they be rendered? Will they each have a number of detailed hi-res textures, bump maps, normal maps, etc? What is your draw distance? What are the AI structures for pathing, flocking, etc for your villagers in the cities? Will they change significantly (say the village rushing the protagonist/group if they come back from a successful raid so that they can touch the hero)? How many animations will your animated models have? How complex will the meshes be for your trees? How complicated do you need your collision to be? Will you need grass/flower/etc shapes rendered along the terrain? What is your target hardware's RAM requirements?

There are so many implementation specific variables in your question that it's nearly impossible to give a satifactory answer.

For example, if you're cognizant of your environment and polygon requirements you could create something like Canon's little low-poly/highly detailed world (which is TGE, not TSE). Combining solid design, knowledge of target hardware requirements, and the paging features inherent in TSE, the potential is there for large, immersive worlds.

But it's very difficult to answer your question adequately because it comes down to it being possible, but the probability of it happening depends on a huge number of undefined variables from your experience as a programmer and your ability to pick up and grok the engine enough to focus and produce something that fits your target metric.

That was a horrible sentence.

EDIT: Clarification because it sounded like he shouldn't take offense and I meant that the community shouldn't find offense with his question since there was nothing offensive in it.

#34 Yeah, what Canon did is really good since the Game I want to make uses the God View because that way I could use Low Poly Buildings etc.. Grass should be Implementet via Shader and this is supportet by TSE. I thought over and over the World Problem and the Polycount, but using God View is the best way to solve the Polycount Problem. The Textures I'm working on are at the Moment High Res 1024x1024 but I want to scale them down about the half to 512x512 if that size is okay for the Engine. The Terrain itself didn't be Highpoly too, it should only look good and with the right Textures this shouldn't be a problem. So I think the Map Size could be big. What is the greatest Map Size TGE features?

Sincerly Carl

#35 --Terrain isn't based on polys, it used height maps (and are paged).
--also keep in mind that TAP supports level of detail based on screen size of your models, so as long as you provide multiple levels of detail models (less polys the "smaller" the object will be on the screen), you have a quite good method of reducing poly count there as well.
--TSE's new terrain, by all accounts, is only limited by your hard drive space. With TGE, it's much more severely limited (I can't recall off the top of my head, but out of the box, it supports a 256x256 height map grid, which is expanded based on your squareSize, which is by default 8).

I hate beating my own dead horse, but rendering (specifically poly count per model) and terrain aren't going to be the performance hits in a massively/supremely large world...optimizing your "active objects" lists will be.