Am Mittwoch, 14. Januar 2004 01:09 schrieb Brian Paul: > Roland Scheidegger wrote: > > I've just had too much spare time and though it would be interesting to > > see which mesa demos/tests have problems (lighting or otherwise), so > > here are the results of all tests which did not run correctly (of course > > quite a few tests wouldn't run at all due to missing arb_fp, arb_vp or > > whatever extension, I didn't list them). > > > > cubemap: > > with hardware tcl inner sphere looks correct, outer cube has > > only blue face, the others are missing, and texture is more fuzzy (might > > be just a different lod bias?) compared to software mesa. > > tcl_mode=0 is even worse: inner sphere everything is only blue/white, > > outer cube same errors as above. > > I believe the problem is that TexCoord3 commands are only getting > their S and T coords passed to the hardware. That is, (S,T,R) > texcoords aren't a supported vertex format at this time. > > I had implemented texture cube maps and 3D textures in the R200 driver > over a year ago, but wasn't sure how to go about implementing the > TexCoord3 stuff. > > > fire: > > way too much fog is applied, the ground gets almost completely > > white. Happens with both tcl and tcl_mode=0. > > > > isosurf: > > "Reflect" looks much different with hardware tcl (only in > > polygon mode fill, polygon mode line causes a tcl fallback and thus it > > will look the same as software tcl) than with tcl_mode=0 > > (LIBGL_ALWAYS_INDIRECT looks exactly the same as tcl_mode=0). Can't > > really say which one is correct though, the overall impression is still > > the same, it's just as if the colors are somehow reversed... > > > > pointblast: > > (both with hardware tcl and without) the points are almost > > invisible. IIRC this was already mentioned some time ago to be because > > all points are drawn with size 1 only. > > > > stex3d: > > the 3d texture fallback seems to be very slow. software mesa > > seems to run about 2-3 times faster than hardware acceleration using the > > fallback. > > Not sure about that, but the TexCoord3 issue would also apply here.
Can you verify the "clipping bug" (with r200) when you move the window to the right and below side/corner? It is still there for months. See below. > > occlude: > > GL_HP_occlusion_test is not supported in r200 driver, though I believe > > the hardware should be able to support it (ATI supports this extension > > in their driver). > > > > fogcoord: > > doesn't work correctly with software mesa, all squares are white (test > > says should be white -> gray -> black) > > GL_EXT_fog_coord is not implemented in r200 driver. Both the XiG and ATI > > driver support this in their driver, so I guess the hardware should > > support it too. > > It seems OK w/ stand-alone Mesa. When you say software mesa, do you > mean LIBGL_ALWAYS_INDIRECT? If so, it might be a client/server-side > GLX bug. > > > projtex: > > (both with tcl and tcl_mode=0) the projected texture coordinates are > > obviously wrong, the size of the projected texture doesn't even seem to > > depend on where the projection ray hits the object (both projected > > textures on the cube seem to have the same size). > > > > seccolor: > > works with hardware acceleration (with or without software tcl), but not > > correctly with software mesa (all squares are red). > > Same story as for fogcoord. > > > stencilwrap: > > fails all tests (with or without hardware tcl), always getting 0 or 255, > > software mesa works correctly. > > > > yuvrect: > > texture has pink tint (both with or without tcl), works ok with software > > mesa. > > > > yuvsqure: > > same problem as with yuvrect (only the left texture, the right one is > > correct). > > > > Quite a few things to fix :-( > > (cvs version from sometime 1-2 days ago, with Michel's latest lighting > > fix applied). > > > > Roland > > -Brian -- Dieter Nützel @home: <Dieter.Nuetzel () hamburg ! de>
<<attachment: stex3d-clipping-bug.png>>
