Index:
[thread]
[date]
[subject]
[author]
From: teunis <teunis@computersupportcentre.com>
To : ggi-develop@eskimo.com
Date: Thu, 20 Aug 1998 19:49:17 -0700 (MST)
Re: LibGGI3D RFC
On Thu, 20 Aug 1998, Jon M. Taylor wrote:
[clipped all but one note!]
> Thus, over time the generalized, modular system will get replaced
> by more and more specific-case rendering/shading DrawTriangle() functions.
> IMHO this sort of evolutionary approach is the way to go, and LibGGI makes
> it quite easy to do. Get it working first for the general case(s), THEN
> optimize for specific cases. Often, implementing the general case
> solutions will enable you to get a clearer picture of the nature of the
> specific-case optimization needs, and you might end up being able to
> implement the specific-case optimizations in a better way than if you had
> taken that path from the beginning.
>
> This relates back to the "why don't you just use Mesa"
> discussions. Just as I am not saying specific-case rendering functions
> are wrong, I am not saying that accelerating Mesa on a specific-case basis
> is wrong. They are not wrong, but they *are* specific-case optimizations,
> and those should ALWAYS come after the general case(s) have been taken
> care of. IMHO.
The point I wish to make is this: How the API is initially designed shows
how far it can go. A pure triangle-renderer that knows nothing about
triangles around itself is -slow- on more advanced rendering. the
extensibility of parameters itself limits things...
Here's an API I just came up with and a few ideas:
typedef int ID_3drenderFunc
struct ggi3d_coordref
{
float x,y,z;
void *additional;
};
struct ggi3d_triangleref
{
struct ggi3d_coordref* cache
int a,b,c; /* offsets into cache pointing to current coords */
ID_3drenderFunc_ID rendering_function;
void* additional;
};
void ggi3DTriangle(struct ggi3d_triangleref* tri);
and then you can associate more data as needed. The basic case (invisible
3D triangle - ie no colour data) is still simple.
>From first glance it may look slower but:
you can cache coordinates (and link 'em together :)
you can cache triangles
nothing is assumed about the data (afaik)....
An amusing varient: (I have no idea if this is what info's needed. I know
-nothing- about infinite planes beyond some guesswork)
struct ggi3d_planeref
{
struct ggi3d_coordref* position;
struct ggi3d_coordref* normal;
ID_3drenderFunc_ID rendering_function;
void* additional;
};
void ggi3DInfinitePlane(struct ggi3d_triangleref* tri);
And you can add some cache-generation and cache-management extensions
easily enough to libGGI as well as triangle-lists, triangle-groups, ...
and if you tie the renderer to the cache you can do the more accelerated
tricks :)
What do you think?
G'day, eh? :)
- Teunis
Index:
[thread]
[date]
[subject]
[author]