Jump to content
  • Advertisement


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


Portals vs Occluders

This topic is 5560 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post

Link to post
Share on other sites
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

Share this post

Link to post
Share on other sites
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


Share this post

Link to post
Share on other sites
My ATi 9700 supports NV_occlusion_query
But I wouldn''t use it (pipeline bubbles etc.)

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!