Depth sharing Design

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.

Re: Depth sharing Design

Postby masterfalcon » Sun Apr 11, 2010 5:02 am

OMG, I'm so sorry. This is totally something that I've screwed up locally. Definitely not related to the depth sharing code.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
 
Posts: 4267
Kudos: 130
Joined: 25 Feb 2007
Location: Bloomington, MN

Re: Depth sharing Design

Postby Wolfmanfx » Sat Apr 17, 2010 1:17 am

Setup details I use a hidden RenderWindow which holds the D3D9 device then i create a window in C# and pass the window handle as externalWindow to ogre and create a render window.
Now the first render window shows up and renders correct after that i double click on the container (using an dockmanager) which destroys the old renderwindow and creates a new renderwindow with the new window handle and nothing is rendered when i resize the window sometime it renders sometime not. I posted the ogre log which shows the window creations.

This one is done with directx:
Code: Select all
02:27:10: D3D9RenderSystem::_createRenderWindow "TestRW_1", 1062x870 windowed  miscParams: externalWindowHandle=2885682 
02:27:10: D3D9 : Created D3D9 Rendering Window 'TestRW_1' : 1062x870, 32bpp
02:27:10: D3D9 : WARNING - disabling VSync in windowed mode can cause timing issues at lower frame rates, turn VSync on if you observe this problem.
02:27:10: D3D9 : WARNING - disabling VSync in windowed mode can cause timing issues at lower frame rates, turn VSync on if you observe this problem.
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT16_RGB
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT16_RGBA
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT32_RGB
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT32_RGBA
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT16_R
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT32_R
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT16_GR
02:27:14: D3D9: Vertex texture format supported - PF_FLOAT32_GR
02:27:14: Texture: default_light.png: Loading 1 faces(PF_A8R8G8B8,128x128x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,128x128x1.
02:27:14: Mesh: Loading unitBox.mesh.
02:27:14: WARNING: unitBox.mesh is an older format ([MeshSerializer_v1.40]); you should upgrade it as soon as possible using the OgreMeshUpgrade tool.
02:27:14: Loading an Atlas.
02:27:14: Atlas: Dimensions estimated as 256x512
02:27:17: Atlas loaded in 2.551 secs. Packed 1100 font glyphs and 0 textures into 256x512, with an efficiency of 63.9656%.
02:27:17: Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with  hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
02:28:34: D3D9RenderSystem::_createRenderWindow "TestRW_1", 1034x635 windowed  miscParams: externalWindowHandle=791152
02:28:34: D3D9 : Created D3D9 Rendering Window 'TestRW_1' : 1034x635, 32bpp
02:28:34: D3D9 : WARNING - disabling VSync in windowed mode can cause timing issues at lower frame rates, turn VSync on if you observe this problem.
02:28:34: D3D9 : WARNING - disabling VSync in windowed mode can cause timing issues at lower frame rates, turn VSync on if you observe this problem.
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT16_RGB
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT16_RGBA
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT32_RGB
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT32_RGBA
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT16_R
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT32_R
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT16_GR
02:28:34: D3D9: Vertex texture format supported - PF_FLOAT32_GR
02:32:21: OGRE EXCEPTION(3:RenderingAPIException): Failed to setDepthStencil : Invalid call in D3D9RenderSystem::_setViewport at ..\..\..\RenderSystems\Direct3D9\src\OgreD3D9RenderSystem.cpp (line 2909)


I also tested it with opengl. In opengl everything renders correct but it also give me some errors =>
Code: Select all
02:40:51: WARNING: Couldn't create a suited DepthBufferfor RT: TestRW_1
02:40:51: WARNING: Couldn't create a suited DepthBufferfor RT: TestRW_1
02:40:51: WARNING: Couldn't create a suited DepthBufferfor RT: TestRW_1
02:40:51: WARNING: Couldn't create a suited DepthBufferfor RT: TestRW_1
02:40:51: WARNING: Couldn't create a suited DepthBufferfor RT: TestRW_1
02:40:51: WARNING: Couldn't create a suited DepthBufferfor RT: TestRW_1


I also attached 2 screenshots one shows the depthSurface when the rendering works and one when the rendering fails. Also note that everything worked fine before the depth sharing was introduced :(
Attachments
DepthBufferFail.png
DepthBufferFail.png (77.68 KiB) Viewed 5041 times
DepthBufferWorking.png
DepthBufferWorking.png (82.7 KiB) Viewed 5041 times
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
 
Posts: 1450
Kudos: 101
Joined: 03 Feb 2006
Location: Austria - Leoben

Re: Depth sharing Design

Postby dark_sylinc » Sun Apr 18, 2010 11:36 pm

Thanks this is indeed very usefull.

I asked for the variable "depthBuffer" and not "depthSurface" though. It's ok for now anyway.

I believe there's something very nasty going on the D3D9 side when using multiple RenderWindows (which were created externally).

The OGL warning can be safely ignored because there's no FBO on the RenderTarget (because it's a window) therefore no depthbuffer can be created, yet you can still get a DepthBuffer as long as it is a window.
This is a limitation from OGL (RSC_RTT_MAIN_DEPTHBUFFER_ATTACHABLE is not present)
I will try to see if I can avoid the warning. The function shouldn't be called anyway. :?

Anyway it's hinting me how you're using the engine and I will try to replicate your issue in a simple application.
Hopefully I will be able to reproduce this bug.

I'll research about this bug around this week.

Thanks
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby dark_sylinc » Mon Apr 19, 2010 2:47 am

I am yet unable to reproduce your D3D9 bug.
However at least, thanks to you, I was able to spot an OGL bug in GLRenderSystem, which was causing that annoying Ogre.log warning. Patch here

I'll keep looking

@masterfalcon:
See if this GL bug also translates to GLES 1 & 2.
The fix is actually pretty easy.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby masterfalcon » Mon Apr 19, 2010 5:48 am

Neither of the GLES rendersystems have support for multiple windows right now. Just because I don't know of any devices that use GL ES and aren't full screen. But you're right, it is an easy change and couldn't hurt to apply it to them too.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
 
Posts: 4267
Kudos: 130
Joined: 25 Feb 2007
Location: Bloomington, MN

Re: Depth sharing Design

Postby Wolfmanfx » Mon Apr 19, 2010 6:29 am

@dark_sylinc

Can i help you in anyway? I do not understand the new Depth Sharing Design (at the moment never take a deeper look) thats why the debugging suxs a little bit :)
The hidden window i create on startup has the dim 128x128 pixel and gets hidden with WinApi call.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
 
Posts: 1450
Kudos: 101
Joined: 03 Feb 2006
Location: Austria - Leoben

Re: Depth sharing Design

Postby dark_sylinc » Tue Apr 20, 2010 3:49 am

@Wolfmanfx:
A small piece of C++ code reproducing your bug would be awesome. I'm not sharp on C#, but I could try investigating some C# code reproducing the bug.

As for explaining how the DepthSharing works:
The DepthBuffer class is an abstract interface that holds (in D3D9 case) the Direct3D9Surface used as the depth buffer.
Each RenderTarget (which includes RenderWindows) has DepthBuffer (optional).
At _setRenderTarget the RenderSystem gets the DepthBuffer from the RenderTarget. If it returns null or it determines it should be changed, it calls "RenderSystem::setDepthBufferFor" which is again an abstract call responsable for finding an existing compatible depth buffer, and if there isn't any; it creates a new one, which will end up calling D3D9RenderSystem::_createDepthBufferFor.

For some reason, this last function is creating a Direct3D9Surface that is not a depth buffer, and putting it in a DepthBuffer container class.

...or...

Although RenderWindows are sort of a special case, because the depth buffer is created with the backbuffer, in which case D3D9RenderSystem::_addManualDepthBuffer is used, where it works very similar, but the Direct3D9Surface isn't created, rather externally supplied as input and then put in a DepthBuffer container class.
If this is the code path that is going wrong, the input Direc3D9Surface being supplied is wrong as it isn't a depth buffer. Go up in the call stack to see where and how it is being created and why it isn't working.
I'm betting here's the problem.

Hope this helps
Cheers
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Mattan Furst » Fri Apr 23, 2010 11:51 am

I believe I am encountering the same crash Wolfmanfx has talked about (And in the process found another crash). I have created a simple c++ console application to reproduce the crash. The code for which is this:
Code: Select all
// crashEvoker.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "OgreRoot.h"
#include "OgreTextureManager.h"
#include "OgreTexture.h"
#include "OgreRenderWindow.h"
#include "OgreHardwarePixelBuffer.h"

using namespace Ogre;

#define CRASH_NUMBER 1

int _tmain(int argc, _TCHAR* argv[])
{
   std::string loadPostfix = ".dll";
#ifdef _DEBUG
   loadPostfix = "_d.dll";
#endif
   //
   // Initialize ogre
   //
   Root* pRoot = new Root("","","");
   
   pRoot->loadPlugin(String("RenderSystem_Direct3D9") + loadPostfix);
   pRoot->setRenderSystem(
      *(Root::getSingleton().getAvailableRenderers().begin()));
   pRoot->initialise(false);
   SceneManager* pScene = pRoot->createSceneManager(ST_GENERIC);

   //
   // create a render window
   //
   RenderWindow* pWindow1 = pRoot->createRenderWindow("wnd1",500,500,false);
   Camera* pWndCamera1 = pScene->createCamera("windowCam");
   Viewport* pWndViewport1 = pWindow1->addViewport(pWndCamera1);
   
#if CRASH_NUMBER == 1
   //
   // create a render window 2 (BEFORE DELETING RENDER WINDOW 1)
   //
   // Notice that the size of window 2 is bigger than window 1
   // this is important for the crash
   //
   RenderWindow* pWindow2 = pRoot->createRenderWindow("wnd2",600,600,false);
   Camera* pWndCamera2 = pScene->createCamera("windowCam2");
   Viewport* pWndViewport2 = pWindow2->addViewport(pWndCamera2);
#endif

   //
   //render and then delete window 1
   //
   pWndViewport1->update();
   pWindow1->destroy();
   pScene->destroyCamera(pWndCamera1);

#if CRASH_NUMBER == 2
   //
   // create a render window 2 (AFTER DELETING RENDER WINDOW 1)
   //
   RenderWindow* pWindow2 = pRoot->createRenderWindow("wnd2",600,600,false);
   Camera* pWndCamera2 = pScene->createCamera("windowCam2");
   Viewport* pWndViewport2 = pWindow2->addViewport(pWndCamera2);
#endif

   //render window 2
   pWndViewport2->update(); //CRASH HERE
   
}


set CRASH_NUMBER pre-processor definition to 1 for the crash Wolfmanfx is talking about. And to 2 for another null pointer crash.

P.S.
I have also attached the project (vs2005).

Update:
I have found the line causing the first crash though I still don't understand why.
The line in the example code pScene->destroyCamera(pWndCamera1) calls D3D9RenderWindow::destroy() which calls D3D9Device::detachRenderWindow() which calls D3D9Device::releaseRenderWindowResources(). The final function release a depth buffer. This does not seem to be the same depth buffer which window 2 uses. However if the depth buffer is not deleted the program doesn't crash

Update 2:
I don't know enough about DirectX9 to say for certain but the problem might be located in the function D3D9Device::acquireRenderWindowResources(RenderWindowToResorucesIterator it).

This function assigns depth buffers. Around line number1063 the function checks whether to create one by itself or ask the device for a depth buffer. In window mode the function requests the depth buffer from the device for each window. perhaps this is wrong. If the depth buffers are created instead of requested the program doesn't crash.
Attachments
crashEvoker.zip
(4.1 KiB) Downloaded 117 times
Last edited by Mattan Furst on Fri Apr 23, 2010 12:43 pm, edited 1 time in total.
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel

Re: Depth sharing Design

Postby Wolfmanfx » Fri Apr 23, 2010 12:40 pm

Nice! Thx for the help :)
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
 
Posts: 1450
Kudos: 101
Joined: 03 Feb 2006
Location: Austria - Leoben

Re: Depth sharing Design

Postby dark_sylinc » Fri Apr 23, 2010 3:20 pm

Sweeeeet!

I'll play with it this weekend.

Thanks!
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby dark_sylinc » Sun Apr 25, 2010 6:26 am

Crash 1

Bad news:
Crash 1 doesn't crash.
I tried on these machines:

1) GeForce 8600 GTS
Windows XP SP2
ForceWare 195.62

2) ATI Mobility Radeon HD 4650
Windows 7
Catalyst 8.6

Using latest Mercurial source code.
VC2008 Express Edition

I also played modifying the dimensions, adding, removing calls, changing order, but nothing.
Only lots of memory leaks on exit.

Good news:
Thanks to your code, I found a DANGLING POINTER!
I bet that's what's causing problem. I assumed RenderWindows only release their depthbuffers when releasing the D3D9 device. Waaaay wrong assumption. When the RenderWindow is removed without clearing the device, the pool will still contain a DepthBuffer with a dangling pointer. That actually explains why Wolfmanfx gets a Direct3D9Surface as a non-depthbuffer surface.
Also it explains why I can't reproduce it. Dangling pointers can have specific behaviors in a PC or OS config, or even previous usage.

Patch here

Hope this fixes your crashes!

Crash 2
It crashes at DepthSharing code, but that's not the cause.
Unfortunately, OGRE D3D9 plugin (and probably D3D9 itself too) assumes there's at least one render window. The crash arises because for a brief period of time, there's no RenderWindow.
Solutions are:
1) Don't release the last RenderWindow until you've created a new one (best)
2) If you can't control the release of the last RenderWindow, release the D3D9 device and create a new one (not recommended, but should work). This practically means to shutdown the D3D9 plugin correctly (AFAIK, may be there's an exposed method to do this, but I can't find it)

Cheers
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Wolfmanfx » Sun Apr 25, 2010 12:44 pm

@dark_sylinc
Everything works again thx.

@sinbad
You can close the bug report its working now :)
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
 
Posts: 1450
Kudos: 101
Joined: 03 Feb 2006
Location: Austria - Leoben

Re: Depth sharing Design

Postby iloseall » Fri May 07, 2010 8:51 am

I change ogre from Old SVN Head to HG Changeset 2132. I got crash when I move window from one Display to another.
Ogre version:
changeset 2132 (e705483e90ab) A patch by mirlix: createPlane function documentation
(include the patch: http://sourceforge.net/tracker/?func=de ... tid=302997)

1, If a texture loaded failed(file not found,but the exception is catched and then ingore),then texture state is LOADSTATE_Unloaded.
when window moved to another display, D3D9Texture::notifyOnDeviceCreate(IDirect3DDevice9* d3d9Device) called,
call createTextureResources, filt not found exception throw angin,now ogre crash

so change the code to:
Code: Select all
         LoadingState state=getLoadingState();
         //
         if(state==LOADSTATE_LOADING||state==LOADSTATE_LOADED||state==LOADSTATE_PREPARED)
         {
            createTextureResources(d3d9Device);
         }

Now,this is ok in my mini test program.

2,
after fixed 1,
I got crash on anthor big project when I move window to another display:

Code: Select all
void D3D9RenderSystem::_setRenderTarget(RenderTarget *target)
   {
.....
hr = getActiveD3D9Device()->SetDepthStencilSurface( depthSurface );

if (FAILED(hr))
{
      String msg = DXGetErrorDescription(hr);

      OGRE_EXCEPT(Exception::ERR_RENDERINGAPI_ERROR, "Failed to setDepthStencil : " + msg, "D3D9RenderSystem::_setViewport" );

}

excepation msg is "Invalid call".
local variable:
depthSurface:
"Name = 0x0000004b <Bad Ptr>"
target:
"mName = "rtt/164955248/c0/rt_output/Joy_Creative_GameClient"
mDepthBufferPoolId is 1

In this program, I use 2 compositors with pooled render target texture (Main render compositor and bloom compositor).
I close any one,still crash .
I closed all compositor and run angin, no crash.
Last edited by iloseall on Wed May 12, 2010 12:18 am, edited 2 times in total.
User avatar
iloseall
Gremlin
 
Posts: 160
Kudos: 0
Joined: 14 Sep 2003
Location: Beijing China

Re: Depth sharing Design

Postby dark_sylinc » Tue May 11, 2010 3:52 pm

Ooops, last time I tested moving to a different window was working.
Will check in around a week because I'm currently full loaded of exams.

Changing to another monitor is tricky.

In the meantime:
1) Please include any relevant OGRE warning, or just the log.
2) Enable DX9 Debug Runtimes and include any warning/error it throws
3) GPUs used. Do you use 1 GPU and 2 monitors? or 2 GPUs and 2 monitors?
4) Describe steps to reproduce because it's not veerrry clear, unless it's an obvious error.

Thanks
Dark Sylinc

Edit: Oh, I didn't saw you included information about the variables in the crash :oops:
This is very likely a DepthBuffer which should've been removed but didn't, and the monitor switch invalidad the D3D9 surface it contained.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby Mattan Furst » Thu May 13, 2010 1:49 pm

@Iloseall, Dark_sylinc

Just committed a patch which fixes a crash in the depth buffer system when moving a window from one monitor to another.
The problem was caused because the depth buffer was created using the device which did not correspond to the device of the depth surface it was attached too. I hope this fixes your problem also Iloseall.

BTW The actual fix was created by Assaf Raman. I just added it in.
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel

Re: Depth sharing Design

Postby Assaf Raman » Thu May 13, 2010 3:53 pm

Thanks Mattan.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 79
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Depth sharing Design

Postby iloseall » Fri May 14, 2010 5:46 am

Thanks Mattan.

edit 1:
Where is it?
I could not find the patch on SF.net.
On sf.net, a patch for depth buffer is " 2991918 Dangling pointer in D3D9 RenderWindows (DepthBuffers)", and that is in head(trunk).

edit 2:
to Mattan:
Thanks! I got it from the trunk.
Last edited by iloseall on Fri May 14, 2010 7:34 am, edited 1 time in total.
User avatar
iloseall
Gremlin
 
Posts: 160
Kudos: 0
Joined: 14 Sep 2003
Location: Beijing China

Re: Depth sharing Design

Postby Mattan Furst » Fri May 14, 2010 6:29 am

@Iloseall
It's already checked in to the trunk in bitbucket under the title "Fixed crash in D3D9 depth buffer system when moving windows between monitors" (The last changeset for now).
http://bitbucket.org/sinbad/ogre/changeset/b1ae02be4e84

If you want the diff file it's here:
http://bitbucket.org/sinbad/ogre/changeset/b1ae02be4e84/raw/ogre-b1ae02be4e84.diff
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel

Re: Depth sharing Design

Postby LBDude » Tue Apr 26, 2011 3:24 am

This is cool. I'm implementing light pre-pass deferred lighting and I was just wondering about depth buffer sharing between the rendering stages. No, I haven't looked at how to use this depth buffer sharing in depth, I'm just wondering if it's automatically supported already or whether I have to manually tell the system that I want to share depth buffer between two RenderToTexture's render targets. I was wondering also whether having the same depth but differing format would affect the sharing. I'm using float point textures so hopefully will work as long as bit depth is same.
My blog here.
Game twitter here
LBDude
Gnome
 
Posts: 389
Kudos: 22
Joined: 26 Jul 2010

Re: Depth sharing Design

Postby dark_sylinc » Sat Apr 30, 2011 4:24 pm

Yes this is automatic. By default everything gets an ID of 1, which means everything is shared with everything.

Note that, as put in sparksprime words, this is a conservative thing. You can't force things to be shared, but you can force them not to be shared. It depends on the API restrictions.

If it is shared in your card, it will be shared in other cards, but make sure you understand the rules to avoid surprises (read the comments from RSC_RTT_SEPARATE_DEPTHBUFFER, RSC_RTT_MAIN_DEPTHBUFFER_ATTACHABLE, RSC_RTT_DEPTHBUFFER_RESOLUTION_LESSEQUAL)

For this message the author dark_sylinc has received kudos
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby kornerr » Wed Jun 22, 2011 6:29 am

Hi.
I'm using modulate stencil shadows, and I'm having problem with default branch since 1817 revision when depth buffer sharing has been introduced.
This is how it works before this revision:
Image
This is how it works since the revision:
Image
I.e. there's no lighting in my RTT.
Can you please explain how I should enable it?
Thanks.
kornerr
Greenskin
 
Posts: 110
Kudos: 5
Joined: 04 Dec 2005
Location: Russia

Re: Depth sharing Design

Postby dark_sylinc » Wed Jun 22, 2011 6:53 pm

Hi, thanks for the report.

Unfortunately you've provided too little information. Plus, the images weren't posted correctly, so I can't see them.

What render systems are you using? Did you try both D3D9 & OGL?
What's the code you're using for setting up the stencil shadows? (i.e. mSceneMgr->setShadowTechnique(SHADOWTYPE_STENCIL_ADDITIVE) and Co.)
Are you using FF pipeline or shaders?
Do you have multiple compositors enabled as well? Are you doing additional RTT renderings?

I find it strange, since depth sharing has little to do with stencil shadows and the default settings were made to behave the same way it worked before depth sharing. May be there's something we missed or the stencil shadow code was somehow relying in undefined behavior.

Furthermore, the stencil shadow test works fine; so I can't reproduce it.

Cheers
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby kornerr » Thu Jun 23, 2011 2:29 am

Hi.
Sorry for images, i didn't thought google code images would run away. Downloaded them to google picasa.

Before 1817 revision (and still in v1-7 branch):
Image
(https://picasaweb.google.com/lh/photo/3 ... directlink)

Since 1817 revision (default branch):
Image
(https://picasaweb.google.com/lh/photo/w ... directlink)

Here's the code: http://dl.dropbox.com/u/12634473/cegui_rtt.zip
I use SHADOWTYPE_STENCIL_MODULATIVE with LT_POINT, but tried LT_SPOTLIGHT as well with no success.
I use GL rendering system, can't try D3D, because I'm on Linux. FF pipeline. No compositors. Single RTT only.

Thanks.
kornerr
Greenskin
 
Posts: 110
Kudos: 5
Joined: 04 Dec 2005
Location: Russia

Re: Depth sharing Design

Postby dark_sylinc » Thu Jun 23, 2011 4:25 am

Wow, with code!
I'm extremely busy right now, so I'll take a look at it in 2 weeks. Can't promise anything sooner. If I find some tiny free time I may be able to look it sooner.

Thanks
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 972
Kudos: 190
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Depth sharing Design

Postby kornerr » Thu Jun 23, 2011 6:52 am

Ok. I can wait for 2 weeks. My next game release is 1.5 months away, but it would be nice to fix the issue ASAP :)
kornerr
Greenskin
 
Posts: 110
Kudos: 5
Joined: 04 Dec 2005
Location: Russia

PreviousNext

Return to Developer talk

Who is online

Users browsing this forum: No registered users and 1 guest