I think it’s silly to have to implement a software-based buffer for something that is already (mostly) being done in hardware.
The idea would be that you set an array (similar to ‘vertex array’) with simplified geometry, and use the standard arrays for your detailed representation. When the occlusion array is assigned, its data is pulled (or is could be triggered via an ‘enable’ like lights are). Data will be pulled from standard arrays based on whether the depth test would have passed for the occlusion geometry or not.
If the occlusion geometry fails the depth test, the ‘standard’ arrays aren’t touched.
This approach does not require the programmer to know the results of the test, so it does not require the much dreaded ‘round trip’. It is transparent to current implementations, requires at most two new tokens (one for the buffer in ‘enableclientstate’ and one for the test in ‘enable’) and could be adapted to VAR with little effort…
Opinions?
– Jeff
[This message has been edited by Thaellin (edited 04-23-2001).]
How would that fit in with immediate calls (glBegin/glEnd)? Would that be, if the “simplified” geometry rendering failed the depth test, to simply ignore these calls ? It surely would be transparent to the user but, isn’t it faster to have this “round trip”? You’re breaking the pipeline but on the other hand the user can simply skip these useless OpenGL calls that will be ignored.
I had not given sufficient thought to immediate mode.
I’ve thought about this a while and the most consistent method I can come up with so far is to provide a new set of primitive tokens (‘occlusion’ versions of the current set) and possibly encase the complex geometry in a new version of begin/end… It starts to resemble a far higher-order system than OpenGL is meant to present, though.
As for the round trip, I’d been told by driver developers and/or read on these forums and usenet that a round-trip OpenGL call involved an ‘unacceptable’ amount of overhead.
The problem I’m trying to work with is that a hardware-based occlusion test is not available, though the components necessary to support it are in place. A software-based solution means I have to duplicate the transformation operations and keep a software depth-buffer… it’s a lot of extra code for a slower solution than what should be available.
I’d really like to see this happen. We just need some details (and a vendor who wants to implement it, of course).