José Fonseca wrote: > > I finally figured out what I was doing wrong when attempting to do > premultiply the tex coords. Unfortunately I was making a lot of mistakes > (such as remultiplying in reused vertices on primitive drawing functions, > igoring the coordinate pointer increment in _vbtmp.h so effectively > reading the homogeneous coord from the vertex ahead, and forgetting the > vertex interpolation for clipping) which took me a bunch of time to > debug... > > In the end I come up to the conclusion that this is neither one is the way > to do it: > > - Premultipling in the _emit function is not enough because clipping is > made after. Even if we premultiply the interpolation result during > clipping this doesn't give the correct results since we are interpolating > with the w values in there. To give the right results we would have to > divide by w, make the interpolation, and multiply again... which obviously > is not efficient.
This is what the tdfx driver does. (see tdfx_vbtmp.h...) I think it's the lesser of two evils. > - Doing this on the primitive drawing functions also leads to unnecessary > work duplication as for each reused vertex we make the same exact > calculation. And it makes it hard to do the '_render.c' optimizations. (Although they probably won't apply to mach64 anyway) > One way would be make a premultiplication pass between the vertex buffer > emition/clipping and the primitive drawing. The temporary clipped vertices don't hang around for long. This won't work unless you change that. > Nevertheless, care must be > taken with the hybrid callbacks (mach64_callback_point/line/tri), since > they wouldn't expect the vertexes with the tex coords premultiplied. I > think that since the software callbacks would be so slow compared with the > hw ones, the best would be simply undo the multiplication before feeding > the vertexes to these functions, which would be barely noticed. > > Any ideas? I think the best approach is the one in tdfx_vbtmp.h -- multiply in emit(), do extra work in interpolate(). Keith _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
