Re: [Openquartz-general] Re: [Quake-devel] how far have you planed to go?

[Seth G. <sga...@li...>]

On Sun, 25 Mar 2001, Joseph Carter wrote:

> > We don't plan to stay compatible with non-OQ versions of QCC.
> 
> That could be a problem since QF intends to have its own qcc.

What does QF need a QCC for, client side QC?
What's going to be different about your QCC?
Will you remain compatible with existing compiled QC?

> > This may require two versions of player.qc or it might be done in one
> > player.qc file with some preprocessor commands (#ifdef EXTRA_ANIMATION)
> 
> Again, if you do that, you lose the ability to have old clients connect
> and you are stuck with two mods that are different but look from outward
> appearances (ie, to qstat/gamespy/whatever) as the same.

They will have to identify themselves as different mods.

> > 2. The two engines most likely to support significantly enhanced model
> > formats are DP and QF - I hope you will agree on a standard.
> 
> Assuming of course Forest comes out of hiding again..  =)

Anybody know how to contact him?
My brother says his email address doesn't work anymore.

> > 3. Only some of the models should be enhanced to exploit new engine
> > features.  Item models that don't need animation or high precision should
> > be left in Quake 1 .mdl format.
> 
> Why?  There is a certain amount of unavoidable overhead with model
> rendering that is jsut a fact of life.  Add more kinds of models which
> have to be rendered seperately and with different modes, you increase
> overhead. [...] Overhead for two model renderers each frame.

That's a very strange claim.  What do you mean by overhead?
program size?  That's going to be small compared to the data size.
processing power?  Multiple model types are already supported, if there
would be a CPU drain from switching between types, it's already there.

> I'd rather move new stuff to a unified format which doesn't have seperate
> overhead for setting things up.  It's no longer necessary to have several
> different kinds of models.  BSP models exist solely because they can be
> lit since they don't go anywhere.

That approach creates a slightly simpler program (you only avoid creating
ONE new type of model, not "several"), but it makes old format models use
up to 6 times as much memory - which at least means raising the system
requirements from say 32 MB of RAM to something like 40 or 48 MB.

> Descent-style is correct for a simulator since there is no "up" other than
> the direction you perceive as up..

The vehicles control system is not designed to adapt to the pilot's
perception of "up" - it always treats the vehicle's local up vector as up.
Millions of years of evolution have produced humans with a sense of up
that gives visual cues first priority, gravity and acceleration second,
and local coordinates last.  Vehicles aren't smart or psychic enough 
respond to visual cues, but humans are.

All I'm saying is I'd like to see what happens when can adapt your
controls to whatever version of up you want.

> You don't get it..  PVS == bad for big spaces
> Since Quake's world model is PVS, and that the entire game revolves
> around the world model, you can't just change it.

I understand that PVS is no good for situations like an open arena with
lots of visibility blocking objects like pillars or boxes, or a central
atrium with lots of passages branching out from it.

Here is what I don't know:

 * What makes it so poor in these situations?  What goes on that bogs
   the computer down?  Is visibility slowing things down compared to
   not using any visibility system? (if so, by how much), or just failing
   to speed things up?
 * Is it bad for large areas if visibility is simple - using "detail"
   brushes for pillars, boxes etc. and not too many exits?
 * How do other visibility systems that might be used work?

> There are entire books written on the subject.  Essentially, you have to
> walk up and down a hierarchical tree many times to render a frame.  The
> more you can see, the more you have to walk the tree.  A patch system more
> of a foot-bone's-connected-to-the-ankle-bone structure, so you can
> traverse it much faster.  A big space means one traversal of that space
> whereas a PVS tree can involve many, many traversals up and down divisions
> of spaces since only the bottom leaves actually contain any data.  Better
> than that and you'll need to learn how the data structures work.  =)

How well can this be controlled by changing the way the PVS is calculated?
Can you just say "put this big area into one big leaf"?

> > That's another thing I don't get:  after you have already re-written so
> > much stuff to improve the structure of the engine, why would you suddenly
> > switch to a "from scratch" approach (unless of course you were about to
> > have an amazing amount of collective free time on your hands :-)
> 
> To kill the backward compatibility gremlin from the start.  If the engine
> is something new, nobody is gonna scream when something isn't compatible
> with Quake or with anything else.  Free hand to do things the way you want
> to do them rather than being constrained by the way things were done
> before.  The freedom to say for example that .mdl sucks ass and spend a
> week or so making it go away and never having to worry about someone's 5
> year old mod that can't be made to use new models.
>
> It was supposed to be a parallel project to do the things that Quake
> wasn't designed for.  It probably wouldn't do some things as well as Quake
> could, but then it had different design goals and could do other things
> better.

Actually that makes a lot of sense, but a project like that is very hard
to get started and even harder to finish.

I've seen it happen lots of times.  I started out trying to write my own
GPL 3D engine from scratch a few years ago.  While trying to attract other
developers I discovered Crystal Space.  I spent a year or so learning
about that engine and becomming a developer.  A year or so later the Quake
source was released and I started watching Quake engine developments
because I had already so much experience with Quake editing.

> > 1. Maintain three (NQ, QW and QF) protocols - the network protocol is
> > going to be the big compatibility issue - and it already is with NQ vs.
> > QW.  It does not matter if some new QF mods are not compatible with other
> > clients as long as all of the old mods still work with the old protocols.
> 
> This is what makes the merge so very hard.  Not only are there the two
> antiquated protocols to support, but anything we want to change has to
> also be maintained in parallel.  We're coming back to that exponential
> maintenance effort again.  The merge is an attempt to combat this to at
> least some degree.

If you can keep it down to three variations with one merged code base, the
problem won't become exponential.  On the other hand if every permutation
of all the good ideas spawns a new CVS module, then you are going to have
an exponential problem :-)
  __    __    _                                    _    __    __
_/  \__/  \__/  Seth Galbraith  "The Serpent Lord"  \__/  \__/  \_
 \__/  \__/  \_ sga...@kr...  #2244199 on ICQ  _/  \__/  \__/
_/  \__/  \__/    http://www.planetquake.com/gg     \__/  \__/  \_