Re: [Glelite-deve] Re: Things to do

[Kalle A. Sandstr\o. <ksa...@ik...>]

On Tue, Apr 24, 2001 at 04:47:23PM +0300, tsuoranta wrote:

> > Perhaps we should also prepare for the (IMO) inevitable addition of
> > graphics-card side vertex buffers by providing a kind of abstraction fo=
r it.
> > Nvidia, at least, seem to have their own extension for this.
>=20
> Yes, I would like to have support for NVidia AGP vertex arrays,
> normal vertex arrays, compiled vertex arrays, displaylists etc.

Total genericity can be a real bitch to implement...

> > One thing that I learned while writing one of my failed prototype 3d
> > engines was that you can't really keep material handling separate from
> > geometry handling. At the very least, for multitexturing (primitive per=
-pixel
> > point lights, that sort of thing), you'd need some kind of an interface=
 for
> > the geometry to draw itself multiple times in a certain order, etc...
>=20
> The current rendering architecture in Teddy does indeed have multiple
> pass rendering.
>=20
> http://glelite.sourceforge.net/doc/Mesh_cpp-source.html
>=20
> See drawImmediate() and drawElements(). It currently does not support
> multitexturing, which potentially would require a lot of changes to
> the current architecture. I hadn't thought much about multitexturing
> until this mail, since there is no textures in glElite / Teddy yet
> at all.

Multitexturing is important for visual quality; you can do some pretty
neat things with it when used correctly (approximate per-pixel lighting
comes to mind, as well as some rather surreal effects...)

> The current implementation simply redraws every element multiple
> times if required. For example, for hidden line removal to happen
> when drawing wireframes, you have to first draw with filled polygons
> and polygon offset, and then do a second pass with lines and no
> polygon offset. You can also enable borders by using second pass.

One thing I've been wondering is that would it be sensible to have
partially transparent surfaces at all?  I mean, they'd require special
handling (i.e. "draw opaque surfaces first, then draw transparent
polygons in a back-to-front order while making sure that they don't
intersect") which may not be feasible on the polygon level without
building potentially huge data structures.  On the other hand,
transparencies are pretty much a requirement for a good-looking engine
glow...

One way would be to add a 'flags' field (or a bunch of bool variables,
whatever) to a Renderable entity and then reorder the visible object list
so that first objects with only opaque surfaces would be drawn into an
'empty' color buffer and then objects with both opaque and transparent
surfaces in an approximate back-to-front order.  (Computing the back-to-fro=
nt
order can get pretty weird unless the objects could be partially rendered,
or something.  Object cutting is something I'm not going to touch with a
ten-foot pole, however.)

> Actually I think multitexturing is slightly different from multiple
> passes like border lines above. With multitexturing you may not have
> to actually render multiple passes, but I know no good method that
> could do border lines in a single pass. Applying multitextures might
> be simple to add to current Projection <-> Mesh architecture I think..

I think that we should give the "must work with single texturing cards"
principle a boot in the aft section.  If Teddy is going to target graphics
cards from the G400 up, it makes little sense to pretend that someone would
want to run Teddy-based programs in single textured mode.

On a research engine I had about half a year ago, I tried to implement
layered-texture stuff so that it would run on both single- and multitexturi=
ng
cards.  The results were less than satisfactory; you can't do emulated
per-pixel point lighting from multiple light sources with only one texture
unit.

> > Perhaps a good design would be to keep the "what happen ?" code
> > separate from the "main screen turn on" stuff, so that if the game were
> > run without networking the server object (or some such) would run on the
> > local computer in a separate POSIX thread.
>=20
> Yes, something like that. The simulation already runs in seperate
> thread as SDL timer. Nope, I haven't protected anything with semaphores
> as I should have.. yet :)

I don't have a very high opinion of the SDL threading interface; perhaps
we should provide our own abstraction of POSIX-style threading (i.e.
threads, mutexes, conds, possibly read-write locks) in order to remain
sane -- I mean, there supposedly is a POSIX threads implementation for
win32 too, so it can't be that hard.  (we might be able to cut'n'paste
some code from SDL too ;-)

--=20
Kalle A. Sandstro"m                             ksandstr &at& iki &dot& fi
http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto
1ED7 C636:              7728 49D5 F784 D2DD D20F  63CF 655D F19E 1ED7 C636