Water effects not rendered through warp glass

[nbohr1more]

8 minutes ago, stgatilov said:

If they have same material and "sort" value, then they are eventually sorted by surface index. This order is constant in one playthrough, but can change even if you restart the game.

And if you have two postprocessing surfaces on the same place, then both of them will be visible if they render in correct order. If the closest surface renders first, then the farthest surface won't be visible.

I see. so if we are "lucky" the glass renders first then the torch haze second but we seem to be consistently unlucky in some scenarios so the reverse order is happening...

I am hesitant to suggest it, but what about forcing all alpha blends and transparencies to use the painter algorithm (with a depth buffer check for opaque objects)?

[stgatilov]

1 hour ago, nbohr1more said:

I am hesitant to suggest it, but what about forcing all alpha blends and transparencies to use the painter algorithm (with a depth buffer check for opaque objects)?

If you suggest something like depth buffer, then you'll eventually get at the technique called "depth peeling".

It works by rendering all translucent surfaces over and over again, rendering exactly one layer of translucent surfaces one every phase, until all layers are rendered and nothing changes.
This is quite expensive, although the true cost depends on maximum degree of overlapping.

If you suggest something like sorting surfaces from back to front on CPU, then you get a well-known unsolvable problem. The worst thing here is that when surfaces' boxes intersect, their order toggles back and forth as you run around them.

In order to perfectly solve depth sorting in general case, you have to split surfaces. For static geometry, BSP tree is the best way to do it: that's how e.g. Doom worked without depth buffer. But adding dynamic surfaces into BSP tree is still an issue.

[AluminumHaste]

@stgatilov This might be worth looking at: http://www.humus.name/index.php?page=3D&ID=92

[stgatilov]

6 minutes ago, AluminumHaste said:

@stgatilov This might be worth looking at: http://www.humus.name/index.php?page=3D&ID=92

Yes, that's exactly what I'm talking about regarding BSP tree.
World brush geometry can be put into its own BSP tree by dmap, which can be rendered in perfect back-to-front order.

UPDATE: But, even static geometry will cause problem with postprocessing surfaces. Because you have to copy renderbuffer befor every postprocessing surface rendered in order to get proper picture, and that's very expensive.

With depth peeling, you need to copy renderbuffer after every layer, if there is a chance that next layer will include postprocessing shader.

[AluminumHaste]

I was mostly posting it cause he includes the source code for implementing it. I didn't realize til after that humus switched to Directx11 instead of OpenGL.

[nbohr1more]

The discussion area for that Humus thread has an optimized variant:

https://sites.google.com/site/doronfeinstein/demos/rendering

https://sites.google.com/site/doronfeinstein/demos/rendering/OIT_OPTIMIZED11.zip?attredirects=0&d=1

[AluminumHaste]

Man Humus's website is a treasure trove of code:

http://www.humus.name/index.php?page=3D&ID=45

 

 

[AluminumHaste]

5 minutes ago, nbohr1more said:

The discussion area for that Humus thread has an optimized variant:

https://sites.google.com/site/doronfeinstein/demos/rendering

https://sites.google.com/site/doronfeinstein/demos/rendering/OIT_OPTIMIZED11.zip?attredirects=0&d=1

Interesting, the original demo runs at 14,000fps on my computer. I can't imagine how much faster his optimized version runs at.

[stgatilov]

By the way, revisions 9966 + 9967 broke test/glass map pretty bad.

It has a glass wall near starting location, which consists of 8 glass windows of different material.
Previously, it looked nice from all directions.
But now when you look them from behind, they toggle on and off as you walk around.

[Frost_Salamander]

On 7/9/2022 at 1:05 PM, AluminumHaste said:

As far as I know you should only use twosided shaders on patches, as the back side of the patch is not rendered. Brushes should use onesided shaders.

Yes thanks for that.  I didn't realize the glass materials were 2-sided.  I've changed the windows in my WIP FM to patches instead now.

In the test map, 3 of the windows are brushes, but the last one (on the far right) is a patch.

Edited July 10, 2022 by Frost_Salamander

[stgatilov]

I disabled the feature in svn rev 10033, although it can be enabled back with r_testPostprocessMultiple.

The problem is that any window with two-sided warping material previously worked fine, but now will flicker (like test/glass). Also, it seems that the original problem is not going to be solved anyway due to depth sorting problem... better have a feature with clear limitation (one layer copy) than have a randomly broken feature...