Depth of Field demo release

Phantom · Post by **Phantom** » Thu Mar 16, 2006 8:51 pm

Will try it with the source...

marlboro · Post by **marlboro** » Thu Mar 16, 2006 9:21 pm

ok im kinda awful at debugging but this is good practice

i've think the error has something to do this

	
mCompositor->addListener(this);



> dof.exe!DepthOfFieldEffect::addCompositor()  Line 159 + 0x12	C++

everytime i debug through Visual Studio it won't let me step over this line of code, which to be honesty didnt surprise me at all since i've been having problems with the compositor recently anyway, if it helps im using a Radeon x600

robalex · Post by **robalex** » Thu Mar 16, 2006 10:27 pm

the error occurs in:

Code: Select all

	void GLSLLinkProgram::activate(void)
	{
		if (!mLinked)
		{
            // if performing skeletal animation (hardware skinning) then bind default vertex attribute names
            // note that attribute binding has to occur prior to final link of shader objects
            if (mSkeletalAnimation)
            {
                glBindAttribLocationARB(mGLHandle, 7, "BlendIndex");
                glBindAttribLocationARB(mGLHandle, 1, "BlendWeight");
            }

			glLinkProgramARB( mGLHandle );
			glGetObjectParameterivARB( mGLHandle, GL_OBJECT_LINK_STATUS_ARB, &mLinked );
			// force logging and raise exception if not linked
			checkForGLSLError( "GLSLLinkProgram::Activate",
				"Error linking GLSL Program Object", mGLHandle, !mLinked, !mLinked );
			if(mLinked)
			{
				logObjectInfo( String("GLSL link result : "), mGLHandle );
				buildUniformReferences();
			}

		}

		if (mLinked)
		{
		    glUseProgramObjectARB( mGLHandle );
		}
	}

but i dont know what this function is good for... maybe it will help ...

in linux it works.. this happens only in windows

Post by **DWORD** » Thu Mar 16, 2006 10:43 pm

Yep, managed to debug it on my Radeon 9800 XT, too. It crashes in a call to glLinkProgramARB(). Here's the stack trace:

Code: Select all

>	RenderSystem_GL.dll!Ogre::GLSLLinkProgram::activate()  Line 63	C++
 	RenderSystem_GL.dll!Ogre::GLSLLinkProgramManager::getActiveLinkProgram()  Line 123	C++
 	RenderSystem_GL.dll!Ogre::GLSLGpuProgram::bindProgramParameters(Ogre::SharedPtr<Ogre::GpuProgramParameters> params={...})  Line 118 + 0xc	C++
 	RenderSystem_GL.dll!Ogre::GLRenderSystem::bindGpuProgramParameters(Ogre::GpuProgramType gptype=GPT_FRAGMENT_PROGRAM, Ogre::SharedPtr<Ogre::GpuProgramParameters> params={...})  Line 2377	C++
 	OgreMain_d.dll!Ogre::SceneManager::renderSingleObject(const Ogre::Renderable * rend=0x00c7dc60, const Ogre::Pass * pass=0x00c3adf0, bool doLightIteration=false, const std::vector<Ogre::Light *,std::allocator<Ogre::Light *> > * manualLightList=0x00000000)  Line 2508	C++
 	OgreMain_d.dll!Ogre::SceneManager::_injectRenderWithPass(Ogre::Pass * pass=0x00c3adf0, Ogre::Renderable * rend=0x00c7dc60)  Line 4842 + 0x19	C++
 	OgreMain_d.dll!Ogre::RSQuadOperation::execute(Ogre::SceneManager * sm=0x00c29648, Ogre::RenderSystem * rs=0x00bff7c8)  Line 162 + 0x26	C++
 	OgreMain_d.dll!Ogre::CompositorChain::RQListener::flushUpTo(unsigned char id=0)  Line 349 + 0x35	C++
 	OgreMain_d.dll!Ogre::CompositorChain::RQListener::renderQueueStarted(unsigned char id=0, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & invocation={...}, bool & skipThisQueue=false)  Line 322	C++
 	OgreMain_d.dll!Ogre::SceneManager::fireRenderQueueStarted(unsigned char id=0, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & invocation={...})  Line 2901 + 0x2f	C++
 	OgreMain_d.dll!Ogre::SceneManager::renderVisibleObjectsDefaultSequence()  Line 1638 + 0x41	C++
 	OgreMain_d.dll!Ogre::SceneManager::_renderVisibleObjects()  Line 1566 + 0xd	C++
 	OgreMain_d.dll!Ogre::SceneManager::_renderScene(Ogre::Camera * camera=0x00c32ba0, Ogre::Viewport * vp=0x00c33560, bool includeOverlays=true)  Line 1080 + 0x10	C++
 	OgreMain_d.dll!Ogre::Camera::_renderScene(Ogre::Viewport * vp=0x00c33560, bool includeOverlays=true)  Line 393 + 0x2a	C++
 	OgreMain_d.dll!Ogre::Viewport::update()  Line 192	C++
 	OgreMain_d.dll!Ogre::RenderTarget::update()  Line 107	C++
 	OgreMain_d.dll!Ogre::RenderWindow::update(bool swap=true)  Line 72	C++
 	OgreMain_d.dll!Ogre::RenderWindow::update()  Line 63 + 0x12	C++
 	OgreMain_d.dll!Ogre::RenderSystem::_updateAllRenderTargets()  Line 100 + 0x24	C++
 	OgreMain_d.dll!Ogre::Root::_updateAllRenderTargets()  Line 995 + 0x18	C++
 	OgreMain_d.dll!Ogre::Root::renderOneFrame()  Line 739	C++
 	OgreMain_d.dll!Ogre::Root::startRendering()  Line 727 + 0x8	C++
 	dof.exe!ExampleApplication::go()  Line 58 + 0xe	C++
 	dof.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, char * strCmdLine=0x00141f07, HINSTANCE__ * __formal=0x00000000)  Line 105 + 0x8	C++
 	dof.exe!WinMainCRTStartup()  Line 390 + 0x39	C
 	kernel32.dll!77e814c7()

From searching the net it sounds like a driver bug. Apparently the drivers crash badly on some shader code. Maybe there's something wrong with my shaders, but I don't know, and as it doesn't give me an error message, my chances to fix it are small.

molistok · Post by **molistok** » Wed Apr 26, 2006 7:31 pm

Hi, I am working in a project of rain, and I need to know the depth of my world( in my ogre aplication), Therefore, I want to do a depthmap.

I am looking at your work but..doesn't work me, altough you can give me one advice for do this(the depthmap in my application)?

Thanks.

Post by **DWORD** » Wed Apr 26, 2006 8:46 pm

molistok wrote:I am looking at your work but..doesn't work me, altough you can give me one advice for do this(the depthmap in my application)?

Maybe I can help, but you have to ask a question.

It looks like you got some advice in the other thread. If that's not enough, you'll have to be more specific about what is your problem.

molistok · Post by **molistok** » Fri May 05, 2006 7:13 pm

Hi,
Tanks for the reply.

I am trying to modify your DoF_Depth for get the depthmap, but I have the problem that with my computer your project doesn't work, with a other computer I see your work.

I execute your project and this is my error:

ogresharedptr.h
line: 107
expresion: pRep

Somebody have any idea for solve this error?thanks.

My 3d graphic card is nvidia geoforce 5200

molistok · Post by **molistok** » Wed May 10, 2006 1:26 pm

Anybody have any idea for solve my error?or somebody have any idea why appear this error when I execute the dof sample?

The error is this:

ogresharedptr.h
line: 107
expresion: pRep

Thanks.

klaxplus · Post by **klaxplus** » Fri May 12, 2006 12:29 pm

I'm trying to do the same thing. Using it as a depth map. For this I am integrating the Class into an existing application. And I have the same error. With me, its an assertion that fails, because

Code: Select all

mDepthMaterial = MaterialManager::getSingleton().getByName("DoF_Depth");

returns a null pointer. So somehow it can't find the material.

If I load the material somewhere else in the application, it finds it.

Any idea?

raflegan · Post by **raflegan** » Fri Jun 09, 2006 10:19 am

Hello,
i am trying to use the DoF effect in a program but i get problems when i try to use materials using a vertex program.
If the material uses a vertex program in the first pass and the DoF Compositor is enabled, the screen gets black whenever that material is rendered (whenever the object using that material comes into view).
This only happens with vertex programs (not fragment programs, but it seems it happens with any vertex program) and only if the program is used in the first pass.

Here is an example of a material that does not work for me with DoF:

Code: Select all

material Stone1
{
  technique
  {
    // Base ambient pass
//    pass
//    {
//    }
    
    pass
    {
      // base colours, not needed for rendering, but as information
      // to lighting pass categorisation routine
      ambient 1 1 1
      diffuse 0.5 0.5 0.5 
      specular 0 0 0 0
      // Really basic vertex program
      // NB we don't use fixed function here because GL does not like
      // mixing fixed function and vertex programs, depth fighting can
      // be an issue
      vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture
      {
        param_named_auto worldViewProj worldviewproj_matrix
        param_named_auto ambient ambient_light_colour
      }
      
      //fragment_program_ref Ogre/BasicFragmentPrograms/test
      //{
      //}
      
    }
  }
}

AmbientOneTexture is a very basic vertex program assigning the ambient light colour as colour for the vertices. I have also tried an even simpler vertex program (just transforming the vertex position with the worldview matrix) and it also resulted in a black screen with DoF.
If the first empty pass is commented in, DoF does work (but then the material is useless to me, because of depth fighting as described in the comment above the vertex program).
The depth texture shown in the debug panel seems to be ok, even when the screen is black.

Apparently the gl_TexCoord[0] coordinates in the DoF_DepthOfField fragment program are wrong when rendering a material with a vertex program in the first pass. When the material is not in view, the texture coordinates are as they should be, covering the whole screen from (0,0) to (1,1).
When the material comes into view, suddenly the whole visible area of the compositor quad has only texture coordinate (1,0) in every fragment.

Does anyone know what could be the problem here, or could someone try if he gets the same problem with this material?

Thanks.

Paulov · Post by **Paulov** » Fri Jun 09, 2006 12:50 pm

cool demo

it runs at 30fps in a P3000 1GBram xfx6600GT

I find it quite resource consuming to be rendering just 400faces, but anyway the demo is fine.

coment that when switching betwen deferent tasks with the task manager, when returning into the demo, everything is black and there is no way to recover the 3D scene.

Post by **DWORD** » Fri Jun 09, 2006 4:19 pm

raflegan: The demo does not, as you have seen, take materials using vertex programs into account. That's because the material used for rendering the depth texture uses a vertex program to store the depth. But I don't understand why the whole screen turns black, I would've thought that the depth was just being wrong for the objects rendered with materials using vertex programs. :S

(For the mixing of fixed-function and vertex programs, IIRC there's a function to directly transform vertices that makes sure they're exactly transformed as fixed-function does. Can't remember the name, though.)

Paulov: It's not the cheapest way to do DoF, but it's not the ugliest either.

Regarding the switch to task manager. Does this only happen when running in fullscreen, and what about the Ogre demos in general?

klauss · Post by **klauss** » Fri Jun 09, 2006 5:16 pm

DWORD wrote:(For the mixing of fixed-function and vertex programs, IIRC there's a function to directly transform vertices that makes sure they're exactly transformed as fixed-function does. Can't remember the name, though.)

ftransform(), but only in GLSL.

Paulov · Post by **Paulov** » Fri Jun 09, 2006 7:45 pm

I´ve tested it in windowed mode and runs fine when switching betwen tasks; I´ve set it to fullscreen again and do the same.... and has run fine

>> dont know what I did in the morning but now is runing ok so if it doesnt happen again I´ll leave as solved.

About the DOF technique, to me many of the things you (programers) talk about is like chinese readen upside down, since I´m just a 3D artist, but I´ll try to give you the information I´ve about DOF and blur effects so that someone can find it useful.

I also saw another DOF demo done with quest3D that was pretty fine.

mentioned demo
http://www.quest3d.com/download/demo3/Q ... d_Uani.exe

An article about cinematic effects done by bit-tech.net
http://www.bit-tech.net/gaming/2005/12/ ... cts/1.html

Cryengine 2 also features "support" for DOF but they dont say much about it:
http://www.totalcry.com/index.php?optio ... &Itemid=56

I´ve seen some videos and its true that they have a nice DOF, it activates when modifying the weapong and only it gets focused blurring the background, without afecting the performance.

Thats all about DOF this 3D soft user can say

__

raflegan · Post by **raflegan** » Sat Jun 10, 2006 9:05 am

DWORD: hmm, but you use a different technique for the depth rendering on a different render target, so should that not work fine with vertex programs assigned to the original technique? After all DoF works with fragment program materials and you also use a fragment program to calculate the depth.
It is also possible to use different vertex and fragment programs in different passes, so it should also be possible to use two different vertex programs when rendering to two different targets. Or am I getting something completely wrong here?
Also, the depth image seems to be fine, the only problem is that the texture coordinates of the final compositor quad somehow become corrupted.
On the other hand, if i comment out that line:

Code: Select all

 *ppTech = mDepthTechnique;

in the DepthOfFieldEffect::renderableQueued function there are no problems with the texture coordinates anymore.
I don't see what could be causing this, maybe a bug in the graphics card drivers? (I am using nvidia drivers)
Maybe you could quickly test the material and see if it works for you?
The AmbientOneTexture vertex program should be in the ogre media directory already.

Thanks

Post by **DWORD** » Sat Jun 10, 2006 1:52 pm

raflegan: I've tested this thouroughly with different vertex program setups (static and animated), and there are no problems here on my machine - other than the depth texture being wrong as expected if the vertex program modifies vertex positions (see image below).

I've added the tests and uploaded a new version. Please see if running this causes problems, too, because then you probably have faulty drivers or something.

Binary Windows demo: dof-0.1.2-bin-win32.zip
Source for Linux and Windows (VS.NET 7.1): dof-0.1.2-src.tar.bz2

The proof:

Test_Plain uses no vertex program, Test_StaticVertexProgram uses a vertex program but doesn't animate, and... surprise... Test_AnimatedVertexProgram animates the vertices of the plane.

Note the blurring being off in on the right animated plane, because the depth vertex program doesn't animate the vertices too. This could be fixed though, if you really wanted to, but it requires a bit more work. Also note that the background in the transparent parts of the textures is blurred just as if it was at the plane's depth.

raflegan · Post by **raflegan** » Sat Jun 10, 2006 4:47 pm

Thanks for the test program.
I am really starting to believe that there is a bug in my video card drivers.
The test program runs fine, even if i add an object with the material I posted earlier. But when I try to add the full material (3 passes, each with vertex program), I get the same black screen.
Also, when I use the test material I posted and I comment out the creation of the 3 test planes in the createScene() function, I get the same problems as before.

I have downloaded the newest Forceware Drivers and if it is a bug in the drivers, it is not corrected yet.

I have also tried using the "Ogre/BasicVertexPrograms/AmbientOneTexture" vertex program (the one causing the problems) in the "Test_StaticVertexProgram" material (instead of Test_StaticVertexProgramVP_GLSL) and I get the same problems as always.
Interestingly, the screen only turns black if the right upper vertex is in view (if everything is in view except that vertex, the plane renders fine, with depth of field and everything).

Here are two images showing this. In the first image, the right upper vertex of the plane with the "Ogre/BasicVertexPrograms/AmbientOneTexture" vertex program is not in view and everything renders fine. But as soon as the vertex comes into view (the right image) the screen gets black.
Maybe there is some problem when mixing cg and GLSL programs.

Post by **DWORD** » Sat Jun 10, 2006 6:11 pm

raflegan: Ok, that's very very strange, especially that the frame rate goes up that high when there's black screen.

I would still think it's the drivers, but I can't say. What happens when you press space to use pinhole focus mode (i.e. disable compositors)?

raflegan · Post by **raflegan** » Sun Jun 11, 2006 8:30 am

Then the screen does not go black, but whenever the top right vertex gets into view, the middle plane start to wave as if it had assigned the vertex program of the third plane (which it has not).
Very strange, somehow the vertex programs get mixed up.
So it seems this has nothing to do with the DoF program (I even commented out the part where you create the DoF effect and the part where you add the Frame Listener). Assuming an error in the material script itself cannot cause this, it is either a bug in Ogre or a bug in my display drivers (I don't know which of the two is more likely).

Grom · Post by **Grom** » Thu Jul 06, 2006 4:54 am

Hey man I tried your code, it looks freakin sweet! The first two releases binaries ran fine, but when I copied over the DepthOfFieldEffect.h and .cpp (and the materials), it causes a crash when I try to initialize a new DepthOfFieldEffect in my code. And the third demo's binary crashes in much the same way. I have a Geforce 7800 GT OC. None of these crashes come with Ogre log outputs.

Is it possible to convert this code to hlsl? Maybe that would solve a lot of problems...

Also, is it necessary to have part of the creation process done in code? I was going to try to mimic the effect in the rendermonkey samples, but I'm not too sure of the compositor coding just yet to go at it head on...

Post by **DWORD** » Thu Jul 06, 2006 7:15 pm

OzwaldoRinaldo wrote:Hey man I tried your code, it looks freakin sweet! The first two releases binaries ran fine, but when I copied over the DepthOfFieldEffect.h and .cpp (and the materials), it causes a crash when I try to initialize a new DepthOfFieldEffect in my code. And the third demo's binary crashes in much the same way. I have a Geforce 7800 GT OC. None of these crashes come with Ogre log outputs.

Hm, weird. Did you try debugging the crash? Backtrace?

OzwaldoRinaldo wrote:Is it possible to convert this code to hlsl? Maybe that would solve a lot of problems...

Definitely. The article from which I stole the idea did it using HLSL (link in first post of this thread).

OzwaldoRinaldo wrote:Also, is it necessary to have part of the creation process done in code? I was going to try to mimic the effect in the rendermonkey samples, but I'm not too sure of the compositor coding just yet to go at it head on...

No, the compositors in this demo are built through code only because it was made before .compositor scripts were functional, but there are some things that still need to be setup at runtime. I did mean to convert the compositor to scripts, but never got around to it.

Post by **nfz** » Thu Jul 06, 2006 7:35 pm

I had started the conversion from code to script but still haven't finished.

ahmedismaiel · Post by **ahmedismaiel** » Fri Jul 07, 2006 12:32 pm

hi ,the shader was not working at my ATI X700 but finally i found out why this was happening

there is 2 statement were not standard in the opengl specification that it looks that nvidia understands them so easily but ATI don't!!

1- in Test_AnimatedVertexProgram.vert
make the line

Code: Select all

float uniform time;

to

Code: Select all

uniform float time;

2-in Test_Common.frag
change line

Code: Select all

gl_FragColor = texture2D(texture, gl_TexCoord[0]);

to

Code: Select all

gl_FragColor = texture2DProj(texture, gl_TexCoord[0]);

now it's working great on ATI
please every one check if my changes will work on both ATI and nvidia cards

raflegan · Post by **raflegan** » Sat Jul 08, 2006 12:09 pm

Hello,
I have rewritten the shaders to HLSL (I didn't have to change much, GLSL and HLSL are similar) and the materials now have two techniques, one for OpenGL, one for DirectX, so the DoF Effect should work in DirectX now, too (although I have only tried on one computer).
Also, I do not get the problems I described in my posts above in DirectX (which I even get on other computers when using OpenGL).

If anyone wants them, the modified files are here, just copy them to the media directory and overwrite the old files.

ahmedismaiel · Post by **ahmedismaiel** » Sat Jul 08, 2006 12:51 pm

the link for the changed HLSL files is not working ,could you please post it again or pm me if you can i'm in bad need for these files to compare the performance

sorry ,it looks like you server is loaded ,dowloaded thanks