Roland Scheidegger wrote: > Brian Paul wrote: > >>Roland Scheidegger wrote: >> >>>Currently, fog in vertex programs doesn't work when using >>>per-vertex fog, since the fog factor computation is not done in the >>>tnl pipeline. I think the most elegant solution to this problem >>>would be to just move the (slightly changed) fog pipeline stage to >>>after the various vertex prog extensions. Is it safe to move >>>pipeline stages around? I think it should be as long as a stage >>>doesn't need the output of another one. It seems to work (only >>>tested with arb_vp), but I might miss some pitfalls... (obviously, >>>hw drivers using their own pipelines would need to change the order >>>too). >> >>There's no requirement that OpenGL implement per-vertex fog. >>Ideally, it would always be done per-fragment, so that it properly >>modifies the post-texture color. > > Yes, but there is no requirement that an implementation must support > per-fragment fog neither. Most Mesa-based hw drivers do not seem to > support per-fragment fog (though I don't know how many of them could). > > >>Per-vertex fog (triggered by glHint(GL_FASTEST/GL_DONT_CARE)) was >>intended as a way to allow a faster/less-accurate fog effect on >>slower hardware/software. >> >>If the R200 supports per-pixel fog, is there any reason why we don't >> want to use it all the time? > > Well, r200/radeon support per-pixel fog - kinda. It is table-based. I > actually tried to make it work but hit some roadblocks. Basically, you > precalculate the fog factors for the 256-entry table and upload that > (whenever you change fog mode, density etc. you need a new table). But > there were mainly 2 problems. First, when using FRAGMENT_DEPTH as fog > coord source, it just didn't work always (some of mesa's various fog > tests worked, other didn't) - not sure though why, I didn't investigate > it any further due to the second problem. It is impossible to make this > scheme really work with FOG_COORD_SRC, as the fogcoord is unfortunately > not a clamped value - building the precalculated fog table really only > works if you know the range of the fog coord values. In short, I think > this feature of the chip is useless for opengl - might work better in > d3d (note that fglrx doesn't use it neither - at least not by default, > didn't try the fog hint).
OK, thanks for the info. > In any case, the tnl pipeline needs to be fixed for the drivers not > allowing per-fragment fog. I was looking at the code in r200_vertprog.c that appends the instructions for the three fog modes. I'm wondering if it would be better to add a new function to src/mesa/shader/programopt.c to add the extra fog instructions to a vertex program before its compiled into the r200 code. The idea being code re-use and driver simplification. Though, I haven't looked at things close enough yet to know if that has any pitfalls. -Brian ------------------------------------------------------------------------- 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
