Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi I have no longer moving waves in latest SVN . adrian 2009/6/19 Ümit Uzun umituzu...@gmail.com Hi Kim, There is strange view as you can see from osgOcean_Artifact.jpg Is this artifact or what? And when creating VisualStudio solution, Cmake doesn't create osgOcean's Header Files folder which is created for oceanExample as you can see from osgOcean_Classes.jpg This make the solution panel look messy. Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, Yes, apparently samplerRect has been depreciated. Ulrich flagged this one on OSX and corrected it. I guess some glsl compilers are more fussy than others. Glad you got it working. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Thu 18/06/2009 12:36 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Actually I am sorry for not thinking it can be the svn adress :) You make the really good magic. It works perfect without any error as you can see from the attached screenshot:) Thanks so much :) But there is some dots flickering as JS and Martins's said about. And it's not problem I think :) This is really really good application. What did you do? You have only changed samplerRect to sampler2D? Regards and Congratulations :) 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, Sorry use svn checkout http://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ osgocean-read-only http://osgocean.googlecode.com/svn/tags/osgOcean-1.0/%0Aosgocean-read-only or grab a copy of the tortoise client to download it. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 11:45 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Thanks you so much. But prompted screen wants username and password from me? Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, I've just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 07:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Adrian, Kim, J-S has made a modification to the OceanTechnique base class which allows you to enable/disable animation. You’ll need to set FFTOceanSurface::startAnimation(void). I had forgotten to initialize the _isAnimating member in the ctor and copy ctor. Fixed - the default behavior is identical to before (_isAnimating = true by default). The trunk is being used for development so it may or may not work properly. I would use the release 1.0 tag, I’m misusing the definition of a tag a little since I’m adding bug fixes to it as I find them. I agree with Kim, I'm making the trunk move forward according to what we need for our project so it won't always be stable. If you want something to use in your projects use the 1.0 branch. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, I've just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 07:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Thanks you so much. But prompted screen wants username and password from me? Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, I’ve just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: *https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/* Regards, Kim. *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Ümit Uzun *Sent:* 18 June 2009 07:35 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, I have same problem with samplerRect before when I wanted to try osgMovie example as you suggested to Robert. And I tried to use sampler2d instead of and was solved. And as this problem, osgWidget's Widget class texture operation was only supported with TextureRectange and I have implemented Texture2D to show my movie on it by myself. I think my GPU's main one problem is TextureRectangle implementation. Regards. 2009/6/18 Ümit Uzun umituzu...@gmail.com Hi Kim, Thanks you so much. But prompted screen wants username and password from me? Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, I’ve just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: *https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/* Regards, Kim. *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Ümit Uzun *Sent:* 18 June 2009 07:35 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, Sorry use svn checkout http://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ osgocean-read-only or grab a copy of the tortoise client to download it. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 11:45 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Thanks you so much. But prompted screen wants username and password from me? Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, I've just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 07:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Actually I am sorry for not thinking it can be the svn adress :) You make the really good magic. It works perfect without any error as you can see from the attached screenshot:) Thanks so much :) But there is some dots flickering as JS and Martins's said about. And it's not problem I think :) This is really really good application. What did you do? You have only changed samplerRect to sampler2D? Regards and Congratulations :) 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, Sorry use svn checkout *http*://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ osgocean-read-onlyhttp://osgocean.googlecode.com/svn/tags/osgOcean-1.0/%0Aosgocean-read-only or grab a copy of the tortoise client to download it. Regards, Kim. *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Ümit Uzun *Sent:* 18 June 2009 11:45 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Thanks you so much. But prompted screen wants username and password from me? Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, I’ve just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: *https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/* Regards, Kim. *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Ümit Uzun *Sent:* 18 June 2009 07:35 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, Yes, apparently samplerRect has been depreciated. Ulrich flagged this one on OSX and corrected it. I guess some glsl compilers are more fussy than others. Glad you got it working. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Thu 18/06/2009 12:36 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Actually I am sorry for not thinking it can be the svn adress :) You make the really good magic. It works perfect without any error as you can see from the attached screenshot:) Thanks so much :) But there is some dots flickering as JS and Martins's said about. And it's not problem I think :) This is really really good application. What did you do? You have only changed samplerRect to sampler2D? Regards and Congratulations :) 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, Sorry use svn checkout http://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ osgocean-read-only http://osgocean.googlecode.com/svn/tags/osgOcean-1.0/%0Aosgocean-read-only or grab a copy of the tortoise client to download it. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 11:45 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Thanks you so much. But prompted screen wants username and password from me? Regards. 2009/6/18 Kim C Bale k.b...@hull.ac.uk Hi Umit, I've just applied a patch that should solve the samplerRect issue for you, I think I was being too hasty to blame your graphics drivers. Update your code from: https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ https://osgocean.googlecode.com/svn/tags/osgOcean-1.0/ Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 18 June 2009 07:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim and JS; Thanks for suggestion. I have tried again and as you said I really need new version GPU. This is only solution which will resolve kind of these problems. Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Firsty congratulations for these awesome works. When I try to create solution file in cmake on VisualStudio2008 I get the errors; CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR used as include directory in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean FFTSS_LIBRARY linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I have compiled the FFTSS library and locate it in same folder with osgOcean-Source folder. Should I declare specific Environment Variable to help cmake for finding right fftss include directory and library? And Do we have to OpenThreads library in debug mode? I have a OSG distiribution in only release mode. Regards. 2009/6/16 Kim C Bale k.b...@hull.ac.uk Hi Martin, This problem arises with two particular effects, the glare and the underwater dof which require special treatment of the alpha component in the framebuffer. You can disable those using: enableUnderwaterDOF(false) enableGlare(false) Then you need to disable the default scene shader with this: setUseDefaultSceneShader(false) In the OceanScene class. If you remove the default shader you'll also lose the underwater light scattering and fogging calculations on models below the surface. Trying to offer lots of out-of-the-box shader effects whilst also accommodating the fixed pipeline is a tricky problem and this area needs a little work, but that should work for you. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 16 June 2009 15:18 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I compiled osgOcean and everything works fine here. I ran into trouble when integrating it with my existing application. When I used the last version of osgOcean, I could just put the ocean somewhere in the scene graph and it did not interact with my other stuff. Now osgOcean blocks my view onto the other objects in the scene. When I add the objects as children to the OceanScene, the objects are shown, but the ocean shaders are applied to the objects. This add some sparkling effects to my animations, which looks nice but is not really what I want. So how can I add my objects to the scene without interference? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14038#14038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or ghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or%0Ag * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, Firsty congratulations for these awesome works. Thank you, still plenty to fix though it seems J CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR When you run CMake it should let you set these manually if they're not found automatically. You will need to explicitly specify the path to the include directory and also the fftss.lib file (this is what I do when I run CMake) When you run the example application the fftss.dll will need to be in the same directory as the exe or by adding the directory it's in to your PATH environment variable (if you're in windows) OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I think if you just point it to the release mode version of OpenThreads it will let you build the project. But be careful, if you try and build a debug version of the application/library it's highly likely you'll get errors. If that doesn't solve it get back to me. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 17 June 2009 11:48 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Firsty congratulations for these awesome works. When I try to create solution file in cmake on VisualStudio2008 I get the errors; CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR used as include directory in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean FFTSS_LIBRARY linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I have compiled the FFTSS library and locate it in same folder with osgOcean-Source folder. Should I declare specific Environment Variable to help cmake for finding right fftss include directory and library? And Do we have to OpenThreads library in debug mode? I have a OSG distiribution in only release mode. Regards. 2009/6/16 Kim C Bale k.b...@hull.ac.uk Hi Martin, This problem arises with two particular effects, the glare and the underwater dof which require special treatment of the alpha component in the framebuffer. You can disable those using: enableUnderwaterDOF(false) enableGlare(false) Then you need to disable the default scene shader with this: setUseDefaultSceneShader(false) In the OceanScene class. If you remove the default shader you'll also lose the underwater light scattering and fogging calculations on models below the surface. Trying to offer lots of out-of-the-box shader effects whilst also accommodating the fixed pipeline is a tricky problem and this area needs a little work, but that should work for you. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 16 June 2009 15:18 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I compiled osgOcean and everything works fine here. I ran into trouble when integrating it with my existing application. When I used the last version of osgOcean, I could just put the ocean somewhere in the scene graph and it did not interact with my other stuff. Now osgOcean blocks my view onto the other objects in the scene. When I add the objects as children to the OceanScene, the objects are shown, but the ocean shaders are applied to the objects. This add some sparkling effects to my animations, which looks nice but is not really what I want. So how can I add my objects to the scene without interference? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14038#14038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or%0Ag * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun
Re: [osg-users] osgOcean 1.0 (LGPL) Released
streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader glare_composite_fragment_shader FAILED FRAGMENT Shader glare_composite_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:2: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. I think these all related about driver because of my driver 2.5 years old and it's last updated driver support only opengl 2.1 and GLSL 1.20. I think I can't run osgOcean in my company computer. I have to use another newer one. Any suggestions? Regards. 2009/6/17 Kim C Bale k.b...@hull.ac.uk Hi Umit, Firsty congratulations for these awesome works. Thank you, still plenty to fix though it seems J CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR When you run CMake it should let you set these manually if they’re not found automatically. You will need to explicitly specify the path to the include directory and also the fftss.lib file (this is what I do when I run CMake) When you run the example application the fftss.dll will need to be in the same directory as the exe or by adding the directory it’s in to your PATH environment variable (if you’re in windows) OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I think if you just point it to the release mode version of OpenThreads it will let you build the project. But be careful, if you try and build a debug version of the application/library it’s highly likely you’ll get errors. If that doesn’t solve it get back to me. Regards, Kim. *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Ümit Uzun *Sent:* 17 June 2009 11:48 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Firsty congratulations for these awesome works. When I try to create solution file in cmake on VisualStudio2008 I get the errors; CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR used as include directory in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean FFTSS_LIBRARY linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I have compiled the FFTSS library and locate it in same folder with osgOcean-Source folder. Should I declare specific Environment Variable to help cmake for finding right fftss include directory and library? And Do we have to OpenThreads library in debug mode? I have a OSG distiribution in only release mode. Regards. 2009/6/16 Kim C Bale k.b...@hull.ac.uk Hi Martin, This problem arises with two particular effects, the glare and the underwater dof which require special treatment of the alpha component in the framebuffer. You can disable those using: enableUnderwaterDOF(false) enableGlare(false) Then you need to disable the default scene shader with this: setUseDefaultSceneShader(false) In the OceanScene class. If you remove the default shader you'll also lose the underwater light scattering and fogging calculations on models below the surface. Trying to offer lots of out-of-the-box shader effects whilst also accommodating the fixed pipeline is a tricky problem and this area needs a little work, but that should work for you. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 16 June 2009 15:18 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I compiled osgOcean and everything works
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, VERTEX glCompileShader terrain_vertex_shader FAILED VERTEX Shader terrain_vertex_shader infolog: I've just fixed this one, if you download the code from the svn it will go away. The rest of the errors seem to suggest that your graphics card / drivers don't support texture rectangles (at least in the shaders), which may well be the case if it's very old. However, you can bypass the texture rectangles by using: oceanScene::setEnableGlare(false); oceanScene::setEnableUnderwaterDOF(false); Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 17 June 2009 13:38 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Thanks for tips. I have changed the fft library fftss to fftw and I can compiled without any error. When I run the example I get errors as follows. Building scene... . Loading cubemaps: 0.660514s . Generating ocean surface: 0.0465612s . Creating ocean scene: 0.0113174s . Loading islands: 0.079017s . Setting up lighting: 1.81587e-005s complete. Time Taken: 0.798147s VERTEX glCompileShader terrain_vertex_shader FAILED VERTEX Shader terrain_vertex_shader infolog: Vertex shader failed to compile with the following errors: ERROR: 0:34: '*' : wrong operand types no operation '*' exists that takes a le ft-hand operand of type 'uniform 4-component vector of float' and a right operan d of type '3-component vector of float' (or there is no acceptable conversion) ERROR: 0:34: 'assign' : cannot convert from 'uniform 4-component vector of floa t' to 'out 3-component vector of float' ERROR: 2 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Vertex shader(s) were not successfully compiled before glLinkProgram() was calle d. Link failed. Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) VERTEX glCompileShader scene_shader_vertex_shader FAILED VERTEX Shader scene_shader_vertex_shader infolog: Vertex shader failed to compile with the following errors: ERROR: 0:29: '*' : wrong operand types no operation '*' exists that takes a le ft-hand operand of type 'uniform 4-component vector of float' and a right operan d of type '3-component vector of float' (or there is no acceptable conversion) ERROR: 0:29: 'assign' : cannot convert from 'uniform 4-component vector of floa t' to 'out 3-component vector of float' ERROR: 0:45: 'computeScattering' : no matching overloaded function found ERROR: 3 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Vertex shader(s) were not successfully compiled before glLinkProgram() was calle d. Link failed. FRAGMENT glCompileShader downsample_glare_fragment_shader FAILED FRAGMENT Shader downsample_glare_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:2: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Ümit, When you run the example application the fftss.dll will need to be in the same directory as the exe or by adding the directory it’s in to your PATH environment variable (if you’re in windows) Actually FFTSS doesn't have a DLL, it's a static-link library. FFTW has a DLL (though you could compile it to link statically too if you wanted). When I run the example I get errors as follows. [... snip lots of shader errors ...] I think these all related about driver because of my driver 2.5 years old and it's last updated driver support only opengl 2.1 and GLSL 1.20. I think I can't run osgOcean in my company computer. I have to use another newer one. Any suggestions? Well, some drivers are more permissive than others regarding implicit casts from vec4 to vec3. Some of the errors above seem to be what some drivers would only give warnings about. I'll try to tighten up the shaders so they give no warnings, that will reduce the number of errors you get, but it won't eliminate all of them, because others are about texture rectangles, which your card/driver doesn't seem to support. The full-screen effects require texture rectangles (NPOT textures) to be able to render at the same resolution as your screen (which is in general not in power-of-two resolutions)... Tuth is, 2.5 years is a long time in Graphics. I assume you have a good reason for not updating your driver, but there's little we can do to support such old drivers and still retain all functionality. We could do it if funded to do so, but if not we have to choose a subset of cards/drivers we need to support and do what is necessary for those. If you want to try and fix all errors, of course, we'll be glad to fold your changes into the source :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martin, Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. I've seen that too, and also: If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. Perhaps they're the same problem, and the black line you see from underwater is peeking over the water only at certain places, hence when above water you only see a few black pixels at different points as the waves move? These two are probably just problems in the shaders, not bugs in drivers or such. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Alejandro, Just to reiterate what J-S said. The oceanExample.exe should be in the same directory as the root resources something like this: Directory_name\oceanExample.exe Directory_name\resources\shaders Directory_name\resources\textures Directory_name\resources\island If you wish to change where the resources are loaded from you can add new data path to the registry within the application.cpp in oceanExample and recompile. Preferably at the top of main(). i.e. osgDB::Registry::instance()-getDataFilePathList().push_back(resources/island); That *should* solve that one. Let me know if it doesn't. Why it cannot change type of Shader? I notice you're using osg 2.9.3, I've tested osgOcean against 2.8. I suspect that the registry in 2.9.3 can now differentiate between the shader extensions .frag and .vert and assigns the shader type automatically. Perhaps Robert could shout out on this one. Either way in osg2.8 at least that doesn't cause the shader to fail but rather flag a warning. I'll try and dig around in the osg 2.9.3 source to see if this is the case. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: 16 June 2009 03:46 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Alejandro, But apparently it doesn't find the instaled resources, neither in the bin directory (instaled there by default) nor in the OSG data directory (where osgDB find things). Only finds them if I run it from the source directory. Not sure about this, I think the easiest way right now is to put resources in a resources subdirectory of your current directory from which you run the executable. So you would have the executable, and in the same directory you'd have resources/shaders, resources/textures, resources/islands. This is configurable if you're developing an app with osgOcean. Just add the path to the resources directory to the osgDB search paths and it will find its resources. I got these output in the console: Building scene... . Loading cubemaps: 0.321772s . Generating ocean surface: 0.000128s . Creating ocean scene: 0.001092s . Loading islands: cannot change type of Shader cannot change type of Shader 0.08298s . Setting up lighting: 7.6e-05s complete. Time Taken: 0.406433s Why it cannot change type of Shader? Not sure what would cause this message. I'll have a look when I get back to my desk tomorrow morning. I'm running it in a Debian GNU/Linux 2.6.26, 8GB RAM, OSG 2.9.3, NV Quadro FX 1700. Thanks for testing, and keep us informed of any cool things you do with osgOcean! :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim,
First up, congrats on the release :-)
On Tue, Jun 16, 2009 at 9:45 AM, Kim C Balek.b...@hull.ac.uk wrote:
Why it cannot change type of Shader?
I notice you're using osg 2.9.3, I've tested osgOcean against 2.8. I suspect
that the registry in 2.9.3 can now differentiate between the shader
extensions .frag and .vert and assigns the shader type automatically. Perhaps
Robert could shout out on this one. Either way in osg2.8 at least that
doesn't cause the shader to fail but rather flag a warning. I'll try and dig
around in the osg 2.9.3 source to see if this is the case.
The .glsl plugin does now set the shader type automatically based on
whether the .frag or .vert extension is used. The code in question is
(from src/osgPlugins/glsl/ReaderWriterGLSL.cpp:
if (shader-getType() == osg::Shader::UNDEFINED)
{
// set type based on filename extension, where possible
if (ext == frag) shader-setType(osg::Shader::FRAGMENT);
if (ext == vert) shader-setType(osg::Shader::VERTEX);
}
I haven't merged this change into the OSG-2.8 branch, which is
probably why you don't see the warning. It would be odd to load a
.vert shader and then set it to be a FRAGMENT shader type so this
suggests a bug lurking in osgOcean or the resources.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, congratulations on the 1.0 release! On 16/6/09 10:45 AM, Kim C Bale wrote: The oceanExample.exe should be in the same directory as the root resources something like this: Directory_name\oceanExample.exe Directory_name\resources\shaders Directory_name\resources\textures Directory_name\resources\island Should the osgOcean-Resources-1.0.rar extract to that directory structure? I'm not sure if it's my environment, but when I unpack that (and the source as well) with 'unrar e rar' I get all files unpacked in the current directory and quite a few overwrites. (This is on OS X with unrar 3.80 from DarwinPorts). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Chris, J-S pretty much covered everything in his reply. I did a fair bit of research into FFT libraries (the free ones) and found that a lot of them didn't support 2D transforms out of the box or they were very poorly documented. Due to time restraints I had to choose the one that was easiest to implement. FFTSS could be dropped in with very little work and was also very straight forward to compile on both linux and windows so I went with that. If you're interested in the timing differences between FFTSS and FFTW I found that FFTSS took approximately twice as long to compute 1000 64x64 complex to complex FFTs. My tests were fairly rudimentary though. I believe J-S found less of a difference when he tested the timings on his machine. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: 16 June 2009 02:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim C Bale wrote: Hi all, - FFT ocean simulation model and rendering - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. I curious if you evaluated the (very free) DJBFFT library and if so, if you found it insufficient. I know someone else who is evaluating FFT libraries and just wanted your input if you had already tried it out and found it lacking. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Robert,
Thank you, thank you.. hopefully there won't be too many bugs to fix.
With regard to the shader type issue. I located the code you pointed out
in the 2.9.3 source.
It looks like the code in 2.9.3 sets the shader type twice if you load a
shader with a .frag or .vert extension whilst also specifying the shader
type using:
inline osg::Shader* readShaderFile(osg::Shader::Type type, const
std::string filename) [include/osgDB/ReadFile]
Which calls this:
inline osg::Shader* readShaderFile(osg::Shader::Type type, const
std::string filename,const ReaderWriter::Options* options)
{
osg::Shader* shader = readShaderFile(filename, options);
if (shader type != osg::Shader::UNDEFINED) shader-setType(type);
return shader;
}
That function goes on to call the readShader in the ReaderWriterGLSL.
This correctly identifies the shader type from the extension and assigns
it. The plugin returns a valid shader with a vaid type, but
readShaderFile will try and set it again because it's checking against
the type passed in not the type already assigned to the shader by the
plugin. The result is the cannot change type of Shader warning
described.
It's a harmless warning, but perhaps a bit misleading if you're
migrating from 2.8.
Regards,
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 16 June 2009 10:01
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim,
First up, congrats on the release :-)
On Tue, Jun 16, 2009 at 9:45 AM, Kim C Balek.b...@hull.ac.uk wrote:
Why it cannot change type of Shader?
I notice you're using osg 2.9.3, I've tested osgOcean against 2.8. I
suspect that the registry in 2.9.3 can now differentiate between the
shader extensions .frag and .vert and assigns the shader type
automatically. Perhaps Robert could shout out on this one. Either way in
osg2.8 at least that doesn't cause the shader to fail but rather flag a
warning. I'll try and dig around in the osg 2.9.3 source to see if this
is the case.
The .glsl plugin does now set the shader type automatically based on
whether the .frag or .vert extension is used. The code in question is
(from src/osgPlugins/glsl/ReaderWriterGLSL.cpp:
if (shader-getType() == osg::Shader::UNDEFINED)
{
// set type based on filename extension, where
possible
if (ext == frag)
shader-setType(osg::Shader::FRAGMENT);
if (ext == vert)
shader-setType(osg::Shader::VERTEX);
}
I haven't merged this change into the OSG-2.8 branch, which is
probably why you don't see the warning. It would be odd to load a
.vert shader and then set it to be a FRAGMENT shader type so this
suggests a bug lurking in osgOcean or the resources.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g*
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal/email_disclaimer.html
*___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Ulrich, I did create a directory structure within the RAR file. It should look like this: osgOcean-Source-1.0.rar --- OsgOcean\ OsgOcean\CMakeModules\ osgOcean\include\ osgOcean\src\ osgOcean\resources\ osgOcean\AUTHORS.TXT etc.. osgOcean-Resources-1.0.rar -- Textures\ island\ The texture and island directories should be extracted into osgOcean\resources\ I created it using WinRAR 3.8 for win32. It does seem odd that the structure isn't getting replicated at your end. Perhaps RAR isn't a great distribution format for cross platform packages, a quick Google seems to suggest that it's not a particularly well used format on Macs. Do you have the same issue with unrarx? If you'd like me to email you a zip file of the source just let me know. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ulrich Hertlein Sent: 16 June 2009 10:11 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, congratulations on the 1.0 release! On 16/6/09 10:45 AM, Kim C Bale wrote: The oceanExample.exe should be in the same directory as the root resources something like this: Directory_name\oceanExample.exe Directory_name\resources\shaders Directory_name\resources\textures Directory_name\resources\island Should the osgOcean-Resources-1.0.rar extract to that directory structure? I'm not sure if it's my environment, but when I unpack that (and the source as well) with 'unrar e rar' I get all files unpacked in the current directory and quite a few overwrites. (This is on OS X with unrar 3.80 from DarwinPorts). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim,
The warning reported only gets reported is the type changes, so if you do:
readShaderFile(osg::Shader::VERTEX,myfile.vert); it shouldn't emit
a warning, but if you do:
readShaderFile(osg::Shader::FRAGMENT,myfile.vert); it will emit a warning.
The code that emits that warning in Shader.cpp looks like:
bool Shader::setType( Type t )
{
if (_type==t) return true;
if (_type != UNDEFINED)
{
osg::notify(osg::WARN) cannot change type of Shader std::endl;
return false;
}
_type = t;
return true;
}
So this suggest to me that in osgOcean there is a mix up on the
types/filenames some where along the line, or a bug in
OSG-2.9.x/svn/trunk Shader.cpp/ReaderWriterGLSL.cpp that we haven't
spotted yet. To me the svn/trunk code looks OK.
Robert.
On Tue, Jun 16, 2009 at 11:57 AM, Kim C Balek.b...@hull.ac.uk wrote:
Hi Robert,
Thank you, thank you.. hopefully there won't be too many bugs to fix.
With regard to the shader type issue. I located the code you pointed out
in the 2.9.3 source.
It looks like the code in 2.9.3 sets the shader type twice if you load a
shader with a .frag or .vert extension whilst also specifying the shader
type using:
inline osg::Shader* readShaderFile(osg::Shader::Type type, const
std::string filename) [include/osgDB/ReadFile]
Which calls this:
inline osg::Shader* readShaderFile(osg::Shader::Type type, const
std::string filename,const ReaderWriter::Options* options)
{
osg::Shader* shader = readShaderFile(filename, options);
if (shader type != osg::Shader::UNDEFINED) shader-setType(type);
return shader;
}
That function goes on to call the readShader in the ReaderWriterGLSL.
This correctly identifies the shader type from the extension and assigns
it. The plugin returns a valid shader with a vaid type, but
readShaderFile will try and set it again because it's checking against
the type passed in not the type already assigned to the shader by the
plugin. The result is the cannot change type of Shader warning
described.
It's a harmless warning, but perhaps a bit misleading if you're
migrating from 2.8.
Regards,
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 16 June 2009 10:01
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim,
First up, congrats on the release :-)
On Tue, Jun 16, 2009 at 9:45 AM, Kim C Balek.b...@hull.ac.uk wrote:
Why it cannot change type of Shader?
I notice you're using osg 2.9.3, I've tested osgOcean against 2.8. I
suspect that the registry in 2.9.3 can now differentiate between the
shader extensions .frag and .vert and assigns the shader type
automatically. Perhaps Robert could shout out on this one. Either way in
osg2.8 at least that doesn't cause the shader to fail but rather flag a
warning. I'll try and dig around in the osg 2.9.3 source to see if this
is the case.
The .glsl plugin does now set the shader type automatically based on
whether the .frag or .vert extension is used. The code in question is
(from src/osgPlugins/glsl/ReaderWriterGLSL.cpp:
if (shader-getType() == osg::Shader::UNDEFINED)
{
// set type based on filename extension, where
possible
if (ext == frag)
shader-setType(osg::Shader::FRAGMENT);
if (ext == vert)
shader-setType(osg::Shader::VERTEX);
}
I haven't merged this change into the OSG-2.8 branch, which is
probably why you don't see the warning. It would be odd to load a
.vert shader and then set it to be a FRAGMENT shader type so this
suggests a bug lurking in osgOcean or the resources.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
*
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal/email_disclaimer.html
*
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Robert,
Sorry, you're absolutely right I didn't think to look in the trunk. I was
looking at the code in these two:
svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.3/
svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.4/
Where the extra comparison isn't present in osg::Shader.
If Alejandro updates I suspect the warning will disappear.
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: 16 June 2009 12:58
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim,
The warning reported only gets reported is the type changes, so if you do:
readShaderFile(osg::Shader::VERTEX,myfile.vert); it shouldn't emit
a warning, but if you do:
readShaderFile(osg::Shader::FRAGMENT,myfile.vert); it will emit a warning.
The code that emits that warning in Shader.cpp looks like:
bool Shader::setType( Type t )
{
if (_type==t) return true;
if (_type != UNDEFINED)
{
osg::notify(osg::WARN) cannot change type of Shader std::endl;
return false;
}
_type = t;
return true;
}
So this suggest to me that in osgOcean there is a mix up on the
types/filenames some where along the line, or a bug in
OSG-2.9.x/svn/trunk Shader.cpp/ReaderWriterGLSL.cpp that we haven't
spotted yet. To me the svn/trunk code looks OK.
Robert.
On Tue, Jun 16, 2009 at 11:57 AM, Kim C Balek.b...@hull.ac.uk wrote:
Hi Robert,
Thank you, thank you.. hopefully there won't be too many bugs to fix.
With regard to the shader type issue. I located the code you pointed out
in the 2.9.3 source.
It looks like the code in 2.9.3 sets the shader type twice if you load a
shader with a .frag or .vert extension whilst also specifying the shader
type using:
inline osg::Shader* readShaderFile(osg::Shader::Type type, const
std::string filename) [include/osgDB/ReadFile]
Which calls this:
inline osg::Shader* readShaderFile(osg::Shader::Type type, const
std::string filename,const ReaderWriter::Options* options)
{
osg::Shader* shader = readShaderFile(filename, options);
if (shader type != osg::Shader::UNDEFINED) shader-setType(type);
return shader;
}
That function goes on to call the readShader in the ReaderWriterGLSL.
This correctly identifies the shader type from the extension and assigns
it. The plugin returns a valid shader with a vaid type, but
readShaderFile will try and set it again because it's checking against
the type passed in not the type already assigned to the shader by the
plugin. The result is the cannot change type of Shader warning
described.
It's a harmless warning, but perhaps a bit misleading if you're
migrating from 2.8.
Regards,
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 16 June 2009 10:01
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim,
First up, congrats on the release :-)
On Tue, Jun 16, 2009 at 9:45 AM, Kim C Balek.b...@hull.ac.uk wrote:
Why it cannot change type of Shader?
I notice you're using osg 2.9.3, I've tested osgOcean against 2.8. I
suspect that the registry in 2.9.3 can now differentiate between the
shader extensions .frag and .vert and assigns the shader type
automatically. Perhaps Robert could shout out on this one. Either way in
osg2.8 at least that doesn't cause the shader to fail but rather flag a
warning. I'll try and dig around in the osg 2.9.3 source to see if this
is the case.
The .glsl plugin does now set the shader type automatically based on
whether the .frag or .vert extension is used. The code in question is
(from src/osgPlugins/glsl/ReaderWriterGLSL.cpp:
if (shader-getType() == osg::Shader::UNDEFINED)
{
// set type based on filename extension, where
possible
if (ext == frag)
shader-setType(osg::Shader::FRAGMENT);
if (ext == vert)
shader-setType(osg::Shader::VERTEX);
}
I haven't merged this change into the OSG-2.8 branch, which is
probably why you don't see the warning. It would be odd to load a
.vert shader and then set it to be a FRAGMENT shader type so this
suggests a bug lurking in osgOcean or the resources.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
*
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal/email_disclaimer.html
*
___
osg-users mailing list
osg
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, On 16/6/09 1:13 PM, Kim C Bale wrote: I did create a directory structure within the RAR file. It should look like this: ... osgOcean-Resources-1.0.rar -- Textures\ island\ ... I created it using WinRAR 3.8 for win32. It does seem odd that the structure isn't getting replicated at your end. Perhaps RAR isn't a great distribution format for cross platform packages, a quick Google seems to suggest that it's not a particularly well used format on Macs. Do you have the same issue with unrarx? unrarx works! Thanks for that. :-) Obviously my mistake was to use unrar e filename instead of unrar x filename. The x option extracts files with full path. Guess I learned something new, sorry for the noise. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Chris, If you're interested in the timing differences between FFTSS and FFTW I found that FFTSS took approximately twice as long to compute 1000 64x64 complex to complex FFTs. My tests were fairly rudimentary though. I believe J-S found less of a difference when he tested the timings on his machine. Yes, I found negligible difference between FFTW single, FFTW double and FFTSS. Not sure what it depends on, but I have a quad-core with 4GB RAM. And since we're talking about something that takes just a few hundredths of a second anyways, the difference is even less significant... Even if it took twice the time, it wouldn't change much in practice. Creating the mesh from the FFT results is what takes most time. You'll see if you change some FFT settings that dirty the ocean mesh (in the oceanExample) it takes a few seconds before the next frame is drawn. This is done in the update traversal when the dirty flag is set on the OceanTechnique. If you're testing out parameters to customize the visual look of the ocean, you can disable automatic dirtying of the geometry, so that it doesn't regenerate each time you make a change. Press capital 'D' to disable this, and then change all your parameters and press small 'd' to dirty the geometry manually when you want to see the result. I'd like to eventually refactor the OceanTechnique a bit. Right now it combines the generation function (FFT) and the meshing (geomipmapping). Separating the two would allow us to change one independently of the other. That's one of the things I'll be doing in the near future. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi, I compiled osgOcean and everything works fine here. I ran into trouble when integrating it with my existing application. When I used the last version of osgOcean, I could just put the ocean somewhere in the scene graph and it did not interact with my other stuff. Now osgOcean blocks my view onto the other objects in the scene. When I add the objects as children to the OceanScene, the objects are shown, but the ocean shaders are applied to the objects. This add some sparkling effects to my animations, which looks nice but is not really what I want. So how can I add my objects to the scene without interference? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14038#14038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martin, This problem arises with two particular effects, the glare and the underwater dof which require special treatment of the alpha component in the framebuffer. You can disable those using: enableUnderwaterDOF(false) enableGlare(false) Then you need to disable the default scene shader with this: setUseDefaultSceneShader(false) In the OceanScene class. If you remove the default shader you'll also lose the underwater light scattering and fogging calculations on models below the surface. Trying to offer lots of out-of-the-box shader effects whilst also accommodating the fixed pipeline is a tricky problem and this area needs a little work, but that should work for you. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 16 June 2009 15:18 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I compiled osgOcean and everything works fine here. I ran into trouble when integrating it with my existing application. When I used the last version of osgOcean, I could just put the ocean somewhere in the scene graph and it did not interact with my other stuff. Now osgOcean blocks my view onto the other objects in the scene. When I add the objects as children to the OceanScene, the objects are shown, but the ocean shaders are applied to the objects. This add some sparkling effects to my animations, which looks nice but is not really what I want. So how can I add my objects to the scene without interference? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14038#14038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgOcean 1.0 (LGPL) Released
Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Great news, congratulations! To compile, is there a way to avoid using the debug libraries of openthreads, fftw and osgviewer? Regards, Alejandro On Mon, Jun 15, 2009 at 5:02 PM, Kim C Balek.b...@hull.ac.uk wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Nevermind, I made it compile. It looks nice (see attached image) and is fast for a real time ocean simulation. But apparently it doesn't find the instaled resources, neither in the bin directory (instaled there by default) nor in the OSG data directory (where osgDB find things). Only finds them if I run it from the source directory. I got these output in the console: Building scene... . Loading cubemaps: 0.321772s . Generating ocean surface: 0.000128s . Creating ocean scene: 0.001092s . Loading islands: cannot change type of Shader cannot change type of Shader 0.08298s . Setting up lighting: 7.6e-05s complete. Time Taken: 0.406433s Why it cannot change type of Shader? I'm running it in a Debian GNU/Linux 2.6.26, 8GB RAM, OSG 2.9.3, NV Quadro FX 1700. Regards, Alejandro On Mon, Jun 15, 2009 at 5:53 PM, Alejandro Aguilar Sierraalgsie...@gmail.com wrote: Hi Kim, Great news, congratulations! To compile, is there a way to avoid using the debug libraries of openthreads, fftw and osgviewer? Regards, Alejandro On Mon, Jun 15, 2009 at 5:02 PM, Kim C Balek.b...@hull.ac.uk wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org attachment: test.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Kim C Bale wrote: Hi all, - FFT ocean simulation model and rendering - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. I curious if you evaluated the (very free) DJBFFT library and if so, if you found it insufficient. I know someone else who is evaluating FFT libraries and just wanted your input if you had already tried it out and found it lacking. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Alejandro, But apparently it doesn't find the instaled resources, neither in the bin directory (instaled there by default) nor in the OSG data directory (where osgDB find things). Only finds them if I run it from the source directory. Not sure about this, I think the easiest way right now is to put resources in a resources subdirectory of your current directory from which you run the executable. So you would have the executable, and in the same directory you'd have resources/shaders, resources/textures, resources/islands. This is configurable if you're developing an app with osgOcean. Just add the path to the resources directory to the osgDB search paths and it will find its resources. I got these output in the console: Building scene... . Loading cubemaps: 0.321772s . Generating ocean surface: 0.000128s . Creating ocean scene: 0.001092s . Loading islands: cannot change type of Shader cannot change type of Shader 0.08298s . Setting up lighting: 7.6e-05s complete. Time Taken: 0.406433s Why it cannot change type of Shader? Not sure what would cause this message. I'll have a look when I get back to my desk tomorrow morning. I'm running it in a Debian GNU/Linux 2.6.26, 8GB RAM, OSG 2.9.3, NV Quadro FX 1700. Thanks for testing, and keep us informed of any cool things you do with osgOcean! :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Chris, I curious if you evaluated the (very free) DJBFFT library and if so, if you found it insufficient. I know someone else who is evaluating FFT libraries and just wanted your input if you had already tried it out and found it lacking. Well, Kim had initially implemented osgOcean using FFTW, and searching for an easy replacement that would remove the GPL limitation, I found FFTSS which has an identical API, so the change was pretty painless (most of the work went into supporting compile-time choice between the two, not in actually supporting FFTSS). I know Kim looked at a few others and had problems with badly documented API with KissFFT notably, but I don't know which others (if any) he checked out. I read the articles on FFT benchmarking on DJBFFT's site, and especially noted that they were quite old. They say version 0.75 was released in 1999, and the current version is 0.76. And also, their install docs state The djbfft installation procedure assumes that you have a UNIX system with gcc. So that kind of put me off, personally, as I don't know if a library dating from 1999 and specifically made for gcc will support newer compilers and Windows... And if it really can be that optimized versus a current library that probably has special optimizations for newer chipsets/SSEx/... It would be worth a try if we really wanted to compare speed and wanted another alternative. It should be easy to implement another option for choosing DJBFFT in addition to the 3 choices right now (FFTW single-precision, FFTW double-precision, FFTSS). But for now FFTW and FFTSS kind of fill the needs we have (one really fast, the other more flexible licensing-wise). Hope that clears things up, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
