[quake3] Greetings

[Robert Beckebans]

I would like to clearify a few things about XreaL because many people 
complain about the incompatibility with existing mods assets:

XreaL was not initially based on the IOQuake 3 project at all. I merged 
it later with IOQuake 3 because I don't want to maintain so much 
platform dependent code. It is a different project with complete 
different project goals.

Another thing: adding advanced rendering stuff like per pixel lighting, 
VBO based scene management (the Q3A geometry per vertex processing is 
crap) requires many changes to the shader scripting language that aren't 
obvious for most non-OpenGL gurus.
You might be able to hack it together that it works somehow with the Q3A 
.shader language but you won't be able to redesign the renderer with 
newer rendering techniques without breaking compatibility in a few ways.
If you compare the material languages of Q3A and Doom 3 then you can see 
that Doom 3's material language is designed for a more modern renderer 
because most keywords work on a per-object base instead on a per-vertex 
base.
You can add per-pixel lighting to the IOQuake 3 renderer while sticking 
with the old shader language and get it to work with Q3A's geometry 
tesselation at runtime but it will be highly inefficient and slow.
Q3A's renderer design was good when it was released but GFX programming 
evolves really fast. Much faster than many other disciplines around game 
programming.
The old renderer design distracts many experienced OpenGL programmers 
because it is way too CPU bound with todays hardware.
It really does not matter to upgrade to a newer GPU with the old 
renderer design. You will be always CPU bound by the geometry tesselator 
when you try to put a few custom models into your map with many 
polygons. That's usually not a problem when you have a renderer that 
uses VBOs in a clever way. It's not clever to update VBOs every frame 
like in a very early IOQuake 3 patch. You need static VBOs that are 
created at map load to speed up the rendering performance so 200 000 or 
500 000 triangles per frame will be no problem. Q3A even pre-tesselated 
bezier curves at map load and post-tesselated them into triangles in the 
renderer backend every frame. Most of my OpenGL coder friends who saw 
that piece of code just said: WTF. It was a good idea in 1999 though.
I implemented a more modern renderer on top of Q3A that supports all 
that per-pixel lighting crap, efficient VBO geometry management and even 
directional light mapping with Doom 3 maps.
However power has a price and the price is breaking assets compatibility 
this time.

>> Other than that I think it is a very good idea to create a second,
>> more progressive version of ioquake3. I'd love to contribute to that,
>> e.g. by adding per-pixel lighting, ambient occlusion, etc.
>>     
>
> I would wonder if a fork is a good idea?  This is the situation we
> currently have with XReaL et al.  Forks with extra goodies.  But everyone
> tends to go back to the base ioq3 for bugfixes and to build with.
>
> Would people keep a fork sync'ed up?  And how would the fork distinguish
> itself from other fork projects?  Would the fork start breaking
> compatibility or lose the ability to run on other operating systems and
> platforms?
>
> If the base ioq3 were extended, it would be valuable because:
>
> 1) the code would always be up-to-date, no need to merge in fixes
> 2) you don't split mindshare between the "original" and "new" (marketing
> thinking, 'ere?  one-stop shopping?)
> 3) it would force any extensions to take into account the many platforms
> that ioq3 already runs on (one of the great values for us in ioq3 over,
> say, XReaL or one of those .NET ports)
> 4) it would force any extensions to take into account being able to run
> existing baseq3 media, i.e. XReaL supports neat things but does NOT
> support older lightmapped maps so our existing content (and pretty much
> all existing Q3 content) is not available for use in that engine
>
> If you extend ioq3 and it doesn't hurt backward compatibility, is there a
> good reason to fork?  If people just don't like that idea, ok, I get it. 
> But forking seems like it would just require more maintenance and might
> end up splitting attention.
>
> Anything the list discusses that they don't want to include in the base
> ioq3 or can't come to a consensus on, they can always publish as a patch
> like is currently done, I'd think.
>
> Monk.
>
> ---
> To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20080409/ba33040d/attachment.htm>