Inside3D!
     

Quake Standards Base discussion
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Jan 20, 2010 6:19 pm    Post subject: Reply with quote

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 ?
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 20, 2010 6:43 pm    Post subject: Reply with quote

frag.machine wrote:
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.php/Engine_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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Wed Jan 20, 2010 7:03 pm    Post subject: Reply with quote

frag.machine wrote:
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=ZuvKeQa8sso&feature=player_embedded
http://www.youtube.com/watch?v=GEoYxXpPaNo




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


Last edited by Teiman on Wed Jan 20, 2010 9:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Wed Jan 20, 2010 7:36 pm    Post subject: Reply with quote

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.
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Jan 20, 2010 9:47 pm    Post subject: Reply with quote

Baker wrote:

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.

Baker wrote:
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.php/Engine_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:

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

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.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Wed Jan 20, 2010 10:32 pm    Post subject: Reply with quote

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.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Wed Jan 20, 2010 10:58 pm    Post subject: Reply with quote

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Wed Jan 20, 2010 11:58 pm    Post subject: Re: Large Map Sizes Reply with quote

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.)
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Thu Jan 21, 2010 1:31 am    Post subject: Reply with quote

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 Smile

Code:

//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);
}

_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Thu Jan 21, 2010 2:13 am    Post subject: Reply with quote

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

Code:
MSG_WriteByte (sb, Q_rint(f * 256) & 255);
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Jan 21, 2010 3:32 am    Post subject: Re: Large Map Sizes Reply with quote

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


Marcher Fortress runs in ancient stock GLQuake Razz

Jago in Func release thread wrote:
Btw, vanilla glquake works fine on this system.

_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Thu Jan 21, 2010 8:10 am    Post subject: Re: Large Map Sizes Reply with quote

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


Marcher Fortress runs in ancient stock GLQuake Razz


True and yet it was still beyond the ambitions of anyone at the time (except maybe the unrealistic ones) Smile
Back to top
View user's profile Send private message
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Thu Jan 21, 2010 11:20 am    Post subject: Reply with quote

Marcher Fortress in GLQuake has other issues, though.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Thu Jan 21, 2010 11:56 am    Post subject: Reply with quote

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

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


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

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


Jumping from 4096 to 32768 units allows to make really big maps.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sat Feb 06, 2010 6:24 pm    Post subject: Reply with quote

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

Sorry it took so long, I've been busy Sad

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 Smile

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!
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 2 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group