On Sat, 2004-01-31 at 22:34, Roland Scheidegger wrote:
now that the lighting bugs are finally mostly gone, I've just gone ahead and changed the lighting code a bit more... (patch against cvs, without the earlier colormat fix).
Good work! This fixes neverball and neverputt here, and improves trackballs a lot (in foggy levels, the ground used to be mostly invisible; now it's visible, but white (the fog colour) instead of the correct colour about half the time).
[...] some whitespace trouble, should be fixed with this patch. It has also some initialization ugliness fixed, and there is some new code (but it's outcommented as I can't test it right now and I'm not sure if it's needed or if will just lock up the chip...) which might fix some shininess trouble [...]
Any news on that?
Looks like it's not necessary. The OpenGL spec doesn't explicitly say it, but the specular exponent always seems to use what's specified with the color material - even if it is set to track the specular value of the current vertex (the spec DOES say it tracks the specular value, and says nothing about the specualar exponent, so I guess it implicitly says the specular value will still use the value from the color material). Using some hacked-up samples/wave demo, mesa at least acts that way too. I guess changing this shininess parameter there in the lighing model would only be useful for some funky vertex programs...
Actually, no it doesn't cause the segfault, regardless if it's there or not running with tcl_mode=0 always segfaults specviewperf proe02. It "only" causes the rendering errors in viewperf proe-02 (which is what's so strange, the other parts of the patch look completely innocent regarding the sw tcl pipeline). Without switching tcl off, it will not segfault, neither with this applied or not (even though it will cause a fallback).
@@ -2130,29 +2177,10 @@ r200VtxfmtInvalidate( ctx ); }
-/* A hack. The r200 can actually cope just fine with materials - * between begin/ends, so fix this. - */ -static GLboolean check_material( GLcontext *ctx ) -{ - TNLcontext *tnl = TNL_CONTEXT(ctx); - GLint i; - - for (i = _TNL_ATTRIB_MAT_FRONT_AMBIENT; - i < _TNL_ATTRIB_MAT_BACK_INDEXES; - i++) - if (tnl->vb.AttribPtr[i] && - tnl->vb.AttribPtr[i]->stride) - return GL_TRUE; - - return GL_FALSE; -} -
static void r200WrapRunPipeline( GLcontext *ctx ) { r200ContextPtr rmesa = R200_CONTEXT(ctx); - GLboolean has_material;
if (0) fprintf(stderr, "%s, newstate: %x\n", __FUNCTION__, rmesa->NewGLState); @@ -2162,19 +2190,11 @@ if (rmesa->NewGLState)
r200ValidateState( ctx );
- has_material = (ctx->Light.Enabled && check_material( ctx )); -
- if (has_material) { - TCL_FALLBACK( ctx, R200_TCL_FALLBACK_MATERIAL, GL_TRUE ); - }
/* Run the pipeline. */ _tnl_run_pipeline( ctx );
- if (has_material) { - TCL_FALLBACK( ctx, R200_TCL_FALLBACK_MATERIAL, GL_FALSE ); - } }
Reverting this part (which you suspect causes a viewperf segfault, right?) returns trackballs to the old, very broken behaviour, so there seems to be some good to it after all. :)
The rendering errors look like some material changes simply are missed (or maybe submitted too late, after the primitive is already drawn?), as the color used isn't arbitrary - it always seems to be one used by adjacent vertices.
Does trackball use two-sided lighting and fog? The TCL fallback for this case seems to be broken (playing a bit with samples/fog indicates that switching off either of them fixes the problem, though I've no idea where to look for the problem, software mesa works just fine).
Looks like that's already in the works (it was Keith's suggestion), I've submitted a ssh key yesterday :-).About keeping track of your patches: I wonder what others think about giving you write access?
Roland
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
