Skybox rendered to indoor reflective textures

[nbohr1more 2239]

On 8/1/2020 at 7:57 PM, Silverflame3 said:

Hey, sorry for the long wait, I tried to delete the Darmod.cfg completely and let the game create a new one upon starting, and the issue persisted. I captured a few screenshots I will attach under the spoiler. they are all captured inside the arsenal building, two up at the kitchen, the other two in the basement, near the grate with the arrow next to it.

  Hide contents

https://ibb.co/72JKmzq
https://ibb.co/pxmcxWF
https://ibb.co/0BwkJ2k
https://ibb.co/1qmPDn3

It might not be obvious on all pictures, but I've tried to capture the reflection of the moon in the skybox inside a building that had a very clear defined roof above the surface with the reflection.

This was almost certainly caused by 2.06 beta revision 7351 @duzenko ?

[duzenko 668]

2 hours ago, nbohr1more said:

This was almost certainly caused by 2.06 beta revision 7351 @duzenko ?

Doubt that

getviewpos?

[nbohr1more 2239]

5 hours ago, duzenko said:

Doubt that

getviewpos?

5730.23 977.48 3.78 : 33.77 -4.2 0

Look at the reflective puddle and you will see the stars and moon from the skybox reflected there.

I suspect that (currently) the only way to prevent this is to portal the area off from the skybox completely so that the

skybox is not available to the reflective surfaces. There needs to be a line-of-sight check or a material flag to disable this behavior.

[duzenko 668]

3 hours ago, nbohr1more said:

5730.23 977.48 3.78 : 33.77 -4.2 0

Look at the reflective puddle and you will see the stars and moon from the skybox reflected there.

I suspect that (currently) the only way to prevent this is to portal the area off from the skybox completely so that the

skybox is not available to the reflective surfaces. There needs to be a line-of-sight check or a material flag to disable this behavior.

Seems like a frontend bug, seemingly related to the hot bugtracker ticket - g_stopTime 0/1 appears to affect this as well.

[nbohr1more 2239]

On 1/31/2021 at 1:32 PM, duzenko said:

Seems like a frontend bug, seemingly related to the hot bugtracker ticket - g_stopTime 0/1 appears to affect this as well.

The  g_stopTime bug would only affects this because all portalsky rendering dies when time is stopped and this mission has a portalsky. Also, that "bug" may be a bit of a red herring because I went back and tested versions as old as TDM 1.07 up to the present and found that the same behavior persists. g_stopTime kills all portalsky rendering. The reason why someone might believe that this is new is that not all skyboxes are portalsky type. For example "Special Delivery" uses a skybox that is not a portalsky and it renders perfectly with g_stopTime even in the latest beta. ( I was a busy boy today ).

2.07 beta 1  ( rev 7836 ) has the same issue so we need to bisect from 2.06 to that revision.

 

some bounds:

 

Rev 7351 dec 20 2017
Rev 7768 nov 27 2018 Assets 15391

 

Edit:

Couldn't start the windows binary from 15391 via wine but linux binary 7742 does not have the issue.

Edit 2:

Scons compiling was broken for a awhile during 2.07 but when it was restored at Rev 7814 Assets 15414 the bug was there. going to get Rev 7768 files and backport to 7814

Edit 3:

Backport of 7768 still has the bug

Edit 4:

Backporting 7638 tr_subview to 7814 fixes the issue. The bug was introduced in 7768.

Edit 5:

It's either:

R_PortalRender

parms->superView = tr.viewDef;
parms->subviewSurface = surf;

or

if ( tr.viewDef->superView && tr.viewDef->superView->isSubview ) // #4615 HOM effect - only draw mirrors from player's view and top-level asubviews

Gonna try reverting to:

if ( tr.viewDef->isSubview )

Yes, that fixes it... but what does it break?

@duzenko ?

[duzenko 668]

On 2/1/2021 at 7:25 AM, nbohr1more said:

The  g_stopTime bug would only affects this because all portalsky rendering dies when time is stopped and this mission has a portalsky. Also, that "bug" may be a bit of a red herring because I went back and tested versions as old as TDM 1.07 up to the present and found that the same behavior persists. g_stopTime kills all portalsky rendering. The reason why someone might believe that this is new is that not all skyboxes are portalsky type. For example "Special Delivery" uses a skybox that is not a portalsky and it renders perfectly with g_stopTime even in the latest beta. ( I was a busy boy today ).

2.07 beta 1  ( rev 7836 ) has the same issue so we need to bisect from 2.06 to that revision.

 

some bounds:

 

Rev 7351 dec 20 2017
Rev 7768 nov 27 2018 Assets 15391

 

Edit:

Couldn't start the windows binary from 15391 via wine but linux binary 7742 does not have the issue.

Edit 2:

Scons compiling was broken for a awhile during 2.07 but when it was restored at Rev 7814 Assets 15414 the bug was there. going to get Rev 7768 files and backport to 7814

Edit 3:

Backport of 7768 still has the bug

Edit 4:

Backporting 7638 tr_subview to 7814 fixes the issue. The bug was introduced in 7768.

Edit 5:

It's either:

R_PortalRender

parms->superView = tr.viewDef;
parms->subviewSurface = surf;

or

if ( tr.viewDef->superView && tr.viewDef->superView->isSubview ) // #4615 HOM effect - only draw mirrors from player's view and top-level asubviews

Gonna try reverting to:

if ( tr.viewDef->isSubview )

Yes, that fixes it... but what does it break?

@duzenko ?

Busy week at work and at home

My head hurts (maybe butt too) when I'm looking at that portal sky game code

Need some vodka before diving in

[duzenko 668]

Did you know the portal sky here has a reflective water in the bottom?

Just wondering if anyone at all has noticed it, even though everyone has paid a performance price to render it every frame.

@nbohr1more

@Melan

@Bikerdude

I believe this needs to be fixed on the FM level. Here's the technical explanation:

At the view pos where this bug happens we have two mirrors rendered every frame

1. the small puddle in the room; material name is "textures/darkmod/decals/dirt/puddle" from "materials/tdm_yan_textures.mtr"

2. the bigly "sea" in the skybox; material name Decl "textures/water_source/cave_water_reflective_01" from "materials/tdm_water.mtr"

Not sure but you can check whether the two are the core assets

Anyway, both mirror materials reference the same render output texture: '_scratch'

Regretfully, the second mirror render overwrites the first one, so the puddle paints with the "outdoor sea" texture.

The good news is, it has nothing to do with g_stopTime, the game code, or portalSky entity area traversal at all :)

As the simplest fix I would suggest replacing the skybox sea material with a custom one. Consider removing the sea mirror at all since no one can see it (unless I'm mistaken here)

[nbohr1more 2239]

10 hours ago, duzenko said:

Did you know the portal sky here has a reflective water in the bottom?

Just wondering if anyone at all has noticed it, even though everyone has paid a performance price to render it every frame.

@nbohr1more

@Melan

@Bikerdude

I believe this needs to be fixed on the FM level. Here's the technical explanation:

At the view pos where this bug happens we have two mirrors rendered every frame

1. the small puddle in the room; material name is "textures/darkmod/decals/dirt/puddle" from "materials/tdm_yan_textures.mtr"

2. the bigly "sea" in the skybox; material name Decl "textures/water_source/cave_water_reflective_01" from "materials/tdm_water.mtr"

Not sure but you can check whether the two are the core assets

Anyway, both mirror materials reference the same render output texture: '_scratch'

Regretfully, the second mirror render overwrites the first one, so the puddle paints with the "outdoor sea" texture.

The good news is, it has nothing to do with g_stopTime, the game code, or portalSky entity area traversal at all :)

As the simplest fix I would suggest replacing the skybox sea material with a custom one. Consider removing the sea mirror at all since no one can see it (unless I'm mistaken here)

I tried changing _scratch to _scratch2
 

//Author: Dram
textures/water_source/cave_water_reflective_01
{
    qer_editorimage textures/glass/glass1
    translucent
    noshadows
    nonsolid
        description "broken? Creates mirror effect, but has no rippling and objects don't make splashes"

    {
        blend    blend
        mirrorRenderMap 1024 1024
        program fresnel.vfp
        vertexParm    0    0.6
        fragmentMap    0    _scratch2
    }
}

It did not remove the skybox from the puddle...

Also, there is no _scratch texture in the puddle def:
 

textures/darkmod/decals/dirt/puddle
{
    qer_editorimage textures/darkmod/decals/dirt/puddle_ed
    noShadows
    noimpact
    translucent
    
    {    
        blend GL_DST_COLOR, GL_SRC_COLOR
        map textures/darkmod/decals/dirt/puddle
    }

    {    
        maskColor
        map textures/darkmod/decals/dirt/puddle
    }

    {
        maskAlpha
        blend gl_dst_alpha, gl_one
        mirrorRenderMap     512 512
        translate   0.5 , 0.5
        scale   0.5 , 0.5
        red   .75 * Parm0
        green .75 * Parm1
        blue  .75 * Parm2
    }
}

Are all mirrorRenderMap operations sharing _scratch internally?

[peter_spy 1615]

Mirror render map doesn't need anything except for the keyword itself to work in such image stage. And stuff like resolution stopped working some time ago, it defaults to game resolution. Not sure what would you get by using translate in such stage, so I suppose it doesn't work either.

Edit: yup, both translate and scale is redundant, and the fresnel program and everything that goes after that can be deleted too.

Edited February 7 by peter_spy

[duzenko 668]

4 hours ago, nbohr1more said:

I tried changing _scratch to _scratch2
 

//Author: Dram
textures/water_source/cave_water_reflective_01
{
    qer_editorimage textures/glass/glass1
    translucent
    noshadows
    nonsolid
        description "broken? Creates mirror effect, but has no rippling and objects don't make splashes"

    {
        blend    blend
        mirrorRenderMap 1024 1024
        program fresnel.vfp
        vertexParm    0    0.6
        fragmentMap    0    _scratch2
    }
}

It did not remove the skybox from the puddle...

Also, there is no _scratch texture in the puddle def:
 

textures/darkmod/decals/dirt/puddle
{
    qer_editorimage textures/darkmod/decals/dirt/puddle_ed
    noShadows
    noimpact
    translucent
    
    {    
        blend GL_DST_COLOR, GL_SRC_COLOR
        map textures/darkmod/decals/dirt/puddle
    }

    {    
        maskColor
        map textures/darkmod/decals/dirt/puddle
    }

    {
        maskAlpha
        blend gl_dst_alpha, gl_one
        mirrorRenderMap     512 512
        translate   0.5 , 0.5
        scale   0.5 , 0.5
        red   .75 * Parm0
        green .75 * Parm1
        blue  .75 * Parm2
    }
}

Are all mirrorRenderMap operations sharing _scratch internally?

I understand the confusion

The material language describing subviews is quite odd, and I added to that myself when some time ago when I made the code ignore some of the material parameters while people keep trying the older examples that don't work for them any more

Do we have any docs on material language in the Wiki that you based your attempts on? If so, we need to update the docs so it's clear that

• fragmentMap sends a texture to a GL program (shader). It has no relation to what texture is used as a render target for subviews. It also has no use in 'legacy' stages (that now use shaders too internally but take their inputs from the 'classic' parameters)
• mirror subviews do not usually use GPU shaders (unless you explicitly want a fancy FX like waves or something). First thing you should do when debugging materials is to remove anything related to shaders.
• mirrorRenderMap will use _scratch if not explicitly specified otherwise in the material declaration
• mirrorRenderMap takes the material stage texture as its render output
• the keywords for material stage texture are: map, cubeMap, cameraCubeMap

Based on that, here's an example material that seems to work for me

textures/darkmod/decals/dirt/puddle
{
	qer_editorimage textures/darkmod/decals/dirt/puddle_ed
	noShadows
	noimpact
	translucent
	
	{	
		blend GL_DST_COLOR, GL_SRC_COLOR
		map textures/darkmod/decals/dirt/puddle
	}

	{	
		maskColor
		map textures/darkmod/decals/dirt/puddle
	}

	{
		maskAlpha
		blend gl_dst_alpha, gl_one
		mirrorRenderMap
		red   .75 * Parm0
		green .75 * Parm1
		blue  .75 * Parm2
		map _scratch2 // avoid conflicts with other mirrors, like skybox sea in PD3
	}
}

Having said that, I still think it's better be fixed on the FM level

 

Spoiler

 

[peter_spy 1615]

.

Edited February 7 by peter_spy

[nbohr1more 2239]

@duzenko @cabalistic

Thank you the clarifications. I will test this tonight.

That said, this does bring to mind a possible ongoing issue:

If a mapper legitimately uses a skybox with a large body of animated water and the map has an indoor area with puddles then

they will encounter this problem too. Hopefully fixing the material in to core files will avoid this but there is no guarantee that other

authors wont create new water shaders for their skybox which will again encounter this issue. Maybe we can change the _scratch

behavior so that every mirror material (etc) in the same visleaf gets it's own scratch? Too much effort given the proposed move

to probe based reflections?

[duzenko 668]

3 hours ago, nbohr1more said:

@duzenko @cabalistic

Thank you the clarifications. I will test this tonight.

That said, this does bring to mind a possible ongoing issue:

If a mapper legitimately uses a skybox with a large body of animated water and the map has an indoor area with puddles then

they will encounter this problem too. Hopefully fixing the material in to core files will avoid this but there is no guarantee that other

authors wont create new water shaders for their skybox which will again encounter this issue. Maybe we can change the _scratch

behavior so that every mirror material (etc) in the same visleaf gets it's own scratch? Too much effort given the proposed move

to probe based reflections?

The current system has a certain advantage that it forces the mapper to acknowledge multiple mirrors as a problem of its own

If many mirrors just worked out of the box, what would stop mappers from abusing it like they tend to do with everything else?

This particular map is a good example. A big mirror is rendered every frame, but few if any have noticed its existence at all.

[nbohr1more 2239]

Thank you. The material def worked.

I guess I can sorta get on-board with the idea of reducing the use this feature but ultimately we should make available

features mapper friendly so that there are clear paths to resolution. Maybe we can create more _scratch images (4)?

So that water, reflective objects, mirrors, and glass all have their own scratch.

 

[nbohr1more 2239]

Confirmed that the fix also fixes issues in:

Penny Dreadful 2

Sir Talbot's Collatoral

[stgatilov 1319]

@duzenko, @nbohr1more, thanks for explanation what this weird "map _scratch2" is about!

I was under impression that two mirror surfaces cannot work simultaneously at all.
So I assume it still does not work completely with the "map" change?

What I don't like about the fix is that it gives false impression that many mirrors could works. And to make it work one "merely" needs to choose a random scratch number which does not collide with anything else... which is obviously not maintainable, i.e. also gives false hope in some cases.

[peter_spy 1615]

Actually, you can get a mirror that reflects a view from another mirror, if you align them properly, without multiple map scratches. You just need to make sure there's only one mirror directly in player view cone. But I agree that multiple active mirrors will give way to mapper abuse and 15fps gameplay. I've already heard questions like, "can we start adding mirrors to every fancy marble floor now".

Edited February 15 by peter_spy

[duzenko 668]

37 minutes ago, stgatilov said:

@duzenko, @nbohr1more, thanks for explanation what this weird "map _scratch2" is about!

I was under impression that two mirror surfaces cannot work simultaneously at all.
So I assume it still does not work completely with the "map" change?

What I don't like about the fix is that it gives false impression that many mirrors could works. And to make it work one "merely" needs to choose a random scratch number which does not collide with anything else... which is obviously not maintainable, i.e. also gives false hope in some cases.

In fact you may actually have multiple mirrors per single storage texture, as long as they don't overlap on the view projection

This particular bug was caused by both mirrors being "on the floor", one behind the other.

I have expressed my opinion that the skybox mirror is redundant.

[duzenko 668]

Ironically, this is also a manifestation of a bigger issue that portal subviews don't get visportal-clipped which is the unfortunate luggage from the 1.x days. Some maps actually rely on it for proper sky rendering.