| Name |
| |
| NV_occlusion_query |
| |
| Name Strings |
| |
| GL_NV_occlusion_query |
| |
| Contact |
| |
| Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright NVIDIA Corporation, 2001, 2002. |
| |
| IP Status |
| |
| NVIDIA Proprietary. |
| |
| Status |
| |
| Shipping (version 1.0) |
| |
| Version |
| |
| NVIDIA Date: February 6, 2002 (version 1.0) |
| |
| Number |
| |
| 261 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 1.3 specification. |
| |
| Requires support for the HP_occlusion_test extension. |
| |
| Overview |
| |
| The HP_occlusion_test extension defines a mechanism whereby an |
| application can query the visibility of an object, where "visible" |
| means that at least one pixel passes the depth and stencil tests. |
| |
| The HP extension has two major shortcomings. |
| |
| - It returns the result as a simple GL_TRUE/GL_FALSE result, when in |
| fact it is often useful to know exactly how many pixels passed. |
| - It provides only a simple "stop-and-wait" model for using multiple |
| queries. The application begins an occlusion test and ends it; |
| then, at some later point, it asks for the result, at which point |
| the driver must stop and wait until the result from the previous |
| test is back before the application can even begin the next one. |
| This is a very simple model, but its performance is mediocre when |
| an application wishes to perform many queries, and it eliminates |
| most of the opportunites for parallelism between the CPU and GPU. |
| |
| This extension solves both of those problems. It returns as its |
| result the number of pixels that pass, and it provides an interface |
| conceptually similar to that of NV_fence that allows applications to |
| issue many occlusion queries before asking for the result of any one. |
| As a result, they can overlap the time it takes for the occlusion |
| query results to be returned with other, more useful work, such as |
| rendering other parts of the scene or performing other computations |
| on the CPU. |
| |
| There are many situations where a pixel count, rather than a boolean |
| result, is useful. |
| |
| - If the visibility test is an object bounding box being used to |
| decide whether to skip the object, sometimes it can be acceptable, |
| and beneficial to performance, to skip an object if less than some |
| threshold number of pixels could be visible. |
| - Knowing the number of pixels visible in the bounding box may also |
| help decide what level of detail a model should be drawn with. If |
| only a few pixels are visible, a low-detail model may be |
| acceptable. In general, this allows level-of-detail mechanisms to |
| be slightly less ad hoc. |
| - "Depth peeling" techniques, such as order-independent transparency, |
| would typically like to know when to stop rendering more layers; it |
| is difficult to come up with a way to determine a priori how many |
| layers to use. A boolean count allows applications to stop when |
| more layers will not affect the image at all, but this will likely |
| be unacceptable for performance, with minimal gains to image |
| quality. Instead, it makes more sense to stop rendering when the |
| number of pixels goes below a threshold; this should provide better |
| results than any of these other algorithms. |
| - Occlusion queries can be used as a replacement for glReadPixels of |
| the depth buffer to determine whether, say, a light source is |
| visible for the purposes of a lens flare effect or a halo to |
| simulate glare. Pixel counts allow you to compute the percentage |
| of the light source that is visible, and the brightness of these |
| effects can be modulated accordingly. |
| |
| Issues |
| |
| * Should we use an object-based interface? |
| |
| RESOLVED: Yes, this makes the interface much simpler, and it is |
| friendly for indirect rendering. |
| |
| * Should we offer an entry point analogous to glTestFenceNV? |
| |
| RESOLVED: No, it is sufficient to have glGetOcclusionQueryivNV |
| provide a query for whether the occlusion query result is back |
| yet. Whereas it is interesting to poll fence objects, it is |
| relatively less interesting to poll occlusion queries. |
| |
| * Is glGetOcclusionQueryuivNV necessary? |
| |
| RESOLVED: Yes, it makes using a 32-bit pixel count less painful. |
| |
| * Should there be a limit on how many queries can be outstanding? |
| |
| RESOLVED: No. This would make the extension much more |
| difficult to spec and use. Allowing this does not add any |
| significant implementation burden; and even if drivers have some |
| internal limit on the number of outstanding queries, it is not |
| expected that applications will need to know this to achieve |
| optimal or near-optimal performance. |
| |
| * What happens if glBeginOcclusionQueryNV is called when an |
| occlusion query is already outstanding for a different object? |
| |
| RESOLVED: This is a GL_INVALID_OPERATION error. |
| |
| * What happens if HP_occlusion_test and NV_occlusion_query usage is |
| overlapped? |
| |
| RESOLVED: The two can be overlapped safely. Counting is enabled |
| if we are _either_ inside a glBeginOcclusionQueryNV or if |
| if GL_OCCLUSION_TEST_HP is enabled. The alternative (producing |
| an error) does not work -- it would require that glPopAttrib be |
| capable of producing an error, which would be rather problematic. |
| |
| Note that glBeginOcclusionQueryNV, not glEndOcclusionQueryNV, |
| resets the pixel counter and occlusion test result. This can |
| avoid certain types of strange behavior where an occlusion |
| query's pixel count does not always correspond to the pixels |
| rendered during the occlusion query. The spec would make sense |
| the other way, but the behavior would be strange. |
| |
| * Does EndOcclusionQuery need to take any parameters? |
| |
| RESOLVED: No. Giving it, for example, an "id" parameter would |
| be redundant -- adding complexity for no benefit. Only one query |
| can be active at a time. |
| |
| * How many bits should we require the pixel counter to be, at |
| minimum? |
| |
| RESOLVED: 24. 24 is enough to handle 8.7 full overdraws of a |
| 1600x1200 window. That seems quite sufficient. |
| |
| * What should we do about overflows? |
| |
| RESOLVED: Overflows leave the pixel count undefined. Saturating |
| is recommended but not required. |
| |
| The ideal behavior really is to saturate. This ensures that you |
| always get a "large" result when you render many pixels. It also |
| ensures that apps which want a boolean test can do one on their |
| own, and not worry about the rare case where the result ends up |
| exactly at zero from wrapping. |
| |
| That being said, with 24 bits of pixel count required, it's not |
| clear that this really matters. It's better to be a bit |
| permissive here. In addition, even if saturation was required, |
| the goal of having strictly defined behavior is still not really |
| met. |
| |
| Applications don't (or at least shouldn't) check for some _exact_ |
| number of bits. Imagine if a multitextured app had been written |
| that required that the number of texture units supported be |
| _exactly_ two! Implementors of OpenGL would be greatly annoyed |
| to find that the app did not run on, say, three-texture or four- |
| texture hardware. |
| |
| So, we expect apps here to always be doing a "greater than or |
| equal to" check. An app might check for, say, at least 28 bits. |
| This doesn't ensure defined behavior -- it only ensures that once |
| an overflow occurs (which may happen at any power of two), that |
| overflow will be handled with saturation. This behavior still |
| remains sufficiently unpredictable that the reasons for defining |
| behavior in even rarely-used cases (preventing compatibility |
| problems, for example) are unsatisfied. |
| |
| All that having been said, saturation is still explicitly |
| recommended in the spec language. |
| |
| * What is the interaction with multisample, which was not defined |
| in the original spec? |
| |
| RESOLVED: The pixel count is the number of samples that pass, not |
| the number of pixels. This is true even if GL_MULTISAMPLE is |
| disabled but GL_SAMPLE_BUFFERS is 1. Note that the depth/stencil |
| test optimization whereby implementations may choose to depth |
| test at only one of the samples when GL_MULTISAMPLE is disabled |
| does not cause this to become ill-specified, because we are |
| counting the number of samples that are still alive _after_ the |
| depth test stage. The mechanism used to decide whether to kill |
| or keep those samples is not relevant. |
| |
| * Exactly what stage are we counting at? The original spec said |
| depth test; what does stencil test do? |
| |
| RESOLVED: We are counting immediately after _both_ the depth and |
| stencil tests, i.e., pixels that pass both. This was the |
| original spec's intent. Note that the depth test comes after the |
| stencil test, so to say that it is the number that pass the depth |
| test is reasonable; though it is often helpful to think of the |
| depth and stencil tests as being combined, because the depth test |
| result impacts the stencil operation used. |
| |
| * Is it guaranteed that occlusion queries return in order? |
| |
| RESOLVED: Yes. It makes sense to do this. If occlusion test X |
| occurred before occlusion query Y, and the driver informs the app |
| that occlusion query Y is done, the app can infer that occlusion |
| query X is also done. For applications that do poll, this allows |
| them to do so with less effort. |
| |
| * Will polling an occlusion query without a glFlush possibly cause |
| an infinite loop? |
| |
| RESOLVED: Yes, this is a risk. If you ask for the result, |
| however, any flush required will be done automatically. It is |
| only when you are polling that this is a problem because there is |
| no guarantee that a flush has occured in the time since |
| glEndOcclusionQueryNV, and the spec is written to say that the |
| result is only "available" if the value could be returned |
| _instantaneously_. |
| |
| This is different from NV_fence, where FinishFenceNV can cause an |
| app hang, and where TestFenceNV was also not guaranteed to ever |
| finish. |
| |
| There need not be any spec language to describe this behavior |
| because it is implied by what is already said. |
| |
| In short, if you use GL_PIXEL_COUNT_AVAILABLE_NV, you _must_ use |
| glFlush, or your app may hang. |
| |
| * The HP_occlusion_test specs did not contain the spec edits that |
| explain the exact way the extension works. Should this spec fill |
| in those details? |
| |
| RESOLVED: Yes. These two extensions are intertwined in so many |
| important ways that doing so is not optional. |
| |
| * Should there be a "target" parameter to BeginOcclusionQuery? |
| |
| RESOLVED: No. We're not trying to solve the problem of "query |
| anything" here. |
| |
| * What might an application that uses this extension look like? |
| |
| Here is some rough sample code: |
| |
| GLuint occlusionQueries[N]; |
| GLuint pixelCount; |
| |
| glGenOcclusionQueriesNV(N, occlusionQueries); |
| ... |
| // before this point, render major occluders |
| glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE); |
| glDepthMask(GL_FALSE); |
| // also disable texturing and any fancy shading features |
| for (i = 0; i < N; i++) { |
| glBeginOcclusionQueryNV(occlusionQueries[i]); |
| // render bounding box for object i |
| glEndOcclusionQueryNV(); |
| } |
| // at this point, if possible, go and do some other computation |
| glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); |
| glDepthMask(GL_TRUE); |
| // reenable other state |
| for (i = 0; i < N; i++) { |
| glGetOcclusionQueryuivNV(occlusionQueries[i], GL_PIXEL_COUNT_NV, |
| &pixelCount); |
| if (pixelCount > 0) { |
| // render object i |
| } |
| } |
| |
| * Is this extension useful for saving geometry, fill rate, or both? |
| |
| It is expected that it will be most useful for saving geometry |
| work, because for the cost of rendering a bounding box you can |
| save rendering a normal object. |
| |
| It is possible for this extension to help in fill-limited |
| situations, but using it may also hurt performance in such |
| situations, because rendering the pixels of a bounding box is |
| hardly free. In most situations a bounding box will probably |
| have more pixels than the original object. |
| |
| One exception is that for objects rendered with multiple passes, |
| the first pass can be wrapped with an occlusion query almost for |
| free. That is, render the first pass for all objects in the |
| scene, and get the number of pixels rendered on each object. If |
| zero pixels were rendered for an object, you can skip subsequent |
| rendering passes. This trick can be very useful in many cases. |
| |
| * What can be said about guaranteeing correctness when using |
| occlusion queries, especially as it relates to invariance? |
| |
| Invariance is critical to guarantee the correctness of occlusion |
| queries. If occlusion queries go through a different code path |
| than standard rendering, the pixels rendered may be different. |
| |
| However, the invariance issues are difficult at best to solve. |
| Because of the vagaries of floating-point precision, it is |
| difficult to guarantee that rendering a bounding box will render |
| at least as many pixels with equal or smaller Z values than the |
| object itself would have rendered. |
| |
| Likewise, many other aspects of rendering state tend to be |
| different when performing an occlusion query. Color and depth |
| writes are typically disabled, as are texturing, vertex programs, |
| and any fancy per-pixel math. So unless all these features have |
| guarantees of invariance themselves (unlikely at best), requiring |
| invariance for NV_occlusion_query would be futile. |
| |
| For what it's worth, NVIDIA's implementation is fully invariant |
| with respect to whether an occlusion query is active; that is, it |
| does not affect the operation of any other stage of the pipeline. |
| (When occlusion queries are being emulated on hardware that does |
| not support them, via the emulation registry keys, using an |
| occlusion query produces a software rasteriation fallback, and in |
| such cases invariance cannot be guaranteed.) |
| |
| Another problem that can threaten correctness is near and far |
| clipping. If the bounding box penetrates the near clip plane, |
| for example, it may be clipped away, reducing the number of |
| pixels counted, when in fact the original object may have stayed |
| entirely beyond the near clip plane. Whenever you design an |
| algorithm using occlusion queries, it is best to be careful about |
| the near and far clip planes. |
| |
| * How can frame-to-frame coherency help applications using this |
| extension get even higher performance? |
| |
| Usually, if an object is visible one frame, it will be visible |
| the next frame, and if it is not visible, it will not be visible |
| the next frame. |
| |
| Of course, for most applications, "usually" isn't good enough. |
| It is undesirable, but acceptable, to render an object that |
| wasn't visible, because that only costs performance. It is |
| generally unacceptable to not render an object that was visible. |
| |
| The simplest approach is that visible objects should be checked |
| every N frames (where, say, N=5) to see if they have become |
| occluded, while objects that were occluded last frame must be |
| rechecked again in the current frame to guarantee that they are |
| still occluded. This will reduce the number of wasteful |
| occlusion queries by a factor of almost N. |
| |
| It may also pay to do a raycast on the CPU in order to try to |
| prove that an object is visible. After all, occlusion queries |
| are only one of many items in your bag of tricks to decide |
| whether objects are visible or invisible. They are not an excuse |
| to skip frustum culling, or precomputing visibility using portals |
| for static environments, or other standard visibility techniques. |
| |
| In general, though, taking advantage of frame-to-frame coherency |
| in your occlusion query code is absolutely essential to getting |
| the best possible performance. |
| |
| New Procedures and Functions |
| |
| void GenOcclusionQueriesNV(sizei n, uint *ids); |
| void DeleteOcclusionQueriesNV(sizei n, const uint *ids); |
| boolean IsOcclusionQueryNV(uint id); |
| void BeginOcclusionQueryNV(uint id); |
| void EndOcclusionQueryNV(void); |
| void GetOcclusionQueryivNV(uint id, enum pname, int *params); |
| void GetOcclusionQueryuivNV(uint id, enum pname, uint *params); |
| |
| New Tokens |
| |
| Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, |
| and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, |
| and GetDoublev: |
| |
| OCCLUSION_TEST_HP 0x8165 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| OCCLUSION_TEST_RESULT_HP 0x8166 |
| PIXEL_COUNTER_BITS_NV 0x8864 |
| CURRENT_OCCLUSION_QUERY_ID_NV 0x8865 |
| |
| Accepted by the <pname> parameter of GetOcclusionQueryivNV and |
| GetOcclusionQueryuivNV: |
| |
| PIXEL_COUNT_NV 0x8866 |
| PIXEL_COUNT_AVAILABLE_NV 0x8867 |
| |
| Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) |
| |
| None. |
| |
| Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) |
| |
| None. |
| |
| Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| Add a new section "Occlusion Tests and Queries" between sections |
| 4.1.6 and 4.1.7: |
| |
| "4.1.6A Occlusion Tests and Queries |
| |
| Occlusion testing keeps track of whether any pixels have passed the |
| depth test. Such testing is enabled or disabled with the generic |
| Enable and Disable commands using the symbolic constant |
| OCCLUSION_TEST_HP. The occlusion test result is initially FALSE. |
| |
| Occlusion queries can be used to track the exact number of fragments |
| that pass the depth test. Occlusion queries are associated with |
| occlusion query objects. The command |
| |
| void GenOcclusionQueriesNV(sizei n, uint *ids); |
| |
| returns n previously unused occlusion query names in ids. These |
| names are marked as used, but no object is associated with them until |
| the first time BeginOcclusionQueryNV is called on them. Occlusion |
| queries contain one piece of state, a pixel count result. This pixel |
| count result is initialized to zero when the object is created. |
| |
| Occlusion queries are deleted by calling |
| |
| void DeleteOcclusionQueriesNV(sizei n, const uint *ids); |
| |
| ids contains n names of occlusion queries to be deleted. After an |
| occlusion query is deleted, its name is again unused. Unused names |
| in ids are silently ignored. |
| |
| An occlusion query can be started and finished by calling |
| |
| void BeginOcclusionQueryNV(uint id); |
| void EndOcclusionQueryNV(void); |
| |
| If BeginOcclusionQueryNV is called with an unused id, that id is |
| marked as used and associated with a new occlusion query object. If |
| it is called while another occlusion query is active, an |
| INVALID_OPERATION error is generated. If EndOcclusionQueryNV is |
| called while no occlusion query is active, an INVALID_OPERATION error |
| is generated. Calling either GenOCclusionQueriesNV or |
| DeleteOcclusionQueriesNV while an occlusion query is active causes an |
| INVALID_OPERATION error to be generated. |
| |
| When EndOcclusionQueryNV is called, the current pixel counter is |
| copied into the active occlusion query object's pixel count result. |
| BeginOcclusionQueryNV resets the pixel counter to zero and the |
| occlusion test result to FALSE. |
| |
| Whenever a fragment reaches this stage and OCCLUSION_TEST_HP is |
| enabled or an occlusion query is active, the occlusion test result is |
| set to TRUE and the pixel counter is incremented. If the value of |
| SAMPLE_BUFFERS is 1, then the pixel counter is incremented by the |
| number of samples whose coverage bit is set; otherwise, it is always |
| incremented by one. If it the pixel counter overflows, i.e., exceeds |
| the value 2^PIXEL_COUNTER_BITS_NV-1, its value becomes undefined. |
| It is recommended, but not required, that implementations handle this |
| overflow case by saturating at 2^PIXEL_COUNTER_BITS_NV-1 and |
| incrementing no further. |
| |
| The necessary state is a single bit indicating whether the occlusion |
| test is enabled, a single bit indicating whether an occlusion query |
| is active, the identifier of the currently active occlusion query, a |
| counter of no smaller than 24 bits keeping track of the pixel count, |
| and a single bit indicating the occlusion test result." |
| |
| Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) |
| |
| Add to the end of Section 5.4 "Display Lists": |
| |
| "DeleteOcclusionQueriesNV, GenOcclusionQueriesNV, IsOcclusionQueryNV, |
| GetOcclusionQueryivNV, and GetOcclusionQueryuivNV are not complied |
| into display lists but are executed immediately." |
| |
| Additions to Chapter 6 of the OpenGL 1.3 Specification (State and |
| State Requests) |
| |
| Add a new section 6.1.13 "Occlusion Test and Occlusion Queries": |
| |
| "The occlusion test result can be queried using GetBooleanv, |
| GetIntegerv, GetFloatv, or GetDoublev with a <pname> of |
| OCCLUSION_TEST_RESULT_HP. Whenever such a query is performed, the |
| occlusion test result is reset to FALSE and the pixel counter is |
| reset to zero as a side effect. |
| |
| Which occlusion query is active can be queried using GetBooleanv, |
| GetIntegerv, GetFloatv, or GetDoublev with a <pname> of |
| CURRENT_OCCLUSION_QUERY_ID_NV. This query returns the name of the |
| currently active occlusion query if one is active, and zero |
| otherwise. |
| |
| The state of an occlusion query can be queried with the commands |
| |
| void GetOcclusionQueryivNV(uint id, enum pname, int *params); |
| void GetOcclusionQueryuivNV(uint id, enum pname, uint *params); |
| |
| If the occlusion query object named by id is currently active, then |
| an INVALID_OPERATION error is generated. |
| |
| If <pname> is PIXEL_COUNT_NV, then the occlusion query's pixel count |
| result is placed in params. |
| |
| Often, occlusion query results will be returned asychronously with |
| respect to the host processor's operation. As a result, sometimes, |
| if a pixel count is queried, the host must wait until the result is |
| back. If <pname> is PIXEL_COUNT_AVAILABLE_NV, the value placed in |
| params indicates whether or not such a wait would occur if the pixel |
| count for that occlusion query were to be queried presently. A |
| result of TRUE means no wait would be required; a result of FALSE |
| means that some wait would occur. The length of this wait is |
| potentially unbounded. It must always be true that if the result for |
| one occlusion query is available, the result for all previous |
| occlusion queries must also be available at that point in time." |
| |
| GLX Protocol |
| |
| Seven new GL commands are added. |
| |
| The following two rendering commands are sent to the server as part |
| of a glXRender request: |
| |
| BeginOcclusionQueryNV |
| 2 8 rendering command length |
| 2 ???? rendering command opcode |
| 4 CARD32 id |
| |
| EndOcclusionQueryNV |
| 2 4 rendering command length |
| 2 ???? rendering command opcode |
| |
| The remaining fivecommands are non-rendering commands. These |
| commands are sent separately (i.e., not as part of a glXRender or |
| glXRenderLarge request), using the glXVendorPrivateWithReply |
| request: |
| |
| DeleteOcclusionQueriesNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 4+n request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 n |
| n*4 LISTofCARD32 ids |
| |
| GenOcclusionQueriesNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 4 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 n |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 n reply length |
| 24 unused |
| n*4 LISTofCARD322 queries |
| |
| IsOcclusionQueryNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 4 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 CARD32 id |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 0 reply length |
| 4 BOOL32 return value |
| 20 unused |
| 1 1 reply |
| |
| GetOcclusionQueryivNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 CARD32 id |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 INT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofINT32 params |
| |
| GetOcclusionQueryuivNV |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 ???? vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 CARD32 id |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 CARD32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofCARD32 params |
| |
| Errors |
| |
| The error INVALID_VALUE is generated if GenOcclusionQueriesNV is |
| called where n is negative. |
| |
| The error INVALID_VALUE is generated if DeleteOcclusionQueriesNV is |
| called where n is negative. |
| |
| The error INVALID_OPERATION is generated if GenOcclusionQueriesNV or |
| DeleteOcclusionQueriesNV is called when an occlusion query is active. |
| |
| The error INVALID_OPERATION is generated if BeginOcclusionQueryNV is |
| called when an occlusion query is already active. |
| |
| The error INVALID_OPERATION is generated if EndOcclusionQueryNV is |
| called when an occlusion query is not active. |
| |
| The error INVALID_OPERATION is generated if GetOcclusionQueryivNV or |
| GetOcclusionQueryuivNV is called where id is not the name of an |
| occlusion query. |
| |
| The error INVALID_OPERATION is generated if GetOcclusionQueryivNV or |
| GetOcclusionQueryuivNV is called where id is the name of the |
| currently active occlusion query. |
| |
| The error INVALID_ENUM is generated if GetOcclusionQueryivNV or |
| GetOcclusionQueryuivNV is called where pname is not either |
| PIXEL_COUNT_NV or PIXEL_COUNT_AVAILABLE_NV. |
| |
| The error INVALID_OPERATION is generated if any of the commands |
| defined in this extension is executed between the execution of Begin |
| and the corresponding execution of End. |
| |
| New State |
| |
| (table 6.18, p. 226) |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| --------- ---- ----------- ------------- ----------- ------ --------- |
| OCCLUSION_TEST_HP B IsEnabled FALSE occlusion test enable 4.1.6A enable |
| OCCLUSION_TEST_RESULT_HP B GetBooleanv FALSE occlusion test result 4.1.6A - |
| - B GetBooleanv FALSE occlusion query active 4.1.6A - |
| CURRENT_OCCLUSION_QUERY_ID_NV Z+ GetIntegerv 0 occlusion query ID 4.1.6A - |
| - Z+ - 0 pixel counter 4.1.6A - |
| |
| New Implementation Dependent State |
| |
| (table 6.29, p. 237) Add the following entry: |
| |
| Get Value Type Get Command Minimum Value Description Sec Attribute |
| -------------------------- ---- ----------- ------------- ---------------- ------ -------------- |
| PIXEL_COUNTER_BITS_NV Z+ GetIntegerv 24 Number of bits in 6.1.13 - |
| pixel counters |
| |
| Revision History |
| |
| none yet |