currently, GL_SPHERE_MAP texgen causes a tcl fallback, which should not be necessary (and this fallback causes lots of z fighting with for instance tuxracer or nwn, though this is supposedly the apps fault). The fallback is used since the results with hw tcl are wrong. Some analysis with fglrx shows that this driver sets R200_LOCAL_VIEWER in the tcl lighting model control with at least the simple samples/sphere app, and when hacking this into the r200 driver (I have really no idea where and when...) this indeed fixes at least isosurf (in reflect mode) and sphere as far as I can tell, and tuxracer also seems to look correct. This also easily explains why sometimes the GL_SPHERE_MAP indeed worked correctly (for instance in gloss, this sets the GL_LIGHT_MODEL_LOCAL_VIEWER to true). I do not really understand the lighting model nor its interaction with the r200 chip, so I have no idea how a proper fix would look like unfortunately. I guess always setting this bit would cause errors in other places?
I've turned the fallback off, since it seems GL_SPHERE_MAP should work, and apparently works in some cases. I've confirmed that R200_LOCAL_VIEWER did fix texcyl (just drop it into the TCL_LIGHT_MODEL_CTL_0 of r200_state_init.c to see), though reading gl specs and ati specs, I can't come up with a reason why. Perhaps Michel could shed some light on this?
(In reply to comment #1) > I've turned the fallback off, since it seems GL_SPHERE_MAP should work, and > apparently works in some cases. I've confirmed that R200_LOCAL_VIEWER did fix > texcyl (just drop it into the TCL_LIGHT_MODEL_CTL_0 of r200_state_init.c to > see), though reading gl specs and ati specs, I can't come up with a reason why. I think this is a common hardware limitation, Direct3d has a caps bit for exactly that (D3DVTXPCAPS_NO_TEXGEN_NONLOCALVIEWER, though it needs to be said the radeons do not set it). I believe the reason is that some calculations related to eye-coordinate transforms are shared between lighting and texgen. However, I'm wondering is it possible (and if not, what sort of lights will break?) to always set R200_LOCAL_VIEWER if texgen is enabled? It seems it's necessary to set _mesa_allow_light_in_model to 0 (same as fog already does) in that case, with that set lighting still seems to be correct if R200_LOCAL_VIEWER is always enabled, but the math behind it escapes me a bit. I think it would be needed for all texgen modes, not just GL_SPHERE_MAP, with probably the exception of the GL_OBJECT_LINEAR mode, on both r100 and r200. I'll code that up if someone else thinks this might be the correct thing to do :-).
Created attachment 3445 [details] [review] proposed fix for tcl texgen proposed fix. It just puts the chip in LOCAL_VIEWER mode whenever texgen needs eye coords - this seems to be what fglrx is doing (though I'm not sure, maybe it does more than that). This may break specular highlights if at the same time lighting is enabled and the light model is not set to local viewer. I'm not sure it's worth worrying about that. I've not yet confirmed it's necessary for all those 4 texgen modes, only for GL_SPHERE_MAP. But if it's necessary for all of them then the radeon driver would need the same patch probably.
fixed in cvs - the only change to the last patch is that GL_EYE_LINEAR mode does not seem to need the R200_LOCAL_VIEWER bit (as per fglrx).
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.