View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004660 | The Dark Mod | Graphics | public | 11.11.2017 16:48 | 11.02.2024 21:31 |
Reporter | stgatilov | Assigned To | stgatilov | ||
Priority | normal | Severity | normal | Reproducibility | sometimes |
Status | suspended | Resolution | open | ||
Product Version | TDM 2.06 | ||||
Summary | 0004660: Soft shadows: sometimes light leaks near edges (in complete darkness) | ||||
Description | Sometimes surfaces become brighter near edges because of soft shadows. I'm speaking about the case when all surfaces are dark around the edge, and everything should be in shadow. NOTE: this is not about the famous halo effect. | ||||
Steps To Reproduce | See screenshot from "Patently Dangerous". It is in the outside area near the beginning of the mission. | ||||
Tags | shadows | ||||
Attached Files | 4660_draw_stencil.cpp (8,529 bytes)
/***************************************************************************** The Dark Mod GPL Source Code This file is part of the The Dark Mod Source Code, originally based on the Doom 3 GPL Source Code as published in 2011. The Dark Mod Source Code is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. For details, see LICENSE.TXT. Project: The Dark Mod (http://www.thedarkmod.com/) ******************************************************************************/ #include "precompiled.h" #include "tr_local.h" #include "glsl.h" /* ============================================================================== BACK END RENDERING OF STENCIL SHADOWS ============================================================================== */ /* ===================== RB_T_Shadow the shadow volumes face INSIDE ===================== */ static void RB_T_Shadow( const drawSurf_t *surf ) { GL_CheckErrors(); const srfTriangles_t *tri; // set the light position if we are using a vertex program to project the rear surfaces if ( surf->space != backEnd.currentSpace ) { idVec4 localLight; R_GlobalPointToLocal( surf->space->modelMatrix, backEnd.vLight->globalLightOrigin, localLight.ToVec3() ); localLight.w = 0.0f; if ( r_useGLSL.GetBool() ) qglUniform4fv( stencilShadowShader.lightOrigin, 1, localLight.ToFloatPtr() ); else qglProgramEnvParameter4fvARB( GL_VERTEX_PROGRAM_ARB, PP_LIGHT_ORIGIN, localLight.ToFloatPtr() ); } tri = surf->backendGeo; if ( !tri->shadowCache ) { return; } qglVertexAttribPointer( 0, 4, GL_FLOAT, false, sizeof( shadowCache_t ), vertexCache.Position( tri->shadowCache ) ); // we always draw the sil planes, but we may not need to draw the front or rear caps int numIndexes; bool external = false; if ( !r_useExternalShadows.GetInteger() ) { numIndexes = tri->numIndexes; } else if ( r_useExternalShadows.GetInteger() == 2 ) { // force to no caps for testing numIndexes = tri->numShadowIndexesNoCaps; } else if ( !(surf->dsFlags & DSF_VIEW_INSIDE_SHADOW) ) { // if we aren't inside the shadow projection, no caps are ever needed needed numIndexes = tri->numShadowIndexesNoCaps; external = true; } else if ( !backEnd.vLight->viewInsideLight && !(surf->backendGeo->shadowCapPlaneBits & SHADOW_CAP_INFINITE) ) { // if we are inside the shadow projection, but outside the light, and drawing // a non-infinite shadow, we can skip some caps if ( backEnd.vLight->viewSeesShadowPlaneBits & surf->backendGeo->shadowCapPlaneBits ) { // we can see through a rear cap, so we need to draw it, but we can skip the // caps on the actual surface numIndexes = tri->numShadowIndexesNoFrontCaps; } else { // we don't need to draw any caps numIndexes = tri->numShadowIndexesNoCaps; } external = true; } else { // must draw everything numIndexes = tri->numIndexes; } // set depth bounds if ( glConfig.depthBoundsTestAvailable && r_useDepthBoundsTest.GetBool() ) { qglDepthBoundsEXT( surf->scissorRect.zmin, surf->scissorRect.zmax ); } // debug visualization if ( r_showShadows.GetInteger() ) { if ( r_showShadows.GetInteger() == 3 ) { if ( external ) { qglColor3f( 0.1 / backEnd.overBright, 1 / backEnd.overBright, 0.1 / backEnd.overBright ); } else { // these are the surfaces that require the reverse qglColor3f( 1 / backEnd.overBright, 0.1 / backEnd.overBright, 0.1 / backEnd.overBright ); } } else { // draw different color for turboshadows if ( surf->backendGeo->shadowCapPlaneBits & SHADOW_CAP_INFINITE ) { if ( numIndexes == tri->numIndexes ) { qglColor3f( .5 / backEnd.overBright, 0.1 / backEnd.overBright, 0.1 / backEnd.overBright ); } else { qglColor3f( .5 / backEnd.overBright, 0.4 / backEnd.overBright, 0.1 / backEnd.overBright ); } } else { if ( numIndexes == tri->numIndexes ) { qglColor3f( 0.1 / backEnd.overBright, 1 / backEnd.overBright, 0.1 / backEnd.overBright ); } else if ( numIndexes == tri->numShadowIndexesNoFrontCaps ) { qglColor3f( 0.1 / backEnd.overBright, 1 / backEnd.overBright, 0.6 / backEnd.overBright ); } else { qglColor3f( 0.6 / backEnd.overBright, 1 / backEnd.overBright, 0.1 / backEnd.overBright ); } } } qglStencilOp( GL_KEEP, GL_KEEP, GL_KEEP ); qglDisable( GL_STENCIL_TEST ); GL_Cull( CT_TWO_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); GL_Cull( CT_FRONT_SIDED ); qglEnable( GL_STENCIL_TEST ); GL_CheckErrors(); return; } // patent-free work around if ( !external ) { // depth-fail stencil shadows if ( r_useTwoSidedStencil.GetBool() && glConfig.twoSidedStencilAvailable ) { qglStencilOpSeparate( backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, tr.stencilDecr, GL_KEEP ); qglStencilOpSeparate( backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, tr.stencilIncr, GL_KEEP ); GL_Cull( CT_TWO_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); } else { // "preload" the stencil buffer with the number of volumes // that get clipped by the near or far clip plane qglStencilOp( GL_KEEP, tr.stencilDecr, tr.stencilDecr ); GL_Cull( CT_FRONT_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); qglStencilOp( GL_KEEP, tr.stencilIncr, tr.stencilIncr ); GL_Cull( CT_BACK_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); } } else { // traditional depth-pass stencil shadows if ( r_useTwoSidedStencil.GetBool() && glConfig.twoSidedStencilAvailable ) { qglStencilOpSeparate( backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, GL_KEEP, tr.stencilIncr ); qglStencilOpSeparate( backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, GL_KEEP, tr.stencilDecr ); GL_Cull( CT_TWO_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); } else { qglStencilOp( GL_KEEP, GL_KEEP, tr.stencilIncr ); GL_Cull( CT_FRONT_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); qglStencilOp( GL_KEEP, GL_KEEP, tr.stencilDecr ); GL_Cull( CT_BACK_SIDED ); RB_DrawShadowElementsWithCounters( tri, numIndexes ); } } GL_CheckErrors(); } /* ===================== RB_StencilShadowPass Stencil test should already be enabled, and the stencil buffer should have been set to 128 on any surfaces that might receive shadows ===================== */ void RB_StencilShadowPass( const drawSurf_t *drawSurfs ) { if ( !r_shadows.GetBool() ) { return; } if ( !drawSurfs ) { return; } RB_LogComment( "---------- RB_StencilShadowPass ----------\n" ); globalImages->BindNull(); // for visualizing the shadows switch ( r_showShadows.GetInteger() ) { case -1: GL_State( /*GLS_DEPTHMASK |/**/ GLS_COLORMASK | GLS_ALPHAMASK | GLS_DEPTHFUNC_LESS ); break; case 1: // draw filled in GL_State( GLS_DEPTHMASK | GLS_SRCBLEND_ONE | GLS_DSTBLEND_ONE | GLS_DEPTHFUNC_LESS ); break; case 2: GL_State( GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO | GLS_POLYMODE_LINE | GLS_DEPTHFUNC_ALWAYS ); break; case 3: GL_State( GLS_SRCBLEND_ONE | GLS_DSTBLEND_ZERO | GLS_POLYMODE_LINE | GLS_DEPTHFUNC_LESS ); break; default: // don't write to the color buffer, just the stencil buffer GL_State( GLS_DEPTHMASK | GLS_COLORMASK | GLS_ALPHAMASK | GLS_DEPTHFUNC_LESS ); break; } if ( r_softShadowsQuality.GetBool() && !r_shadowPolygonFactor.GetBool() ) { qglPolygonOffset ( 1.0f, -r_shadowPolygonOffset.GetFloat() ); qglEnable ( GL_POLYGON_OFFSET_FILL ); } else { if ( r_shadowPolygonFactor.GetFloat() || r_shadowPolygonOffset.GetFloat() ) qglPolygonOffset( r_shadowPolygonFactor.GetFloat(), -r_shadowPolygonOffset.GetFloat() ); qglEnable( GL_POLYGON_OFFSET_FILL ); } qglStencilFunc( GL_ALWAYS, 1, 255 ); if ( glConfig.depthBoundsTestAvailable && r_useDepthBoundsTest.GetBool() ) qglEnable( GL_DEPTH_BOUNDS_TEST_EXT ); RB_RenderDrawSurfChainWithFunction( drawSurfs, RB_T_Shadow ); GL_Cull( CT_FRONT_SIDED ); if ( r_shadowPolygonFactor.GetFloat() || r_shadowPolygonOffset.GetFloat() ) qglDisable( GL_POLYGON_OFFSET_FILL ); if ( glConfig.depthBoundsTestAvailable && r_useDepthBoundsTest.GetBool() ) qglDisable( GL_DEPTH_BOUNDS_TEST_EXT ); qglStencilOp( GL_KEEP, GL_KEEP, GL_KEEP ); if ( !r_softShadowsQuality.GetBool() || backEnd.viewDef->renderView.viewID < TR_SCREEN_VIEW_ID ) qglStencilFunc( GL_GEQUAL, 128, 255 ); } | ||||
related to | 0004851 | resolved | cabalistic | Soft shadows with multisampling produces sparklies near wall edges |
I don't understand where the algorithm manages to find unshadowed pixels near the edges. It seems to me that all the pixels surrounding the edge are in shadow, and I don't see any bright pixels without soft shadows. I have found a workaround, which fixes the problem completely in this case. I'm pretty sure it should work well in other cases. It is: increase polygon offset for shadow volumes rendering. The default settings are: r_shadowPolygonOffset -1 r_shadowPolygonFactor 0 The issue does not happen with either this: r_shadowPolygonOffset -10 r_shadowPolygonFactor 0 or with this: r_shadowPolygonOffset -1 r_shadowPolygonFactor 1 |
|
Duzenko, could you guess where unshadowed pixels come from? Is there any easy debug-way to see the contents of stencil buffer on screen? |
|
You can visualize the stencil texture via interaction.fs provided you have a non-zero in r_softshadowsquality. Base value sampled from u_stencilTexture is 128. 129 is one shadow-deep, etc. |
|
Added debug stencil visualizer in the end of StencilSoftShadow in interaction.fs. Ran out of time with it but it looks like a driver bug. If sampling from base texcoord then it returns a correct value. If sampling from base texcoord + const offset then it returns noise for some pixels. |
|
What if stencil buffer really contains white pixels there, but we do not see them, because those pixels are not rendered with this face? I also tried showing stencil buffer contents, and they are black for unshifted case and contains white for shifted case. I suspect that stencil buffer there is really wrong, but we do not see it with such a way of debug visualization. |
|
Added stencil.png, where you can see white lines somewhere. Those lines are blurred and generate the artifacts. If you increase polygon offset for shadow volumes (as suggested above), those lines disappear. P.S. To be honest, I wonder how I got this picture. On previous attempt, I did not saw the lines there... |
|
Ok, I see those white lines in stencil buffer only when r_useFBO is disabled. I also have 2xAA in effect in this case. When I enable r_useFBO, these lines disappear. But the issue appears regardless of r_useFBO. | |
Hmm. I wonder if GL_EXT_polygon_offset_clamp could be used to enhance r_shadowPolygonOffset ? https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_polygon_offset_clamp.txt https://image.slidesharecdn.com/siggraphkilgardnvidiaopenglin2017-170731201008/95/nvidia-opengl-46-in-2017-40-638.jpg?cb=1502125537 |
|
Is there any problem in using "r_shadowPolygonFactor 1" without any clamping? | |
I don't think so. Shadow Polygon Offset 1 probably good enough in 99.9999% of cases. I just remembered seeing GL_EXT_polygon_offset_clamp awhile back and thought I would ping Duzenko to see if it looks useful. We manually adjusted regular surface offset factors in 2.03 so I don't see why we can't change shadow polygon offsets in 2.06. Does the change cause any adverse effects when soft shadows aren't enabled? (I doubt it). |
|
So you suspect stencil might not have the default value for pixels not on the interaction faces? The only way to test that is to draw a full screen quad. I will try that when I have the time. Thanks Nbohr1more for bringing depth test in the conversation. When I think about it the noise did look a lot like depth fighting. |
|
I had to fix the no-primary-fbo soft-shadow operation first on Intel so did not have the time for fullscreen quads tonight but in the process I noticed this thing. I start with primary fbo off and SS on. Glitch is there. I turn the primary fbo on -> glitch goes away. I turn off the P-FBO off -> glitch does not come back. How does it go for you? Also, please test that I did not break the non-Intel path while fixing on Intel. |
|
The latest build still renders just fine on Nvidia. That said, I will relay that the first note on "Closemouthed Shadows" has some sorta rendering issue with a self-shadow that doesn't exist when you enable f_useFBO. |
|
VanishedOne wrote me about two places where he saw light leaking with soft shadows only, and in both places setting "r_shadowPolygonFactor 1" fixed the issue. Maybe we simply change r_shadowPolygonFactor to 1 by default and see how the beta continues? |
|
I noticed hairline polygon cracks in the shadows for the first guard in "The Thieves" when setting r_shadowPolygonFactor 1 without soft shadows but I haven't noticed any widespread problems with the setting. I guess, ideally, this would hard code to 0 if soft shadows are off? At the very least, it should be set to cvar_archive so that you can save your preferred setting from session to session. |
|
All these cvars which must behave differently depending on other cvars is too complicated, isn't it? If setting cvar to 1 is not an option, then it would be better to remove the cvar, and compute it on-demand depending on soft shadows cvars. But this reduces game tweakability... Alternatively, we can add value -1, which means something like "auto" or "default", and make if default. And in this case effectively set 0 or 1 depending on soft shadows presence. |
|
I like your last idea "-1 == auto" I'm not terribly inclined to object to a default of 1 either as long as the cvar can be archived and we inform users about the caveats of the new default with hard shadows. |
|
After some consideration, this idea is weird. Value -1 is quite valid for polygon offset factor: it is just the same as value 1, but with offsetting to the opposite side. One the other hand, we can set default value of r_shadowPolygonFactor to be "default", and then check for it everywhere. But it is rather awkward to set string value to a float variable =) |
|
Ok, I have checked the Thieves mission and I understand what you mean. It seems that those artifacts are caused by using offsetfactor. This is because offset is different for adjacent faces of the mesh (unless they are parallel), so a crack appears between them. For instance, it is described here: https://www.opengl.org/discussion_boards/archive/index.php/t-147627.html To be honest, I do not feel that depth fighing the real issue here. Maybe we should simply leave things as they are? at least until we understand where this light comes from... |
|
Easy workaround for 2.06 Set the cvars to CVAR_ARCHIVE in RenderSystem_init.cpp idCVar r_shadowPolygonOffset( "r_shadowPolygonOffset", "-1", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "bias value added to depth test for stencil shadow drawing" ); idCVar r_shadowPolygonFactor( "r_shadowPolygonFactor", "0", CVAR_RENDERER | CVAR_FLOAT | CVAR_ARCHIVE, "scale value for stencil shadow drawing" ); Let user know they can cure some shadow leakage via r_shadowPolygonFactor 1. Move bug to 2.07 for further investigation. |
|
I tried disabled culling for stencil visualization but failed. What works for me is r_showshadows 1 and then step inside the building corner shadow. (also r_singlelight 87 helps here) Screenshot attached What I can see here is a shadow surface flickering on top of the wall, classic depth fighting case. One way to fix it is to merge both corner walls in one surface so it casts a single shadow. I'm not sure what the flickering surface is - is it SV front cap or ??? |
|
Current version appears to be able to render the back faces for stencil debugging. I set r_lightallbackfaces as exe run parameters in VS debugging options or alternatively you can quick save/load after toggling it on the fly. Attached screenshot with stencil visualization on both front and back faces. |
|
If you disable r_useFBO, then you will see the same issue without any flickering. Stencil buffer contains zero inside the wall. At least that is what I see when I use your debug code with X shift and without FBO. It seems this effect shows every time you have a wall, and some static box object at zero distance from it (i.e. sharing a plane). In such case there is a whole vertical line which makes a reflex angle between the wall and the object. If you place a light in front of the object, so the the line is in shadow, then you get this light leaking. I have tried to position a candle near several static objects close to walls, and I can reproduce it in all cases. EDIT: Ok, not in all cases. But in many cases the issue shows up. |
|
Added a new image (LeakAgain) near the fountain. In this case the issue happens only with r_useFBO 0. I suppose that there is something wrong with rendering stencil in such cases, but it leads to different results in FBO and non-FBO cases. Like if some buffer is not cleared between frames or something like that. |
|
The problem disappears if I dmap the map with shadowOptLevel set to SO_NONE instead of SO_MERGE_SURFACES. Strangely enough, this is true even if R_CreateShadowVolume is called with SO_STATIC, so the key difference is not in R_CreateShadowVolume. | |
Halo reduction shaders 15171, 15172, 15173 have significantly reduced this problem but it still persists. r_shadowPolygonFactor 1 is still the best option |
|
I think this is a pretty easy workaround: draw_stencil.cpp // If softshadows is enabled and r_shadowPolygonFactor is 0 change it to 1 // otherwise carry on using the cvars as originally intended if ( r_softShadowsQuality.GetBool() && !r_shadowPolygonFactor.GetBool() ) { qglPolygonOffset ( 1.0f, -r_shadowPolygonOffset.GetFloat() ); qglEnable (GL_POLYGON_OFFSET_FILL); } else { if ( r_shadowPolygonFactor.GetFloat() || r_shadowPolygonOffset.GetFloat() ) qglPolygonOffset( r_shadowPolygonFactor.GetFloat(), -r_shadowPolygonOffset.GetFloat() ); qglEnable( GL_POLYGON_OFFSET_FILL ); } Edit: seems to work as expected (edited version attached) |
|
We still know that "r_shadowPolygonFactor 1" adds issues to stencil shadows. So this workaround is not perfect. Besides, no one knows why the problem exists, and how this workaround hides it. |
|
In the above, we aren't really changing the cvar though. We are changing it's affect on the renderer so the cvar remains at 0 but the renderer acts as if it's 1. It's basically a blacklist for a value-combo we know to be broken. "Never let Polygon Factor = 0 if soft shadows is on". I think this would reduce a lot of confusion for end users in 2.06 and we could do a deeper dive in 2.07? |
|
In Patently Dangerous 2.07\SVN this problem barely exists now. It is also cured in Shadow Map mode. I suggest we move this to 2.08 or remove the release version target and suspend it. |
|
I don't mind. The problem seems to happen rarely, and we did not manage to fully understand why it happens despite much time. The anti-halo patch diminishes the problem, and shadow maps are not affected at all. |
|
Is this the same issue? http://forums.thedarkmod.com/topic/19774-beta-testing-207/?p=433190 |
|
I recall I looked into STiFU's case at some moment, and it was indeed the same issue. I guess it can be put off the roadmap, because despite much time and effort, it is not clear what's wrong exactly. Luckily, the problem does not appear too often =( |
|
Date Modified | Username | Field | Change |
---|---|---|---|
11.11.2017 16:48 | stgatilov | New Issue | |
11.11.2017 16:48 | stgatilov | Status | new => assigned |
11.11.2017 16:48 | stgatilov | Assigned To | => stgatilov |
11.11.2017 16:48 | stgatilov | File Added: PatentlyDangerous_SoftShadows_EdgeLeak.jpg | |
11.11.2017 16:53 | stgatilov | Note Added: 0009575 | |
11.11.2017 16:55 | stgatilov | Note Added: 0009576 | |
11.11.2017 16:55 | stgatilov | File Added: Quicksave_0.save | |
11.11.2017 16:56 | stgatilov | File Added: Quicksave_0.jpg | |
12.11.2017 19:42 | duzenko | Note Added: 0009585 | |
13.11.2017 11:43 | duzenko | Note Added: 0009597 | |
13.11.2017 11:43 | duzenko | Note Edited: 0009597 | |
13.11.2017 15:29 | stgatilov | Note Added: 0009598 | |
13.11.2017 15:39 | stgatilov | File Added: stencil.png | |
13.11.2017 15:40 | stgatilov | Note Added: 0009599 | |
13.11.2017 16:14 | stgatilov | Note Added: 0009601 | |
13.11.2017 16:24 | nbohr1more | Note Added: 0009602 | |
13.11.2017 16:49 | stgatilov | Note Added: 0009603 | |
13.11.2017 17:05 | nbohr1more | Note Added: 0009604 | |
13.11.2017 17:11 | nbohr1more | Note Edited: 0009604 | |
13.11.2017 19:22 | duzenko | Note Added: 0009605 | |
13.11.2017 19:22 | duzenko | Note Edited: 0009605 | |
13.11.2017 20:21 | duzenko | Note Added: 0009606 | |
14.11.2017 02:00 | nbohr1more | Note Added: 0009609 | |
20.11.2017 05:33 | stgatilov | Note Added: 0009642 | |
20.11.2017 05:52 | nbohr1more | Note Added: 0009643 | |
20.11.2017 16:14 | stgatilov | Note Added: 0009644 | |
20.11.2017 16:50 | nbohr1more | Note Added: 0009645 | |
21.11.2017 17:14 | stgatilov | Note Added: 0009663 | |
21.11.2017 17:47 | stgatilov | Note Added: 0009664 | |
21.11.2017 18:18 | nbohr1more | Note Added: 0009665 | |
21.11.2017 18:19 | nbohr1more | Note Edited: 0009665 | |
21.11.2017 18:19 | nbohr1more | Note Edited: 0009665 | |
22.11.2017 04:28 | stgatilov | Target Version | => TDM 2.07 |
22.11.2017 11:46 | duzenko | Note Added: 0009673 | |
22.11.2017 11:46 | duzenko | File Added: Untitled.jpg | |
22.11.2017 11:50 | duzenko | Note Edited: 0009673 | |
23.11.2017 10:14 | duzenko | Note Added: 0009680 | |
23.11.2017 10:15 | duzenko | File Deleted: Untitled.jpg | |
23.11.2017 10:15 | duzenko | File Added: Untitled.jpg | |
23.11.2017 17:19 | stgatilov | Note Added: 0009685 | |
23.11.2017 17:20 | stgatilov | Note Edited: 0009685 | |
23.11.2017 17:20 | stgatilov | Note Edited: 0009685 | |
23.11.2017 17:22 | stgatilov | Note Edited: 0009685 | |
23.11.2017 17:25 | stgatilov | File Added: PatentlyDangerous_LeakAgain.jpg | |
23.11.2017 17:28 | stgatilov | Note Added: 0009686 | |
24.11.2017 06:05 | stgatilov | Note Added: 0009687 | |
26.04.2018 03:04 | nbohr1more | Note Added: 0010402 | |
10.05.2018 01:58 | nbohr1more | Note Added: 0010456 | |
10.05.2018 01:59 | nbohr1more | Status | assigned => feedback |
10.05.2018 02:08 | nbohr1more | Note Edited: 0010456 | |
10.05.2018 02:36 | nbohr1more | Note Edited: 0010456 | |
10.05.2018 02:36 | nbohr1more | Note Edited: 0010456 | |
10.05.2018 03:10 | nbohr1more | File Added: 4660_draw_stencil.cpp | |
10.05.2018 03:10 | nbohr1more | Note Edited: 0010456 | |
10.05.2018 16:23 | stgatilov | Note Added: 0010459 | |
10.05.2018 16:23 | stgatilov | Status | feedback => assigned |
10.05.2018 16:31 | nbohr1more | Note Added: 0010460 | |
25.06.2018 06:11 | stgatilov | Relationship added | related to 0004851 |
11.12.2018 03:06 | nbohr1more | Note Added: 0010865 | |
11.12.2018 03:06 | nbohr1more | Status | assigned => feedback |
11.12.2018 04:10 | stgatilov | Note Added: 0010867 | |
11.12.2018 04:10 | stgatilov | Status | feedback => assigned |
11.12.2018 04:21 | nbohr1more | Target Version | TDM 2.07 => TDM 2.08 |
20.01.2019 14:12 | STiFU | Note Added: 0011445 | |
18.05.2019 08:13 | stgatilov | Status | assigned => suspended |
15.05.2020 14:07 | nbohr1more | Target Version | TDM 2.08 => TDM 2.09 |
17.12.2020 03:52 | stgatilov | Note Added: 0013152 | |
17.12.2020 03:52 | stgatilov | Target Version | TDM 2.09 => |
11.02.2024 21:31 | Fiver | Tag Attached: shadows |