Water effects not rendered through warp glass

[stgatilov]

So if you have two similar translucent objects with different colors, they will look good from one side, but wrong from the other?

[Frost_Salamander]

1 hour ago, duzenko said:

@Frost_Salamander Are you using the exe from my link? It's supposed to be 32-bit, unlike what you reported above

 

When I tried your .exe, I got this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

You also suggested trying the 'latest development build'.  I asked if that can be obtained using tdm_installer, and you said 'yes'.  That's what I reported here: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475856

So - I am probably doing something wrong but not sure what 

[stgatilov]

In order to depth sort, it is desirable to take bounding box of surface into account.
That would allow to support world surfaces, and entities not centered at origin.

Depth sorting has one major problem: as player moves, objects order sometimes changes, which results in a hugely visible "toggling". In a sense, it is more pleasant to render surfaces in fixed order than to sort them dynamically.

Wouldn't it make sense if we apply proper sorting only for static surfaces whose bounding boxes don't intersect?
I believe it is possible to reliably decide which box should be more distance in this case.
Not sure yet what to do if boxes intersect, or how to mix it with dynamic objects: comparison must be transitive...

 

[stgatilov]

After some more consideration, it won't work, even in limited case.

Actually, nothing will help. You'll just replace one problem with another, no matter what you do.
Translucency is common problem which remains unsolved. If you have ordinary translucent objects with common material, then you can at least do some OIT (like per-pixel lists, depth peeling, or weighted approximation), but if you need to copy background, nothing of it works.

Just remember that you should not have more than one heatHaze material per view, and that if you have many translucent objects, they'll probably render in wrong order.

[stgatilov]

I think the best solution would be to save the current way of rendering objects, but allow mappers to specify tie-breakers in scripts. Don't try to make clever automatic solution, it won't work and won't be easily configurable.

If mapper really wants to get complicated translucency work, he can often get away with some simple conditions like:

• if in area Q, then render A then B, otherwise render B then A
• if coord X < 1540, then render A then B, otherwise render B then A

But for this to make sense, we need to guarantee that we won't try to tweak anything above this tie-breaker ourselves. We won't change "sort" variable in core materials, won't split its values into more classes, etc. All that tweaking that you did in the core game must be stopped, because if you continue, you'll break mapper's translucency tweaks.

[Dragofer]

I got quite good results manually reordering render order inside my lighthouse. Lamp beam > transparent windows > foggy skybox. Of course it helps that you can't really look into the lighthouse top from outside up close.

[stgatilov]

BTW, there is another solution straight from the days of the first Doom: we can use BSP to establish rendering order.

But:

1. Our BSP is too large to traverse in realtime, so we should build a separate BSP only for translucent geometry.
2. If some surface is split into chunks by BSP planes, we must not merge it back: we must retain each chunk as separate surface and order + render each chunk separately.
3. Obviously, this only works for world brushes: no entities, no patches, no models.
4. It is not obvious how to merge unsupported translucent geometry into BSP order... maybe by some origin point.
5. This requires quite serious effort on dmap + rendered frontend + integration with backend.

 

[duzenko]

We don't really need universal or fully automatic solution

If there is a workflow that allows to achieve a particular result with minimum effort from mapper it should be good enough

Some problems can even be solved on the material level

E.g. glass is safe to render after water, etc.

[duzenko]

13 hours ago, Frost_Salamander said:

When I tried your .exe, I got this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

You also suggested trying the 'latest development build'.  I asked if that can be obtained using tdm_installer, and you said 'yes'.  That's what I reported here: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475856

So - I am probably doing something wrong but not sure what 

Put the downloaded exe into the folder with the dev build and run it from there

[stgatilov]

1 hour ago, duzenko said:

We don't really need universal or fully automatic solution

Then let's remove this sort by some matrix element, and think how to allow mappers tweak order dynamically in such a way that we won't break it in future.

[duzenko]

On 7/3/2022 at 2:52 PM, stgatilov said:

Then let's remove this sort by some matrix element, and think how to allow mappers tweak order dynamically in such a way that we won't break it in future.

Umm... ok

[peter_spy]

Have you tested it performance-wise? Last time I checked, heat haze was getting more resource hungry the more pixels in player viewport it used. So sticking your nose to the glass and looking at another big heat haze surface, like a body of water or something, could be really expensive.

[Frost_Salamander]

On 7/3/2022 at 11:18 AM, duzenko said:

Put the downloaded exe into the folder with the dev build and run it from there

Sorry finally got around to trying this - it still looks like this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

[stgatilov]

@duzenko, how can mappers control render order now, including dynamically from script?

Can they set "sort" parameter directly as spawnarg?
Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value?
Can it be done in script during runtime?

[duzenko]

8 minutes ago, stgatilov said:

@duzenko, how can mappers control render order now, including dynamically from script?

Can they set "sort" parameter directly as spawnarg?
Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value?
Can it be done in script during runtime?

Sort is per material

There is additional drawSortOffset entity spawnarg that allows mapper to mark some entities to draw "a little later" but it's very rigid. I think it covers like 90% of all situations though. It's main problem is that it has to be set manually for each 'fixed' entity by mapper who must understand the technical 3D scene breakdown.

I don't know about script support and I don't think it's a good direction to take. Scripts are for game events IMHO.

Now one new thing I just noticed is we already have sort by distance for SEED objects. I wish I knew how to use it for translucents.

[duzenko]

9 hours ago, Frost_Salamander said:

Sorry finally got around to trying this - it still looks like this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

Can I have a screenshot with a console version on it? Use shift+tilde for partial console view

[stgatilov]

10 hours ago, duzenko said:

Sort is per material

There is additional drawSortOffset entity spawnarg that allows mapper to mark some entities to draw "a little later" but it's very rigid. I think it covers like 90% of all situations though. It's main problem is that it has to be set manually for each 'fixed' entity by mapper who must understand the technical 3D scene breakdown.

Well, mapper can at least establish relative order between translucent entities of same-kind material.
But I think it is not possible to do this in script right now.

Quote

I don't know about script support and I don't think it's a good direction to take. Scripts are for game events IMHO.

Yes, it is not perfect, but it should work.
It would allow "user-assisted translucency" for those who dare.

Quote

Now one new thing I just noticed is we already have sort by distance for SEED objects. I wish I knew how to use it for translucents.

I don't think there is anything like that.
Moreover, SEED is hardly a good piece of code to look for admiration...

[Frost_Salamander]

10 hours ago, duzenko said:

Can I have a screenshot with a console version on it? Use shift+tilde for partial console view

 

[nbohr1more]

You will need the latest glprog data from the SVN tree:

https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/glprogs/

[Frost_Salamander]

3 hours ago, nbohr1more said:

You will need the latest glprog data from the SVN tree:

https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/glprogs/

Isn't that in the latest dev build though (which is what I'm using for the TDM install that I'm running @duzenko's exe from)?  Also his download included a 'glprogs' folder that I also copied into my TDM installation...

[stgatilov]

I removed DSF_SORT_DEPTH flag and new sorting code.

I committed test map to assets SVN as test/5990_render.map.

I did a few adjustments to the map, most importantly set "drawSortOffset" "1" on the window: now it renders properly always.
However, this assumes that player cannot get into water: it player is inside water, then he won't see glass windows behind water obviously.

Speaking of "drawSortOffset", I think it has some issues right now:

1) I have a pool of water, and I know player cannot get into this pool since the level is too low. I'd like to make sure this piece of water renders before all the surfaces with similar material. I set "drawSortOffset" "-1" on the water, and its rendering is totally broken because it is no longer considered "postprocessing", thus framebuffer is not saved.
Setting "drawSortOffset" on the window is possible but hardly a good idea: I don't have any guarantees about window, so I should not have to tweak it.

2) drawSortOffset is an integer, so it is not very applicable to ordinary translucents. In fact, the original D3 way of tweaking translucents is by classifying them into "close", "medium", "far", but that's only possible in material. softOffset works well only for afterFog, postProcess, last classes, since their "sort" values are far from each other. But: mapper must know that he cannot set large values, or he'll break everything.

Wouldn't it be better if we:

1. Sort by "sort" class first, then by mapper's "drawSortOffset", lastly by surface index. In other words, let softOffset be tie-breaker, instead of a way to break classes in implementation-defined way.
2. Allow mappers to override "sort" class of entity by spawnarg. So if mapper decides that some object is not really "close" but should be "medium", he sets "drawSort" "medium" spawnarg on entity and this is used instead of the value from material.

I'm not even sure it p.2 is necessary. Ideally, these close/medium/far classes either should not exist, or should be totally certain so that mappers don't need to override then on per-entity basis.

[AluminumHaste]

On 6/24/2022 at 1:48 PM, Frost_Salamander said:

Sure, but I'll need you to specify exactly what you need because I don't really understand what's happening on the same level as you do. Name it and I'll add it to the map.

If it's not two-sided how do we replicate the issue?  Do you want a 'window' with only one face textured with the warp glass?

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.

[nbohr1more]

This a very cool development but I am still mystified by the strange inconsistencies:

Lords and Legacy, the windows on the left side of this screen-shot render perfectly behind the heat haze particles of the guard's torch. While the window on the right has the old behavior of only rendering the heat-haze and erasing the window material. Both windows are using the same transparent window material ( textures/darkmod/glass/clear_warp ). I wonder what can account for these different behaviors ?

I wonder if is lighting info passing from lit stages and getting modified by non-lit stages? Maybe those types of interactions need to be passed to their own buffer too? ( increase to 5 ? )

[stgatilov]

47 minutes ago, nbohr1more said:

Lords and Legacy, the windows on the left side of this screen-shot render perfectly behind the heat haze particles of the guard's torch. While the window on the right has the old behavior of only rendering the heat-haze and erasing the window material. Both windows are using the same transparent window material ( textures/darkmod/glass/clear_warp ). I wonder what can account for these different behaviors ?

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.

[duzenko]

I'm not sure how the automatic auto-incrementing counter-offset fits into this equation