Archived

This topic is now archived and is closed to further replies.

duhroach

Chooseing Occluers

Recommended Posts

Hey all, Been messing around with HOM culling for Occlusion Culling, and one of the only things messing with me is how to choose occluers. Below is the code i've mimed up, any advice would be verry helpful. thanks
  
double covered=0.0;
	double screencover=0.0;
	for(int i=0; i<o_list.size() && covered < MIN_COVERED)
	{
		screencover=(o_list[i].screenmax[0]+o_list[i].screenmin[0])*(o_list[i].screenmax[1]+o_list[i].screenmin[1])
		if(screencover > MIN_SBOX)
            if(o_list[i].screenmin[2] < far_clip_plane)
			{
				NakedRender(Object[i]);
				covered+=screencover;
			}
	}

   
~Main == Colt "MainRoach" McAnlis Programmer www.badheat.com/sinewave [edited by - duhroach on October 16, 2002 9:12:33 PM]

Share this post


Link to post
Share on other sites
Ok, well no postings, so i''ll post my own answer

http://www.gup.uni-linz.ac.at/~gk/publications.html

has a few .pdf files in relation to chooseing occluers.

Have fun
~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
Are you choosing occluders from the scene geometry itself, or did you thought about using a separate dedicated occlusion geometry set (occlusion skins) ? Doing the later can speed up the selection process, aswell as be more effective in terms of rendered occlusion faces (as it typically consists of very simple geometry). Of course, the effectiveness of such a system depends on the type of scene you use.

Share this post


Link to post
Share on other sites
currently, i''m choosing from the scene geometry, and the scene is pretty random.

Didn''t think of doing the pre-choosing algo, mainly because it''d still have to determine what is and isn''t an occluer. and unless I do it by hand, i still have to figure it out.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
You''re right, having dedicated occlusion geoemtry doesn''t really avoid the runtime occluder selection. But it alleviates the task.

I was thinking along the lines of a hand created occlusion skin, ie. the artist would create it along with the 3D scene. The skin only needs to model the occlusion behaviour of an object, no more. Perhaps you could use a sophisticated algorithm to derive those skins automatically, but that seems more trouble than it''s worth - they are pretty easy to create by hand, and you don''t really need lots of them either.

What kind of scene do you have in your application ? Assume an architectural type scene (a town, houseblocks, etc). As an example, take an ancient greek style building, with lots of decorated columns. Each one several thousand faces. The occlusion geometry of each column would be a simple box, or even two ''crossed'' quads (in the style of those cheap alpha tree billboards, you know what I mean). It will model the occlusion behaviour of the column to 95%, at only 1/1000th of the face count !

Thus, you can select more occluders given a certain occlusion polygon budget (and get better HOMs), while minimizing selection costs (smaller set to choose from). This style of occlusion is very effective indoors and outdoors with large features (houses, mountains, etc).

I really like promoting this system, as I was very sceptical before implementing it myself. But it ended up giving us a huge performance boost

/ Yann

Share this post


Link to post
Share on other sites
It sounds like a grand idea, however how would you go about actually creating this "skin". IE what would it contain? a render of the object from 26 viewpoints?

Also, how exactially do we "choose" what occluers to use? Does the code i provided before have any relivance? Am I being to simple in my determination? ANY direction/hint at this point would help greatly.

thanks again yann.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
quote:

IE what would it contain? a render of the object from 26 viewpoints?


No, they are just 3D objects like anything else. With the difference of being extremely optimized, as they don't need to represent the visual aspect of the object, but only approximate it's occlusion behaviour. I'll try to post a screenshot later today, makes it easier to show on an image.

quote:

Also, how exactially do we "choose" what occluers to use? Does the code i provided before have any relivance?


Yes and no. It depends on your occlusion skin complexity. For smaller scenes, eg. a Quake like level, you can simply render the whole occlusion skin every frame, it won't be more than a few hundered faces.

For more complex scenes, you'll still need to select parts of that skin as current frame occluders. The selection is similar to the classical one you outlined above, but some assumptions can be made about the geometry (ie. a nearby occlusion object will almost always be a good occluder candidate). In general, the main difference is the facecount. As the skin is a highly optimized (and very low polycount) representation of your scene (in terms of occlusion behaviour), you can render a lot more occluders to your HOM than before. This will give you a much better populated HOM, which in turn results in better culling rates.

[Sidenote: in any case, you'll obviously need to do frustum culling on the occlusion objects, so that irrelevant parts aren't processed]

/ Yann

[edited by - Yann L on October 19, 2002 9:55:31 AM]

Share this post


Link to post
Share on other sites
Yann''s idea of dedicated occlusion geometry appears in a paper called Virtual Occluders.

Rather than having a global set of (virtual) occluders (and then trying to select an optimal subset at run-time), they build a kind of PVS of occluders (Potentially Occluding Set?). Virtual occluders are generated specifically for each cell/sector in the scene (i.e., an occluder generated for cell A would not even be valid for a viewer position in cell B).

Share this post


Link to post
Share on other sites