Game Development Community

Reflection Rendering Bug (GF 600 Series Only?)

by Henry Todd · in Torque 3D Professional · 05/11/2013 (12:14 pm) · 26 replies

I put a GF 680 in this computer several months ago and since then I haven't been getting reflections from "fullReflect" water objects. Specifically the reflections will cut out at any resolution above 1360x768 (they stop rendering if you switch to 1366x768).

At 1360x768 everything looks normal:
i.imgur.com/ZddlFmE.jpg
But at 1366x768 or higher the world reflections stop, leaving only cube map reflections (in this case I've left the default solid black cubemap to make the difference more obvious):

i.imgur.com/9Z6QZjy.jpg
Same results with 1.2 and MIT 3.0, even with the pre-built demo executables. It's also persisted through several months of driver updates. That leaves the video card as the most likely suspect (or Windows 8, which I installed at the same time).

I'm hoping that someone else here has a 600-series card and can check their water reflections for this issue. Someone with another card confirming that their reflections work fine at the same resolutions (especially on Win8) would also be helpful.
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional
Page «Previous 1 2

Duion
#1
05/11/2013 (12:46 pm)
Have that problem, too, with a gt610, had some friends test it (probably with differend graphics cards) and they said everything was fine.
For me everything higher than 800x600 tends to produce this error, not always but over this resolution it can happen, so sometimes it is flickering between on and off.

Torque Owner Jules
Something2Play
#2
05/12/2013 (2:29 am)
Tested on my 610, (2gb version) works ok. Windows 7.. I'll also check on my 650 later.

Torque Owner Jules
Something2Play
#3
05/12/2013 (3:17 am)
double checked... reflections switch off when on 16:9, had it on just 1366x768 (standard)

Duion
#4
05/12/2013 (4:18 am)
Very confusing, for me it is:
800x600 - works
1024x768 - works
1280x800 - works
1280x1024 - works not
1280x960 - works not
1360x768 - works
1440x900 - works not
1600x900 - works not
1600x1024 - works not
1920x1080 - works not

ZeroFault
Default Studio Name
#5
05/12/2013 (1:34 pm)
Tested on my GTX 670 and windows 8. I'm having the same issues. Although, I was able to get it to work on my end by disabling the useOcclusionQuery property on the waterBlock or waterPlane then reloading the level.

Torque Owner Henry Todd
Atomic Walrus
#6
05/12/2013 (3:38 pm)
@ZeroFault:

You're right, that works on my end too. I thought I tried all the options, but I must not have actually saved and reloaded.

So apparently it's an occlusion (water-specific?) bug specific to the 600 series now. Or the newer NVidia drivers that 600 series cards require possibly. I say that because GT610 is technically a Fermi chip (it's a 520 with lower power consumption), not Kepler.

I'm looking at GFXD3D9OcclusionQuery right now but I'm not really getting anywhere. At least we have a workaround now. Unfortunately the side-effect of turning off useOcclusionQuery should be that reflections are still rendering even if you're not looking at the water, if I understand its function.

Torque Owner Chad Hall
#7
07/13/2014 (8:40 pm)
Bumping this because I've just noticed it on T3D 3.5.1. I have a GTX 650 Ti running Windows 7 64 bit. Disabling occlusion query seems to fix it as stated. Anyone ever figure this out?

Torque Owner Nils Eikelenboom
Studio DimSum
#8
07/13/2014 (11:11 pm)
Also have it on my GTX 660 Ti. I've abandoned "full reflect" and only use cubemaps for reflection now. It's a bit of work to create custom cubemaps for each water object, but it's surely safer I guess :S

Edit: With safer I meant to avoid the reflection being rendered as full mirror (without transparency etc.) with certain angles, giving a blinking effect....

Torque Owner Richard Ranft
Roostertail Games
#9
07/14/2014 (6:59 am)
Does it do that in full screen mode too? All of the screenshots have the border so I'm assuming you're running in windowed mode....

Duion
#10
07/14/2014 (12:12 pm)
It does, it depends on resolution, not the mode.

Torque Owner Chad Hall
#11
07/14/2014 (7:42 pm)
Aye, fullscreen doesn't seem to affect anything, only resolution. In my case anything over 1280x800 stops working. Nothing above that works, 16:9 or not.

Torque Owner Richard Ranft
Roostertail Games
#12
07/14/2014 (10:28 pm)
That's unfortunate. And perplexing.

Azaezel
#13
07/14/2014 (11:17 pm)
Haven't spent a whole lot of time looking this one on over, but since it's related to stuff I'm poking at anyway: Confirmed the useOcclusionQuery bit. Looks like it crops up in
github.com/GarageGames/Torque3D/blob/8142a3e9645e881cd8e21434809289855e57a0b4/En.... Not going to speculate further without more research personally, but that'd be a starting point for folks to poke around themselves as well.

Edit: with github.com/Azaezel/Torque3D/tree/tsstatic_DynamicCubemaps in place for minimal-overhead testing, did note that dynamic cubemapped *standard objects* do not have the same issue, so might point to one of the PlaneReflector:: methods in the same file or related. Alternatively, could just not have enough time to run github.com/GarageGames/Torque3D/blob/8142a3e9645e881cd8e21434809289855e57a0b4/En...

Azaezel
#14
07/15/2014 (1:09 pm)
Ok, in the usual vein of 'teach a man to fish', further testing this end:
github.com/GarageGames/Torque3D/blob/8142a3e9645e881cd8e21434809289855e57a0b4/En... to
mWasOccluded = mOccluded;
         if ( status == GFXOcclusionQuery::Occluded )
            mOccluded = true;
         else if ( status == GFXOcclusionQuery::NotOccluded )
            mOccluded = false;
         if ((mWasOccluded != mOccluded)&&(!mOccluded)) Con::errorf("Rendering");
         if ((mWasOccluded != mOccluded)&&(mOccluded)) Con::errorf("Not Rendering");

Quote:
Not Rendering
Win32Window::WindowProc - resetting device due to window size change.
GFXPCD3D9Device::reset - depthstencil 113daea0 has 2 ref's
--- Resetting D3D Device ---
Rendering
Win32Window::WindowProc - resetting device due to window size change.
GFXPCD3D9Device::reset - depthstencil 113db260 has 2 ref's
--- Resetting D3D Device ---
Not Rendering
Win32Window::WindowProc - resetting device due to window size change.
GFXPCD3D9Device::reset - depthstencil 113db300 has 2 ref's
--- Resetting D3D Device ---
Rendering
pretty much nails it down as an issue with the GFXOcclusionQuery result generated at that point. Now to track down why.

Azaezel
#15
07/16/2014 (11:13 pm)
Notes:
A single waterplane or waterblock in the empty room mission is sufficient to reproduce the error.

Removing the groundplane so it's nothing but you, a skybox, and a sun still shows results in mOccluded returning true.

With a Waterblock in the same location as a waterplane, both reflect so long as the Waterblock is in view. (Note that if only the waterblock is around, same issue crops up for it.)

Analyzing the frustum culler during resolution change shows fixed values save for the aspect ratio.

Believe I'm coming to the conclusion that there may be something going pearshaped with the cached query in conjunction with that call mentioned prior.

Edit: Full context in case there's something blindingly obvious I've overlooked:
Part1
Part2
Part3
Part4
Part5
Part6
MSDN's say on the matter.

Torque Owner Chad Hall
#16
07/17/2014 (7:10 pm)
Huh, that is interesting. I get the same results. WaterBlock alongside a WaterPlane makes reflections work, but, WaterBlocks alone do nothing different.

Azaezel
#17
07/17/2014 (7:51 pm)
I AM INFORMED I AM VERY WRONG. DO NOT DO THIS. (But keeping it around so folks don't make the same mistake)


Massive, massive, massive and did I mention Massive disclaimer here that it's wip/experimental work here, but:

github.com/GarageGames/Torque3D/blob/8142a3e9645e881cd8e21434809289855e57a0b4/En...
to
GFXOcclusionQuery* getOcclusionQuery() const { return mOcclusionQuery; }
   void setOcclusionQuery(GFXOcclusionQuery* _query) { mOcclusionQuery = _query; }

github.com/GarageGames/Torque3D/blob/8142a3e9645e881cd8e21434809289855e57a0b4/En...
to
mOcclusionQuery = NULL;//GFX->createOcclusionQuery();

and Part1 From Above, because I apparently have a quota on posting that to keep.

to

GFXOcclusionQuery *query = GFX->createOcclusionQuery();
   mPlaneReflector.setOcclusionQuery(query);

   bool doQuery = ( !mPlaneReflector.mQueryPending && query && mReflectorDesc.useOcclusionQuery );

   if ( doQuery )
      query->begin();

   // Real render call, done by derived class.
   innerRender( state );

   if ( doQuery )
      query->end();   
   query->zombify();

In keeping with similar methods for github.com/GarageGames/Torque3D/blob/8142a3e9645e881cd8e21434809289855e57a0b4/En... Where it does a one-off query on an as-needed basis (And functions in the same testbed under the water failure conditions.) rather than a cached version *seems* to do the trick, though I can't help thinking that if that really was the problem, it'd crop up more often. Not to mention I'm not 100% sure just yet if there aren't side-effects I'm overlooking. (I get a bit paro this close to the metal.)

I AM INFORMED I AM VERY WRONG. DO NOT DO THIS. (But keeping it around so folks don't make the same mistake)

Torque 3D Owner Luis Anton Rebollo
#18
08/03/2014 (3:53 am)
I have dedicated some time to this weird bug.

After pass the O_o phase, i tracked the problem:
  • It's resollution dependent.
  • First frame's call to REFLECTMGR->getRefractTex() break current occlusion query.
  • Seem read from current render target when a occlusion query are active it's the problem.

    • For a simple fix i recomend call REFLECTMGR->getRefractTex() before begin the occlusion query on WaterObject::renderObject

    void WaterObject::renderObject( ObjectRenderInst *ri, SceneRenderState *state, BaseMatInstance *overrideMat )
{
   if ( overrideMat )
      return; 
   
   GFXOcclusionQuery *query = mPlaneReflector.getOcclusionQuery();

   bool doQuery = ( !mPlaneReflector.mQueryPending && query && mReflectorDesc.useOcclusionQuery );

   REFLECTMGR->getRefractTex(); // add this line

   if ( doQuery )
      query->begin();

   // Real render call, done by derived class.
   innerRender( state );

   if ( doQuery )
      query->end();   

   if ( mUnderwater && mBasicLighting )
      drawUnderwaterFilter( state );
}

  • Anyone can test the fix?
  • Anyone can reproduce this problem on a non Nvidia card?
  • A DirectX9 limitation or a driver's bug?

    • Azaezel
    #19
    08/03/2014 (8:00 am)
    Fix tested and verified, and I agree with the github comment. o_0

    Torque Owner Richard Ranft
    Roostertail Games
    #20
    08/03/2014 (10:00 am)
    Seems to be working fine on GeForce GT 640.

    Thanks!
    Page «Previous 1 2