A small but significant improvement made it's way into the occlusion queries system today. Previously the case was that hardware occlusion culling was only applied to models if their complexity was above a certain threshold (more than 96 triangles). This worked fine enough but it was always the case that simpler scenes with a low number of models used to suffer the overhead of query issue and result fetch when it might have been just as fast to just render the things. What's so special about 96 triangles anyway? Why should a gain of one single triangle make the difference? Scene complexity certainly isn't a binary factor.
The solution was to implement a dynamic threshold based on scene complexity. This uses the number of triangles actually rendered in the previous frame (more on this shortly) and scales the threshold so that if the previous frame was complex models in the current frame are more likely to have queries issued, whereas if the previous frame was simple queries are less likely.
There's a lot of "fuzz" in this; the scaling factor chosen was quite arbitrarily and the previous frame thing assumes that a scene isn't going to change too much from frame-to-frame (the occlusions system already makes use of that assumption to prevent stalling the pipeline, by the way). In practice though it works out very well, with small gains and better all-round performance levelling.
Next up I'm going to give the engine the ability to refer to the same cvar by multiple different names. This should help DirectQ coexist better with other engines.
This is getting exciting now.
Tuesday, March 16, 2010
Improvements are coming thick and fast!
Posted by
mhquake
at
5:58 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment