Implementing Massive levels

There's a couple of options:

• Break the level up until chunks in a regular grid pattern. That way, it's easy to load just a few chunks at a time.
• Pre-calculate the octree. This is a bit more work, but may be more efficient since you can make it so that it only loads those sections that are actually visible.

That's two that I can think of off the top of my head.

The main issue, in my opinion, is not "how do I implement a massive world?" but more "how will I populate a massive world with content?" If you're just a one (or few)-man team, you're going to have a hard time, in my opinion, populating a massive world with interesting content.

The Continuous World of Dungeon Siege is a useful read.

The Dungeon Siege article is good, but I read another article (think it was on Gamesutra) by Scott where he said in hindsight the relative positioning they used caused far too many problems and if they were to do it again they would use absolute coordinates.

A double precision number can represent around 70,000,000,000 (70 thousand million) kilometers to millimeter precision before it starts to lose accuracy.
Then do all drawing in view space (camera is always at 0,0,0 adjust everything else) and your fine.

With my terrain engine I stuck to just 4km by 4km all loaded at startup but I've thought a bit about runtime dynamic loading.

If I were going to try it (and I might in the future) then I'd have something like the following:

___3___
__323__
_32123_
3210123
_32123_
__323__
___3___

Where the numbers indicate the LOD of a certain chunk of terrain. (I use terrain blocks split up again into 4 terrain segments which house the terrain vertices). When the viewer moves outside the middle block it would load up the next chunks in the grid (possibly from a file so long as you have good threading in the background for loading) and change the LODs of the ones that are staying.

You should split the chunks up again so that you can't see an obvious difference up close between LOD0 and LOD1 as you get close to it. There are quite a few articles around from people that have methods of doing this. Some use large chunks others load pretty much poly by poly. I'd go somewhere in the middle as it would probably be the most efficient method. Right now I think my actual terrain segment chunks are 128m a side. Loading one of those from a file, even with resource and model data really shouldn't take that long and assuming you've got it running in a background thread it would never be noticed.

Quote:

A double precision number can represent around 70,000,000,000 (70 thousand million) kilometers to millimeter precision before it starts to lose accuracy.

Except operations on floats are faster than those on doubles. Really much faster on some architectures.

Quote:

Original post by loufoque Quote: A double precision number can represent around 70,000,000,000 (70 thousand million) kilometers to millimeter precision before it starts to lose accuracy. Except operations on floats are faster than those on doubles. Really much faster on some architectures.

I suppose that's possible that floating point operations could be faster than double operations but in the grand scheme of things I doubt it would matter.

It's potentially up to ten times slower and at least two times slower.

That's quite enough to make a difference between a game that runs on the target platforms and one that doesn't.

Don't forget that you're only thinking about representation. Once you start performing operations on the doubles, you will quickly run into overflow, error, and other nasty side-effects of performing operations on types that approach the CPU's internal precision limit.

And you'll have to change from double to float when sending any values you need to the GPU shaders.

Personally I try and do all operations in float. You shouldn't have much of a problem using absolute positions with just floats.

Rememeber you only need to use the doubles for absolute translations. Then at draw time just make everything relative to the camera in floats.
And if your worried about doubles being slow use an int64 instead (1.8E13 km to mm precision) most systems nowerdays are 64 bit so they shouldn't be that slow just hit memory harder. Hell if your worlds not that big an int32 can represent just over 4000km to mm precision.

Single floats can only accuratly represent about 16km to mm before they start to quantize!

I really don't think you need to represent locations down to a mm precision. Noone will really notice the difference between that and 1cm precision in a computer game. That would give you 160km to play with, far too big a world for most games.

Yeah, I heard someone measured the size of the world of azeroth in wow to approx 140km, so a 160km world by anything less than a top level development company is going to pretty tough.

Quote:

Original post by loufoque It's potentially up to ten times slower and at least two times slower. That's quite enough to make a difference between a game that runs on the target platforms and one that doesn't.

Do you have any references to support the "two times slower" part? Assuming we're talking FPU and not SIMD, most architectures I can think of, with the exception of a few niche ones, internally use at least double precision, meaning that often the only extra cost will be the additional memory (and thus also the bandwidth when filling in the cache).

Quote:

Original post by Bogomip Yeah, I heard someone measured the size of the world of azeroth in wow to approx 140km, so a 160km world by anything less than a top level development company is going to pretty tough.

Producing unique high-quality geometry for anything this size is effectively impossible, since there's no market to support it. Consider the cost of creating a simple UT map.

So one quickly ends up with different world representation. Terrain is simply flat grid that can be efficiently culled, if necessary, world is repositioned on transition between zones.

On top of this grid, individual objects are placed from pre-defined templates.

So the need to have geometry coordinates cover the range of x km. Almost all of it will be much more local. And even with large worlds, practical radius is perhaps 500-1000m, and anything beyond 100m can afford the drop in precision.

Quote:

I would like to ask for suggestions/recommendation in implementing MASSIVE and Huge 3D levels for Multi-player games.

MASSIVE here is function of budget. The problem isn't really rendering them, but creating the content for them. And once that is solved (how many hundred world designers you can hire), the implementation will follow that.

For example, if I want to render entire Earth, it's no problem. I just download elevation data, pre-process into rectangular chunks, and load them as needed, optionally recentering the world is absolute positioning wouldn't work.

But the original problem remains - what do I put on this grid? Who will create enough unique assets to fill such world?

Actually, open spaces such as forests, plains, mountain ranges, etc. are better done not by hand but by randomization. It thus becomes fairly easy to make it as big as you want.
There is active research to apply that to automatically generate massive cities, too.

Quote:

Assuming we're talking FPU and not SIMD, most architectures I can think of, with the exception of a few niche ones, internally use at least double precision, meaning that often the only extra cost will be the additional memory (and thus also the bandwidth when filling in the cache).

I was thinking of the fastest option, SIMD.
Indeed, on x86, loading a float or a double into a FPU register (which is 80-bit) takes the same number of clocks as far as I know.

You should use a simple static spatial partitioning system (such as a simple grid, or if that doesn't work for you then some form of density-factored box system) for 'zones' which you then load according to proximity, to make a sensibly sized 'local level' which you can use standard (octree etc) partitioning systems on.