Jump to content
The Dark Mod Forums

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


Komag

Recommended Posts

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?

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

  • Replies 64
  • Created
  • Last Reply

Top Posters In This Topic

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. :P

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by demagogue

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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....

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?)

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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... ;);)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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?

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

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.

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Taking a break to alleviate burnout. In retrospect, I probably shouldn't have jumped into a map-making contest so quickly after just finishing another project and especially with my busy schedule, but I do believe I have something that the community will enjoy. No clue if I'll be able to finish it on time for the competition if I factor in a break, but I'd rather take my time and deliver something of quality rather than engage in development crunch or lose part of the map's soul to burnout.
      · 1 reply
    • Skaruts

      Working on an update for my mission By The Cookbook. If anyone that played it has any further bugs to report, please let me know.
      I posted more details about the update in the mission thread.
      · 1 reply
    • lucien

      being thankful for tdm is a good feeling
      · 0 replies
    • The Black Arrow

      Happy birthday to me!
      Yes, today's my birthday and as much as I want to play The Dark Mod, I won't until it's late Autumn, where it should be a bit chilly in my place and there's some wind too.
      For now, it's time to enjoy my birthday, if any of you want to play a great fan mission in my honour...Well that's asking too much, just play the mission because it's fun, not because of me, enjoy it yourself! 💪
      · 5 replies
    • nbohr1more

      New texture wiki article created: https://wiki.thedarkmod.com/index.php?title=Creating_textures_from_Ornate_Photos
      · 11 replies
×
×
  • Create New...