Jump to content
  • Advertisement
Dingybarker

Portal occlusion culling help

Recommended Posts

Posted (edited)

I want to know more about portal occlusion culling for a game engine.
The internet only explains how it works without any code.

Can I get a better explanation with pseudo code?

I don't know if I'm missing information.

Some of the information I found talked about using a visibility tree for the portals.

Edited by Dingybarker

Share this post


Link to post
Share on other sites
Advertisement

So this is how I understand the concept of portals:

If we assume we have a small house with only two rooms (kitchen and living room) then the door between the two rooms would be the portal. Assuming that the door always closes after you when you move from one room to the other.

List_of_visiable_objects kitchen = {chair, table, sink,.......}

List_of_visiable_objects livingRoom = {television, news paper, couch,.....}

if(player is in kitchen)

Render(kitchen)

else

Render(livingRoom)

endif

/Kim

Share this post


Link to post
Share on other sites

I mean, you could always look at the real code? Descent (i thinkt they opened it), Boom, Duke Nukem 3d   aka  the Built engine or so.

Is a scene graph a tree? Ususally space defaults to empty. For effective portals space needs to default so solid. Then carve out caves. Switch between add (usual scene graph) and sub (carving for mines and dunguens) on a per node base of the scene graph?

Or are they talking about screen space? Like Warnock's algorithm. I think for the few portals in descent you could just loop over each one. Or better do some scan line sorting. Full blown 2d tree in a balanced way .. there I always have trouble to optimize the balance (ie the performance).

Share this post


Link to post
Share on other sites

Also a unified  occluder  portal  aproach for screen space is possible. I was thinking about keeping track about portals and occluders. Like there are three objects. One of them is a portal allowing for a line of sigth between the others or an occluder preventing any line of sight between the others. When a player is totally contained in one of these objects for some time ( I am thinking of 120 fps screens, so time is kind of a continuum for me ), she cannot see nor shoot at the objects contained in the other objects.

Share this post


Link to post
Share on other sites

When adding tolerances or estimates of uncertainties to all calculations, some more info can be reused in the next frame.

A chain of overlapping cave objects could form a tunnel (tube) between two objects. Objects overlapping in screen space can be ordered for the most effective occluder (maybe some occluders make others reduntant). I still wonder how to aggregate occluders. I mean I could mark unimportant faces, edges vertices. I could cache which edge from wich occluders overlap. I think about using a lose BSP. I then let AI figure out the optimal balancing algorithm.

Consider that this code can run on a server for a multiplayer game! So the results can be reused for multiple clients and prevent cheating  aaand speed up rendering. In an extreme case: Objects which do not see each other, will not collide. So it may also speed up collision calculations.  And global illumination. I was into this topic after CPU based rendering and before powerful GPUs, so I kinda discarded it.

Share this post


Link to post
Share on other sites
On 8/9/2019 at 1:22 AM, Dingybarker said:

I want to know more about portal occlusion culling for a game engine.
The internet only explains how it works without any code.

Can I get a better explanation with pseudo code?

I don't know if I'm missing information.

Some of the information I found talked about using a visibility tree for the portals.

Firstly portal rendering is beyond a beginner topic (some major 3d engines don't have occlusion culling!)..

But very briefly:

Simple portal system, you would split your world into rooms:

Room contains objects to render, and a list of portals through which you can see into other rooms.

Portals can be contained in more than one room (or have 2 one way portals, one on each side).

e.g.

  • Kitchen (contains walls, floor, sink, girlfriend, chain) + Portals (kitchen door, window)
  • Hallway (contains walls, carpet, painting) + Portals (kitchen door, window, living room door)
  • Outside (contains grass, trees) + Portals (hall window, kitchen window)

Let's consider a portal being a convex polygon on a single plane.

First you need to know which room you are in, let's just pretend you know you are in the kitchen for now.

You first draw all the objects in the kitchen, culling to the view frustum.

  • Draw walls, sink, girlfriend, chain

Next you go through all the portals leading out of the kitchen, culling to the view frustum (if a portal is behind you for instance, it need not be considered).

If the kitchen door is in view, you now add each edge of the kitchen door (portal) as a new clipping plane for your culling routine.

Now draw everything in the hallway (the room which that portal joins to) but cull each object if it is behind these clipping planes.

  • Draw walls, carpet (painting culled, outside view of door)

Now repeat for any portals in the hallway which you can also see through the kitchen door, maybe a window to the outside. If no more portals are visible through that portal terminate the routine.

  • Draw grass, trees (some culled by the window)

This whole thing is recursive in nature.

To do all this of course you need to firstly understand data structures and links / references between them, you might for example use a scene graph. You also need to understand the principles of culling and some geometry.

You also need to keep track of which room the viewer is in, there are various methods for this .. you could simply take note whenever the player crosses a portal (providing the physics is only allowing movement between rooms via portals).

Share this post


Link to post
Share on other sites
3 hours ago, lawnjelly said:

some major 3d engines don't have occlusion culling

Really ? Any sources for this ?

I'm guessing that major 3D engines have whether hardware occlusion culling, their own CPU/GPU occlusion culling or use a third-party one. If I'm not wrong UE4 uses hardware occlusion culling whereas Unity uses a third-party one. I have absolutely no clue about Frostbyte, Unigine, new Id tech and so on.

Share this post


Link to post
Share on other sites

Here is a playlist for occlusion culling by thebennybox. Very enjoyable and informative. I'm not going to reduce it to a link cause I like the thumbnail. :D I wouldn't recommend skipping around looking for the portal specific information.

 

Share this post


Link to post
Share on other sites
2 hours ago, _Silence_ said:

Really ? Any sources for this ?

I'm guessing that major 3D engines have whether hardware occlusion culling, their own CPU/GPU occlusion culling or use a third-party one. If I'm not wrong UE4 uses hardware occlusion culling whereas Unity uses a third-party one. I have absolutely no clue about Frostbyte, Unigine, new Id tech and so on.

the Frostbyte 2 paper only talked about a software occlusion culling, hence there seem to be no portals in place, which makes sense, considering how destructible and outdoor they want their environments to be. (e.g. You wouldn't span portals across trees in Battlefield)

Share this post


Link to post
Share on other sites
8 hours ago, _Silence_ said:

Really ? Any sources for this ?

I'm guessing that major 3D engines have whether hardware occlusion culling, their own CPU/GPU occlusion culling or use a third-party one. If I'm not wrong UE4 uses hardware occlusion culling whereas Unity uses a third-party one. I have absolutely no clue about Frostbyte, Unigine, new Id tech and so on.

Yeah, Godot *cough*, where I've been spending a bit of time contributing lately. There was actually a portal system in the old version 2.1 but there is currently no occlusion culling whatsoever, although it is on the roadmap for version 4.0:

https://github.com/godotengine/godot/issues/22048

I did mention doing a temporary version in that thread but it may not be worth it (duplicating the work that reduz will be able to do better integrated with the visual server etc, plus the difficulties of distribution of modifications versus having code in the master branch).

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!