What is the ultimate maximum size possible - the editor dimension limits?

[Komag]

I'm wondering what the largest possible world size it, in something like square miles.

 

I see in DarkRadiant (and I think it's the same in DoomEd) the units for the editor max out at 65,536 in each direction from the origin 0,0,0 (that's 2 to the 16 power, by the way).

 

So, for example, from the extreme north end to the extreme south end there are 131,072 units.

 

My question then is, do we have a clear conversion rate for these units to feet or meters? To my untrained eyes, it appears to me that about 16 units looks like a foot.

 

If that's the case, then the north-to-south max distance is 8192 feet, or about 1.5 miles (2.5 kilometers), making the whole flat plane about 2.5 square miles (6.25 square kilometers).

 

If that's accurate, it means that although we have a pretty dang large area to work in, if we REALLY wanted to recreate a full scale medieval London for instance, we would be quite limited space-wise.

 

Am I close on these figures, or have I completely missed something?

[greebo]

One DoomUnit is considered an inch. With an inch = 2.54 cm you'll get 3329 meters, so the total area of a plain map would be more than 10 km².

 

And don't forget you can build your map 3.3 km high.

[OrbWeaver]

You can't create a full-size medieval London? That's it, I'm giving up on this crappy engine right away.

 

The co-ordinates are actually floating point so they do not max out at 65536 (although the editor grid may well be limited to this). However, floating point has a limited precision so once you start getting a long way from the origin, you will find that rounding errors become more of a problem.

[Komag]

Hmm, are these floating point rounding errors something that will bite us in the butt if we build wide?

 

And I've looked at more stuff with the 1 unit = 1 inch measure, and I just don't think it's accurate.

 

An 8 unit thick wall looks only around 6 inches thick to me, a 120 unit wide hallway looks only around 7 or 8 feet wide to me (not 10 feet), and the desk model we have sits with the top about 40 units off the floor, whereas my desk and also my wife's desk are measured at about 30 inches off the floor, not 40.

 

All that points back to my original estimate of 16 units = 1 foot (not 12 units = 1 foot)

[jdude]

I don't think anyone will ever make a map that takes up the entire editor though... It's just to huge.

[OrbWeaver]

Hmm, are these floating point rounding errors something that will bite us in the butt if we build wide?

 

It will become a problem if you try to create fine detail at a very large distance from the origin, but probably not during ordinary mapping.

 

Imagine that the brush coordinates have a fixed number of significant figures (not strictly true, since they are using binary not decimal, but the approximation is good enough). If you place a brush from 8.0 to 16.0 there is no problem, but try to place once from 1000008.0 to 1000016.0 and they will both get rounded to 1000000.0.

[Komag]

But what about 60008 to 60016? Because that's what might happen if someone wanted to build a very LONG mission.

[greebo]

Does Doom 3 still use floats? We upgraded DarkRadiant to use doubles instead just to address this issue, haven't we?

 

edit: Just looked through the SDK map parser, it does indeed use floats. idVec3 is also using floats.

[demagogue]

Is it easy to set up loadzones?

I would think if you really want to make that massive of a city, you could just have a wall & gate (or series of them) at one far end of a map that bottlenecks the area and put loadzones to the other half of the city that's just a completely new map, and it really wouldn't be so bad ... as long as the open playable area itself were massive. So you'd only run into a loadzone after hours of play, and only once, and then you're in another massive open playing area for hours.

Edited June 16, 2007 by demagogue

[SneaksieDave]

If only we should be so lucky that any mission will ever reach anywhere near the total size of the grid (and without being completely empty and pointless).

[jdude]

Even if someone did make a really large map that took up all the available space in the editor, it would take a really long time for Doom3 to load it into memory, which would make it a bad idea because it would be so much easier to just use level endings.

[Komag]

Maybe you could do some sort of secret teleport system to warp the player back to the other side of the editing world but down a few thousand units without noticing anything, and you can thus create "layers" of city stacked up. The player would get the illusion that he is just continuing to move in the same direction further and further and further and further....

[Fidcal]

With mass cloning it might not be too 'difficult' to make a very large bland and repeating test map with about 50 stacks of 2 x 2 miles each about 200 foot high that's 100 x 100 miles or 10,000 square miles. Big enough for ya? Problem as said is handling the file size but it illustrates that the only limit is labour, imagination, RAM size and so on.

 

[EDIT] Plus I don't know if there's a pathfinding limit like in T2

[Komag]

Yeah, I'm also wondering what other limits we might find (other than the number of objects limit which can be raised, but how much?)

[ZylonBane]

If you place a brush from 8.0 to 16.0 there is no problem, but try to place once from 1000008.0 to 1000016.0 and they will both get rounded to 1000000.0.

Umm, ahem. 1000008.0 is, you may have noticed, an integer. Even with only single-precision floats you can precisely represent any integer all the way up to 16,777,216.

[OrbWeaver]

Umm, ahem. 1000008.0 is, you may have noticed, an integer. Even with only single-precision floats you can precisely represent any integer all the way up to 16,777,216.

 

I know, it was just an hypothetical example to illustrate the concept.

 

In reality, the problems will probably not occur with simple axis-aligned brushes at nice rounded intervals; the errors happen when you start using the clipper tool or vertex editing to produce angled edges. Because each brush is represented as the intersection of a number of planes, each of which uses a plane equation, angled surfaces can end up with some very ugly floating-point coordinates even if every one of the vertices is grid-aligned.

[STiFU]

Maybe you could do some sort of secret teleport system to warp the player back to the other side of the editing world but down a few thousand units without noticing anything, and you can thus create "layers" of city stacked up. The player would get the illusion that he is just continuing to move in the same direction further and further and further and further....

 

Or you guys could just switch over to PREY and use those huge visual teleporters and build the whole city in mutliple Layers... ;)

[sparhawk]

Yeah. But the geometry still has to be buitl SOMEWHERE. Now guess where this is? It doesn't matter if you walk to 1000008.0 or teleport there.

[Dram]

Speaking of floating points, when you create a func_static does it "offset" the brushes/patches from it's origin or does it still use world coordinates? I know it would use world coordinates for the origin of the static but what about brushes within the static? If it does offset from it's origin, then it would mean that anything detailed could be grouped into statics (I do this now anyway) and would avoid the large floating point value errors.

[greebo]

All child primitives are measured relatively to the origin of the parent func_* entity. Whether this is a workaround or not depends on the way things are handled within the engine. If the children are translated at map loading time, this would resolve nothing. If it is handled by a world2entity transformation matrix this could help a bit.

 

Although there are other things to consider like the collision model generation and such, which would still need to be performed in world coordinates, I reckon.

[Dram]

All child primitives are measured relatively to the origin of the parent func_* entity. Whether this is a workaround or not depends on the way things are handled within the engine. If the children are translated at map loading time, this would resolve nothing. If it is handled by a world2entity transformation matrix this could help a bit.

 

Although there are other things to consider like the collision model generation and such, which would still need to be performed in world coordinates, I reckon.

 

Hmm, that's true. Well it does'nt matter really, the grid itself is much more then what we need. Currently my mansion map has expanded to about 1/800th of the grid. Around that anyways, and it's about 4 times as big as what is currently on SVN, so yeah, we can make huge missions. Funnily enough, however, I am at 2397 entities and I expecting that number to almost double. So I probably will reach or go over the 4096 entity limit. Time will tell I suppose

[Komag]

I read it somewhere, but again why not set the entity limit right now up to like 100,000 or whatever? It takes up some memory or something?

[greebo]

There might be some loops in the code which would take longer. I don't know how often this is the case, but as long as it's not really necessary I'd rather leave it.

[Komag]

Is it something we can change on our own? I can guarantee that it will become necessary pretty soon, especially if our small beta-maps are already approaching it!

 

But I guess if you don't want to mess with it right now then you can just wait until someone is getting really close and requests the increase at that time.

[greebo]

I wouldn't call mansion_alpha a small beta map. (It's a pretty huge, I'd say.) And all the original Doom3 levels were doing just fine with the 4k entity limit as well.