Brian Paul wrote: >> This is a nice idea (note that the t_vp_build.c code adds its own >> fog factor computation too). I think the main drawbacks would be >> that you couldn't really optimize it for a given hw target. For >> example, the code in t_vp_build.c does clamping (for GL_LINEAR fog) >> which just doesn't seem to be necessary on r200 as it seems to get >> clamped later anyway. It would be hard to optimize that away >> later. Similar, you'd need to use an additional constant and the >> POW opcode since there's no exponentiation with base e opcode >> (which might be faster on r200). > > We could easily add a new, internal opcode for that which wouldn't be > otherwise exposed. It wouldn't solve the other (clamping) optimization issues. But yes I guess that would be a small prize to pay.
>> The code in programopt.c also would need to be changed to allow >> modification of the program, as the fog mode may change (though I >> guess that would be rare in practice). Might be easier to just >> reparse the program string maybe. > > We could append the extra fog instructions to a temporary copy of the > program, then discard it after the r200 program is generated. Or > generate a second program with nothing but the fog code, translate to > r200 instructions, then append it. Or something like that. Copying to a temporary program would probably be the most easy way of doing that. > >> Though now that I'm looking at that tnl fog code again, is that >> absolute value of the input for GL_EXP fog actually correct (both >> in t_vp_build.c and t_vb_fog.c)? It seems like it would be needed >> if the fog coord source is FRAGMENT_DEPTH, but I'm not sure about >> FOG_COORD_SRC. Well the spec says "Q: Should the fog coordinate be >> restricted to non-negative values? A: Perhaps" (!?!) If it's not >> restricted, then using fabs surely won't produce the intended >> result. > > The OpenGL spec says that the Z value which is plugged into the fog > expression is the _distance_ to the eye at (0,0,0,1) and may be > implemented as |Ze| (where Ze is the eye coordinate Z value) rather > than sqrt(Xe^2 + Ye^2 + Ze^2) which would be more realistic. It's > supposed to be positive. Yes, but this applies only to the FRAGMENT_DEPTH coordinate source, not FOG_COORD as far as I read that, and the spec only says it's the "interpolated value of the fog coord" in that case (that "Perhaps" quote above was from the EXT_fogcoord specification). > I've actually tested and verified that other OpenGL drivers use the > absolute value. Well I guess if other drivers do this just the same even for FOG_COORD, then that's safe to do :-). Roland ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
