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.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: Depth sharing Design

Post by masterfalcon »

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
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: Depth sharing Design

Post by Wolfmanfx »

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 7653 times
DepthBufferWorking.png
DepthBufferWorking.png (82.7 KiB) Viewed 7653 times
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: Depth sharing Design

Post by masterfalcon »

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
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: Depth sharing Design

Post by Wolfmanfx »

@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
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

@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
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Depth sharing Design

Post by Mattan Furst »

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 203 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
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: Depth sharing Design

Post by Wolfmanfx »

Nice! Thx for the help :)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

Sweeeeet!

I'll play with it this weekend.

Thanks!
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: Depth sharing Design

Post by Wolfmanfx »

@dark_sylinc
Everything works again thx.

@sinbad
You can close the bug report its working now :)
User avatar
iloseall
Gremlin
Posts: 156
Joined: Sun Sep 14, 2003 3:54 am
Location: Beijing China
Contact:

Re: Depth sharing Design

Post by iloseall »

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
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Depth sharing Design

Post by Mattan Furst »

@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
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Depth sharing Design

Post by Assaf Raman »

Thanks Mattan.
Watch out for my OGRE related tweets here.
User avatar
iloseall
Gremlin
Posts: 156
Joined: Sun Sep 14, 2003 3:54 am
Location: Beijing China
Contact:

Re: Depth sharing Design

Post by iloseall »

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
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel
x 32

Re: Depth sharing Design

Post by Mattan Furst »

@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/change ... e4e84.diff
it's turtles all the way down
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: Depth sharing Design

Post by LBDude »

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
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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)
kornerr
Greenskin
Posts: 110
Joined: Sun Dec 04, 2005 5:17 pm
Location: Russia
x 5
Contact:

Re: Depth sharing Design

Post by kornerr »

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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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
kornerr
Greenskin
Posts: 110
Joined: Sun Dec 04, 2005 5:17 pm
Location: Russia
x 5
Contact:

Re: Depth sharing Design

Post by kornerr »

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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Depth sharing Design

Post by dark_sylinc »

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
kornerr
Greenskin
Posts: 110
Joined: Sun Dec 04, 2005 5:17 pm
Location: Russia
x 5
Contact:

Re: Depth sharing Design

Post by kornerr »

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 :)
Post Reply