>> > Anyway, here's my plans. Please let me know if anything is off so I
>> > can do this right the first time:
>> >
>> > o Define GL_PHONG in gl.h as 0x1D02. Currently unused, immediately
>> > precedes GL_SMOOTH.
>> You might be better off incorporating SGI's fragment lighting
>> extension into Mesa. Go to
>You should check out the spec for EXT_frament_lighting at
>http://reality.sgi.com/ljp_engr/registry/EXT/fragment_lighting.txt
>
>There's some IP/patent issues to consider.
Any ideas on who I'd need to talk to to get permission for this?
As far as fragment lighting versus true Phong, I think that, theoretically, the
results should be about the same. However, in terms of implementation, I think
that fragment lighting won't look at good. Any time you cut corners (fixed
point math, etc) you're going to lose something. In part, what I'm looking for
is a seperate code path in Mesa that would (even if it were slow) perform
rendering without cutting any major corners.
In fact, one of the particular problems I'd like to get around is how shaded
rendering (even without specular) never shades completely smoothly between
polygons. This can easily be seen by rendering a reasonably-tesselated sphere
with GLUT. The error reminds me of doing Phong without normalizing your
interpolated normal at each pixel.
Jonathan Dinerstein
[EMAIL PROTECTED]
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
