Have we been selling visportals short?

[Obsttorte]

 

Ok, I've listened to the video

Sorry for that

 

:)

 

My question is, what value is added by having the large, closed visportals there?

The yellow areas aren't taken into consideration for rendering. Note that this refers to tris, not lights or shadowcasters. Destined misunderstood that, as you've already noticed (see my note at the end of the post).

 

As the areas get culled via the visportal (the small ones), it is clear they will be discarded during this process anyway. However, this still has to be calculated. So if the big visportal weren't there, for each tris in the yellow area the engine would have to check whether it gets culled by the visportal or not. Due to the big closed visportals the tris in the yellow area gets completely ignored, because it is already clear they will not be visible for the player. Note that this is no draw call.

 

Draw calls means that something should get rendered by the engine. The major part in regards to performance optimization takes place in the frontend, though. And the only thing that gets rendered there is the depth image. So as I stated in several similar threads the draw call is no sufficient indicator for the performance impact. Most missions that suffer performance issue do not suffer them because a lot of stuff gets rendered (at least not only), but because a lot of stuff has to be discarded during the preprocessing of the rendering. This means that the renderer has to deal with a lot of stuff that never gets rendered, which is a waste of computing time.

 

 

This means: if there is a light in the yellow part that extends into the corridor, it would not show.

 

2. Additional lights and shadow-casting objects in sealed off areas are taken into consideration if they could potential be seen (casting shadows or throwing light into visible areas)

This statement means the exact opposite. See the linked webpage for a detailed description with images (the latter ones will make it much more clear what is meant).

[Springheel]

So if I get this right, closed visportals are a shortcut--if things are behind an opened visportal, the engine has to check and see if they are visible to the player. If they are behind a closed visportal, that check can be skipped because the engine knows right away they're not visible.

Draw calls means that something should get rendered by the engine. The major part in regards to performance optimization takes place in the frontend, though. And the only thing that gets rendered there is the depth image. So as I stated in several similar threads the draw call is no sufficient indicator for the performance impact. Most missions that suffer performance issue do not suffer them because a lot of stuff gets rendered (at least not only), but because a lot of stuff has to be discarded during the preprocessing of the rendering. This means that the renderer has to deal with a lot of stuff that never gets rendered, which is a waste of computing time.

Is there any console command to show how much preprocessing is taking place? How can a mapper tell whether his visportal is doing any good if draws and even shadows don't tell the whole story?

[Obsttorte]

 

So if I get this right, closed visportals are a shortcut--if things are behind an opened visportal, the engine has to check and see if they are visible to the player. If they are behind a closed visportal, that check can be skipped because the engine knows right away they're not visible.

Now you've got it

 

Is there any console command to show how much preprocessing is taking place? How can a mapper tell whether his visportal is doing any good if draws and even shadows don't tell the whole story?

Not that I know off. It is a matter of mission conception anyways. If an area behind an opened visportal is for the most part not visible, the visportal is doing a bad job. If a visportal is only open when you can see most of the respective visleaf, it does a good job. You cannot completely avoid the above mentioned check, though. You should just make sure it doesn't get out of hand.

[Destined]

Thanks for clearing it up. I hope, I also understood, finally.

[peter_spy]

So basically it works like in other engines. In UE2, back when it had ZonePortals, I saw similar behavior, especially while working on a nature/pagan setting. At some angles, grass and vegetation meshes were popping in gradually, based both on player FOV and the ZP placement. You could also adjust how aggressive portals were in terms of cutting stuff off.

Edited June 22, 2017 by Judith

[Bikerdude]

edit:

I did a test using your setup above and could not confirm your claim. The large visportal was even closed from the player's position. There was NO difference to drawcalls or shadows, regardless of whether the large visportal was present or not. This suggests that the 3 AI are not being drawn even with only 1 visportal.

The second large VP is red, which means its closed. So anything behind that should be not be rendered, the only thing I can think of is that because you used Ai instead of ordinary entities. What did r_showtris 2 show being rendered..?

 

edit - Obs post above put it better

Edited June 22, 2017 by Bikerdude

[Springheel]

he second large VP is red, which means its closed. So anything behind that should be not be rendered,

 

 

Nothing is being rendered even if that visportal isn't there, which is why the drawcalls didn't change when it was added.

 

The key is that it's not about rendering...it's what the engine has to do to decide what is being rendered. That's the piece that has been missing from most of our documentation.

 

That fact also severely undermines using drawcalls or even shadows as a primary performance guide. As far as those two things are concerned, you could have every visportal in your map open and it wouldn't make a difference.

[nbohr1more]

Hmm.

 

I know that SteveL worked on func_occluders to work more like typically engine occlusion culling.

 

I wonder if you just had VP's that span an open area every 100 units (etc) if it would act the same?

Eg. The blocking geometry in front of the next nearest open VP would cause the shortcut to kill

all the rendering behind it just like an occlusion system.

 

That would also explain the strange performance characteristic where a long view which is barren of geometry

still has a large impact on rendering whereas a short view with TONS of complex geometry can perform very well.

It's the increased search space for the algorithm as you go further from the source of the view frustum.

 

Experiment:

 

 

???

[peter_spy]

If I have more than 3000-3500 drawcalls on either of my machines, the FPS goes down, regardless of the tris or shadow count, I guess it clogs down the graphic pipeline. With DCs over 4500, I could probably make scrambled eggs on my CPU

[Springheel]

Can anyone confirm that visportals not in the players field of view (eg, behind him) are automatically closed?

[Bikerdude]

Can anyone confirm that visportals not in the players field of view (eg, behind him) are automatically closed?

As I understand yes, I'm sure Steve said this was the case.

[Obsttorte]

They are.

 

I wonder if you just had VP's that span an open area every 100 units (etc) if it would act the same?

Eg. The blocking geometry in front of the next nearest open VP would cause the shortcut to kill

all the rendering behind it just like an occlusion system.

I'm not sure this approach would work very well once the missions become sufficiently large. The more vp's you have the more complex is the BSP tree. I guess sooner or later you could reach a point where this could become a problem.

 

It's the increased search space for the algorithm as you go further from the source of the view frustum.

I think it is more that you will likely have more adjacent visleafs and therefore more stuff that needs to get tested. For each light in an adjacent but closed off visleaf you have to check whether its light volume is in the visible part of the BSP tree. More of such leafs means more to test, which is bad. I don't think distance or tris size plays any role here.

 

At some angles, grass and vegetation meshes were popping in gradually, based both on player FOV and the ZP placement.

This sounds like an additional optimization step on top of the basic visportal structure. idTech4 doesn't go that far.

 

All engines are using such techniques btw. Engines meant for creating inner areas due rely more on the visportal approach (even the DarkEngine did, although the portals were created automatical there, possible due to the low poly count back in the day), open world engines rely more on tiles, as vp's don't work there very well. Some engine might feature both, dunno.

[peter_spy]

Engines like UE3 and newer don't use portals at all, they all rely on automatic culling and LODs. Since they use static lighting and lightmaps, they're much more forgiving in terms of perfomance, but you have to be careful about your models, because they act as occluders. That means e.g. one mistake, like a small space or hole in your wall model, or improper placement, will cause the whole location behind it to be rendered.

[stgatilov]

I don't like that you are talking about performance of rendering as a binary thing: engine either renders an object or not.

It is much more complex. Aside from draw calls (which are very important), there are other things involved.

For instance, pixel fill rate (think about pixels you have to fill with data) and other read/writes to memory.

Also, the complexity of the per-pixel visual effects (which are done in pixel = fragment shaders).

So it is all more complicated: the engine is big, and it is very hard to fully understand all the performance details.

 

First I'll try to correct some misunderstanding here (well, at least I think so):

1. An entity cannot be culled out only because it is occluded by some set of entities. So if there is a candle behind a crate (or several crates) in a room, the candle will be rendered regardless of crates presence. In my opinion, there is no efficient way to check that the candle is fully behind a crate or a barrel, that's why I think so.
2. Quake 1 really has software renderer with zero overdraw, but Doom 3 renderer does not have. If engine renders several surfaces which are located on the same place on the screen (and thus occlude each other), then even occluded pixels would take some time to render. However, Doom 3 performs "early depth pass": it renders all the geometry without any lighting/coloring/texturing at the very beginning of the frame to produce depth map. After that it renders everything again, but all the complex math for lighting/texturing (i.e. fragment shader) is done only for the pixels which are actually visible and not occluded by anything. For the pixels which are occluded, only depth calculation and comparison is done (which is much cheaper than full rendering). So you pay for visible pixels, and pay much less for occluded pixels.

As you see, the only way to not pay for triangles and draw calls is to cull the surface completely in frontend.

This is what I'll try to explain now: let's go back to portals culling.

 

Let's call arbitrary convex polygon on screen "winding". For instance, every portal that you see with r_showPortals is rectangular, and its winding (which is a 2D thing) is a 4-gon.

Every area can be seen by player through a sequence of portals (let's call it "portal path"). For the area where the player is located there are zero portals in this sequence.

Given a portal path, you can intersect the windings of its portals, and you'll get a polygonal winding through which you see the area at the end of the path.

For instance, on this picture the outside area is visible through two portals, which together yield 5-gonal winding (marked by orange color):

 

Now the main rules are:

1. If the windings of the portal path have empty intersection, then it is culled out.
2. if one of the portals is sealed (maybe closed door), then the portal path is culled out.

If all portal paths leading to an area are culled out, then it is not rendered and you don't pay for it.

If there is a single remaining portal path into an area, then its winding (recall that it is intersection of path's portals) is used to cull out the entities in the area: if an entity's bounding box is not visible through the winding, then entity is not rendered (so you do not pay for it). If there are several portal paths leading into an area, an entity is drawn only if its bbox gets into at least one winding (I think so). Unfortunately, I cannot say how the winding of the portal path affects the world geometry, but I can imagine that surfaces (sorry, I don't know if "surface" is a known concept/term in DR) which are surely not visible through the winding are culled out too.

This is not over yet. There is also an OpenGL thing called "scissor test", which allows to skip rendering of pixels outside of a specified (axis-aligned) rectangle on the screen. Doom3 uses it heavily: when rendering an area, it sets scissor rectangle to be minimal rectangle bounding the windings of all the portal paths leading to the area (usually one portal path leads to an area, but not always).

 

As you see, even portals which can be seen through by player (drawn as green when you enable r_showPortals) can help a lot with culling. Note that the description above explains the final effect of portals culling, but does not exactly describe how the implementation works internally. Also, I think that the overhead introduced by portals is pretty low: you should not be afraid that setting 2x more portals would waste CPU time (I suppose so).

 

Note that there are also shadows, which are culled by different code. For each shadow-casting light, a similar procedure is started from the light itself. It does not matter whether portal is sealed or not here. The algorithm for culling by portal path seems to be completely different in this case, but it also takes into account the fact that even visible portals limit the range through which the light goes.

 

 

Having said all that, I'd like to ask a question: has anyone seen a case when adding a portal (or several portals) seriously reduces performance?

[Bikerdude]

Having said all that, I'd like to ask a question: has anyone seen a case when adding a portal (or several portals) seriously reduces performance?

Yes, from memory when you have a big open area and the geom dosen't allow for efficient culling with VPs. The town area in one of my early maps, St Albans cathedral - that was a a bloody night mare due to my virgin VP skills. It was on that map I learned about the inefficiency of too many horizontal VPs and that it was better to use vertical.