Quake Standards Base discussion

[frag.machine]

So, I was reading the proposed values to some QSB limits...

BSP/Dimensions
Normal limit: 4096 units
QSB: 1073741824 units(!!!!1ONE)

Aren't we being a bit overkill here ? I mean, while I agree 4096 units is too small, more than 1 billion of units is not feasible for a indoor-class 3D engine. And I am not even touching in the network part of the problem, lets just stick to how would we deal with such farclip limit.

Which brings another question: are we sticking to protocol 15, or embracing FitzQuake protocol 666, or DP 7, or create our own protocol, or what ?

[Baker]

So, I was reading the proposed values to some QSB limits...

BSP/Dimensions
Normal limit: 4096 units
QSB: 1073741824 units(!!!!1ONE)

Aren't we being a bit overkill here ? I mean, while I agree 4096 units is too small, more than 1 billion of units is not feasible for a indoor-class 3D engine. And I am not even touching in the network part of the problem, lets just stick to how would we deal with such farclip limit.

Which brings another question: are we sticking to protocol 15, or embracing FitzQuake protocol 666, or DP 7, or create our own protocol, or what ?

If this is referring to max x,y,z dimensions of a map or whatever you want to call them ...

1) What map editor for Quake supports greater than 4096 x,y,z thru -4096 x,y,z (tool support?)
2) Where is a map anyone made of this size that anyone plays? (need)
3) If the wiki entry is correct and both aguirReQuake and FitzQuake 0.85 support only 4096 [I'm thinking that information is not true] ( http://quakery.quakedev.com/qwiki/index ... ine_Limits ) and even the super-giant maps like Warpspasm/Soul of Evil Indian Summer are within these limits what would incredible size maps be used for or needed for? AirQuake or something? (is there a valid purpose?)
4) What map compiler supports this? hmap2? Does txqbsp? (tool support again)
5) Other than gl_farclip, what happens if a software engine tries to load such a map?

Plus unless it can be tutorialized, any new standards are pointless.

FitzQuake 0.85 protocol 666 *can* be tutorialized easily, for instance, because it occurs between a single engine version (FitzQuake 0.80 vs. FitzQuake 0.85). What all breaks if you change that limit? If the Quake wiki entry is wrong and FitzQuake 0.85 and aguirReQuake support such map size dimensions then that changes everything.

/FitzQuake protocol 666 doesn't have some of the modding features being discussed so a "FitzQuake 667" is really what I mean.

[Teiman]

So, I was reading the proposed values to some QSB limits...

BSP/Dimensions
Normal limit: 4096 units
QSB: 1073741824 units(!!!!1ONE)

Aren't we being a bit overkill here ? I mean, while I agree 4096 units is too small, more than 1 billion of units is not feasible for a indoor-class 3D engine. And I am not even touching in the network part of the problem, lets just stick to how would we deal with such farclip limit.

Such limits could be usefull to make total conversions.


Like this, but not this:
http://www.youtube.com/watch?v=ZuvKeQa8 ... r_embedded
http://www.youtube.com/watch?v=GEoYxXpPaNo




but I think is better to have precission than extension.. (if you know what I mean.)

[Sajt]

RE: map sizes

By far the biggest ramification of such large coordinates is the degradation of floating point quality. When the player is even a fraction of that far from the origin things tend to go spectacularly to crap: objects twitch around, texture coordinates slide around, and the player bumps around badly (and most likely the physics starts to break).

I don't know what's at that youtube link (can't view them) but I think Urre once made a map of such huge size (runnable in DarkPlaces). The player started on the top of a pedestal whose height was supposedly equal to the radius of the earth. When you jumped off and hit the ground several minutes later (naturally taking only 5 damage) you could see quite well what I mean by floating point degradation.

[frag.machine]

If this is referring to max x,y,z dimensions of a map or whatever you want to call them ...

1) What map editor for Quake supports greater than 4096 x,y,z thru -4096 x,y,z (tool support?)

I'd love if the only problem with such map limits were the tools. I am talking about the stress the rendering subsystem would be submitted having to deal with huge open areas. Besides, the .BSP file is far from the ideal format for such kind of map.

3) If the wiki entry is correct and both aguirReQuake and FitzQuake 0.85 support only 4096 [I'm thinking that information is not true] ( http://quakery.quakedev.com/qwiki/index ... ine_Limits ) and even the super-giant maps like Warpspasm/Soul of Evil Indian Summer are within these limits what would incredible size maps be used for or needed for? AirQuake or something? (is there a valid purpose?)

From FitzQuake source:

Code: Select all

//johnfitz -- original behavior, 13.3 fixed point coords, max range +-4096
void MSG_WriteCoord16 (sizebuf_t *sb, float f)
{
   MSG_WriteShort (sb, Q_rint(f*8));
}

//johnfitz -- 16.8 fixed point coords, max range +-32768
void MSG_WriteCoord24 (sizebuf_t *sb, float f)
{
   MSG_WriteShort (sb, f);
   MSG_WriteByte (sb, (int)(f*255)%255);
}

//johnfitz -- 32-bit float coords
void MSG_WriteCoord32f (sizebuf_t *sb, float f)
{
   MSG_WriteFloat (sb, f);
}

void MSG_WriteCoord (sizebuf_t *sb, float f)
{
   MSG_WriteCoord16 (sb, f);
}


And, while we're here, let's take a look at how FitzQuake writes angles:

Code: Select all

void MSG_WriteAngle (sizebuf_t *sb, float f)
{
   MSG_WriteByte (sb, Q_rint(f * 256.0 / 360.0) & 255); //johnfitz -- use Q_rint instead of (int)
}

//johnfitz -- for PROTOCOL_FITZQUAKE
void MSG_WriteAngle16 (sizebuf_t *sb, float f)
{
   MSG_WriteShort (sb, Q_rint(f * 65536.0 / 360.0) & 65535);
}
//johnfitz

So, from the network aspect, yeah, looks like FitzQuake can send/ receive big values (as longs or floats) as coordinates. As pointed however, this last approach, besides having a negative impact in network usage, can lead to a lot of errors due lack of precision.

[goldenboy]

It should be able to go a bit higher than 4096. I agree that (some large number here) is overkill.

One of Ricky's maps for RMQ is already hitting those limits, that's not just a fantastic story, it happens.

Of course you don't hit all limits at once. You will usually hit the horizontal limit north/south, or east/west. Although I think that negke's vertical map scratched that limit, too.

I have two maps that might reach the limit; one has very deep water (which I would like to make deeper) and a tower next to it, the other will have a large secret area (a super secret) that I'd like to put next to the existing layout, not below or above it (practical reasons).

So, bottom line, RMQ scratches the limit.

I would say doubling the old limit is definitely enough even for us. No need to go to radical numbers.

Quest supports crossing the old limits, can't be sure about other editors. qbsp compiled my map fine when I crossed the limit (a hom appeared in the map, but I could run around in the area and "feel" the brushes - the geometry was there, just not rendered properly.

So, yes and yes.

[mh]

Re: that Fitz code: I've implemented protocol 666 and can confirm that those functions may well be present in the code, but they are never actually used as part of the protocol. Protocol 666 uses standard Quake co-ords and angles all the way (aside from for client angles).

Precision on co-ords isn't that important in current generation maps - most things are either moving too fast or not moving at all (even a relatively slow plat - or the bars in the e4 entrance in start.bsp - is too fast here); precision on angles is just about to start becoming critical however, mainly as a result of the recent rotation tutorials. As it stands though Quakes angles quantization can't handle smooth rotation of bmodels too well.

For what it's worth interpolation ain't the answer here: DirectQ sends bmodels through the same orientation interpolation path as alias models and it resolves nothing.

Back to co-ords: Quake and the BSP format are actually far more capable of rendering big open scenes than common knowledge would have it; they're still not optimal, but structure of the rendering code can overcome a lot of obstacles and boost most scenes that currently drop to the 20s back up to 72 FPS.

So I vote for extended co-ords - maybe rob a bit of precision in the standard coords to set a flag indicating another byte-worth of extension is following. Or just send the full original float without any compression.

[metlslime]

As far as i know, the primary obstacle is network protocol which restricts coordinates to 13.3 fixed-point format. Changing this to a 32-bit float is the easiest, most obvious fix. Especially since the internal format is floating point on both client and server. I don't think map compilers or editors care about this limit (but older QERadiant versions and maybe some other editors only show grid lines out to +-4096.)

As others have pointed out, floating point formats have precision issues as you get to higher numbers, but in practical terms, i doubt any SP mapper is going to create a map big enough to experience actual problems with that. (On the other hand, with the limit lifted, It's hard to predict how far mappers will go, since few people in 1996 would have envisioned a map like Marcher Fortress being possible, for example.)

Regarding the WriteCoord code frag.machine posted, that was part of my R&D but i eventually decided not to include large coordinates as a feature of protocol 666, as I never came up with a good solution that didn't bloat packet sizes. (I have some better ideas now, though.)

[frag.machine]

IMHO the sample code below would be more than enough for QSB 1.0. If someday we decide that's not enough, then it's time for QSB 1.1

Code: Select all

//johnfitz -- 16.8 fixed point coords, max range +-32768
void MSG_WriteCoord24 (sizebuf_t *sb, float f)
{
   MSG_WriteShort (sb, f);
   MSG_WriteByte (sb, (int)(f*255)%255);
}


[metlslime]

actually that code appears to be wrong, i think the WriteByte line should actually be:

Code: Select all

MSG_WriteByte (sb, Q_rint(f * 256) & 255);

[Baker]

since few people in 1996 would have envisioned a map like Marcher Fortress being possible, for example.

Marcher Fortress runs in ancient stock GLQuake

Btw, vanilla glquake works fine on this system.

[metlslime]

since few people in 1996 would have envisioned a map like Marcher Fortress being possible, for example.

Marcher Fortress runs in ancient stock GLQuake

True and yet it was still beyond the ambitions of anyone at the time (except maybe the unrealistic ones)

[goldenboy]

Marcher Fortress in GLQuake has other issues, though.

[frag.machine]

actually that code appears to be wrong, i think the WriteByte line should actually be:

Code: Select all

MSG_WriteByte (sb, Q_rint(f * 256) & 255);

Sorry, I was asleep when wrote that (note to self: go sleep when you're asleep). What I mean is that should be enough for QSB 1.0:

Code: Select all

//johnfitz -- 16.8 fixed point coords, max range +-32768


Jumping from 4096 to 32768 units allows to make really big maps.

[Urre]

Created a first draft of the spec on the Quakery Wiki!

Sorry it took so long, I've been busy

I'd like to see more bugfixes mentioned. I also have a feeling I forgot a bugfix or two which people mentioned should be part of the spec, please remind me if so, or add them yourselves as may be

Are any of the extensions questionable considering usefulness? Should I add examples of how the extensions might be useful for a modder or mapper?

Discuss!