I wanted to know if there is any "limit" to how big a game world can be in the engine. I KNOW that MED and WED have size limits for models and maps. But our plans are to make a monstrous map, comprising of the better portion of North Africa. I've read a bit about using "chunked terrain", but don't know a lot about it. I've also seen examples in the AUM for "stitching" terrains together, and for making "endless" terrain.

Basically, I'm thinking we need to use chunked terrain and some way of "stitching" or weaving the different pieces together. And we'd want to code it so that the client's PC doesn't have to worry about the "sectors" of terrain he/she can not see. If we can do that, I think we should have good performance. But we need smooth transitions from one "chunk/sector" to the other. I think a strong LOD system is going to be crucial here as well.

So basically, I want to know if A7 is prohibitive in any way about making very, very, very large worlds. Can this work if it's done correctly? I'd also like a basic explanation of the benefits of chunked terrain (just simple summary/overview).

Thanks for your time!

I cant help with the chunked/unchunked terrain stuff, but the current A7's
"world space" has a limit of +1,000,000 to -1,000,000 quants in all x,y, and z directions.
(The actual number is 1048576. The limit of a var... )

Quoting the Forecast:

Yes, but is it not possible to "cull" sectors of the world which aren't in use by the client/player? That way you don't exceed the limit and also gain in performance? I think we'd need to do it like that anyway, out of performance concerns alone. For instance, it's irrelevant for Libya to exist on my PC while I'm in western Egypt (and vice-versa). I don't need it until I'm about to cross over into it. In which case, we could scrap the place I just left?

Which AUM is "endless" terrain in? I've seen the "stitching" AUM, but not the "endless" one. I'm interested..

You dont have any limits if you do a "levelload" for
every new sector of the "land", and only load the required models
and assets.

You can set up an endless landscape using coding tricks.

Dont try to reach the "limits" of the engine by just loading
massive amounts of data at once.
The might work on one PC, but crashed on another.

Yeah, but the problem is having that "transition" for one part to another seamless, without any lag or pause for loading. That would basically defeat the fun factor of our game. Imagine your chasing down a Bf-109 across the skies of Africa, you're zeroing in to make the kill, and he runs to a new "sector", then the game pauses to load or lags, and totally ruins your pursuit. No one would want to play, lol. I guess we could pre-load or pre-allocate the whole world before the player ever enters the game. Then they can go from piece to piece with no delay. I hope... I know it worked for bullets. If I didn't preload the mesh and texture, I would have lag when you fired your first shot. But when I preloaded it, ent_create would work on demand without a hitch. So I guess level_load could be handled in a similar way. I suppose we could break the whole world down into "chunks", which load one by one before you spawn into the world. Then your PC only deals with the part you are in. Then we'll have to make it so that 4 chunks are close to the size limits of the engine. That's in case a player is at a corner, where 4 parts come together.

Does that sound reasonable?

I was thinking about doing the same thing with ent_preload. I would load resources associated with the sectors around the player before approaching them. I would then use ent_purge when the data was in a sector that is not adjacent to the player's sector.

This should work fine, but I am not sure about using ent_preload. If it works the way I am thinking it does, it will load the model data all in one frame, this would cause a jerk if it tries to load too much data. Also, it has to read the data from the hard drive which is known to have a delay while it seeks where the data is. There is a possibility to stagger the ent_preloads to try and minimize the jerks, and if the data is relatively close to each other on the hard drive there may not be much of a jerk.

If ent_preload were to load the data over multiple frames then there would be no jerking. This would be called streaming, and I do not think that A7 supports streaming.

No, I don't use ent_preload.

But I think this could work with the terrain, using level_load, or even converting to models and doing it that way, maybe with ent_create. Then the program can remove sectors not needed and re-add them when required. It would take a little longer to load all of the world this way, but that's also true of other games of this scale. Initial loading takes longer than your average fps, but the game "flows" without any problem.

Yes, but use ent_create so that you can load another sector without leaving the current one. Also this means you can have some LoD -- for example, you want some mountains on the horizon, but since they player isn't actually anywhere near them you don't want to have the high-detailed version eating up resources.

Jibb