Visportals vs func_portals vs antiportals

[Springheel]

Occluders would be an addition that does a lot less but is much easier to use. Basically they would be 2D shapes that mappers can place in a map (and that can be controlled by scripts, triggers etc, or be bound to moving entities) that simply act like a blackened pane of glass, preventing anything behind them from being sent to the graphics card.

 

Ok, that's a good explanation.

 

I assume the functionality is limited to single-sided planes, like visportals? Otherwise, wouldn't it be ideal to just add that functionality to brushes by default?

[nbohr1more]

Ok, that's definitely a consideration... However, AFAIK, this is a discussion about a new map object called func_ occluder rather than changing anything that maps currently use ( other than the Visportal alignment fix).

[grayman]

True, but we don't want the occluder to occlude things that need to be seen. I think it was mentioned above that if a func_static is entirely behind an occluder, it's okay for it not to be rendered (good), but if some parts are behind and some are not, we don't want the occluder to find the parts that are behind and thus take the entire func_static out of the scene (bad).

[Tels]

True, but we don't want the occluder to occlude things that need to be seen. I think it was mentioned above that if a func_static is entirely behind an occluder, it's okay for it not to be rendered (good), but if some parts are behind and some are not, we don't want the occluder to find the parts that are behind and thus take the entire func_static out of the scene (bad).

 

Exactly. And this is also why the mapper must place it manually, and we can't just add this to worlspawn brushes on general. The places where one would use it are rather limitied, in most cases visportal is the better choice.

 

Techncally, yeah, one could go overboard with the occluders. Cart on wheel? Add occluder! Free-standing bar top? Add occluder! Clothes on a zip line? Add occluder! (The thief might somehow hower in the air in front of the clothes) and so on. In a lot of cases the occluder would only bring minor performance gains in selected circumstances (e.g. the player has to be on one side, massive geometry on the other side hidden 100%).

 

However, it has it's places in outdoor scenarioes or in caes where half-broken wall covers sometimes an open doorway (with a large view behind).

[SteveL]

Quick progress update: I spent all morning struggling with geometry that I haven't had to use since school. But before breaking for lunch I did finally manage to get the renderer to project a 3d occluded space from the silhouette of an arbitrary 2d shape on screen, and to use that to close visportals. If I had more space around my desk, I'd have done cartwheels. I'll be writing new tests for the renderer to use after all, not just using old ones. The existing ones typically do more work than we need them to, because they are not looking for yes/no answers, they need precise measurements.

 

So, so far so good for anti-portals. On to entities next. I've taken another look at the code and it won't be as simple as blocking entities from being picked up by the routine that discovers stuff in view through portals. Turns out that that's only the first opportunity that an entity gets to put its name on the render list for the current frame. Front-end rendering is a multi-pass operation, to reduce the overall work done. For example, we don't want to update animated meshes for AI that won't be seen this frame, but we sometimes won't know for sure whether they'll be seen until we've updated their animations. So we do a rough test to see whether the AI's max bounding box (or shadow) could be in view, then update its animations, then do the final pass.

 

The stages I've spotted so far that need to be taken into account:

1. Entities and lights that are possibly in view through portals are discovered. That's where I suggested occluding them originally. If any entities are partly occluded through a VP so that they can be cut down using a simple on-screen rectangle to define their "viewable area", then they get that rectangle attached to them in this step.
   
2. The shadow-fix discussed above: unseen entities being hit by viewable lights get put on the list, if their shadow might hit something that's in view. They have an empty view rectangle because the model itself won't need showing.
   
3. Finally, animated entities in view get their animations updated and get tested again.
   

So simply hiding entities in step 1 won't help if step 2 puts them back on the list for shadowcasting purposes and step 3 resets the viewable region after updating animations. Not sure if whether it will yet, but I'm about to find out. And if so, there are what look like a couple of flags available to block further rendering for an entity for the current frame in a given view. I've not checked those out yet. So plenty to test / look at.

 

This part of the code is a pleasure to work with. It was written by someone with a remarkable talent for clarity and elegant design, and a gift for writing brief but illuminating comments. There are hardly any ugly bugfixes sticking out. For the most part it's the pristine work of a very talented coder.

[grayman]

Excellent.

[SteveL]

Very brief update because my brain ran out of steam shortly after that last post and I left further actions for this evening.

 

Entity culling does what was expected, and AI don’t get put back in stage 3. I’ll step through that bit of code later to make sure I understand why. I have a couple of weird bugs to look into though. I can occlude a barrel or an AI ok, but if I stand them next to one another, they vanish and repop at the same time, when either is occluded. No idea what’s causing that but it was first-draft code and it feels fixable.

 

After entities, there’s lights to be considered. They can be taken out of play too if their entire volume is occluded.

 

A design question: should occluders be 1-sided or 2-sided? The coding default is 2-sided: if we want them 1-sided we’d need an extra test to see whether the view was on the right or wrong side. But that’s no big deal. It’ll make no difference to performance unless 2-sided would mean lots of useless occlusion in many situations, so it comes down to how they’d be easiest to use.

 

If people let occluders get outside of a visible model, they’ll see some weirdness. AI heads are separate entities from the body, so if you use a bare occluder and position yourself right you can see an AI head float past and greet you.

[chedap]

A design question: should occluders be 1-sided or 2-sided? The coding default is 2-sided: if we want them 1-sided we’d need an extra test to see whether the view was on the right or wrong side. But that’s no big deal. It’ll make no difference to performance unless 2-sided would mean lots of useless occlusion in many situations, so it comes down to how they’d be easiest to use.

If the performance difference is marginal, I'd say two-sided. Having to decide which way it should face to work can become confusing (to people unfamiliar with how engines work, it's unintuitive enough that a single one-sided plane won't drop shadow if it's facing a light).

[SteveL]

If the performance difference is marginal, I'd say two-sided. Having to decide which way it should face to work can become confusing (to people unfamiliar with how engines work, it's unintuitive enough that a single one-sided plane won't drop shadow if it's facing a light).

True, that's a strong point in favour of two sided. I need to retract or clarify what I said about performance though. An occluder that doesn't hide anything is a bad thing for performance, because stuff will get tested against it without any benefits. Maybe that would happen a lot with 2-way occluders.

 

Spawnargs are an option too of course.

 

I need to think more about how the occlusion tests will be ordered in reality. That might shed more light on it. Right now in my test map I'm simply testing every entity in every open visleaf against every "visible" occluder. There might well be more efficient ways to do it, although most of the tests will end up being very cheap as we can do a quick bounding box check or screen rectangle check to exclude most entities before doing a more expensive comparison against the actual shape of the occluder.

[Springheel]

Do occluders stop rendering everything behind them, or do they only close visportals that are behind them?

[SteveL]

Plan is they should block all entity models and lights as well as VPs.

 

I have the VP-closing working already. I'm working on testing entities. Lights I haven't tried yet.

 

If I can get it working right, entities and lights will only be culled if their entire bounding box sits within the occluded zone. That's a 3d shape that starts at the occluder surface itself, and continues "back" into the screen. The sides spread out slightly because.... actually I'll take 5 to do a quick diagram. Should save some typing!

 

 

The yellow area is the player's view, the area that would normally generate light/surface interactions and load stuff to the graphics card. The blue bar is the occluder, and the pink area is the occluded zone. It spreads out from the occluder face because it's shaped from the player's eye position.

 

In this pic, 1 light, 1 barrel, and one VP get occluded. The tall thin light volume doesn't, because it sticks out of the occluded zone. Likewise the second barrel.

[Springheel]

Cool!

 

Again, I have to wonder, in a perfect world wouldn't we want this to happen by default for all regular brushes? Is it just too difficult to do?

[SteveL]

Another intriguing idea. It mightn't be too difficult to do from a coding point of view... you could generate occluders from the silhouettes of solid opaque brushes. But there's a danger it could slow the renderer down, if there are too many tests done to see whether any entities are hidden by an occluder when for that occluder the answer always turns out to be "no". I can't predict which way that would go. It might work out great, it might not. We'll probably know more after we've had a chance to play around with occluders a bit.

 

One issue is that a lot of (most?) opaque brushes already occlude because they face out on to a different visleaf or the void. Adding occluders for those would be pure waste. So we'd have to figure out a way to tell the difference before generating the occluders.

[SteveL]

NB I've not even got as far as working out where occlusion should happen in the rendering flow yet, which is why I can't think about the brush question much yet. The most fundamental choice will be:

• Should occlusion happen after the entities and lights in view have been discovered, so it tests and filters the stuff that's about to be rendered ?
  
• Or should it happen before that process, so that it filters the lights and entities that get considered for viewing?
  

I'll need to do some profiling in real maps to figure out that one. At a quick glance, the occlusion tests look faster than the in-view tests because they generally have less work to do. They're just figuring out "is this blocked?" whereas the current renderer tests answer questions like "exactly which parts of this model are in view?". But both processes have ways of cutting down their workload by doing quick tests that deal with the commonest cases before moving on to precise tests when the first test passes, so without actually taking some measurements on real maps it's hard to guess how much work will get done by any given chunk of code.

[Springheel]

One issue is that a lot of (most?) opaque brushes already occlude because they face out on to a different visleaf or the void. Adding occluders for those would be pure waste. So we'd have to figure out a way to tell the difference before generating the occluders.

 

Yes, that's a good point. It would only make sense for brushes that are within an open leaf (it would be a waste to have any occluders operating inside closed leafs, wouldn't it?).

[SteveL]

Last theoretical note from me before I get back to work: we don't yet know whether there'll be noticeable performance benefits. The engine is already highly efficient at culling unnecessary work. It caches a lot of data that it used last frame, and it doesn't apply shaders to entities tris until it knows they'll be seen on screen. So the gains might be a bit marginal. But there're grounds for cautious optimism: other games find them beneficial; they'll certainly be able to cut out unnecessary animated mesh updates (which is pure front-end); and we know VPs do help a lot with rendering time. So extending the VP method of culling stuff to more situations might well squeeze out some more fps.

Edited August 18, 2014 by SteveL

[SteveL]

Yes, that's a good point. It would only make sense for brushes that are within an open leaf (it would be a waste to have any occluders operating inside closed leafs, wouldn't it?).

 

Not sure what you mean by open/closed leafs?

[Springheel]

A closed leaf is any area behind a closed portal.

[Tels]

Very brief update because my brain ran out of steam shortly after that last post and I left further actions for this evening.

 

Entity culling does what was expected, and AI don’t get put back in stage 3. I’ll step through that bit of code later to make sure I understand why. I have a couple of weird bugs to look into though. I can occlude a barrel or an AI ok, but if I stand them next to one another, they vanish and repop at the same time, when either is occluded. No idea what’s causing that but it was first-draft code and it feels fixable.

 

After entities, there’s lights to be considered. They can be taken out of play too if their entire volume is occluded.

 

A design question: should occluders be 1-sided or 2-sided? The coding default is 2-sided: if we want them 1-sided we’d need an extra test to see whether the view was on the right or wrong side. But that’s no big deal. It’ll make no difference to performance unless 2-sided would mean lots of useless occlusion in many situations, so it comes down to how they’d be easiest to use.

 

If people let occluders get outside of a visible model, they’ll see some weirdness. AI heads are separate entities from the body, so if you use a bare occluder and position yourself right you can see an AI head float past and greet you.

 

 

Me thinks it makes sense to add "r_showOccluders" so you can visually debug them (like visportals).

 

As for one-sided - would there ever be a case you'd want it only be occluding from one side?

 

I can think maybe of "half-transparent" windows - you can look in from the street, but you cannot look out once you are inside. (because the street is huge). But I'm not sure this special case is really needed?

[Tels]

Cool!

 

Again, I have to wonder, in a perfect world wouldn't we want this to happen by default for all regular brushes? Is it just too difficult to do?

 

I'd rather have this to be a manual tool. There are an aweful lot of brushes, you'd end up with thousands of occluders that never occlude anything (like the floor).

 

Plus, then you could not stick an occluder into a barrel, f.i. (the barrel could even be moveable and still contain a cross-sectin of two occluders.

 

Let's first get the implementation right, then we can worry about using it automatically.

[Tels]

Not sure what you mean by open/closed leafs?

 

I think Springheel meant that if the occluder is itself in a leaf that is closed (e.g. not rendered), then the occluder can be inactive. You only need to test occluders that are in the currently visible space.

[SteveL]

A closed leaf is any area behind a closed portal.

Ah yes, not sure why I didn't understand that first time round. That's right, occluders will only be used by the renderer if they sit in open leaves that are in front of the player's viewpoint.

 

 

Me thinks it makes sense to add "r_showOccluders" so you can visually debug them (like visportals).

Already implemented, even at this stage in testing Currently using DebugWinding() to draw it in cyan.

[Tels]

Ah yes, not sure why I didn't understand that first time round. That's right, occluders will only be used by the renderer if they sit in open leaves that are in front of the player's viewpoint.

 

Already implemented, even at this stage in testing Currently using DebugWinding() to draw it in cyan.

 

Splendig!

[chedap]

As for one-sided - would there ever be a case you'd want it only be occluding from one side?

I can think of a couple. Basically any time the shape of an object doesn't allow for occluder's placement inside of it. E.g. a privacy screen, or curtains you can hide behind. With two-sided you risk accidentally occluding the object itself, or other small objects close to it. It's a pretty rare case though, and the use of an occluder probably wouldn't be justified in the first place.

[Tels]

I can think of a couple. Basically any time the shape of an object doesn't allow for occluder's placement inside of it. E.g. a privacy screen, or curtains you can hide behind. With two-sided you risk accidentally occluding the object itself, or other small objects close to it. It's a pretty rare case though, and the use of an occluder probably wouldn't be justified in the first place.

 

Hm, thinking about this, yeah, if you have a wave-shaped curtain, and wand to stick a strait occluder in it, that wouldn't work. But it is a special case, isn't it?

 

I envision of the occluder like a visportal (Steve, please correct me if I'm wrong): e.g. it is a brush, where all faces are no-draw, except one face.

 

The question is, is this face one-sided (e.g. the engine ignores it from one direction) or two-sided (like visportals).

 

If it is one-sided, then you can make it two-sided by just adding the same shader/texture to the other brush face. (Adding it to the small side-faces of the brush is also possible, but pointless for thin brushes. It make sense for larger brushes, tho).

 

If the occluder-face is always two-sided, then there is no way to make it one-sided.

 

There really might be cases where you want the occluder to only occlude from one side, the "window-see-through only from the outside" is one case. The "wall with large objects behind it" might be a second case, f.i. if the player either cannot get on the other side of the wall, or if he can get, there is nothing in the other direction that occluding makes sense (albeit moveables might enter the occluded space...)

 

Another case where one-sided makes sense is a "occluding box". If you stick three two-sided occluders into a crate perpendicular to each other, you can hold the crate in front of you and it properly occludes (given that occluders can be moved around, tho). With one-sided occluder faces you can also build a slightly smaller box and stick it in the crate. It would then use the 6 one-sided occluders, vs. 3 two-sided ones. The 3-two-sided only fors for boxes tho, for other geometries (like barrels, trapezoids etc.) you might be better of with one-sided faces approximating the geometry...

 

Decisions!

 

So, from the point of flexibility, I think a one-sided texture would be more versatile. It would, however, mean that we either need two different textures to cover both cases, or always have two faces on a brush painted with the occluder, so both sides occlude in the other direction. The latter case means two occluders (instead one with two side), tho, unless the engine could combine them somehow into one two-sided face..

Edited August 18, 2014 by Tels