Well, I saw the Yann L's post in the 'the 7 pages long thread'. I definitely want to discuss portals vs completely occluder based VSD solution. Why are portals so nice (for me)? Because they simply mark all other space (screenspace) as occluder, and can efectively describe Quake-style,low-poly urban environment (sometimes named 'indoor'), because there are lots of convex cells there -> environment are nicely subdivided into convex subspaces, and the actual portals are very few faces from that subspaces, compared to walls (i.e. occluders). So - using portals here will result in much more occluders compared to portals. So the criteria is (for static environments) - subdividing the scene into convex cells, what faces are more - those that are portals, or those that are walls. Imho that is the criteria for using one of the above - portals or occ. One more - fusion. Combining portals is just an intersection of convex shapes, it is easy and are not CPU intensive. Occluders need much more - (z/s/c)-buffers for memory (screenspace,discrete) or something like SVBSP/MOBSP tree (geometric). There are many more structures to aid fusion and hierarchical (occluder vs primitive) test, but they tend to perform poorly in indoor scenes. HOMs suffer from inacuracies (stick two walls together?). Beam-trees will cut everything into pieces. And the second big problem - what geometric set is used for occluders? Original geometry? Some LOD-ed version? Hand-created by artists? Imho - the best solution is to use both portals and occluders, placing more of that type which aid the VSD better in the given environment. And it will be interesting to hear more opinions on that subject! [edited by - Zemedelec on April 30, 2003 9:52:06 AM]

I agree with Zemedelec. Portals and cells are a great way to represent indoor environments. Scenes can be portalized easily (well, if u have a good algorithm ) and the hsr performance is better than anything else. It is the best to combine occ with portals and more output sensitivity can be accomplished this way.
Portals can be used in high polygon environments using semi-automatic portalization techniques and they don`t care about occluder complexity or fusion. It would be much harder to produce good occluders instead like portals using semi-automatic methods if one wanted to use oc only...
Coders of the world, declare your love for portal rendering

Very interesting topic this!

In my engine I used extremenly simple portals,
(i.e. hand-made in WYSIWYG editor), so there is not
even any convex space generation or anything.
It took about a day to implement, with editor functionality
and all, and it does the job beautifully.
(I.e. Outdoor=sector0, portals at doors and windows to
other sectors (rooms, houses, etc))

I''ve always been fond of simple but powerful techniques.

I''m only one guy working on the 3D engine, so that''s how I
rationalize making some things the easy way =)

However, after reading many of Yann''s posts about HSR,
i.e. Hierachical Occlusion Mapping and all that,
I''ve been thinking about re-architecting that whole part of
the engine.

I''m thinking about spending a month this summer on HSR,
what would you recommend? HOM?

I''ve often read posts that OpenGL Occlusion Query extensions
don''t perform that well, is this true?

Any good links/hints for the "find good occluders" problem?


...more input to this thread is much appreciated


Christian

That''s the NV_OCCLUSION_QUERY extension, and as far as I know, if you use that you''re limiting your audience to people with NV cards...

My ATi 9700 supports NV_occlusion_query
But I wouldn''t use it (pipeline bubbles etc.)