Re: "Most Wanted" list

[Dair G. <da...@re...>]

Joseph J. Strout wrote:

>In OpenGL, and in QD3D, he "does his own lighting" by applying vertex
>colors to textured TriMeshes.  The color applied at each vertex as
>calculated based on the lights in the scene

I'm not sure I understand what the problem is then - this is also how
things work under Quesa: if you use a NULL shader, the final vertex
colour is the colour you supply * the texture.


>This is clearly using the hardware texture & lighting, except that=20
>it's not actually using the lighting portion -- it's faking it with=20
>vertex coloring.

The T in T&L actually means Transform - normally "do your own lighting"
means doing what QD3D's IR did, i.e., transform the geometry from the
world to the camera coordinate system, light it as appropriate, and
produce a final colour of:

    output =3D calc_light(vertex_colour * texture_colour)

And then push down your fully-lit triangle to the rasteriser.

The normal reason for doing it is so that you can use a different
lighting model than the one GL allows, e.g., to introduce different
light types or use a different illumination model.


>But we're supposed to be binary compatible with QD3D; this is=20
>something QD3D can do, and is clearly not incompatible with OpenGL,=20
>so shouldn't Quesa's IR behave the same way?

I think it does, doesn't it? I went through my backlog of mail yesterday
so may have missed it in that, so is there still a situation that's not
handled by using a null shader?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/