Surface subdivision - I’m not 100% convinced that this should be hidden inside the API layer, as the application will very often need access to the subdivided geometry for patch stitching, collision detection etc. I know the Id folks had a lot of problems with this during the development of Q3A, and I suspect hiding the implementation would just compound the problem.
Programmable shading is due out this year in hardware (PixelFusion), will be accessible via extensions. I agree though, given the snail’s pace at which the ARB works, it’d be nice to get this in the spec even though it won’t have widespread hardware support for another couple of years.
Displacement mapping is a knotty one. It’d be extremely cool, yes, but I can’t see how things like frustrum clipping or backface culling are going to work when bits of a surface can stick out from the plane defined by the poly verts.
Displacement mapping, but I can’t see how things like frustrum clipping or backface culling are going to work when bits of a surface can stick out from the plane defined by the poly verts.
I was actually thinking of moving the poly verts. So the cull is the same as long as it is after the mapping. Only really useful on V.highly tessalated models though.
I’m just trying to think how we move GL on to the next gen.
about programmable shading… i was thinking about it some months ago… but how deep can be the control over such a low level process?
how can it be faster?
the really question is: where i can find thecnical infos about this issue?