RE: [Glelite-deve] Things to do

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

On Tue, Apr 24, 2001 at 06:49:01AM -0700, gle...@li...=
forge.net wrote:

(I'm responding to the digest... Maybe I'll switch to "real" mailing list
format at some point.)

> Date: Tue, 24 Apr 2001 10:50:19 +1000 (EST)
> From: Phillip Martin <q95...@to...>
> To: Timo K Suoranta <tks...@cc...>
> cc: mic...@no..., gle...@li...
> Subject: RE: [Glelite-deve] Things to do
>=20
> Sorry about not including the previous post in here, I'm using a unix
> email client, and editing large bodies of atext is a pain.
>=20
> Anyhow, my post is primarily about the having objectes draw themselves
> issue.
>=20
> My thought on the matter is that objects do not draw themselves, but
> essentially create a data structure which the renderer then interpreets ,
> and sends off to the appropriate api. If a nice enough set of classes was
> written that would easily define meshes, materials, colours, textures and
> all that jazz, each object can create or have its own internal 3d
> representation, then which is passed to the renderer for efficient
> rendering.
>=20
> This has the major benefits of:=20
>  - Each object has the ability to define how itself is drawn
>  - the renderer can optimise any which way it lieks to draw the given
> objects efficiently. Such optimsiations are away from the internal
> objects.
>  - it would be easy to alter the internal meshes to use vertex buffers or
> display lists without chaning the interface to those classes at all.
>=20

I tried to do this with a previous research prototype. My data structure
was a "state tree" -- the rendering optimized would then re-order
the state changes for different primitive groups in the most efficient
way for the underlying driver & hardware combination (perhaps based on
benchmarks run on program startup, or something), trying to minimize the
cost associated with state changes.

Now I'll be the first to admit that this would only deal with state change
cost (which seemed a good thing to concentrate on at the time; I can easily
imagine how a glLoadMatrix of GL_MODELVIEW would be a serializing operation
on a na=EFve hardware T&L driver), but the main lesson that I learned from
this was that it's not worth the hassle if the primitive groups are too
small.

The main issues that I see in this approach would be "what kind of a
data structure would be best for this?" and "what kind of data should
we put in the data structure?".  What the renderer will optimize for (speed,
of course! but how?) would also be something to think about.

--=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