[quake3] Rendering System..

[Stephan Reiter]

> On the other hand it would be cool to have a map format that does not
require pre-processing like BSP space-partitioning.

Hmm, I think that'd be something for me, because in the raytracing patch
we're already building a very optimized acceleration structure similar to
the BSP in a few seconds at load time. It's a kd-tree: splitting planes are
axis aligned, which makes it a special form of a BSP.

In radiant there's the option to build a low-quality bsp for
"map-debugging". Does anyone know if that sets a flag in the map header we
could react to and build a BSP at runtime? Any other ideas?

Stephan


2008/4/10, Robert Beckebans <trebor_7 at gmx.net>:
>
> Well I think adding C++ to the Q3A architecture just f**** up everything.
>
> That is what I figured when I rewrote Quake2 into C++ before I began with
> the Q3A source. Or just have a look at Overdose. It is way more easy to
> break things completely instead of extending it. The team got a C++ coder
> who thought rewriting in C++ is fancy and Overdose is more broken than
> before. (I think it was a good choice not giving him access to the XreaL
> SVN)
>
> First of all you need a renderer for your type of game. I decided to keep
> everything designed for indoor rendering in XreaL like in Q3A.
> When you replace the renderer to support terrain rendering like in FarCry
> or Crysis then please don't provide basic level editing support with some
> closed-source world editing tools that break everything. You need to care
> about the network code, (bot code) and first of all collision code as well.
> Well all together I think it is pretty pointless to write a cool terrain
> renderer on top of Q3A if you break everything that your engine is not much
> more usable than a basic map viewer because collision detection and entity
> interactions are completely messed up.
>
> On the other hand it would be cool to have a map format that does not
> require pre-processing like BSP space-partitioning.
>
> I think it is not a problem to add Unreal Tournament 3 graphics to the Q3A
> engine with a complete engine overhaul like I did.
> The key problem is really Q3A shaders language which was a very early
> attempt for material scripting in games at all. I think it is not possible
> to support it completely with a modern renderer design. However it is not a
> problem to write a powerful renderer without C++.
>
> I think even the an id Tech 5 style renderer with virtualized textures can
> be implemented without too much trouble in pure C.
> The problem are the tools to create the content that really need to fit to
> the engine with all required aspects.
>
> Chris do you have a demo of your Nvidia Scenegraph based renderer? I would
> like to try it.
>
> Chris Bunting schrieb:
>
> > Hello,
> >
> > The talks about a plugin rendering system is the main reason why I've
> > mentioned a C++ port. If supporting varied plugin renderers were possible
> > with C, we would already have an OpenGL base renderer, OpenGL supporting
> > shader 2.0/3.0 and then a DX 8/9/10 renderers.. But it's not worth the
> > trouble for a C based engine.
> >
> > If you are really familier with the Q3 codebase, it takes maybe 60
> > minutes to rip out all of the bot/ai code. It's takes less than 30 minutes
> > to remove the small bits of network code. Network code is easlily replaced
> > with Rakknet or OpenTNL (GarageGames). But then, with the network code and
> > bot code removed, the rest of the code is based around OpenGL and all of the
> > hard coding. Most of the Q3 engine is full of opengl calls. The reason I
> > mentioned Hord3e is because it's extremely small, offers all of the same
> > rendering power and more if you want to use the built in pipelines and such.
> > There is also a linux build of Horde3D and also and SDL conversion for
> > linux.
> >
> > There are a lot of options but a plugin rendering system with c instead
> > of C++ / Classes / Real plugin support is just going to make it hard. For
> > every good idea there is a big drawback it would seem. There are a few
> > commercial engines I like but they just cost way to much for a personal
> > project of sorts.
> >
> > It seems there are a lot of people with older systems. So I don't know
> > what type of features they can actually support. If I was going to start
> > over again, I would replicate only a couple of Doom3 style features mainly
> > based around a shader system as this would help give Q3 the rendering
> > results simular to COD4. Xreal and Evolution both have a simular shader
> > implementaion. But the Quake 2 engine, A branch of Quake 2 Evolved called
> > OverDose has a small, clean Doom 3 style shader system,
> > http://q2e.svn.sourceforge.net/viewvc/q2e/OverDose/code/OverDose/renderer/r_shader.cpp?revision=228&view=markup
> >
> > Some sort of shader support is really the only thing that Ioq3 seems to
> > be missing. You can do a lot with shaders as there is code for just about
> > everything if your OS supports it. Otherwise, you just default back to the
> > base renderer if your card/driver doesn't support it's features just like
> > stock q3 does.
> >
> > Chris
> >
> >
> > ----- Original Message ----- From: <monk at rq3.com>
> > To: <quake3 at icculus.org>
> > Sent: Thursday, April 10, 2008 3:48 PM
> > Subject: Re: [quake3] How far can SGI MIPS, Sun SPARC, and LinuxPPC go?
> >
> >
> >     I'm not on the ioq3 voting review board
> > > > >
> > > >
> > > > Yes, you are.
> > > >
> > >
> > > Oh geez, you let SPARC users vote?!? ;)
> > >
> >
> >
> > ---
> > To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> > Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
> >
> >
> >
>
> ---
> 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/20080411/803bc274/attachment.htm>