nbohr1more 2239 Posted January 31 Report Share Posted January 31 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 ? Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
duzenko 668 Posted January 31 Report Share Posted January 31 2 hours ago, nbohr1more said: This was almost certainly caused by 2.06 beta revision 7351 @duzenko ? Doubt that getviewpos? Quote Link to post Share on other sites
nbohr1more 2239 Posted January 31 Author Report Share Posted January 31 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. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
duzenko 668 Posted January 31 Report Share Posted January 31 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. 1 Quote Link to post Share on other sites
nbohr1more 2239 Posted February 1 Author Report Share Posted February 1 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 ? 1 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
duzenko 668 Posted February 6 Report Share Posted February 6 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 Quote Link to post Share on other sites
duzenko 668 Posted February 6 Report Share Posted February 6 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) 1 Quote Link to post Share on other sites
nbohr1more 2239 Posted February 7 Author Report Share Posted February 7 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? 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
peter_spy 1615 Posted February 7 Report Share Posted February 7 (edited) 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 Quote Misc. assets for TDM Link to post Share on other sites
duzenko 668 Posted February 7 Report Share Posted February 7 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 1 Quote Link to post Share on other sites
peter_spy 1615 Posted February 7 Report Share Posted February 7 (edited) . Edited February 7 by peter_spy Quote Misc. assets for TDM Link to post Share on other sites
nbohr1more 2239 Posted February 7 Author Report Share Posted February 7 @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? 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
duzenko 668 Posted February 7 Report Share Posted February 7 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. Quote Link to post Share on other sites
nbohr1more 2239 Posted February 7 Author Report Share Posted February 7 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. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
nbohr1more 2239 Posted February 7 Author Report Share Posted February 7 Confirmed that the fix also fixes issues in: Penny Dreadful 2 Sir Talbot's Collatoral Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to post Share on other sites
stgatilov 1319 Posted February 15 Report Share Posted February 15 @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. 2 Quote Link to post Share on other sites
peter_spy 1615 Posted February 15 Report Share Posted February 15 (edited) 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 Quote Misc. assets for TDM Link to post Share on other sites
duzenko 668 Posted February 15 Report Share Posted February 15 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. 1 Quote Link to post Share on other sites
duzenko 668 Posted February 15 Report Share Posted February 15 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. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.