Michael wrote: > > Ok, I've found a couple of problems going through the glut demos but I'm > a bit stuck which direction to move to fix them and thought someone > brighter might give me a pointer. > > Both problems have similar symptoms. The example here is underwater.c. > > Scenario 1. vertices are rendered in 2 passes. > > Pass 1 has lighting and texturing enabled. _NeedEyeCoords is true and > the vertices are transformed using separate Model / Projection matrices. > > Pass 2 has lighting disabled hence vertices are transformed using the > combined Model/projection matrix. > > Problem : z values are slightly different (see attached file) and this > causes artifacts on the rendered surface (proved by hacking both paths > to use seperate model / project matrices)
My solution to this would be to always produce Clip coordinates from Model coordinates using the ModelProject matrix, rather than the current situation where they are computed in two steps (Model->Eye, Eye->Clip) if _NeedEyeCoords is true. This would require changes to Mesa/src/tnl/t_vb_vertex.c and Mesa/src/state.c to keep ModelProject uptodate all the time. > Scenario 2. vertices again rendered in 2 passes. > > Pass 1 has no texturing, hence _NeedProjectCoords is true > (TINY_VERTEX_FORMAT) and the vertices are sent to the hardware (radeon) > pre 1/w. Pass 2 enables texturing and the vertices are sent via > emit_wgt0 for the hardware to do the divide. > > Same / similar symptoms which leads me to believe similar problems with > z-values (again, forcing the same path "fixes" the problem) > > That said, a 16-bit Z buffer reduces the problem and I've seen other > programs (RTCW) that exhibit problems with the z-buffer (when running > with a driver that has problem 1 hacked around by using separate > matrices for both paths and with things that are textured, so not > problem 2 afaict - making me think it's either another different path > issue or this is just an over sensitive z buffer?) > > So does the z-buffer zscale / zoffset need tweaking or does it always need > to do hw divide? This one I'm not sure how to fix, but it's conceivable that you can get different results via the two different paths. First of all the cop-out answer: opengl doesn't require that we get exactly the same results in these two cases - certainly it's desirable, but the specification specifically allows these types of variances. Secondly, we need to investigate the software path - is unwanted additional precision somehow sneaking in? It's often appealing to allow GLdouble intermediate values for calculations, but it can lead to exactly this sort of problem. At the moment we go to some effort to keep extra bits out of our computations: we put the x87 fpu into a mode where bits beyond 32 are abandoned, and where I've seen GLdouble intermediates used, I've replaced them with floats. (An alternative would be to use doubles everywhere, but consistency is required either way). I think some investigation of the demo is required to see if it is expecting something unreasonable or not. Keith _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
