Do you think it will speed up game engines or do you think it's worth the effort? JFYI it isn't done yet.

If it's fast enough it could be a big speed up, allowing 2nd level culling of occluded objects on a near-pixel-perfect basis. The problem is that doing the test requires accessing a significant multiple of the number of pixels that would be drawn, which could be inefficient. Because it this it would be far more significant for distant objects in scenes where there isn't any easy way to do good occlusion (complex geometry such as terrain).

However, it should never be used as the ONLY occlusion method. If you can work out some sort of portal/antiportal system you would want to use that as a first pass, and only run the GL_HP_occlusion_test test if it passes that. You could get even fancier and figure out a way of determining that an object MIGHT be occluded (such as a trace from the camera to the center of the object) and only do the test if that says the object is occluded.

Why discuss GL_HP_occlusion_test when there is the much better GL_NV_occlusion_test already implemented in PC drivers and the newly standardized (and very similar to the NV version) GL_ARB_occlusion_test?

If what you're rendering is complex, you may be able to make significant savings through the use of such an extension. You should probably investigate data-structure-based occlusion culling before GPU-based occlusion culling however, since the former is likely to be orders of magnitude more efficient.

Oh it's complex, it's a terrain engine.

Reason is the GL_HP_occulsion_test is part of OpenGL 1.5

No, GL_ARB_occlusion_test is part of 1.5. The two extensions are not the same, and the ARB one owes much more to the NV one than to the HP one.

Also, the current generation of video cards can't support OpenGL 1.5, so I fail to see how that's relevant.

A terrain engine is scarcely what I would call "complex". "Complex" means tens of thousands of vertex- and pixel-shaded polygons. Terrain is also an ideal case for algorithmic occlusion culling, since the geometry is so simple.

Quote:Originally posted by OneSadCookie
No, GL_ARB_occlusion_test is part of 1.5. The two extensions are not the same, and the ARB one owes much more to the NV one than to the HP one.

Also, the current generation of video cards can't support OpenGL 1.5, so I fail to see how that's relevant.

A terrain engine is scarcely what I would call "complex". "Complex" means tens of thousands of vertex- and pixel-shaded polygons. Terrain is also an ideal case for algorithmic occlusion culling, since the geometry is so simple.

Well if you download the glviewer program and look up the extentsions that are part of each OpenGL version GL_HP_occlusion is a part of the 1.5 requirements.

Yes I am rendering 132k polygons each frame and they are blending with many combiner functions and soon to add in water and a skydome and lighting so yes their needs to be some sort of culling algorithm done, but I want it to not cause any image quality loss like some culling algorithms do.

Also because I am on a PC for now, PC has newer drivers usually than Mac does, and this is the only other extenstion supported by ATI 9700Pro other than GL_HP_occlusion and that is GL_NV_occlusion_query

No GL_ARB_occlusion_test

Quote:Originally posted by Mars_999
Well if you download the glviewer program and look up the extentsions that are part of each OpenGL version GL_HP_occlusion is a part of the 1.5 requirements.

If you read the 1.5 spec, it says that ARB_occlusion_query is required.

Quote:Yes I am rendering 132k polygons each frame and they are blending with many combiner functions and soon to add in water and a skydome and lighting so yes their needs to be some sort of culling algorithm done, but I want it to not cause any image quality loss like some culling algorithms do.

Culling algorithms don't cause a loss of image quality. LOD algorithms cause a loss of image quality.

Quote:Also because I am on a PC for now, PC has newer drivers usually than Mac does, and this is the only other extenstion supported by ATI 9700Pro other than GL_HP_occlusion and that is GL_NV_occlusion_query

No GL_ARB_occlusion_test

ARB_occlusion_query (not test) is too new to have found its way into drivers yet. In the mean time however, you should be using the NV version, since a) it's better and b) it's closer to the ARB version.

I feel like I'm repeating myself a bit here...

OneSadCookie Wrote:Also, the current generation of video cards can't support OpenGL 1.5, so I fail to see how that's relevant.

*cough cough*

David Wrote:someone even made a pixel shader that did this in order to add shadows to their bumpmapping

That was most likely done using horizon mapping, which has little effect on occlusion and requires significant texture memory.

[edit]Hmm... Where did David's post go?[/edit]

I realised that this thread was a year old Anyways frustum culling, limiting view distance and LOD should be the first step in fighting fps problems on a terrain, and if it still has problems, then occlusion culling could be an option.

OneSadCookie Wrote:Also, the current generation of video cards can't support OpenGL 1.5

10.3.5, released today, adds full support for OpenGL 1.5 on Radeon 9600/9700/9800.

yep, I was under the misconception that ARB_texture_non_power_of_two had been made core for 1.5. This isn't the case, and therefore 9500+ and FX can support 1.5.

EXT_shadow_funcs (promoted to core in 1.5) isn't reported by the Radeon drivers. Do you know if the functionality is actually there?

I actually reported a bug on that string not being exported. It's part of the 1.5 core though, so the functionality has to be there. The spec (sec I.2 "Promoting Extensions to Core Features") uses the word "continue" so I guess it's OK to not export it since the extension wasn't supported in 10.3.4? Mmmrrr.

Anyway, regardless if the hardware can or can not support a certain feature, it can always have a software fallback. Witness the gf4MX PC drivers with 1.5 support, with no hardware 3D textures.

I submitted the same bug, a good 10 mins after the update installed

They've asked for user feedback about this sort of thing before (EXT_separate_specular_color being the particular trigger IIRC), with the unanimous response that the extension string is very important to people.