Have we been selling visportals short?

[Springheel]

I'm working on the visportal lesson for my mapper's workshop, and I've been doing some tests with visportals.

 

According to Komag's visportal video, if a visleaf is open, it does not provide any performance benefit. The wiki also states: "Since the player can see straight down through [the visportals] then they serve no purpose as they will all be open"

 

Both sources suggest that if you have two rooms, and put one visportal between them (see image below), then that provides no benefit in terms of performance, because the visportal will always be in the player's line of sight, and so it will never close. Since it never closes, the entirety of room 2 will be drawn when the player is in room 1 and vice versa.

 

However, this doesn't appear to be how visportals actually work. In a long hallway with open doorways, I tested the numbers with no visportals at all, and then put visportals in the doorways. The numbers dropped to about 25% of the values I had with no visportals at all, even though all the visportals I added were open.

 

Additionally, setting r_showtris to 3, which is supposed to show all tris, rendered or not, only showed tris for the main hall. No tris were shown beyond the open visportals until I was actually able to see into the room. It seemed to be accurately drawing the tris that were being rendered for the player.

 

From what I can tell, open visportals DO keep the visleaf beyond from being rendered, other than what the player can directly see from their position. So, in the image below, room 2 would not be rendered unless the player moved to the top of room 1, looking down the hall, and then, only the parts the player could directly see would be rendered.

 

This makes visportals much more effective than I thought they were. Was everyone else aware of this already?

[nbohr1more]

Hmm I wonder if SteveL improved things there?

 

Compare your understanding to this explanation (towards the bottom):

 

http://fabiensanglard.net/doom3/dmap.php

 

[Goldwell]

Currently I'm at the stage of optimization for my city mission and I've noticed that having as many visportals as possible really does help.

 

It's good to see that you've tested it and returned positive results too.

[Destined]

Incidentally, I have also watched Komag's video just yesterday (meant to for a longer time, and finally found teh time). While he demonstrates the effect of only one visportal, only tris visible through the portal are rendered. He states that the rest is not shown by r_schowtris, but still rendered. Maybe this is simply wrong information on his side? In the video he never uses other means of checking his performance, so it might be possible. The more important question is: How big is the difference between using the double visportal method vs the single visportal method. The two visportals in the hall will still lead to lower draw calls than just one (none vs the tris visible through the visportal), even if not the whole room is rendered.

[Fingernail]

Is there any reason not to put one at either end of the hall/corridor in your example, Spring?

[demagogue]

I've always thought that an open visPortal is culling non-visible triangles just because it kind of wears the culling on its sleeve, so to speak. It's so easy to see how the algorithm can do a quick check to see if a triangle is inside the boundaries of the visportal that I just assumed that's what it did, on top of the rendering triangles not showing them.

 

(I understood that it still rendered non-visible light sources, though, because they stretch into visible areas. Someone should double check whether it renders non-visible particle sources with the particles falling into visibility.)

 

And generally speaking I've thought from early on that visportals are the most critical element of learning to map, and what every mapper should start with when planning their mission space, and around which everything else should be planned.

[peter_spy]

I think Rich said once that brushes perform some culling as well. Plus stats for drawcalls and tris change a lot and all the time, when you move and look around, even without visportals.

[Obsttorte]

Things that can't be seen don't get rendered. IdTech4 doesn't produce any overdraw. But Hidden tris might be depth-tested if they are not occluded by an visportal. The example you procivided is very rough. Two rooms with one vp in it isn't really representative for a real mission. Visportals cull the viewspace of the player, so even though a visportal might be open if the player looks at it, it might occlude another one causing it to be closed. Having an open visportal only means that the visleaf behind it gets taken into consideration for rendering, not that it gets actually rendered.

 

Another note on your example image. The visportal placement is rubbish. Noone should place a vp like that. In the example two visportals are required at each end of the hallway. And with this two vp's one vp will occlude the other and cause it to get closed when the player looks at it from the correct angle.

 

In the image below you can see how this work. By default the red visportal is in the player FOV and would be open. But as the greenish vp restricts the FOV into that visleaf, the red vp is no longer part of said one and gets closed. This will cause all tris that belong to the visleaf connected via the red vp to be ignored for rendering.

 

 

[peter_spy]

Makes sense, thanks for explanation.

[Bikerdude]

There is another way to look at this for new mappers and the example is simple -

 

 

But as per Obs statement above you never place a VP in the middle of a corridor, you would place at the entrance to each room/vizleaf. And then depending on the size and shape of that you would place more VPs inside those rooms/vizleafs.

Edited June 21, 2017 by Bikerdude

[Springheel]

Another note on your example image. The visportal placement is rubbish. Noone should place a vp like that. In the example two visportals are required at each end of the hallway. And with this two vp's one vp will occlude the other and cause it to get closed when the player looks at it from the correct angle.

 

In the image below you can see how this work. By default the red visportal is in the player FOV and would be open. But as the greenish vp restricts the FOV into that visleaf, the red vp is no longer part of said one and gets closed. This will cause all tris that belong to the visleaf connected via the red vp to be ignored for rendering.

 

 

Yes, I understand the above. But the point is that most of our literature says that the benefit of visportals comes ONLY from when they're closed (the red one you mention). However, in the image I posted, having no visportal means that rooms 1 and 2 will be fully rendered if they are within the player's vision cone (brushes do not block rendering). When you add a single visportal, that creates a visleaf and brushes DO block rendering, even if the portal is open (which it always will be when only 1 visportal is present).

 

Perhaps the image below will be clearer--if the player is looking north and there is no visportal, the AI in the next room is fully rendered, even though it cannot be seen. If a single visportal is added in the hallway, the AI is NOT rendered any longer. Our literature suggests that a closed visportal is necessary for that to happen, but that is not the case.

 

I'll upload some of the video I took later tonight, which will demonstrate more clearly what I mean.

 

 

While he demonstrates the effect of only one visportal, only tris visible through the portal are rendered. He states that the rest is not shown by r_schowtris, but still rendered. Maybe this is simply wrong information on his side?

 

 

He is also incorrect when he says that things behind the player are fully rendered. They're not. You can see this easily by turning on r_showprimitives and turning to face a wall. Either Komag had a few misconceptions or visportals have changed since he made the video.

[nbohr1more]

Hmm I think I know the snag here.

 

If the AI was not set to become invisible at an LOD distance and there was a shadow-casting light whose radius

expanded to the open visportal, the AI would still be skinned (triangluated) to ensure the shadow looks right

when it renders in the player FOV.

[Springheel]

Here are a few clips of video. You can see that when visportals are added to the doorways, even though they are all open, the drawcalls drop from 4500 to 1600. Shadows drop from > 124k to around 40k. Brushwork begins to block rendering once the rooms become separate visleafs.

 

[nbohr1more]

124k to 40k

[Springheel]

Oops, fixed.

[HMart]

Nice find, it seams that we were all thinking portals was a all or nothing thing, but even with open portals, the act of dividing the map in "rooms/visleafs" seams to help the culling system, i assume with a open portal it uses the camera occlusion culling system to not render stuff, but anything that is seen within the camera FOV and is not occluded by brush geometry will get rendered, but with a closed portal, even if stuff is in plain view (if you force the portal to close), everything is skipped including the camera/brush occlusion culling system, so having no portals is very bad, having portals even if almost always open is better, having a system of portals where only a few are open at a single time is perfect. I also agree that putting a single portal in the middle of a big corridor is not smart thing to do, even if it helps some.

Edited June 22, 2017 by HMart

[Obsttorte]

@Bikerdude: Sealing geometry is not used for automatic culling as suggested in your image. It is needed to create the visleaf together with vp's, though.

 

@Springheel: The tris shown with r_showtris do not neccessarely represent tris that actually get drawn. These are just the tris that are taken into consideration for drawing. To understand this better here is a rough overview of what the preprocessing (Frontend) of the rendering looks like. (the process is described here, search for the headline 'Doom 3 Renderer Frontend)

 

1. The Frontend collects all visleaf that are potentially visible for the player. To achieve this it subsequently culls the player FOV using the Visportals
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)
3. Visportals are also used to cull away tris that are not visible or models whichs boundary box is outside of the (culled) FOV
4. all tris that are left are drawn to the depth map. note that this is no actual rendering yet. Only the distance is stored.
5. the depth map is then used for the actual rendering process. tris are checked against the value stored in there, so if a tris is occluded by another one, the distance stored in the depth map will be smaller then the distance of the tris. if this is the case, the tris does not get rendered

This means that idTech4 does not produce any overdraw. So the engine does not draw a tris just to overdraw it with another one later on which might be occluding the first one. This already helps a lot in regards to performance. However, even if non-visible tris aren't drawn, the engine will have calculated there depth beforehand and will later on compare the depth to the depth map. Even if occluded tris are discarded, the comparision eats up a bit and it obviously makes sense to reduce the amount of tris that are taken into consideration for rendering as much as possible.

 

In regards to closed visportals point 2 is very important. as nbohr1more already stated, it is possible that a light or a shadow-casting object will contribute to the current render, even if the light source/shadow-caster is in a room sealed of by a closed vp and therefore not visible. You can possible see the shadow of an object, even if you can't see the object itself. However, shadows do only exist inside the light volume of a light. Due to this it is important, especially in missions where you know beforehand that performance will be problematic, like outdoor areas, that you avoid having light volumes that overlap visportals. In some instances you cannot avoid it, but sometimes it is possible. Mappers often oversee this.

 

The article linked above explains this all more in detail and it is definetely a worthwhile read (all the pages are). I've also talked about this topic in the video below (it is rather long as I don't use scripts for my videos and don't cut them). Old video, though, so I can't remember if everything said there is correct

https://www.youtube.com/watch?v=1Bs12aI2i9Y&index=9&list=PLrQt-qjh-krYU2kpnJJRHUO8P4xPG5I9X

[Springheel]

Ok, I've listened to the video, but I'm still left with a point of confusion.

 

Look at the map below. The arrow is the player direction. The four highlighted brushes at the end of the hall are visportals.

 

From the player's perspective, the two larger visportals are closed (red). As I understand it, that means the yellow areas are not rendered (beyond checking to see if lights extend into visible areas).

 

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

 

I always believed that if you didn't have them, the entire room would be rendered. However, that is apparently not the case. The yellow areas are not rendered, regardless of whether there are two visportals there or just one. Not only that, but adding those two large visportals does not change the number of drawcalls or shadow tris in the scene AT ALL. Are they having some other impact on performance that isn't measured?

[Bikerdude]

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

In my case I would only place a VP inside a room/Vizleaf if there was a LOT of entities or models in there, the idea being as the player approached he/she would gradually be presented said entities/models preventing DC spikes.

 

A good example of this is large outside Vizleafs, as the player wondered around a large open area (examples of this that I have worked on are PennyDreadfull 3, No honour Among Thieves and All the CoO city maps). Each VP either becomes visible or is opened manually via a func_portal as they come into the player view.

 

In the above example, if its a normal room then there is no point place a VP inside.

[Destined]

If I understand Obsttorte correctly, the yellow parts are not only not rendered, but are completely ignored regarding rendering, while the remaining part of the room is still checked for lights etc that may have an effect on the visible region of the room. This means: if there is a light in the yellow part that extends into the corridor, it would not show. If a light was in the remaining part of the room, it would illuminate the corridor. The yellow part is completely ignored by the renderer, so it should only start to show, as soon as the door-visportals are open, as this is the first time it has to be considered for rendering. This may also be, why you have to be careful with lights crossing the boundaries of visportals, as they suddenly snap on, which looks strange to the player.

[Springheel]

If I understand Obsttorte correctly, the yellow parts are not only not rendered, but are completely ignored regarding rendering, while the remaining part of the room is still checked for lights etc that may have an effect on the visible region of the room. This means: if there is a light in the yellow part that extends into the corridor, it would not show. If a light was in the remaining part of the room, it would illuminate the corridor. The yellow part is completely ignored by the renderer, so it should only start to show, as soon as the door-visportals are open, as this is the first time it has to be considered for rendering. This may also be, why you have to be careful with lights crossing the boundaries of visportals, as they suddenly snap on, which looks strange to the player.

 

 

I don't believe that's the case. The engine would still have to check to see if lights/shadows were visible to the player, or, as you say, shadows and lights would constantly be popping in and out as the player walks around, which doesn't happen.

 

In my case I would only place a VP inside a room/Vizleaf if there was a LOT of entities or models in there, the idea being as the player approached he/she would gradually be presented said entities/models preventing DC spikes.

 

 

As I said above, the number of drawcalls does not change at all when the closed visportal is added. It is having NO effect on DCs or shadows.

[Bikerdude]

As I said above, the number of drawcalls does not change at all when the closed visportal is added. It is having NO effect on DCs or shadows.

At what location exactly on your diagram above, where the blue arrow is.? then yeah they wont have an effect. But if either/both room/vizleafs have lots of entties or models with hi-tris counts then as the player moves to the point where they can start to see into the rooms then the extra VP's would help. Because I have done exactly that, in numerous maps.

[Springheel]

At what location exactly on your diagram above, where the blue arrow is.? then yeah they wont have an effect. But if either/both room/vizleafs have lots of entties or models with hi-tris counts then as the player moves to the point where they can start to see into the rooms then the extra VP's would help. Because I have done exactly that, in numerous maps.

 

Ok, that's a different question than my original one, but I'll bite--where would the player have to stand for the second visportal to provide a tangible benefit?

[Bikerdude]

ive moved the red(VPs) back into the room to emphasize the point, as this point the player only sees the entities (marked in green) behind the first VP (in the door way). Using a second VP, this hides the entities (marked in purple) behind the second VP - this splits the DC load the engine gets hit with as the player moves forward.

 

 

 

 

 

Edited June 22, 2017 by Bikerdude

[Springheel]

ive moved the red(VPs) back into the room to emphasize the point, as this point the player only sees the entities (marked in green) behind the first VP (in the door way). Using a second VP, this hides the entities (marked in purple) behind the second VP - this splits the DC load the engine gets hit with as the player moves forward.

What evidence do you have that the purple boxes would be rendered if the large visportals weren't there? Everything I'm finding suggests that they wouldn't be drawn anyway, because they are in a separate visleaf from the player and cannot be seen through the portal in the door. The bottom green box would not be drawn either.

 

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.