Re: "Most Wanted" list

[Frank C <li...@si...>]

On 16-Jun-04, at 10:59 AM, Dair Grant wrote:

>> This is clearly using the hardware texture & lighting, except that
>> it's not actually using the lighting portion -- it's faking it with
>> 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 = 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.

The DIY lighting I'm referring to would be static and pre-calculated by 
tracing rays from each light to each vertex. This is generally too slow 
to do at runtime, but has some nice side effects like self-shadowing. 
Basically a poor-man's lightmap...

>> But we're supposed to be binary compatible with QD3D; this is
>> something QD3D can do, and is clearly not incompatible with OpenGL,
>> 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?

Jose committed my patch yesterday, so perhaps Joe missed that this has 
already been fixed.

Frank.