Re: [osg-users] Advice sought for rendering coins in OSG. Lots ofcoins.
Hi Christian, Looks great! The behaviour of the coins is spot on. It's crying out for some shiny shaders though.. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christian Buchner Sent: 21 June 2009 23:53 To: OpenSceneGraph Users Subject: Re: [osg-users] Advice sought for rendering coins in OSG. Lots ofcoins. To profile the peformance bottleneck it would be best to press 's' a couple more times to get the full frame rate stats so you can see exactly which parts of rendering are the bottleneck - the frame rate only tells that you frame rate is reducing it doesn't give any clues to why. I am pretty sure I am limited by the physics. Right now I have to reduce the physics time step dynamically to stay within my tolerated frame rate window. A final video (I promise!) is posted here and it shows an almost complete pusher machine and up to 400 coins in the game. http://www.youtube.com/watch?v=0bLAq7btZbUfmt=22 I have since made the pusher operate faster so the player won't fall asleep. I still have to add the game mechanics (player's coin balance, player controlled coin insertion etc). My coins are currently rendered several OSG PositionAttitudeTransforms, all from the same model instance. I may switch to an approach that uses vertex shaders soon. A future enhancement could put the physics on a separate thread from OSG. We will see how that goes. Christian ___ 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 : Integration into existingDatabase/Application
Hi Adrian, I am wondering why you having problem with terrain mainpulators if the deformation gets done in vertex shader. so what i would like to mention is the fact that if the gpu support shader 3 (since 2007) you could pass a texture with deformation field information to the GPU and then the geometry stay allways similar. The deformation doesn't get done in the vertex shader at the moment. However, it is something to think about. K. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: 19 June 2009 15:57 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean : Integration into existingDatabase/Application Hi Kim and John Manipulator developing is a hard task, i will say good and robust and easy to use manipulator are not quite easy to write or to work out. So it would be important having default or common manipulator working with the osgOcean. I am wondering why you having problem with terrain mainpulators if the deformation gets done in vertex shader. so what i would like to mention is the fact that if the gpu support shader 3 (since 2007) you could pass a texture with deformation field information to the GPU and then the geometry stay allways similar. regards adrian 2009/6/19 John Vidar Larring larr...@weatherone.tv Hi Kim and Adrian, As far as I can tell only two of the osgGA manipulators are compatible - Trackball and FlightManipulator. Although you're right the trackball implementation doesn't seem to work correctly, I suspect this is to do with the fact that it doesn't have a node to focus on. TerrainManipulator and DriveManipulators aren't compatible because the ocean surface is animated and they try to position themselves by intersecting with the surface below them, which in the case of the ocean surface, is moving up and down all the time so it creates a nasty camera juddering. I had a go at adding them but I simply couldn't get them to play nicely. If you manage to get them working I'd be interested to see how. Just one idea I'd like to throw out there before I forget. One could possibly make an EllipsoidManipulator quite easily. It would essentially behave like a TerrainManipulator except that it would not take elevation into account; just doing simple ray-ellipoid intersection testing instead. Even better, if there is a way to tell whether intersecting geometry is static or dynamic, one could theoretically implement a manipulator which behaves like the TerrainManipulator over land, and like an Ellipsoid manipulator over the ocean. Best regards, John Kim C Bale wrote: Hi Adrien, Well first the openscenegraph motionmodel or manipluators, manager aren't working. it would be good to get similar behaviour like in application-viewer example. this would be important for integration into existing applications. As far as I can tell only two of the osgGA manipulators are compatible - Trackball and FlightManipulator. Although you're right the trackball implementation doesn't seem to work correctly, I suspect this is to do with the fact that it doesn't have a node to focus on. TerrainManipulator and DriveManipulators aren't compatible because the ocean surface is animated and they try to position themselves by intersecting with the surface below them, which in the case of the ocean surface, is moving up and down all the time so it creates a nasty camera juddering. I had a go at adding them but I simply couldn't get them to play nicely. If you manage to get them working I'd be interested to see how. it be not much easier that we can append a geometry (osg file, ive file ,... ) which should be used to attach the water shaders. I haven't thought a lot about how to implement non-uniform shapes of animated water yet, the goal of osgOcean 1.0 was to get open sea rendering working. However, one of the nice things about the FFT approach is that it tiles. So it would be possible to modify the algorithm so that it places tiles in a non-uniform configuration rather than in a square shape. The current implementation of osgOcean uses a large vertex array that stores the vertices for all the tiles on screen. But a future enhancement will be to store only 1 tiles worth of vertices and then instance it positioning the tiles using a vertex shader. This will be a far more flexible and efficient approach and more suitable for deployment in large terrain datasets. Regards, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli* 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 : Integration intoexisting Database/Application
Hi John, I'm not quite sure I understand the concept of an ellipsoid manipulator. Do you mean form an bounding ellipse over the ocean surface from which would be used to do the intersection? Wouldn't this suffer from strange intersections nearer the edges? Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of John Vidar Larring Sent: 19 June 2009 14:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean : Integration intoexisting Database/Application Hi Kim and Adrian, As far as I can tell only two of the osgGA manipulators are compatible - Trackball and FlightManipulator. Although you're right the trackball implementation doesn't seem to work correctly, I suspect this is to do with the fact that it doesn't have a node to focus on. TerrainManipulator and DriveManipulators aren't compatible because the ocean surface is animated and they try to position themselves by intersecting with the surface below them, which in the case of the ocean surface, is moving up and down all the time so it creates a nasty camera juddering. I had a go at adding them but I simply couldn't get them to play nicely. If you manage to get them working I'd be interested to see how. Just one idea I'd like to throw out there before I forget. One could possibly make an EllipsoidManipulator quite easily. It would essentially behave like a TerrainManipulator except that it would not take elevation into account; just doing simple ray-ellipoid intersection testing instead. Even better, if there is a way to tell whether intersecting geometry is static or dynamic, one could theoretically implement a manipulator which behaves like the TerrainManipulator over land, and like an Ellipsoid manipulator over the ocean. Best regards, John Kim C Bale wrote: Hi Adrien, Well first the openscenegraph motionmodel or manipluators, manager aren't working. it would be good to get similar behaviour like in application-viewer example. this would be important for integration into existing applications. As far as I can tell only two of the osgGA manipulators are compatible - Trackball and FlightManipulator. Although you're right the trackball implementation doesn't seem to work correctly, I suspect this is to do with the fact that it doesn't have a node to focus on. TerrainManipulator and DriveManipulators aren't compatible because the ocean surface is animated and they try to position themselves by intersecting with the surface below them, which in the case of the ocean surface, is moving up and down all the time so it creates a nasty camera juddering. I had a go at adding them but I simply couldn't get them to play nicely. If you manage to get them working I'd be interested to see how. it be not much easier that we can append a geometry (osg file, ive file ,... ) which should be used to attach the water shaders. I haven't thought a lot about how to implement non-uniform shapes of animated water yet, the goal of osgOcean 1.0 was to get open sea rendering working. However, one of the nice things about the FFT approach is that it tiles. So it would be possible to modify the algorithm so that it places tiles in a non-uniform configuration rather than in a square shape. The current implementation of osgOcean uses a large vertex array that stores the vertices for all the tiles on screen. But a future enhancement will be to store only 1 tiles worth of vertices and then instance it positioning the tiles using a vertex shader. This will be a far more flexible and efficient approach and more suitable for deployment in large terrain datasets. Regards, Kim. ___ 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 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 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
[osg-users] FW: [3rdparty] Is the osgOcean Linux bug still present?
From: Kim C Bale Sent: Thu 18/06/2009 19:30 To: bour...@imerir.com Subject: RE: [osg-users] [3rdparty] Is the osgOcean Linux bug still present? Roman, Pierre, Thank you for testing, the pictures were very helpful. Firstly Roman, do you get the same result as Pierre does? Images at the bottom here: http://perso.imerir.com/bourdin/wiki/doku.php/en/projets/osgocean http://perso.imerir.com/bourdin/wiki/doku.php/en/projets/osgocean This is pretty much my first time programming for multiple platforms so I'm rather at a loss as to what could be causing it. My only thought is that perhaps your compilers are doing something that the .net compiler isn't. If you could tell me which compiler you use that might be shed some light on it. What I've done is created a version of the library and dumps a load of variables to file. This should at least point to the general area of the fault. So if you could find the time to download the version of osgOcean found here: http://osgocean.googlecode.com/svn/branches/osgOcean-1.0-debug/ Run it and fly around for a about 10 seconds. Then send me the file called osgOcean_debug.txt that it dumps out I would be extremely grateful. Thanks guys. Kim. From: Pierre Bourdin (gmail) [mailto:bour...@imerir.com] Sent: Thu 18/06/2009 16:54 To: osg-users@lists.openscenegraph.org Cc: Kim C Bale Subject: Re: [osg-users] [3rdparty] Is the osgOcean Linux bug still present? Hi Kim, I'm sorry to tell it is the same for me... I've compiled osgocean from svn trunk and tag 1.0 with fftss-3.0-20071031.tar.gz linked with OpenSceneGraph Library 2.9.4 I've just made a simple run/shutdown log: http://perso.imerir.com/bourdin/wiki/doku.php/en/projets/osgocean If you need more informations, tell me how I could help. Cheers, Pierre. Le jeudi 18 juin 2009 à 12:27 +, Roman Grigoriev a écrit : Hi, I've tried with FFTSS, FFTW3 and FFTWF and got patchy ocean on osg svn trunk on Fedora 11 on GTX285 180.60 drivers Thank you! Cheers, Roman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14162#14162 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Pierre BOURDIN I.M.E.R.I.R. Av. Pascot BP 90443 66004 PERPIGNAN tél: 04 68 56 84 95 fax: 04 68 55 03 86 email: bour...@imerir.com * 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 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 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
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 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
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
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
[osg-users] osgMovie - Possible shader error?
Hi Robert, I had some people bug reports about the use of samplerRect in the osgOcean shaders. I've found out that the prefered format is now sampler2DRect and texture2DRect. Since this has caused problems for me, i noticed you still have a dangling samplerRect in one of the shaders in http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/examples/osgmovie/osgmovie.cpp uniform samplerRect movie_texture;\n On line 413. Just thought I'd point it out since sampler2DRect is used everywhere else the OSG. 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
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 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 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
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] Is the osgOcean Linux bug still present?
Hi all, I know it's only been out one day, but I was wondering if those linux users (it only seemed to occur on certain linux distributions) that experienced the patchy ocean surface bug with the previous version have managed to test the library and noticed if they still have the same issue? It sounded like a pretty nasty bug and I'd like to sort it if it's still present. 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] 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
[osg-users] nVidia 185.5 Windows Drivers issues
Anybody else having issues with the 185.85 drivers for vista 32bit? I just had to roll mine back to 182.5 as they seem to have buggered up FBO support. I get an 'out of memory' ogl error and a INVALID_FRAMEBUFFER_OPERATION_EXT when I run osgPrerender Had the exact same problem a while back with an earlier driver set, I wouldn't mind so much but it takes an age to reinstall them. Running an 8800GTS 512mb. 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] problem with ocean surface in svn
Hi Martin, I've got a new release due imminently (fixing final bugs) which gets rid of the FFTW dependency. I should be able to test that theory after that. I believe Robert got osgOcean working on his linux box whatever flavour that is. And it runs on a Debian distribution in my lab here. I do hope the problem resides with FFTW as it's going to be hard bug to fix without a suitable linux installation. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 09 June 2009 13:25 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn Hi Kim, I just ran into the same problem on our SuSE boxes. Will you take a look at that? Or do you have any pointers for me where to look? As osgOcean works perfectly fine under windows the best guess is to look for differences in the FFTW library, right? Has anyone got osgOcean running successfully under Linux? Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13772#13772 ___ 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] vertex shader help: compare position against plane
I presume this line:
n = (pos1 -pos0) ^ (pos2 - pos1);
is a cross product of two vectors. i.e. the normal, also known as the
vector perpendicular to the two vectors that define the plane.
In which case you would want to use the glsl function cross(vec3,vec3)
as on the reference sheet I sent previously.
You should have a read about the geometry math being used here. Blindy
copying code without understanding it is a good way to shoot yourself in
the foot later on.
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul
Griffiths
Sent: 27 May 2009 13:40
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] vertex shader help: compare position against
plane
ok, i got the world position with:
Code:
mat4 ToWorldMatrix= osg_ViewMatrixInverse* gl_ModelViewMatrix;
vec3 worldPos = ToWorldMatrix * gl_Vertex;
now i need to check which side of the plane the worldPos is.
I googled and found some code for this but its not for glsl, ive came up
with this but i get errors.
the code is:
Code:
vec3 n;
float d;
n = (pos1 -pos0) ^ (pos2 - pos1);
d = -n * pos0;
inside = 1.0;
if (dot(n, gl_Position) + w)
{
inside = 0.0;
}
the errors i get are:
Code:
VERTEX glCompileShader FAILED
VERTEX Shader infolog:
0(46) : error C1021: operands to ^ must be integral
glLinkProgram eroded FAILED
Program eroded infolog:
Vertex info
---
0(46) : error C1021: operands to ^ must be integral
Warning: detected OpenGL error 'invalid operation' after
RenderBin::draw(,)
so i tried
Code:
vec3 n;
float w;
int p0 = (pos1 -pos0);
int p1 = (pos2 - pos1);
n = p0 ^ p1;
w = -n * pos0;
inside = 1.0;
if (dot(n, worldPos) + w)
{
inside = 0.0;
}
but it alway returns inside = 0.0;
any ideas?
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13031#13031
___
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] [osgPPU] DOF crash
Hi Art, I was just playing with osgPPU with an eye to using it with osgOcean. It all compiles and runs nicely except for the osgppu_dof example which produces the effect- i get a nicely in/out focus cow - but then crashes after a few seconds. Is this a known issue? Everything else seems to work. 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] [osgPPU] DOF crash
Hi Art, I simply ran a release compiled version of the dof example. When I get a moment I'll run it through the .net debugger and try and pin point the crash for you. btw I'm running vista 32, 8800GTS 512mb with the 178.13 driver set. Actually it could be my drivers, they appear to be horrendously out of date. Wiil get back to you.. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Art Tevs Sent: Mon 25/05/2009 17:35 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgPPU] DOF crash Hi Kim, I know about this crash, however in all of my cases the crash appears in very rare situation. The bad thing, I cannot reproduce it, hence I wasn't able to find out why it crashes :( If you could describe the situation when the crash appears, maybe I could write then a patch to solve the issue. Cheers, art Kim C Bale wrote: Hi Art, I was just playing with osgPPU with an eye to using it with osgOcean. It all compiles and runs nicely except for the osgppu_dof example which produces the effect- i get a nicely in/out focus cow - but then crashes after a few seconds. Is this a known issue? Everything else seems to work. Regards, Kim. -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12918#12918 ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture always facing screen?
Hi Paul,
If I understand the problem correctly you can use a screen aligned quad with a
post render camera that has an orthographic projection.
i.e.
osg::Geometry* quadGeometry = osg::createTexturedQuadGeometry( osg::Vec3(0.0,
0.0, -1.0), osg::Vec3(screenWidth,0.0,0.0), osg::Vec3(0.0,screenHeight,0.0),
texSize.x(),texSize.y() );
Bind texture to the quadGeometry
Then use the following camera:
osg::Camera* camera = new osg::Camera;
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
camera-setClearColor( osg::Vec4(0.f, 0.f, 0.f, 1.0) );
camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF_INHERIT_VIEWPOINT);
camera-setProjectionMatrixAsOrtho( 0.f, screenWidth, 0.f, screenHeight, 1.0,
500.f );
camera-setViewMatrix(osg::Matrix::identity());
camera-setViewport( 0, 0, _screenDims.x(), _screenDims.y() );
camera-setRenderOrder( osg::Camera::POST_RENDER );
camera-addChild(quadGeometry);
root-addChild(camera);
Using that the texture will always be infront of the camera and facing the
screen.
Regards,
Kim.
From: osg-users-boun...@lists.openscenegraph.org on behalf of Paul Griffiths
Sent: Sat 23/05/2009 08:42
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Texture always facing screen?
Hi,
How can i get a texture to be displayed always facing the screen? the width of
the texture has to be the width of the screen, same for height. and the corner
of the texture always start at screen coords 0,0
osg::StateSet* stateset = new osg::StateSet();
osg::Image* image =
osgDB::readImageFile(Images/panelForeground.png);
if (image)
{
image-setPixelFormat(GL_BGRA);
osg::Texture2D* texture = new osg::Texture2D;
texture-setImage(image);
texture-setWrap(osg::Texture2D::WRAP_S,
osg::Texture2D::REPEAT);
texture-setWrap(osg::Texture2D::WRAP_T,
osg::Texture2D::REPEAT);
stateset-setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON);
stateset-setMode(GL_LIGHTING,osg::StateAttribute::ON);
stateset-setMode(GL_DEPTH_TEST,osg::StateAttribute::ON);
foregroundGeometry-setStateSet( stateset );
}
...
Thank you!
Cheers,
PaulG
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12801#12801
___
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
*___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture always facing screen?
Ok, I think I get you. You could achieve that by using a texgen node to compute a set of projected texture coordinates for the plane and then map the texture onto it. osgReflection would be a good place to look for that. You'd want a similar approach but instead of using the prerender stage to create the texture, use your full screen one, and get rid of the axis flip it uses. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Paul Griffiths Sent: Sat 23/05/2009 14:41 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Texture always facing screen? Heres an easyer way to show what im after [Image: http://img196.imageshack.us/img196/9836/textureo.png ] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12806#12806 ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Referencing loaded models
Hi Sebastian, Unless you explicitly ask the osg to clone your model's geometry it will share the geometry by default. It simply stores a pointer to the loaded model's vertices etc. So the below code should work for you. You can also set osgDB to cache the model in memory so that if you ever call osgDB::load() with the same path and filename it will just return a pointer to the cached model rather than reloading it. osg::Group* rootNode = new osg::Group; osg::Node* loadedModel = osgDB::load(); osg::PositudeAttitudeTransfrom* instance_1 = new osg::PositudeAttitudeTransfrom instance_1-setPosition( 10.f, 0.0, 0.0); instance_1-addChild(loadedModel); osg::PositudeAttitudeTransfrom* instance_2 = new osg::PositudeAttitudeTransfrom instance_2-setPosition( 20.f, 0.0, 0.0); instance_2-addChild(loadedModel); osg::PositudeAttitudeTransfrom* instance_3 = new osg::PositudeAttitudeTransfrom instance_3-setPosition( 30.f, 0.0, 0.0); instance_3-addChild(loadedModel); //now attach the instances to the graph rootNode-addChild(instance_1); rootNode-addChild(instance_2); rootNode-addChild(instance_3); viewer.setSceneData(rootNode); Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Sebastian Messerschmidt Sent: Sat 23/05/2009 14:42 To: OpenSceneGraph Users Subject: [osg-users] Referencing loaded models Hi, This might be a total beginners question, but I didn't find any sufficient information in the forum nor in the documentation. Let's assume I have a scene composed of some models, let's say a trees/houses which are the same model. If I want to load the model once and use it multiple times (with different transform/state) what is the best way to handle this. The naive way would be to load the model for each instance and add it to the scene graph. But there must be some way to share the node. What I had in mind is to load the model exactly once and sort of clone it in a way that the geometry/textures are still shared and only referenced multiple times. As I understand DRAW_INSTANCED, it performs something like this on GPU side. But what I want is more like a logical structure. I'm sort of lost. If I naively take a loaded model and just add it to the scene-graph with different transform nodes as parent it is still displayed only once :-( something like: osg::Node* loadedModel = osgDB::load(); osg::Node* rootNode = new osg::Group; // create some transforms for different instances osg::Transform* instance_1 = new osg::PositudeAttitudeTransfrom ... set some position to instance_1 osg::Transform* instance_2 = new osg::PositudeAttitudeTransfrom ... set some position to instance_2 osg::Transform* instance_3 = new osg::PositudeAttitudeTransfrom ... set some position to instance_3 //now attach the instances to the graph rootNode.addChild(instance_1); rootNode.addChild(instance_2); rootNode.addChild(instance_3); Shouldn't that work? cheers Sebastian ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Referencing loaded models
Could you not check the name of parent node to identify the instance of the child? I might be wrong I haven't used the picking functionality for a while. K. From: osg-users-boun...@lists.openscenegraph.org on behalf of Paul Griffiths Sent: Sat 23/05/2009 15:39 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Referencing loaded models Kim C Bale wrote: Hi Sebastian, Unless you explicitly ask the osg to clone your model's geometry it will share the geometry by default. It simply stores a pointer to the loaded model's vertices etc. So the below code should work for you. You can also set osgDB to cache the model in memory so that if you ever call osgDB::load() with the same path and filename it will just return a pointer to the cached model rather than reloading it. osg::Group* rootNode = new osg::Group; osg::Node* loadedModel = osgDB::load(); osg::PositudeAttitudeTransfrom* instance_1 = new osg::PositudeAttitudeTransfrom instance_1-setPosition( 10.f, 0.0, 0.0); instance_1-addChild(loadedModel); osg::PositudeAttitudeTransfrom* instance_2 = new osg::PositudeAttitudeTransfrom instance_2-setPosition( 20.f, 0.0, 0.0); instance_2-addChild(loadedModel); osg::PositudeAttitudeTransfrom* instance_3 = new osg::PositudeAttitudeTransfrom instance_3-setPosition( 30.f, 0.0, 0.0); instance_3-addChild(loadedModel); //now attach the instances to the graph rootNode-addChild(instance_1); rootNode-addChild(instance_2); rootNode-addChild(instance_3); viewer.setSceneData(rootNode); Regards, Kim. That works fine unless your pickick with the mouse. Is you select any of the nodes it always selects the first node :( So i had to make a clone for each instance. Guess it depense if your picking... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12815#12815 ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] problem with ocean surface in svn
Ah my apologies I must have missed that. I'll look into it. Thanks for reporting the issue. Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jordi Torres Sent: 22 May 2009 12:15 To: OpenSceneGraph Users Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn Hi Kim, I'm usig Ubuntu 9.04 and Roman is using fedora 10 as he said in his first post. My driver version is 180.44. Regards, Jordi. 2009/5/22 Kim C Bale k.b...@hull.ac.uk Are you using Ubuntu 9.04 aswell? Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 22 May 2009 06:22 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn OSG version from SVN 8600M GT linux 180.51 drivers -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Kim C Bale Sent: Thursday, May 21, 2009 6:45 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn Hi Roman, Which version of OSG 2.8 or 2.8.1? I haven't tried linking it against 2.8.1 yet, so it's possible something broke. What graphics card/drivers are you using? Sorry about all the questions but nobody has reported similar problems and I'm rather at a loss as to why the tessellation would break so badly. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 21 May 2009 12:32 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn No It's your example compiled with openscenegraph svn. Regards, Roman -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Kim C Bale Sent: Thursday, May 21, 2009 12:18 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn Hi Roman, Are you running the example application or is it something that you've created yourself using the library? No need to send a screenshot. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 20 May 2009 18:22 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn you see in the middle of the picture there is flat surface so there is no waves there. and all surface is like a chess board with waves and without if you want I can send a screenshot with textures. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12620#12620 ___ 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 ___ 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 ___ 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 -- Jordi Torres Fabra Instituto de Automática e Informática Industrial http://www.ai2.upv.es * 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] Advice sought for rendering coins in OSG. Lots of coins.
Hi Christian, Out of interest are you simulating a penny push machine? I had the same idea for a hobby project a while back. It's a great idea, although it might be tricky to get the physics working nicely. Unfortunately my ponderings stop there as I never found the time to get on it. However, with regards to glsl effects you wanted, try these two pages http://www.typhoonlabs.com/tutorials/glsl/Chapter_4.pdf http://www.ozone3d.net/tutorials/index_glsl.php They give good explanations and glsl implementations. Getting the shaders to work with the OSG will be trivial. Personally I wouldn't set the Intel GMA chipset as your minimum spec. You'll be making life difficult for yourself just to accommodate hardware that makes a half arsed attempt to offer hardware accelerated 3D. ( Just my 2p ;) ) Hope that helps a little. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christian Buchner Sent: 22 May 2009 11:57 To: OpenSceneGraph Users Subject: [osg-users] Advice sought for rendering coins in OSG. Lots of coins. Hi, I was going to start a hobby (i.e. noncommercial) project to simulate an electromechanical coin arcade game. This would include rendering potentially hundres of coins that physically interact (think 500...1000 coins). For the physics simulation I am going for the free bullet physics package. For rendering I intend to use OSG. One problem with GPUs is that round shapes map badly to triangle meshes. One needs a lot of triangles to make the coins appear sufficiently round. Lots of vertices may conflict with the idea of rendering many coins simultaneously. I could go down the route of using a mesh based 3D model combined with LOD techniques. However this may incur some performance issues on architectures like Intel GMA that have pixel shaders in hardware but do all their vertex processing on the CPU. Also I would really like to include a 3D relief for the coin imprinting (embossment), either by using simple bump mapping or more advanced pixel shader based techniques like parallax mapping or relief mapping. To get simulated (fake) reflections I need to apply some kind of environment mapping. Considering that I will have to use pixels shaders anyway, I was thinking that this can a pixel shader could just as well be used to also render a geometric primitive like for example a cylinder. The pixel shader would have to do some calculatios like does the view ray intersect with the primitive? and what is the surface normal?... very much like in raytracing. The only vertex based geometry needed would be a billboard that fully covers the visible extents of the geometric primitive (or alternatively a box that wraps around the visible extents of the primitive) To get started with this I could use a few pointers and suggestions. 1) Does anyone here know some open sourced OSG based code that renders primitives like spheres, cylinders, cones or the like within a GLSL pixel shader? I know there have been projects in academia that did just this, but is there anything open sourced? 2) Would anyone know a nicely done (in terms of documentation, clarity) parallax mapping or relief mapping implementation in GLSL and OSG? I've found a lot of conference papers on this (Siggraph etc) but almost no source code. It's often 10 times harder to start something from scratch than to modify someone's existing code. So thanks a lot for any pointers and help, Christian ___ 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] problem with ocean surface in svn
Hi Roman, Are you running the example application or is it something that you've created yourself using the library? No need to send a screenshot. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 20 May 2009 18:22 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn you see in the middle of the picture there is flat surface so there is no waves there. and all surface is like a chess board with waves and without if you want I can send a screenshot with textures. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12620#12620 ___ 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] problem with ocean surface in svn
Hi Roman, Which version of OSG 2.8 or 2.8.1? I haven't tried linking it against 2.8.1 yet, so it's possible something broke. What graphics card/drivers are you using? Sorry about all the questions but nobody has reported similar problems and I'm rather at a loss as to why the tessellation would break so badly. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 21 May 2009 12:32 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn No It's your example compiled with openscenegraph svn. Regards, Roman -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Kim C Bale Sent: Thursday, May 21, 2009 12:18 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn Hi Roman, Are you running the example application or is it something that you've created yourself using the library? No need to send a screenshot. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 20 May 2009 18:22 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [osgOcean] problem with ocean surface in svn you see in the middle of the picture there is flat surface so there is no waves there. and all surface is like a chess board with waves and without if you want I can send a screenshot with textures. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12620#12620 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ 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] problem with ocean surface in svn
Hi Roman, I can't see what the problem is from the screenshot I'm afraid, can you explain? Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roman Grigoriev Sent: 20 May 2009 13:10 To: osg-users@lists.openscenegraph.org Subject: [osg-users] [osgOcean] problem with ocean surface in svn Hi, I've just compile osgOcean from svn and have this situation like on screenshot I think there is a problem with geomipmapping testbox - fedora 10 with nvidia 180.51 drivers ... Thank you! Cheers, Roman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12589#12589 * 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 release
Hi Robert, LOD'ing, tiling and local coordinate systems are the tools of the whole earth database trade. In the context of osgOcean I would expect to have several different techniques - one for near water effects like you have which his surface displacement and shaders, then for lower levels of detail techniques that just have static geometry meshes and shaders/textures for the water rendering. You'd also want to try an reuse tiles so that as you move out of range of one set of tiles these then get reused for the new tiles that need to be created. It is sometimes possible to reuse a small set of geometries and just use shaders to map the separate instances - this is what I did for the rain and snow effects - it's an effectively infinite effect, but implementation it's just a single block of geometry that is animated and positioned by uniforms pass into shaders to look like an infinite effect. Perhaps something similar might be possible. All sounds very possible, infact, I've just implemented a similar endless ocean effect into the library. It's in it's infancy, it's not optimised in anyway, but shifting the workload onto the GPU would be fairly trivial. As for the differant techniques, that should be quite simple. From a great distance I think a poly with animated normal maps would surfice, but it's hard to say without experimenting with it. The other challange would be the non uniform boundaries between water and land. Is there any support for this? This is a problem, the FFT ocean looks nice for large expanses of open sea but as you get to shallower depths the wave formations change so the interaction may look odd. As to how the polys interact with the land geometry I haven't tried. I've got a modeller making an island for the demo app so I'll be able to see what that looks like. Understood. Is it possible to do lakes and non flowing rivers though Lakes shouldn't be a problem. Non flowing rivers, slightly more challenging, but something I'll look into. Plenty to look into :) Hope you're feeling better. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield Sent: Mon 11/05/2009 20:41 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim, On Mon, May 11, 2009 at 7:50 PM, Kim C Bale k.b...@hull.ac.uk wrote: Is there any chance that we'd be able to get osgOcean working on geocentric databases? It'd be very cool to be able zoom down from space to the sea. As I don't know a lot about geocentric databases it would be hard for me to say. But the potential for animated oceans on very large terrain datasets would be very exciting. For very large expanses of ocean the problem I forsee is the time it takes to update the vertices and primitive sets. LOD'ing, tiling and local coordinate systems are the tools of the whole earth database trade. In the context of osgOcean I would expect to have several different techniques - one for near water effects like you have which his surface displacement and shaders, then for lower levels of detail techniques that just have static geometry meshes and shaders/textures for the water rendering. You'd also want to try an reuse tiles so that as you move out of range of one set of tiles these then get reused for the new tiles that need to be created. It is sometimes possible to reuse a small set of geometries and just use shaders to map the separate instances - this is what I did for the rain and snow effects - it's an effectively infinite effect, but implementation it's just a single block of geometry that is animated and positioned by uniforms pass into shaders to look like an infinite effect. Perhaps something similar might be possible. The other challange would be the non uniform boundaries between water and land. Is there any support for this? Another little point with geocentric databases is that each tile is slightly curved, the lower the level of detail the large the area covered and the more curvature it will have. For precision one also uses a local MatrixTransform above each tile to ensure that there is a local origin in the center of the tile to maximum precision. One also need to think about the how the tiles boundaries are managed, with a dynamic effect like sea it'll be more difficult to hide than on terrain where even crude skirts can be sufficient. If the boundary is far enough then the gap might be small enough not to matter. However, since the FFT technique is tileable it would be possible to only update 1 tile and then translate them into position using a shader. This would rule out any surface interactions, but for this type of application they probably wouldn't be necessary. I'll add it to the list of things to look at. Is there are plans for following water like in rivers? For the moment rivers are out of the scope of the project as I think this would require a totally differant
Re: [osg-users] osgOcean release
Hi David, Pretty clever solution, but yes it does sound difficult to implement as a general case. To be honest I've don't think I've seen a real time ocean simulation with geometric wake formations, they usually just use texture overlays. I thought the overhead was too great. Perhaps I'm behind the times :) Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of David Spilling Sent: Mon 11/05/2009 20:44 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Kim, For very large expanses of ocean the problem I forsee is the time it takes to update the vertices and primitive sets. However, since the FFT technique is tileable it would be possible to only update 1 tile and then translate them into position using a shader. This would rule out any surface interactions Surface interactions in terms of locally modifying the vertex heights? Tileable FFT doesn't definately rule it out : you can use the following approach: 1) render a FFT derived heightfield into a texture 2) RTT local heightfields (wakes and so on) attached to some object , as if you were the camera. 3) Use a vertex shader operating on a screen-aligned grid (i.e. projective grid approach) and some vertex texture operations to sample the FFT heightfield for the correct world position, and also to sample the RTT texture of local vertex heights. Unfortunately, the possibility of this type of technique makes providing some sort of overall osgOcean architecture that can act as a framework for all techniques very tricky, IMHO. (you get entangled in too many overall scenegraph issues) David winmail.dat* 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 release
Thanks, I've been looking at KissFFT and it's a real pain to use as the documentation is pretty sparse. This one looks a little more readable. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Chris 'Xenon' Hanson Sent: Wed 13/05/2009 23:53 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Jean-Sébastien Guay wrote: Yes, that's one of the tested libraries in the FFTW benchmark: http://www.fftw.org/speed/CoreDuo-3.0GHz-icc/ http://www.fftw.org/benchfft/ffts.html See also: http://cr.yp.to/djbfft.html http://cr.yp.to/djbfft/bench-notes.html Old, but at one time was faster than FFTW. And free. J-S -- 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 winmail.dat* 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] Taking it easy for a couple of days
- eat lemons, this helps really Haha what a great image. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Art Tevs Sent: Thu 14/05/2009 10:14 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Taking it easy for a couple of days Hi Paul, Robert, whenever I get cold, I do following: - drink a lot of (water, juice, whatever, no alcohol!!!) - drink black/green tea with honey - eat lemons, this helps really - then put a lot of clothes over you over night so that you start to sweat - sweating means you increase your body temperature, which meanse you help you body to fight against the invaiders :) And the best advice, stop thinking like: Ohh, I am sick... I am so sick... I cannot do anything... Be positive, this helps also a lot! I wish you fast recovery and take care !!! art Paul Speed wrote: If you ever need a quick breather to clear your head... drink pineapple juice. Something in it cuts through the crud but it doesn't last long. ...sometimes it's just enough to keep one sane, though. :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12083#12083 ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
Hi Robert, Is there any chance that we'd be able to get osgOcean working on geocentric databases? It'd be very cool to be able zoom down from space to the sea. As I don't know a lot about geocentric databases it would be hard for me to say. But the potential for animated oceans on very large terrain datasets would be very exciting. For very large expanses of ocean the problem I forsee is the time it takes to update the vertices and primitive sets. However, since the FFT technique is tileable it would be possible to only update 1 tile and then translate them into position using a shader. This would rule out any surface interactions, but for this type of application they probably wouldn't be necessary. I'll add it to the list of things to look at. Is there are plans for following water like in rivers? For the moment rivers are out of the scope of the project as I think this would require a totally differant approach. The problem is that I'm torn between what I'd like to do and what I'm bound by contract to open source. So for the moment I'm concentrating on getting the code out to keep the reviewers happy, then once I'm done with that I'll do some research into the many suggestions that have been posted here. Sorry for the all the awkward questions, this stuff is just too pretty not to want to put it everywhere :-) Not at all. I'm extremely happy that it has been so well recieved. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield Sent: Fri 08/05/2009 19:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim, On Fri, May 8, 2009 at 5:58 PM, Kim C Bale k.b...@hull.ac.uk wrote: Hi Robert, You need to download the resource pack from the downloads sections and drop the textures into the resource directory before you hit install. I seperated them as I didn't want them to get versioned. But everyone seems to be tripping up on that one so perhaps I should include them by default. Ack... case of me not doing any background reading... Sorry about that. I get the same 'invalid operation' error on an nVidia, I just haven't located the source yet :) still working on it. If you up the OpenGL error checking in osg::State to per StateAttribute you might get a more precise location of the error. After realize you could just do the following on all the viewers graphics windows: graphicswindow-getState()-setCheckForGLErrors(osg::State::ONCE_PER_ATTRIBUTE); It's possible the choppy frame rate is caused by the update callback when it updates the primitives and vertices on a resolution change. If you turn on stats you can see the update callback pinging up when theres a change. I hadn't thought about this actually, on my machine it's barely noticeable. I think i may need to thread the update to prevent the frame being delayed. I had the KDE desktop compositor enabled during my earlier tests. I tested just now with the desktop compositor off and got a solid 75Hz so it does look like it's the ATI driver/KWin compositor not working smoothly. So it does look this is a non issue. Is there any chance that we'd be able to get osgOcean working on geocentric databases? It'd be very cool to be able zoom down from space to the sea. Is there are plans for following water like in rivers? Sorry for the all the awkward questions, this stuff is just too pretty not to want to put it everywhere :-) Robert. ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean release
Hi Martin Thanks for testing it. The screen issue is an odd one, I'll try and reproduce it and fix it. I'll check in a fix in for the resources path today. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Martin Scheffler Sent: Thu 07/05/2009 15:49 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [3rdparty] osgOcean release Hi, I tried everything out and it looks awesome! Some notes: The demo crashes when I use multiple screens. Disabling the extra screen fixed this, so does preventing fullscreen. I have started to integrate this as an actor into the Delta3D game engine. This works pretty good, the only thing that misses is a way to set the location of the water shaders from the outside. At the moment the shader locations are hard coded to the resources folder. Could you change that? Thank you! Cheers, Martin Scheffler -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11626#11626 ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
Hi Sergey, Yes, this is intentional. It came to my attention that the FFTW library is covered by a GPL license and therefore the library must also share the status. However, I am working on replacing the FFTW library with an LGPL alternative so that I can change it back to LGPL, but until then I will have to keep the GPL license. I'll update when I've swapped the library. Apologies. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Sergey Kurdakov Sent: Fri 08/05/2009 12:33 To: OpenSceneGraph Users Subject: [osg-users] osgOcean release Hi Kim, what I noticed that osgOcean ( on main page at google code and as well in License.txt in svn ) is licensed under GPL not LGPL or OSGGPL, is this intended or it is just a mistyping ? Regards Sergey ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
Thanks for clarifying Robert and Sergey. Working in academia these license issues rarely come up. Clearly my understanding has got a little mixed up. I'll amend the license information on the svn. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield Sent: Fri 08/05/2009 13:29 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim, On Fri, May 8, 2009 at 1:04 PM, Kim C Bale k.b...@hull.ac.uk wrote: Hi Sergey, Yes, this is intentional. It came to my attention that the FFTW library is covered by a GPL license and therefore the library must also share the status. However, I am working on replacing the FFTW library with an LGPL alternative so that I can change it back to LGPL, but until then I will have to keep the GPL license. I don't think this is required. Your own source code is yours to license how you like, it's the final composite work that would have to licensed as the GPL. For instances your headers and source could be LGPL, but when you link your application against the GPL library then resulting osgOcean library would need to be under the GPL. If FFTW was replaced by another library that was LGPL then the resulting library would be LGPL, if this library was binary binary compatible then you could actually swap the two implementations without changing anything in your code, and with it the license rules would change with it. If you make your own source code GPL, even temporarily then this isn't possible. Robert. ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
Hi Dimi, Ooh.. err.. I'm not sure about this one. My resident linux guru has gone home for the weekend. But I know he's managed to compile it on debian using the what looked like the bog standard linux CMake interface. Not even sure what ccmake is to be honest. Perhaps someone that speaks linux can help me out on this. Sorry.. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of dimi christop Sent: Fri 08/05/2009 15:14 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi, i am having issues to compile osgOcesn on my linux box. In ccmake . it asks to set osg-DIR to the directory contianing osgConfig.cmake There is no such file in my osg directory. Thanks Dimi ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
Hi Dimi, I've only tested the build on CMake 2.6 I'm afraid. I've added the line cmake_minimum_required (VERSION 2.6) in there to make sure we're all singing from the same hymn sheet but it seems that cmake 2.4 doesn't present the warning without adding a FATAL_ERROR variable inside the brackets. It does appear that a range of commands were deprecated between 2.4 and 2.6 but I'm having trouble finding which ones were. Perhaps you could try CMake 2.6? Regards Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Jean-Sébastien Guay Sent: Fri 08/05/2009 16:07 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Dimi, This is what I did but it specificaly asks for this osgConfig.cmake file. On a note I use cmake 2.4 patch 6 with which i compiled osg-2.8. Is it possible that only cmake 2.6 and up is working on osgOcean builds? It's possible, someone who knows CMake more than me will have to confirm. If that's the case then at least the CMake files for osgOcean should print an error if using a bad version of CMake (which I can do if we get confirmation that it's needed). 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 winmail.dat* 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 release
Hi Robert, You need to download the resource pack from the downloads sections and drop the textures into the resource directory before you hit install. I seperated them as I didn't want them to get versioned. But everyone seems to be tripping up on that one so perhaps I should include them by default. I get the same 'invalid operation' error on an nVidia, I just haven't located the source yet :) still working on it. It's possible the choppy frame rate is caused by the update callback when it updates the primitives and vertices on a resolution change. If you turn on stats you can see the update callback pinging up when theres a change. I hadn't thought about this actually, on my machine it's barely noticeable. I think i may need to thread the update to prevent the frame being delayed. Thanks for giving it a whirl. It seems I have plenty of things to fix. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield Sent: Fri 08/05/2009 17:20 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim, I haven't had a chance to test osgOcean out till now. Just download and it compiled fine for my under Kubuntu 9.04. Everything builds cleanly but when I do an make install I get an error: CMake Error at src/osgOcean/cmake_install.cmake:74 (FILE): file INSTALL cannot find file /home/robert/3rdParty/osgocean/resources/textures/sea_foam.png to install. This sounds seem too severe as I'm still able to run the oceanExample and get some nice animating waves. I do get the following error each time I toggle between the different presets: Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I'm afraid I don't have any more info than this. I have an ATI 4670 card in this machine so this is probably the culprit. The sky is also black, I presume I missing some other textures. The frame rate is also a bit erratic, even when I compile in release build. Should I expect a solid 60Hz? Robert. ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
Ah, well I'll send you a quick hack for this. The INT is used to identify the active light, in the example uLightID is just zero. This is actually one of the problems that I tried to address with the half finished DynamicShader class in amongst the code. I came to the conclusion that it might be better to have a huge uber shader and block out bits effects code with #defines or add constant variables such as the light id using the same method. This way the shader is much more effecient as it reduces branching and also the number of uniforms sent to the shader which is important for the cards supporting lesser shader models. Anyway drop the attached shaders into the resources/shaders directory and give it a whirl. You may find that the shader maxes out the number of varying variables allowed in glsl 1.1 but I can't remember how many are allowed off the top of my head. Let me know how you go. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Thu 07/05/2009 09:07 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim; After last updates I don't see any error about vertex shader as before I saw. But now I have checked the OpenGL and GLSL driver version and saw that OpenGL is 2.0 and GLSL is 1.1 so when I opened up the osgOceanExample I see Error: glUniform1uiv not supported by OpenGL driver. Because of glUniform1uiv function is in GLSL 1.3. I have tried to update my driver for 2 hours but can't find anything because of my card is about 2 years old :( Is there any way to update my driver to OpenGL 3.0 seperate from Graphic Card driver? Or what can I do for this trouble? My Graphic Card : ATI Radeon Mobility HD 2300 256 MB OS : Windows XP Best Regards. 2009/5/6 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi David, I would suggest that an all GPU FFT would just be one in a selection of possible ocean surface techniques. An architecture that supports many such techniques would be a good goal for this kind of project ! I totally agree. I'll be looking into how feasible this is, not just for offloading surface generation to the GPU, but in general for allowing selecting the surface generation technique from a list of possible techniques with different tradeoffs. As soon as there's a non-GPL alternative integrated instead of FFTW, I can start working on that. 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 -- Ümit Uzun winmail.dat* 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 release
David,J-S,Art, Yes this the direction I envisaged for it, I attempted to pull out some common variables into an OceanTechnique base class, but as you can see in the code, that all went a bit pear shaped as I didn't really know how the others were going to be implemented.. The CUDA implementation is certainly something to look at but should be seen as an alternative rather than a main route as it excludes people with lesser graphics cards and, dare I say, it the ATI contingent. There's a nice video here if people are interested. http://www.youtube.com/watch?v=K1I4kts5mqc K. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Jean-Sébastien Guay Sent: Wed 06/05/2009 20:07 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi David, I would suggest that an all GPU FFT would just be one in a selection of possible ocean surface techniques. An architecture that supports many such techniques would be a good goal for this kind of project ! I totally agree. I'll be looking into how feasible this is, not just for offloading surface generation to the GPU, but in general for allowing selecting the surface generation technique from a list of possible techniques with different tradeoffs. As soon as there's a non-GPL alternative integrated instead of FFTW, I can start working on that. 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 winmail.dat* 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 release
See attached. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Thu 07/05/2009 10:04 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim; Thanks for your help but I think when you attach the water vertex and fragment shadr you had made a mistake and you attached two of them in vertex there is no fragment shader. Now I have achieved to GLSL 1.2 and OpenGL 2.1 but it still not enough. I am trying to update to 3.0. Now previous Error gone away but now application send fragment shader not supported as you can see from command screen; glLinkProgram FAILED Program infolog: Fragment shader(s) failed to link, vertex shader(s) linked. Fragment Shader not supported by HW Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Could you attach water.f please? :) Best regards and Thanks. 2009/5/7 Kim C Bale k.b...@hull.ac.uk David,J-S,Art, Yes this the direction I envisaged for it, I attempted to pull out some common variables into an OceanTechnique base class, but as you can see in the code, that all went a bit pear shaped as I didn't really know how the others were going to be implemented.. The CUDA implementation is certainly something to look at but should be seen as an alternative rather than a main route as it excludes people with lesser graphics cards and, dare I say, it the ATI contingent. There's a nice video here if people are interested. http://www.youtube.com/watch?v=K1I4kts5mqc K. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Jean-Sébastien Guay Sent: Wed 06/05/2009 20:07 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi David, I would suggest that an all GPU FFT would just be one in a selection of possible ocean surface techniques. An architecture that supports many such techniques would be a good goal for this kind of project ! I totally agree. I'll be looking into how feasible this is, not just for offloading surface generation to the GPU, but in general for allowing selecting the surface generation technique from a list of possible techniques with different tradeoffs. As soon as there's a non-GPL alternative integrated instead of FFTW, I can start working on that. 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 -- Ümit Uzun winmail.dat* 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 release
Hi Umit, No I think it is a straight forward fact that glsl 1.2 doesn't support uniform ints. Can't say that for certain though as I haven't checked. The uLightID value is defined in the OceanExample code so it's pretty much fixed unless you've tinkered with it. If you wish to use a differant light source, just change the number in the gl_LightSource code in the fragment and vertex shaders. It's not an elegant fix but I'll look into a way of fixing it. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Thu 07/05/2009 11:05 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim; Thanks so much. It works like a charm :D At last I able to see water surface by errorless running. I have looked for uLightID and I think while program is on it send different value from 0. Or Is there a different problem than I was expected which is related about light ID? Best Regards. 2009/5/7 Kim C Bale k.b...@hull.ac.uk See attached. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Thu 07/05/2009 10:04 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim; Thanks for your help but I think when you attach the water vertex and fragment shadr you had made a mistake and you attached two of them in vertex there is no fragment shader. Now I have achieved to GLSL 1.2 and OpenGL 2.1 but it still not enough. I am trying to update to 3.0. Now previous Error gone away but now application send fragment shader not supported as you can see from command screen; glLinkProgram FAILED Program infolog: Fragment shader(s) failed to link, vertex shader(s) linked. Fragment Shader not supported by HW Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Could you attach water.f please? :) Best regards and Thanks. 2009/5/7 Kim C Bale k.b...@hull.ac.uk David,J-S,Art, Yes this the direction I envisaged for it, I attempted to pull out some common variables into an OceanTechnique base class, but as you can see in the code, that all went a bit pear shaped as I didn't really know how the others were going to be implemented.. The CUDA implementation is certainly something to look at but should be seen as an alternative rather than a main route as it excludes people with lesser graphics cards and, dare I say, it the ATI contingent. There's a nice video here if people are interested. http://www.youtube.com/watch?v=K1I4kts5mqc K. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Jean-Sébastien Guay Sent: Wed 06/05/2009 20:07 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi David, I would suggest that an all GPU FFT would just be one in a selection of possible ocean surface techniques. An architecture that supports many such techniques would be a good goal for this kind of project ! I totally agree. I'll be looking into how feasible this is, not just for offloading surface generation to the GPU, but in general for allowing selecting the surface generation technique from a list of possible techniques with different tradeoffs. As soon as there's a non-GPL alternative integrated instead of FFTW, I can start working on that. 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 -- Ümit Uzun * 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
Re: [osg-users] osgOcean release
Hi Richard, Try compiling FFTW with this project file. It's set up for VS2003. ftp://ftp.fftw.org/pub/fftw/fftw-3.1.2-vs2003.zip You must also make sure you're using the floating point library called fftw3f-3. I've compiled it on debian and with VS2005 and not had any issues. Let me know if problems the persist. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Wed 06/05/2009 08:12 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim; Great works. Congratulations. I have tried to install but have some problem on FFTW library on compiling VS2003. I will try to compile it by MinGW very soon. I think you are using Linux environment. Best Regards. 2009/5/6 Schmidt, Richard richard.schm...@eads.com Wow, looks great! -- *Von:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *Im Auftrag von *Kim C Bale *Gesendet:* Dienstag, 5. Mai 2009 21:11 *An:* osg-users@lists.openscenegraph.org *Betreff:* [osg-users] osgOcean release Hello all, Many moons ago I emailed the list to announce my intentions of releasing an ocean rendering library for the OSG. Well after many delays and things getting in the way i've put some code up for your perusal. http://code.google.com/p/osgocean/ At the moment i have only put the surface simulation and ocean rendering code online there is more to follow. But I wanted to get this out as a point for discussion. It uses a precomputed FFT ocean simulation combined with a geomipmapping lod algorithm. This has obvious limitations as the ocean surface is of a fixed size, but I'm afraid I don't have time at the moment to come up with something slicker. The FFT technique can be used in conjunction with a geoclipmap approach which I think would allow for an endless ocean and would be more usable, so if anyone wants to pitch in with that get in touch as it would be valuable addition and quite easy to slot in. One of the big problems with the design is turning parts of the shader on and off. I've used boolean uniforms for this, but it's messy. Ideally it would be more effecient either to dynamically generate the shader or insert #defines to include or block out bits of code. I suspect the latter would be the easiest to implement but i noticed Hydrax chooses to create them on the fly. I'd love to hear from the more experience OSG programmers about this, as I anticipate that this aspect will get rather complicated quite quickly. I remember there was quite a lot of interest in collaborating, if the will is still there get in touch either by email or here and we'll chat about where we can take it. So have a play and let me know what you think! Regards, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun winmail.dat* 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 release
Hi Adrian, Thanks I checked in the shader fix, well spotted. I'm working on the camera manipulator can't seem to get the terrain one to start in the middle of the ocean and play nicely when you first move it. But yes I think you're probably right about it being easier to use, it's taken me a while to get used to the flight manip. Cheers. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Adrian Egli OpenSceneGraph (3D) Sent: Wed 06/05/2009 12:45 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi (1) Shader FIX (2) Use Trackball or Terrain Mainpulation, more easy to use for NOT gamers, or use the osgViewer like motion model switch 2009/5/6 David Spilling david.spill...@gmail.com Umit, ...Error : When I open up the osgOceanExample there is some error in vertex shader as you can see from the attached screenshot. I had something similar - I think this is just coz the shader constructor can't find the underlying shaders; AFAIK the resource folder has to be located in the same directory as the executable. Moving things around might work for you. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli winmail.dat* 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 release
Umit, I've checked in a new vertex shader which should stop the problem. The errors referred to a redundant function so I've commented it out. What graphics card and drivers are you using by the way? Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org on behalf of Ümit Uzun Sent: Wed 06/05/2009 13:03 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi David and Adrian; I had something similar - I think this is just coz the shader constructor can't find the underlying shaders; AFAIK the resource folder has to be located in the same directory as the executable. Moving things around might work for you. I had copied in all resource same folder as executable, and I copied shader folder and all seperated shader files in same folder with executable one by one but anyone doens't work for me. Application is still warning me by the same vertex shader error. And I have updated application.cpp and water.f files in my project but result is same Adrian. Thanks for any helps. 2009/5/6 Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com Hi (1) Shader FIX (2) Use Trackball or Terrain Mainpulation, more easy to use for NOT gamers, or use the osgViewer like motion model switch 2009/5/6 David Spilling david.spill...@gmail.com Umit, ...Error : When I open up the osgOceanExample there is some error in vertex shader as you can see from the attached screenshot. I had something similar - I think this is just coz the shader constructor can't find the underlying shaders; AFAIK the resource folder has to be located in the same directory as the executable. Moving things around might work for you. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun winmail.dat* 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 release
Hello all, Many moons ago I emailed the list to announce my intentions of releasing an ocean rendering library for the OSG. Well after many delays and things getting in the way i've put some code up for your perusal. http://code.google.com/p/osgocean/ At the moment i have only put the surface simulation and ocean rendering code online there is more to follow. But I wanted to get this out as a point for discussion. It uses a precomputed FFT ocean simulation combined with a geomipmapping lod algorithm. This has obvious limitations as the ocean surface is of a fixed size, but I'm afraid I don't have time at the moment to come up with something slicker. The FFT technique can be used in conjunction with a geoclipmap approach which I think would allow for an endless ocean and would be more usable, so if anyone wants to pitch in with that get in touch as it would be valuable addition and quite easy to slot in. One of the big problems with the design is turning parts of the shader on and off. I've used boolean uniforms for this, but it's messy. Ideally it would be more effecient either to dynamically generate the shader or insert #defines to include or block out bits of code. I suspect the latter would be the easiest to implement but i noticed Hydrax chooses to create them on the fly. I'd love to hear from the more experience OSG programmers about this, as I anticipate that this aspect will get rather complicated quite quickly. I remember there was quite a lot of interest in collaborating, if the will is still there get in touch either by email or here and we'll chat about where we can take it. So have a play and let me know what you think! 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] OSG's CMakeLists.txt
I'm trying to create a CMake project for an initial release of osgOcean
and I'd like to follow the OSG's convention of piling all debug and
release libs and dlls into bin and lib folders appending D onto the end
of the debug libraries.
I'm quite new to CMake and I'm finding this quite frustrating, when you
create the visual studio project it appends debug or release to the file
path and nothing I can do will change its mind.
I notice that there's a hack for it, as it's mentioned in the OSG's main
CMakeLists (see below).
..but I can't spot the hack.. where is it?
Apologies for the off topic post but I've trawled the net for it and
found nothing, and I figured I'd get the quickest response about this
here since some of you clearly know your CMake onions.
Cheers.
Kim.
# the following options are MSVC specific,
# the first OSG_MSVC_VERSIONED_DLL activate a custom build-time layout
that should allow to run examples and application
# fron bin folder without requiring installation step.
# it also prepend osg${OPENSCENEGRAPH_SOVERSION}- to only .dll files,
leaving .lib files untouched in lib
# it also use a hack to get rid of Debug and Release folder in MSVC
projects
# all the .dll and .pdb are in bin and all the .lib and .exp are in lib
#
# the second option disable incremental linking in debug build , that is
enabled by default by CMake
##
*
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] OSG's CMakeLists.txt
Cheers chap.
K.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org on behalf of Philip Lowman
Sent: Thu 30/04/2009 13:05
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG's CMakeLists.txt
The PREFIX property does this:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX ../)
For how it's used in the OSG's cmake macros, see OsgMacroUtils.cmake in
SETUP_EXE() and SETUP_PLUGIN()
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/CMakeModules/OsgMacroUtils.cmake
On Thu, Apr 30, 2009 at 6:49 AM, Kim C Bale k.b...@hull.ac.uk wrote:
I'm trying to create a CMake project for an initial release of osgOcean
and I'd like to follow the OSG's convention of piling all debug and release
libs and dlls into bin and lib folders appending D onto the end of the debug
libraries.
I'm quite new to CMake and I'm finding this quite frustrating, when you
create the visual studio project it appends debug or release to the file
path and nothing I can do will change its mind.
I notice that there's a hack for it, as it's mentioned in the OSG's main
CMakeLists (see below).
..but I can't spot the hack.. where is it?
Apologies for the off topic post but I've trawled the net for it and found
nothing, and I figured I'd get the quickest response about this here since
some of you clearly know your CMake onions.
Cheers.
Kim.
# the following options are MSVC specific,
# the first OSG_MSVC_VERSIONED_DLL activate a custom build-time layout that
should allow to run examples and application
# fron bin folder without requiring installation step.
# it also prepend osg${OPENSCENEGRAPH_SOVERSION}- to only .dll files,
leaving .lib files untouched in lib
# it also use a hack to get rid of Debug and Release folder in MSVC
projects
# all the .dll and .pdb are in bin and all the .lib and .exp are in lib
#
# the second option disable incremental linking in debug build , that is
enabled by default by CMake
##
*
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
--
Philip Lowman
winmail.dat*
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] osgForest
I just tried osgForest and I don't appear to be seeing any trees on the shader implementation. I'm using an 8800 GTS 512 on vista with the 178.13 driver set. Anybody else have problems with it? Not a big issue just thought I'd point it out. Cheers. 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] osgForest
No errors reported. As you say it's probably another driver bug. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 21 April 2009 11:19 To: OpenSceneGraph Users Subject: Re: [osg-users] osgForest Hi Kim, As a point of reference all the osgforest modes work fine for me under Kubuntu with either ATI or NVidia graphics. Do you see any OpenGL errors reported? My guess is that it's simply an OpenGL driver error. Robert. On Tue, Apr 21, 2009 at 11:03 AM, Kim C Bale k.b...@hull.ac.uk wrote: I just tried osgForest and I don't appear to be seeing any trees on the shader implementation. I'm using an 8800 GTS 512 on vista with the 178.13 driver set. Anybody else have problems with it? Not a big issue just thought I'd point it out. Cheers. 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.or g ___ 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] memory management incompatibility? (SOLVED)
Moji the ...Great...? Regards, Kim the Fabulous. (sorry childish, couldn't resist) From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mojtaba Fathi Sent: 12 March 2009 14:38 To: OpenSceneGraph Users Subject: [osg-users] memory management incompatibility? (SOLVED) Hi again As expected, that was my fault. I found the problem and now everything is fine. Regards, Moji the Great --- On Thu, 3/12/09, Mojtaba Fathi modjta...@yahoo.com wrote: From: Mojtaba Fathi modjta...@yahoo.com Subject: [osg-users] memory management incompatibility? To: osg-users@lists.openscenegraph.org Date: Thursday, March 12, 2009, 11:15 AM Hi all I'm using OSG 2.8 dll's for VS80 in my application. After some malloc/realloc and free operations, I get messages like this Free Heap block ... modified at ... after it was freed. I think the problem arises from memory management incompatibility between my app and OSG dll's. Is there any specific configuration necessary to avoid such problems? Regards Moji the Great -Inline Attachment Follows- ___ 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] osgMemoryTest
Hi Guy, This is interesting actually, I ran that test because I was having problems with osgText. I’m pretty sure the osgText problem was a driver issue, I ended up reinstalling windows and installing the 7.15.11.7813 drivers for vista which I knew I could rely on. The osgText issue disappeared. I assumed that the memory test problem went with it. However, I’ve just run this memorytest again now and it appears that it hasn’t fixed the problem. Interestingly though I do not have any problems with my OSG applications. FYI this is on Vista 32bit, NV 8800GTS 512mb with the 17/09/2008 v7.15.11.7813 drivers. I haven’t tested it with the most recent drivers as I don’t want to risk buggering up my system again. So I’m afraid I don’t know what’s causing this... Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Guy Sent: 11 March 2009 11:15 To: OpenSceneGraph Users Subject: Re: [osg-users] osgMemoryTest Kim, I've the same card and the same problem. Did you figure it out? Is it drivers issue? Thanks, Guy. מאת: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] בשם Kim C Bale נשלח: Tuesday, March 03, 2009 12:11 PM אל: osg-users@lists.openscenegraph.org נושא: [osg-users] osgMemoryTest I'm trying to figure out what's going on with my program, I think there's an issue with drivers. If I run the command: osgmemorytest --texture 1024 1024 I get: Exception caught, contexts completed = 0, gl objects successfully applied = 0 That shouldn't happen, should it? By my calculations I should be able to create quite a few 1024 textures. I'm using an NV8800 GTS 512Mb K. * 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] osgMemoryTest
I'm trying to figure out what's going on with my program, I think there's an issue with drivers. If I run the command: osgmemorytest --texture 1024 1024 I get: Exception caught, contexts completed = 0, gl objects successfully applied = 0 That shouldn't happen, should it? By my calculations I should be able to create quite a few 1024 textures. I'm using an NV8800 GTS 512Mb K. * 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] Curious osgText crash
Hi all,
I'm getting some odd errors in conjunction with osgText.
I'm loading two font files and assigning them to various osgText
drawables, which are in turn added to a series geodes.
Each geode is then rendered to texture using individual pre render FBO
cameras.
When I set the application to single threaded all is well, however when
I set it to AutomaticSelection
It prints the error:
before Font::Glyph::subload(): detected OpenGL error 'invalid operation
before Font::Glyph::subload(): detected OpenGL error '
Before crashing with an access violation. Last four entries on the call
stack are at the base of the post.
I'm not changing the text at any point after I've done the initial set
up and I've tried setting the data variance on the osgText drawables to
DYNAMIC. But it doesn't seem to help.
Anybody have any ideas what's gone wrong here? Hopefully I've given
enough information.
Cheers,
Kim.
msvcr80d.dll!strlen(unsigned char * buf=0x0549ef78) Line 81 Asm
msvcp80d.dll!std::char_traitschar::length(const char *
_First=0x) Line 559 + 0x9 bytes C++
osg55-osgTextd.dll!std::operatorstd::char_traitschar
(std::basic_ostreamchar,std::char_traitschar _Ostr={...}, const
char * _Val=0x) Line 748 + 0xc bytes C++
osg55-osgTextd.dll!std::operatorstd::char_traitschar
(std::basic_ostreamchar,std::char_traitschar _Ostr={...}, const
unsigned char * _Val=0x) Line 929 + 0xd bytes C++
*
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] Curious osgText crash
Hi Vincent/Gordon,
Thanks for your quick replies.
I've had a read of the thread, but I'm not actually updating the text once it's
added as a drawable so, if I understand correctly, I shouldn't need to worry
about thread safety.
But to be on the safe side, I've also set the text data variance to DYNAMIC,
which worked for me in the past when I had similar issues but only when
updating text objects.
What is odd though is that the crash only happens when I use two fonts.
If I use just one I get the:
before Font::Glyph::subload(): detected OpenGL error 'invalid operation'
error, but continues on, if I use two fonts it bombs.
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tomlinson,
Gordon
Sent: 02 March 2009 14:40
To: OpenSceneGraph Users
Subject: Re: [osg-users] Curious osgText crash
Hi Kim
Not much help:
I have seen the same message occasionally when updating text ( not had crashes)
But have no been able to track down issue that may causing subload message yet
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Vincent
Bourdier
Sent: Monday, March 02, 2009 9:37 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Curious osgText crash
Hi Kim,
I had a problem like this in the past, I solved it using a draw callback to
update the texts.
you can read this problem here :
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/39315/focus=39408
Hopping this can help you.
Regards,
Vincent.
2009/3/2 Kim C Bale k.b...@hull.ac.uk:
Hi all,
I'm getting some odd errors in conjunction with osgText.
I'm loading two font files and assigning them to various osgText
drawables, which are in turn added to a series geodes.
Each geode is then rendered to texture using individual pre render FBO
cameras.
When I set the application to single threaded all is well, however
when I set it to AutomaticSelection
It prints the error:
before Font::Glyph::subload(): detected OpenGL error 'invalid
operation
before Font::Glyph::subload(): detected OpenGL error '
Before crashing with an access violation. Last four entries on the
call stack are at the base of the post.
I'm not changing the text at any point after I've done the initial set
up and I've tried setting the data variance on the osgText drawables
to DYNAMIC. But it doesn't seem to help.
Anybody have any ideas what's gone wrong here? Hopefully I've given
enough information.
Cheers,
Kim.
msvcr80d.dll!strlen(unsigned char * buf=0x0549ef78) Line 81 Asm
msvcp80d.dll!std::char_traitschar::length(const char *
_First=0x) Line 559 + 0x9 bytes C++
osg55-osgTextd.dll!std::operatorstd::char_traitschar
(std::basic_ostreamchar,std::char_traitschar _Ostr={...}, const
char
* _Val=0x) Line 748 + 0xc bytes C++
osg55-osgTextd.dll!std::operatorstd::char_traitschar
(std::basic_ostreamchar,std::char_traitschar _Ostr={...}, const
unsigned char * _Val=0x) Line 929 + 0xd bytes C++
**
*** 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
___
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] Curious osgText crash
I've recreated the problem I've been having in the attached CPP file.
It's a very simple example, so I don't think I've overlooked anything.
Occasionally this will run, but the majority of the time it bombs.
If one of you kind ladies or gentlemen could run it and tell me if you get the
same error/crash I would most grateful. I'm afraid I don't have access to a
different machine to test it on at the moment.
I compiled it with osg2.8
Cheers,
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Kim C Bale
Sent: 02 March 2009 15:47
To: OpenSceneGraph Users
Subject: Re: [osg-users] Curious osgText crash
Hi Vincent/Gordon,
Thanks for your quick replies.
I've had a read of the thread, but I'm not actually updating the text once it's
added as a drawable so, if I understand correctly, I shouldn't need to worry
about thread safety.
But to be on the safe side, I've also set the text data variance to DYNAMIC,
which worked for me in the past when I had similar issues but only when
updating text objects.
What is odd though is that the crash only happens when I use two fonts.
If I use just one I get the:
before Font::Glyph::subload(): detected OpenGL error 'invalid operation'
error, but continues on, if I use two fonts it bombs.
Kim.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tomlinson,
Gordon
Sent: 02 March 2009 14:40
To: OpenSceneGraph Users
Subject: Re: [osg-users] Curious osgText crash
Hi Kim
Not much help:
I have seen the same message occasionally when updating text ( not had crashes)
But have no been able to track down issue that may causing subload message yet
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Vincent
Bourdier
Sent: Monday, March 02, 2009 9:37 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Curious osgText crash
Hi Kim,
I had a problem like this in the past, I solved it using a draw callback to
update the texts.
you can read this problem here :
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/39315/focus=39408
Hopping this can help you.
Regards,
Vincent.
2009/3/2 Kim C Bale k.b...@hull.ac.uk:
Hi all,
I'm getting some odd errors in conjunction with osgText.
I'm loading two font files and assigning them to various osgText
drawables, which are in turn added to a series geodes.
Each geode is then rendered to texture using individual pre render FBO
cameras.
When I set the application to single threaded all is well, however
when I set it to AutomaticSelection
It prints the error:
before Font::Glyph::subload(): detected OpenGL error 'invalid
operation
before Font::Glyph::subload(): detected OpenGL error '
Before crashing with an access violation. Last four entries on the
call stack are at the base of the post.
I'm not changing the text at any point after I've done the initial set
up and I've tried setting the data variance on the osgText drawables
to DYNAMIC. But it doesn't seem to help.
Anybody have any ideas what's gone wrong here? Hopefully I've given
enough information.
Cheers,
Kim.
msvcr80d.dll!strlen(unsigned char * buf=0x0549ef78) Line 81 Asm
msvcp80d.dll!std::char_traitschar::length(const char *
_First=0x) Line 559 + 0x9 bytes C++
osg55-osgTextd.dll!std::operatorstd::char_traitschar
(std::basic_ostreamchar,std::char_traitschar _Ostr={...}, const
char
* _Val=0x) Line 748 + 0xc bytes C++
osg55-osgTextd.dll!std::operatorstd::char_traitschar
(std::basic_ostreamchar,std::char_traitschar _Ostr={...}, const
unsigned char * _Val=0x) Line 929 + 0xd bytes C++
**
*** 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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
osgTextIssue.cpp
Description: osgTextIssue.cpp
*
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal
Re: [osg-users] PING
PONG From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Thomas Hogarth Sent: 24 February 2009 12:51 To: OSG USERS Subject: [osg-users] PING PING * 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] Swapping the color buffer on an FBO
Hello all, I'm trying to swap the color buffer of an FBO camera in an event handler. When I initialise the FBO camera like so: counter = 0; m_camera-attach( osg::Camera::COLOR_BUFFER, m_textureList.at( counter ).get() ); It works, but then when I try to swap the color buffer using the following: ++counter; m_camera-detach( osg::Camera::COLOR_BUFFER ); m_camera-attach( osg::Camera::COLOR_BUFFER, m_textureList.at( counter ).get() ); It appears that the original texture is still attached and being updated. Am I misusing the FBO here? Is it not possible to swap buffers once the camera has been initialised? Obviously the same effect could be achieved using a switch and a series of FBO cameras but this solution seemed like a nice tidy one. Thanks in advance. 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] Compiling OSG 2.8 with Visual Studio 2005 SP1
Good morning all, I'm having problems compiling 2.8 with VS2005SP1 with a build project generated with CMAKE 2.4 When I try to compile osgDB I get the error: 1Compiling... 1osgPlugins-2.8.0 1c1xx : fatal error C1083: Cannot open source file: 'Files/OpenSceneGraph/lib/osgPlugins-2.8.0': No such file or directory I don't understand where the source file path is coming from. It looks a truncated version of the install directory I've specified (c:/Program Files/OpenSceneGraph/..) But it shouldn't be using that directory at this early stage in the compile. Has anybody experienced similar problems? 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] Compiling OSG 2.8 with Visual Studio 2005 SP1
CMake 2.6.2 has sorted it. Cheers, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Vincent Bourdier Sent: 16 February 2009 10:20 To: OpenSceneGraph Users Subject: Re: [osg-users] Compiling OSG 2.8 with Visual Studio 2005 SP1 Hello, Maybe I'm wrong, but I think using the last Cmake can help you... try the 2.6 or later. Regards, Vincent 2009/2/16 Kim C Bale k.b...@hull.ac.uk Good morning all, I'm having problems compiling 2.8 with VS2005SP1 with a build project generated with CMAKE 2.4 When I try to compile osgDB I get the error: 1Compiling... 1osgPlugins-2.8.0 1c1xx : fatal error C1083: Cannot open source file: 'Files/OpenSceneGraph/lib/osgPlugins-2.8.0': No such file or directory I don't understand where the source file path is coming from. It looks a truncated version of the install directory I've specified (c:/Program Files/OpenSceneGraph/..) But it shouldn't be using that directory at this early stage in the compile. Has anybody experienced similar problems? 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.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] Non-Inlined Shaders in OSG files
I'm using OSG 2.6 and I was wondering if it was possible to write OSG files without inlining the shader code into the file? I read some discussion about implementing it but couldn't tell whether it had been added in? At the moment I'm adding the external references manually and it's a bit of a pain. Cheers. 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] Non-Inlined Shaders in OSG files
Ah yes that's what I was looking for. I was sure I had read about it in the forums but I couldn't find the reference again. Cheers. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Art Tevs Sent: 29 January 2009 14:43 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Non-Inlined Shaders in OSG files Hi Kim, a while ago (maybe one year ago), I've submitted a patch to do so. There exists now an osg plugin for .glsl files, which can load the shaders, hence non-inlined support is possible. Evenmore, there is a possibility to enable non-inlined shader support when writing .osg files. Take a look into osgDB::Output::setOutputShaderFiles cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5425#5425 ___ 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] Registry Object Cache
I've enabled the object cache in the registry and was wondering if there is a way to retrieve the list of names that is used to retrieve files in the registries object cache? Nothing is screaming out to me in the documentation. I'm assuming the cache stores filenames with objects and returns the already loaded object if a name is matched.. Cheers. 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] Registry Object Cache
Ignored that, I turned the notifylevel to INFO and it tells me exactly what the cache is up to. Carry on J Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Kim C Bale Sent: 21 January 2009 16:46 To: OpenSceneGraph Users Subject: [osg-users] Registry Object Cache I've enabled the object cache in the registry and was wondering if there is a way to retrieve the list of names that is used to retrieve files in the registries object cache? Nothing is screaming out to me in the documentation. I'm assuming the cache stores filenames with objects and returns the already loaded object if a name is matched.. Cheers. 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] FBO OpenGL Error with new nVidia Driver
I've just noticed that I've been getting some errors when I run osgprerender and also in my own program that uses a lot of pre-render cameras and FBOs.. Firstly I get: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Then the following printed continuously as the program is running: RenderStage::drawInner(,) FBO status= 0x8cd7 Warning: detected OpenGL errorNo= 0x506 after RenderBin::draw(,) I've tracked 0x506 to INVALID_FRAMEBUFFER_OPERATION_EXT which does seem odd, given that I'm running osgprerender which is a well established example. I put this down to the new nVidia driver as it seems to have occurred after that. Just wanted to know if anyone else was experiencing this. I'm running Vista Business 32bit using an nVidia 8800GTS 512mb card, driver version: 7.15.11.8048 * 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] FBO OpenGL Error with new nVidia Driver
After much installing and uninstalling I've found it's also present in the Vista 32-Bit GeForce releases 178.13, 178.24, 180.48. 175.19 work fine. Should I be concerned about these errors? K. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim C Bale Sent: 28 November 2008 13:33 To: OpenSceneGraph Users Subject: [osg-users] FBO OpenGL Error with new nVidia Driver I've just noticed that I've been getting some errors when I run osgprerender and also in my own program that uses a lot of pre-render cameras and FBOs.. Firstly I get: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Then the following printed continuously as the program is running: RenderStage::drawInner(,) FBO status= 0x8cd7 Warning: detected OpenGL errorNo= 0x506 after RenderBin::draw(,) I've tracked 0x506 to INVALID_FRAMEBUFFER_OPERATION_EXT which does seem odd, given that I'm running osgprerender which is a well established example. I put this down to the new nVidia driver as it seems to have occurred after that. Just wanted to know if anyone else was experiencing this. I'm running Vista Business 32bit using an nVidia 8800GTS 512mb card, driver version: 7.15.11.8048 * 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] FBO OpenGL Error with new nVidia Driver
Sorry yes, I'm using OSG 2.6, strangely enough it may well be linked to the dual monitor set up as you suggest. I've just tested this at home on an identical machine but without the extra monitor using driver 178.13 and i don't get the error. I'll try what you suggest on monday, and post the results. Cheers. Kim. From: [EMAIL PROTECTED] on behalf of Wojciech Lewandowski Sent: Fri 28/11/2008 14:59 To: OpenSceneGraph Users Subject: Re: [osg-users] FBO OpenGL Error with new nVidia Driver Hi Kim, Im curious which OSG version you use ? Could this be that you have dual view setup ? Maybe you have the same error Marco Jez reported recently. You may try to change OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND and see if it helps. Cheers, Wojtek - Original Message - From: Kim C Bale mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Friday, November 28, 2008 3:42 PM Subject: Re: [osg-users] FBO OpenGL Error with new nVidia Driver After much installing and uninstalling I've found it's also present in the Vista 32-Bit GeForce releases 178.13, 178.24, 180.48. 175.19 work fine. Should I be concerned about these errors? K. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim C Bale Sent: 28 November 2008 13:33 To: OpenSceneGraph Users Subject: [osg-users] FBO OpenGL Error with new nVidia Driver I've just noticed that I've been getting some errors when I run osgprerender and also in my own program that uses a lot of pre-render cameras and FBOs.. Firstly I get: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Then the following printed continuously as the program is running: RenderStage::drawInner(,) FBO status= 0x8cd7 Warning: detected OpenGL errorNo= 0x506 after RenderBin::draw(,) I've tracked 0x506 to INVALID_FRAMEBUFFER_OPERATION_EXT which does seem odd, given that I'm running osgprerender which is a well established example. I put this down to the new nVidia driver as it seems to have occurred after that. Just wanted to know if anyone else was experiencing this. I'm running Vista Business 32bit using an nVidia 8800GTS 512mb card, driver version: 7.15.11.8048 * 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 winmail.dat* 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] Texture Management BUMP
Hi Sekunder, I've been digging around in the osgDB code and I'm pretty sure that the osgDB cache only stores the osg::Image file in memory rather than the osg::Texture. I noted that glBindTexture is only called within osg::Texture so that is where the texture is loaded onto the card. At the moment all I've set the cache to store are images, as model caching isn't needed. But I don't think the osgDB parses cached models for duplicate osg::Textures only duplicate osg::Images. Perhaps Robert could confirm? Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sukender Sent: 20 November 2008 08:54 To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Management BUMP Hi Kim, Well, if you load a model with its textures, the function will simply return to you a pointer to an already existing model and/or texture (if cache is enabled). Then if all models of your scene share the same texture and/or vertex arrays, I guess (I'm not 100% sure though) this will do what you expect: texture and/or vertex array are only sent to video memory once. Also be sure to create COPIES of the vertex arrays, matrix transforms (and other things) if you plan to modify them. Else you would modify the cached shared ressource (this happened to me! I saw all my models being transformed the same way at the same time...). Anyway, caching is a good thing for performance and RAM usage if your models or textures are duplicated in the scene. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 20 Nov 2008 08:36:31 +0100, Kim C Bale [EMAIL PROTECTED] a écrit: I've been pondering this Database pager. It only caches the image files into memory to prevent loading during runtime doesn't it? Those are then used to build textures on the card memory. Is there anything to deal with loading textures onto the graphics card, dishing out texture IDs rather than reloading the texture onto card memory? Kim. From: [EMAIL PROTECTED] on behalf of Sukender Sent: Wed 19/11/2008 15:53 To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Management Hi Kim, You may just use the osgDB::Registry cache. That's automatic :) For instance, set the cache by writing: osgDB::ReaderWriter::Options* rwoptions = new osgDB::ReaderWriter::Options; rwoptions-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL); osgDB::Registry::instance()-setOptions(rwoptions); This will cache everything loaded with readNodeFile() or readImageFile(). For my use, I preload things in the cache by calling: osgDB::Registry::instance()-addEntryToObjectCache(path, osgDB::readNodeFile(path)); And I set the cache to never unload: osgDB::DatabasePager * pPager = viewer.getDatabasePager(); assert(pPager); osgDB::Registry::instance()-setDatabasePager(pPager); pPager-setExpiryDelay(DBL_MAX); pPager-setExpiryFrames(INT_MAX); Also, you could clear the cache by calling: osgDB::Registry::instance()-clearObjectCache(); Hope it will help. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 19 Nov 2008 16:28:25 +0100, Kim C Bale [EMAIL PROTECTED] a écrit: I have a number of different models in OSG format that all use the same texture. What I want to avoid is having duplicate textures loaded onto the graphics card when I load these separate models. In previous programs I have achieved this using a Texture Manager that manages all texture loading i.e. loading the texture once when required and then dishing out the texture ID on subsequent requests. A fairly standard practice. Is there something similar already built into the OSG? The TextureAtlasBuilder in osgUtil sounds looks like it might do something similar but I'm not 100% sure, there is very little documentation on it. Thanks all. Kim. ___ 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* 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] Texture Management BUMP
Cheers for clearing that up. Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 20 November 2008 09:18 To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Management BUMP Hi Kim, On Thu, Nov 20, 2008 at 7:36 AM, Kim C Bale [EMAIL PROTECTED] wrote: I've been pondering this Database pager. It only caches the image files into memory to prevent loading during runtime doesn't it? Those are then used to build textures on the card memory. The DatabasePager doesn't cache any imagery or nodes itself. The Registry has a cache that you can enable but it's off by default. There is also now (in SVN/2.7.x) an osgDB::FileCache class that wraps up a file cache. Is there anything to deal with loading textures onto the graphics card, dishing out texture IDs rather than reloading the texture onto card memory? You can't just directly down data to the GPU, you have to load from disk into main memory then have the OSG download this imagery to the textures to OpenGL. This is all done for you, the OSG will handle texture object ruse and us texture subloading to keep everything efficient. 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] Texture Management
I have a number of different models in OSG format that all use the same texture. What I want to avoid is having duplicate textures loaded onto the graphics card when I load these separate models. In previous programs I have achieved this using a Texture Manager that manages all texture loading i.e. loading the texture once when required and then dishing out the texture ID on subsequent requests. A fairly standard practice. Is there something similar already built into the OSG? The TextureAtlasBuilder in osgUtil sounds looks like it might do something similar but I'm not 100% sure, there is very little documentation on it. Thanks all. 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] Texture Management
Splendid. Thank you. Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sukender Sent: 19 November 2008 15:53 To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Management Hi Kim, You may just use the osgDB::Registry cache. That's automatic :) For instance, set the cache by writing: osgDB::ReaderWriter::Options* rwoptions = new osgDB::ReaderWriter::Options; rwoptions-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL); osgDB::Registry::instance()-setOptions(rwoptions); This will cache everything loaded with readNodeFile() or readImageFile(). For my use, I preload things in the cache by calling: osgDB::Registry::instance()-addEntryToObjectCache(path, osgDB::readNodeFile(path)); And I set the cache to never unload: osgDB::DatabasePager * pPager = viewer.getDatabasePager(); assert(pPager); osgDB::Registry::instance()-setDatabasePager(pPager); pPager-setExpiryDelay(DBL_MAX); pPager-setExpiryFrames(INT_MAX); Also, you could clear the cache by calling: osgDB::Registry::instance()-clearObjectCache(); Hope it will help. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 19 Nov 2008 16:28:25 +0100, Kim C Bale [EMAIL PROTECTED] a écrit: I have a number of different models in OSG format that all use the same texture. What I want to avoid is having duplicate textures loaded onto the graphics card when I load these separate models. In previous programs I have achieved this using a Texture Manager that manages all texture loading i.e. loading the texture once when required and then dishing out the texture ID on subsequent requests. A fairly standard practice. Is there something similar already built into the OSG? The TextureAtlasBuilder in osgUtil sounds looks like it might do something similar but I'm not 100% sure, there is very little documentation on it. Thanks all. Kim. ___ 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] Texture Management BUMP
I've been pondering this Database pager. It only caches the image files into memory to prevent loading during runtime doesn't it? Those are then used to build textures on the card memory. Is there anything to deal with loading textures onto the graphics card, dishing out texture IDs rather than reloading the texture onto card memory? Kim. From: [EMAIL PROTECTED] on behalf of Sukender Sent: Wed 19/11/2008 15:53 To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Management Hi Kim, You may just use the osgDB::Registry cache. That's automatic :) For instance, set the cache by writing: osgDB::ReaderWriter::Options* rwoptions = new osgDB::ReaderWriter::Options; rwoptions-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL); osgDB::Registry::instance()-setOptions(rwoptions); This will cache everything loaded with readNodeFile() or readImageFile(). For my use, I preload things in the cache by calling: osgDB::Registry::instance()-addEntryToObjectCache(path, osgDB::readNodeFile(path)); And I set the cache to never unload: osgDB::DatabasePager * pPager = viewer.getDatabasePager(); assert(pPager); osgDB::Registry::instance()-setDatabasePager(pPager); pPager-setExpiryDelay(DBL_MAX); pPager-setExpiryFrames(INT_MAX); Also, you could clear the cache by calling: osgDB::Registry::instance()-clearObjectCache(); Hope it will help. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 19 Nov 2008 16:28:25 +0100, Kim C Bale [EMAIL PROTECTED] a écrit: I have a number of different models in OSG format that all use the same texture. What I want to avoid is having duplicate textures loaded onto the graphics card when I load these separate models. In previous programs I have achieved this using a Texture Manager that manages all texture loading i.e. loading the texture once when required and then dishing out the texture ID on subsequent requests. A fairly standard practice. Is there something similar already built into the OSG? The TextureAtlasBuilder in osgUtil sounds looks like it might do something similar but I'm not 100% sure, there is very little documentation on it. Thanks all. Kim. ___ 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting a Camera to Render Only Once.
I've created a custom switch inherited from osg::Group that is designed
to control a series of RTT cameras which only need to render to texture
once at varying times.
So I achieve this by modifying the traverse method. I check for a
CullVisitor, then if a child state is set to render a single frame, I
pass the CullVisitor to the child and then tell the CullVisitor to
ignore it on subsequent visits. (See attached code).
So in my test app, my graph looks a bit like this:
Root
|___ CustomSwitch - RTTCamera - Scene
|
|___ PostRenderCam - ScreenAlignedQuad
This works as long as viewer.frame() has been called at least once on
graph. Otherwise the objects are rendered black.
So this test code works:
-
viewer.frame();
while(!viewer.done())
{
static bool addMe = true;
if(addMe){
frameSwitch-addChild( cam1, FrameSwitch::SINGLE_FRAME );
addMe = false;
}
viewer.frame();
}
-
Whilst this code renders black objects:
-
while(!viewer.done())
{
static bool addMe = true;
if(addMe){
frameSwitch-addChild( cam1, FrameSwitch::SINGLE_FRAME );
addMe = false;
}
viewer.frame();
}
-
So, my question is what's happening on that first CullVisitor that's not
later on? Obviously doing that extra call to frame() fixes it but it's
not a very tidy solution.
Cheers.
Kim.
traverse.cpp
Description: traverse.cpp
*
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] MAX to COLLADA or which format ?
I didn't find a solution to that. However, it doesn't seem to cause any problems. Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun Sent: 05 November 2008 15:46 To: OpenSceneGraph Users Subject: Re: [osg-users] MAX to COLLADA or which format ? Hi Kim, Thanks for explanation. I will try to understand gerstner method. I would I achieve very soon :) When I search the old mail-archive I saw a question asked by you about Error: [Screen #0] GraphicsWindowWin32::requestWarpPointer() - Window not reali ed; cannot warp pointer I have same problem and there no message except this. Have you found the reason this error Kim? Best Regards. Umit Uzun 2008/11/4 Kim C Bale [EMAIL PROTECTED] I'm afraid I can't recall the interpolation method used for generating the normals from the gerstner model, it is detailed in the book. I personally didn't use the gerstner approach since I had already built an FFT simulation for the wave surface and wanted to use that for the the normal computation instead. The extrusion of the parallelpepids is done within the vertex shader, you store the length of the extrusion as a texture coordinate for each vertex. So inside the vertex shader you have something along the lines of: newVertex = oldVertex + (gl_TexCoord[0] * refractionVector); That way you can differentiate between vertices that lie on the water surface and those that need to extruded downward. Finally, everything in the screen shot is simulated, no real world objects. Sorry the screenshot was deliberatly small as I didn't want to bloat peoples inboxes. Regards, Kim. From: [EMAIL PROTECTED] on behalf of Ümit Uzun Sent: Tue 04/11/2008 12:35 To: OpenSceneGraph Users Subject: Re: [osg-users] MAX to COLLADA or which format ? Hi Kim, Thanks for detailed explanation. I grasp the method of sun-beams and I will read in ShaderX5 too. But could you clarify me at some point before I have started to search about this topic? I will create my own water surface and waves algorithm. And then with using sun light I will calculate the reflection and refraction angles for every vertex point. Then I will use this interpolated refraction angle and vertex position I will create a grided parallelepiped volume which is going downward this point under the sea with attenuating the glowing degree. But At that point I can't understand the creation of this parallelepiped volume creation on FragmentShader. How this grid of parallelepiped volumes geometry can be interpolated ? And I like so much your posted screen shot :) This is I think VENUS submarine and I have some question about it. Is there all simulation environment or with pilot cabin? I can't realize joysticks, another screen which is showing above the water surface and sonar gauge are real objects or simulated environment. Thanks for your advices Kim. Best Regards. 2008/11/4 Kim C Bale [EMAIL PROTECTED] Hi Umit, Rendering God-rays is pretty easy. The approach I used is described in the book ShaderX5, although I have to say it's quite badly written. Basically you model the god-rays as a grid of parallelepipeds positioned at the ocean surface, relative to the position of the camera. To create the god-ray geometry you then need to extrude the base points downward along the angle of refraction from the sea surface. In order to compute the angle of refraction you'll need to create a simulation of the ocean surface itself. The technique described in ShaderX5 details a Gerstner wave surface partially computed on the GPU. Using this you can interpolate between the vertex normals to get the normals you need to compute the refraction angles. Finally, you render these god-rays into a FBO and then render that texture to the screen with additive blending. A final stage which would look nice is to apply some sort of blur to the rays texture so the edges aren't quite so crisp. You can see the effect in the attached screenshot. Regards, Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun Sent: 31 October 2008 15:42 To: OpenSceneGraph Users Subject: Re: [osg-users] MAX to COLLADA or which format ? Hi Kim, 2008/10/31 Kim C Bale [EMAIL PROTECTED] Hi Umit, Yes, I am employed on the VENUS project, how on earth do you know that? I have searched on internet and so know VENUS project and your MSc student Franclin Foping and another student Philip Apery who worked same project before. I have read these student thesis and implement in my animation. (caustics, fish motion, aquatic floara, silt on sea bed, water refraction and so on...) Now I only want to much realistic fish motion as I said. So I learned that I should try different tools like animetk or just like it. I want to ask another question about god-rays
Re: [osg-users] MAX to COLLADA or which format ?
I'm afraid I can't recall the interpolation method used for generating the normals from the gerstner model, it is detailed in the book. I personally didn't use the gerstner approach since I had already built an FFT simulation for the wave surface and wanted to use that for the the normal computation instead. The extrusion of the parallelpepids is done within the vertex shader, you store the length of the extrusion as a texture coordinate for each vertex. So inside the vertex shader you have something along the lines of: newVertex = oldVertex + (gl_TexCoord[0] * refractionVector); That way you can differentiate between vertices that lie on the water surface and those that need to extruded downward. Finally, everything in the screen shot is simulated, no real world objects. Sorry the screenshot was deliberatly small as I didn't want to bloat peoples inboxes. Regards, Kim. From: [EMAIL PROTECTED] on behalf of Ümit Uzun Sent: Tue 04/11/2008 12:35 To: OpenSceneGraph Users Subject: Re: [osg-users] MAX to COLLADA or which format ? Hi Kim, Thanks for detailed explanation. I grasp the method of sun-beams and I will read in ShaderX5 too. But could you clarify me at some point before I have started to search about this topic? I will create my own water surface and waves algorithm. And then with using sun light I will calculate the reflection and refraction angles for every vertex point. Then I will use this interpolated refraction angle and vertex position I will create a grided parallelepiped volume which is going downward this point under the sea with attenuating the glowing degree. But At that point I can't understand the creation of this parallelepiped volume creation on FragmentShader. How this grid of parallelepiped volumes geometry can be interpolated ? And I like so much your posted screen shot :) This is I think VENUS submarine and I have some question about it. Is there all simulation environment or with pilot cabin? I can't realize joysticks, another screen which is showing above the water surface and sonar gauge are real objects or simulated environment. Thanks for your advices Kim. Best Regards. 2008/11/4 Kim C Bale [EMAIL PROTECTED] Hi Umit, Rendering God-rays is pretty easy. The approach I used is described in the book ShaderX5, although I have to say it's quite badly written. Basically you model the god-rays as a grid of parallelepipeds positioned at the ocean surface, relative to the position of the camera. To create the god-ray geometry you then need to extrude the base points downward along the angle of refraction from the sea surface. In order to compute the angle of refraction you'll need to create a simulation of the ocean surface itself. The technique described in ShaderX5 details a Gerstner wave surface partially computed on the GPU. Using this you can interpolate between the vertex normals to get the normals you need to compute the refraction angles. Finally, you render these god-rays into a FBO and then render that texture to the screen with additive blending. A final stage which would look nice is to apply some sort of blur to the rays texture so the edges aren't quite so crisp. You can see the effect in the attached screenshot. Regards, Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun Sent: 31 October 2008 15:42 To: OpenSceneGraph Users Subject: Re: [osg-users] MAX to COLLADA or which format ? Hi Kim, 2008/10/31 Kim C Bale [EMAIL PROTECTED] Hi Umit, Yes, I am employed on the VENUS project, how on earth do you know that? I have searched on internet and so know VENUS project and your MSc student Franclin Foping and another student Philip Apery who worked same project before. I have read these student thesis and implement in my animation. (caustics, fish motion, aquatic floara, silt on sea bed, water refraction and so on...) Now I only want to much realistic fish motion as I said. So I learned that I should try different tools like animetk or just like it. I want to ask another question about god-rays. Did you implement god-rays to VENUS? I want to create god-rays in my simulation, so is there any advices and searh path you can give me? Thanks for all advices Kim. Best Regards. Umit Uzun I, personally haven't worked with any flocking algorithms, it's a feature I haven't got round to adding yet. However, I did supervise an MSc student project on flocking using OSG. In order to simulate fish body motion he used an animated vertex shader to distort the model with a dampened sine wave (as you
Re: [osg-users] MAX to COLLADA or which format ?
In my experience the feelingsoftware collada exporter gives the most reliable results when exporting models from Max. However, as far as I know there is no way of getting any animation information out of max and into the OSG. I've noticed that the animation toolkit (osgATK/osgAnimation I forget the name), mentioned recently in the forum had a Blender importer/exporter that does support animation. Perhaps that is worth taking a look at. Hope that is of help. Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun Sent: 31 October 2008 10:06 To: OpenSceneGraph Users Subject: [osg-users] MAX to COLLADA or which format ? Hi Folks, I follows mail list and I know there was a discussion about converting animated MAX format to any format which osg can understand. I searched the all archive and want to ask same question again around the different content. As I said, I have animated MAX format models and want to export another format in animation too. But after searching, I understand that I only can do this conversion in COLLADA format. Is it right ? And if right how should I achive? I found colladamax exporter http://www.feelingsoftware.com/content/view/65/79/lang,en/ There is anyone who used this exporter? I am asking because of leading me to right way. And Does using COLLADA formatted animated model useful or not on simulation project? I have never use collada format before, so I don't know anything about the efficiency. Any advices would be appreciated with glad. Best Regards. Umit Uzun * 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] MAX to COLLADA or which format ?
Hi Umit, Yes, I am employed on the VENUS project, how on earth do you know that? I, personally haven't worked with any flocking algorithms, it's a feature I haven't got round to adding yet. However, I did supervise an MSc student project on flocking using OSG. In order to simulate fish body motion he used an animated vertex shader to distort the model with a dampened sine wave (as you mentioned). With a bit of tinkering this should provide nice results with minimal effort. However, if you want more accurate movement I think it would have to be modelled, but then of course you have the problem of loading the animation into the OSG.. Hope that's of use. Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun Sent: 31 October 2008 12:02 To: OpenSceneGraph Users Subject: Re: [osg-users] MAX to COLLADA or which format ? Hi Kim, Thanks so much for reply. I remember, you have worked on VENUS project. In this project how can you achieve fish motion modeling? Do you use only shaders to give special motion mathematics on each skeletal model or do you use sophisticated tools? I mean, I want to model school of fish by using Reynold's Flocking Algorithms and fish motions. At this point Do I have to model each fish motion by using shaders (for example sinusoaidal travelling wave to modeling fish waving) ? Or there is another way to to it except osganimation toolkit? Thanks for advices. Best Regards. Umit Uzun 2008/10/31 Kim C Bale [EMAIL PROTECTED] In my experience the feelingsoftware collada exporter gives the most reliable results when exporting models from Max. However, as far as I know there is no way of getting any animation information out of max and into the OSG. I've noticed that the animation toolkit (osgATK/osgAnimation I forget the name), mentioned recently in the forum had a Blender importer/exporter that does support animation. Perhaps that is worth taking a look at. Hope that is of help. Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun Sent: 31 October 2008 10:06 To: OpenSceneGraph Users Subject: [osg-users] MAX to COLLADA or which format ? Hi Folks, I follows mail list and I know there was a discussion about converting animated MAX format to any format which osg can understand. I searched the all archive and want to ask same question again around the different content. As I said, I have animated MAX format models and want to export another format in animation too. But after searching, I understand that I only can do this conversion in COLLADA format. Is it right ? And if right how should I achive? I found colladamax exporter http://www.feelingsoftware.com/content/view/65/79/lang,en/ There is anyone who used this exporter? I am asking because of leading me to right way. And Does using COLLADA formatted animated model useful or not on simulation project? I have never use collada format before, so I don't know anything about the efficiency. Any advices would be appreciated with glad. Best Regards. Umit Uzun * 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 * 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] Lighted baked models....
Hi Adrian, I've had numerous problems getting models from Max into the OSG. The OSGs 3DS loader gives very different results depending on how you've created the model in Max. I'm not sure whether that's the loaders fault or Max but either way it's very unreliable. Furthermore I found that the built in Collada exporter in Max is just as temperamental with the ColladaDOM loader that the OSG uses. So... after much clawing and gnashing of teeth I found this little beauty: http://www.feelingsoftware.com/content/view/65/79 It's a freeware Collada exporter for MAX 2008 and that works every time. I believe someone has compiled a version that works with 2009 which you can find here. However, I've not tried it. http://techarttiki.blogspot.com/2008/08/colladamax-for-3ds-max-2009-64-b it.html Hope that's of some use. Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: 24 October 2008 15:41 To: OpenSceneGraph Users Subject: [osg-users] Lighted baked models Hi all, i have some model to test with light baked textures, the model is in the .MAX file format, and now i would like to convert it into a openscenegraph model. unfort. the model was created with MAX 2009 and so the osg max plugin may doesn't work. so i can export the model to collada : 3ds : wavefront obj : what would be the best format with the most different texture supported. i have baked textures (light and color), then reflections maps. with wavefront obj i get some bug, not supported texture layer for the reflection map. what are your experiences with such models -adrian -- Adrian Egli * 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] Collada (DAE) Plugin
I've just started to make the move to OSG2.6 from 2.4 and I'm having issues compiling the collada plugin. Am I right to understand that OSG2.6 uses DOM 2.1? I've downloaded and compiled the new version of the collada DOM and added the relevant paths to CMake (seen below) but I still get compiler errors. COLLADA_INCLUDE_DIR: C:/Build/colladadom/dom/include COLLADA_LIBRARY: C:/Build/colladadom/dom/build/vc8-1.4/libcollada14dom21.lib I've tried using the DOM 13 which worked fine with OSG2.4 but it doesn't seem to work with 2.6. Any help would be greatly appreciated. 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] OpenGL FBO Error/Warning
Hi All, I'm getting the following error/warning when I run my program. Can anybody tell me what it means? Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Cheers, 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] UnderWater Effect on OSG
Look at depth of field, it works very well for underwater scene, going some way to spoof the blurring in the distance caused by water. I believe there's a nice implementation in the book ShaderX3 As for sun-beams or god-rays check out the book ShaderX5 there's a good article on a multipass technique there A great text on ocean simulation/rendering is Tessendorf's Simulating Ocean Water (http://www.finelightvisualtechnology.com/docs/coursenotes2004.pdf http://www.finelightvisualtechnology.com/docs/coursenotes2004.pdf ). And this one is good for over/underwater lighting simulations: http://www.cs.utah.edu/vissim/papers/water/ http://www.cs.utah.edu/vissim/papers/water/ None of these are specific to osg of course but from personal experience I've found the techiques are easily implementable with the OSG. I'd be very interested to see any work you do in this area as it's of particular interest to me. Regards, Kim. From: [EMAIL PROTECTED] on behalf of Ümit Uzun Sent: Tue 26/08/2008 22:12 To: OpenSceneGraph Users Subject: [osg-users] UnderWater Effect on OSG Hi All, I want to create under water effect and searched mail list so found very few mail about this topic. How can I create on OSG? I want to learn more than using a Fog, plankton or bubbles effects. For example, waves, multi-pass particle effect or sun-beam effects? Where should I start? Thanks so much. Best Regards. Ümit Uzun winmail.dat* 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] Getting the Current View Matrix
Hi Robert, I've tried what you suggested, setting the reference frame of the transform to osg::MatrixTransform::ABSOLUTE_RF. That works very well for the main camera. However, I think you've misunderstood my problem. I would like the cockpit to appear relative to the eye position of any child cameras in the scene too. In my case I create an RTT camera and add that as a child to the root, to generate a differant, fixed view of the scene. What i would like to do is to set the position of the cockpit relative to the position of the current camera, so that I get an interior view of the cockpit in both the main and RTT view. Is it possible using this type of transform? I've included the child camera code below if that provides any clues. Thanks, Kim. osg::ref_ptrosg::TextureRectangle mainView2 = createTextureRect( screenDims ); osg::Viewport* viewport = new osg::Viewport( 0, 0, screenDims.x(), screenDims.y() ); osg::Camera* camera = new osg::Camera; camera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); camera-setReferenceFrame ( osg::Transform::ABSOLUTE_RF ); camera-setProjectionMatrixAsFrustum( -1, 1, -1.0*0.8, 1.0*0.8, 1, 1e+006 ); camera-setViewMatrix( fixedViewMatrix ); camera-setViewport ( viewport ); camera-setRenderOrder ( osg::Camera::PRE_RENDER, 4 ); camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); camera-attach( osg::Camera::COLOR_BUFFER, mainView2.get() ); camera-addChild( renderGroup ); screenGroup-addChild( camera ); From: [EMAIL PROTECTED] on behalf of Kim C Bale Sent: Fri 15/08/2008 18:13 To: OpenSceneGraph Users Subject: RE: [osg-users] Getting the Current View Matrix Yes that's the case. Great, thanks for the rapid response. I'll give it a whirl. Regards, Kim. From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Fri 15/08/2008 17:39 To: OpenSceneGraph Users Subject: Re: [osg-users] Getting the Current View Matrix HI Kim, Is the Cockpit fixed related to the camera position? If so just place it under a an Transform with a absolute reference frame, it'll then render relative to eye coordinates and ignore any inherited view matrix - no need for any callbacks at all. Robert. On Fri, Aug 15, 2008 at 5:34 PM, Kim C Bale [EMAIL PROTECTED] wrote: Hi all, I've created a cockpit model which moves around along with the camera movement. To do this I've attached an update callback to the cockpit's transform. I pass the viewers main camera into it and use that to set the cockpit transform to the inverse of the main camera's view matrix. This works fine. However, now I want to render the scene from two differant views, both with the cockpit attached to the camera. Once from the main camera's perspective and again from another view setup using an RTT camera. Using my approach, the cockpit is bound to the main cameras view and therefore, doesn't show up in the RTT view. So my question is this, how can I change the cockpit transform according to the current view point. I presume that I can't use an update callback for this. Is it possible to get hold of the current view matrix within a callback? Thanks for any help, I'm rather stumped on this one. 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Always on top rendering.
I'm having difficultly getting a some geometry to always render infront of a scene. I use an absolute matrixtransfom to move a cockpit model relative to the camera position. However, as i move the camera around it intersects with geometry in the scene. Previously I achieved this by using a post render camera and clearing the depth buffer bit. I can't do that now because in this case the cockpit and scene are rendered through a pre render RTT camera. I can't disable depth testing because the various parts of the model don't render in the right order, and I have tried setting the renderbin on the matrixtransform to 11 but to no effect. Does anybody have any ideas? Thanks. Kim. winmail.dat* 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] Getting the Current View Matrix
Hi all, I've created a cockpit model which moves around along with the camera movement. To do this I've attached an update callback to the cockpit's transform. I pass the viewers main camera into it and use that to set the cockpit transform to the inverse of the main camera's view matrix. This works fine. However, now I want to render the scene from two differant views, both with the cockpit attached to the camera. Once from the main camera's perspective and again from another view setup using an RTT camera. Using my approach, the cockpit is bound to the main cameras view and therefore, doesn't show up in the RTT view. So my question is this, how can I change the cockpit transform according to the current view point. I presume that I can't use an update callback for this. Is it possible to get hold of the current view matrix within a callback? Thanks for any help, I'm rather stumped on this one. 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] Getting the Current View Matrix
Yes that's the case. Great, thanks for the rapid response. I'll give it a whirl. Regards, Kim. From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Fri 15/08/2008 17:39 To: OpenSceneGraph Users Subject: Re: [osg-users] Getting the Current View Matrix HI Kim, Is the Cockpit fixed related to the camera position? If so just place it under a an Transform with a absolute reference frame, it'll then render relative to eye coordinates and ignore any inherited view matrix - no need for any callbacks at all. Robert. On Fri, Aug 15, 2008 at 5:34 PM, Kim C Bale [EMAIL PROTECTED] wrote: Hi all, I've created a cockpit model which moves around along with the camera movement. To do this I've attached an update callback to the cockpit's transform. I pass the viewers main camera into it and use that to set the cockpit transform to the inverse of the main camera's view matrix. This works fine. However, now I want to render the scene from two differant views, both with the cockpit attached to the camera. Once from the main camera's perspective and again from another view setup using an RTT camera. Using my approach, the cockpit is bound to the main cameras view and therefore, doesn't show up in the RTT view. So my question is this, how can I change the cockpit transform according to the current view point. I presume that I can't use an update callback for this. Is it possible to get hold of the current view matrix within a callback? Thanks for any help, I'm rather stumped on this one. 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 *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] World Coordinates
I'm trying to work out the world coordinates of vertices in my shader, and I'd like to check my understanding of a few things. At the moment I manually go through the graph and grabbing the transformations en-route to the target geode and create the matrix myself, pass this to the shader, and multiply it by gl_Vertex. That seems to work fine, although it does involve a lot of faffing. However I noticed a couple of handy things already built into OSG. The first is getWorldMatrices; If I call root-getWorldMatrices(targetGeode) does this achieve the same as above? Accumulate the transformation matrices up to that geode and form a matrix? The second is osg_ViewMatrixInverse. If I simply form a matrix from osg_ViewMatrixInverse * gl_ModelViewMatrix does this not give me the same matrix? I hope that makes sense, thanks for your help. 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] Running OSG application in Firefox
This was mentioned a while ago, search the forum for Problems with osgViewer and ActiveX, there was a chap that was trying to do it in IE so I presume you could get some relevant info from him. Regards, Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rahul Jain Sent: 24 July 2008 10:21 To: OpenSceneGraph Users Subject: [osg-users] Running OSG application in Firefox Hi all , I want to write a plugin so that i can embed my OSG application in Firefox browser. Have any one tried this before ? Please suggest me some pointers to start with . cheers RJ ___ 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] Little ray-tracing example using the KD-tree
Very tidy I like it! Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: 15 July 2008 22:51 To: OpenSceneGraph Users Subject: [osg-users] Little ray-tracing example using the KD-tree Hi all, Here's a small thingy that (ab)uses the new intersection code to do ray tracing, for a single viewpoint (i.e. not interactive) with shadows. See the attached screenshots for normal OSG rendering versus ray-traced rendering. See the source for a few instructions on use. Bye, Paul* 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] osgWidget Remaining Issues
- The anti-aliased look of the fonts is really nice in most cases, but when trying to render small fonts it would be nice if you could disable it. Basically, I'd like to get the sharp look of the DefaultFont using the FreeType plugin. Just to reinforce the above point, we used the freetype library to generate OpenGL screen fonts here and found that for font sizes 12 Disabling anti-aliasing really improved the clarity of the font. So much so we made it automatically default to removing the AA when size below a threshold were set. I think this would be a great tweak to your work. Regards, Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Farshid Lashkari Sent: 14 July 2008 23:08 To: OpenSceneGraph Users Subject: Re: [osg-users] osgWidget Remaining Issues Hi Jeremy, I've also spent a lot of time trying to get crisp fonts rendered in OSG. Here are some things I have noticed: - The width/height of the orthographic projection matrix should match the width/height of the viewport being rendered to. - The font x,y position should be rounded to the nearest integer. Fractional positions will cause blurring. - Ideally the osgText node should not be underneath a Transform node that has scaling. Use the font resolution to adjust the size of the text. - You should use left aligned text. Using center aligned text causes blurring in some cases. If I need a font to be centered I manually compute the bounding box and position it to appear centered while still being left aligned internally. - The anti-aliased look of the fonts is really nice in most cases, but when trying to render small fonts it would be nice if you could disable it. Basically, I'd like to get the sharp look of the DefaultFont using the FreeType plugin. I'm still using OSG 1.2, so some of this might have changed. If you have any other advice on getting crisp fonts I'd be interested to know about it. I've also needed the ability to get the position of a specific glyph. However, I only needed the x position, so I just cropped the text to the glyph I needed, retrieved the bounding box, then restored the previous text. Hope this was helpful. -Farshid On Mon, Jul 14, 2008 at 1:45 PM, Jeremy Moles [EMAIL PROTECTED] wrote: As you've probably noticed, osgWidget development has been extremely stagnant of late. This is somewhat due to my lack of personal time, but in large part is due to a small number of remaining hurdles that I do not have a good solution to. Robert has sent me a few e-mails, and I've been encouraged to bring these issues up here for discussion. Hopefully, with the next release pending, we can work out solutions for these--even if they don't make it into the next release. :) My MAIN concerns at the moment are font-related. It's unfortunate that you have someone like me writing this NodeKit, because a different person probably wouldn't care as much. However, I am an absolute font crackhead, and I will settle for nothing less than the very best font quality possible using OSS. The following are some of the things I'm encountering with osgText as it exists in SVN; any and all input is welcome. 1. [ Font Clarity ] -- Getting crisp, consistent, arbitrarily-sized 2D fonts using osgText is proving very difficult. I have posted many times in the past on this, and have had varying amounts of success using the responses given. However, to this date, I cannot get a version of OSG--patched or otherwise--that will provide the font quality I'm used to seeing. I really wish I could give more info, or more in-depth technical details, but unfortunately my knowledge of the subject doesn't allow me to describe my observations any more intelligently. Robert accepted my osgfont example into SVN, so I would encourage anyone curious to take a look at that and run it with an invocation such as the following: # osgfont fonts/arial.ttf 10 11 12 13 14 15 You'll notice that at some sizes and locations, the text appears crisp and sharp. You'll also notice that at other places the text is blurry and smudged. Why this occurs I can't be sure, but I'll need to be able to identify those situations in which it does so that I can avoid them. 2. [ Low-level Font API ] -- In order to create a proper Input widget, I will need a low-level API for interfacing with the individual text elements (glyphs, characters, or whatever you refer to them as). At the minimum I will need a way to access the individual width, height, and baseline offset. I'm not quite sure how best to accomplish this, nor will I claim to be capable enough to hack osgText's current implementation and add it myself. However, there's no way I can personally conceive of to create an editable osgText object without knowing exactly what (preferrably integer) coordinates a
[osg-users] getViewMatrixAsLookAt
Hi all, Just a quick one for you.. when I use the following code: osg::Vec3 eye, centre, up; float dist = 0.f; viewer.getCamera()-getViewMatrixAsLookAt( eye, centre, up, dist ); I seem to get the same value for both eye and centre. Is that supposed to happen? If so how can I get the view vector from the camera? 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] getViewMatrixAsLookAt
Ha sorry my mistake.. I though dist was an output parameter. Must think before I speak/post! Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim C Bale Sent: 02 July 2008 11:16 To: OpenSceneGraph Users Subject: [osg-users] getViewMatrixAsLookAt Hi all, Just a quick one for you.. when I use the following code: osg::Vec3 eye, centre, up; float dist = 0.f; viewer.getCamera()-getViewMatrixAsLookAt( eye, centre, up, dist ); I seem to get the same value for both eye and centre. Is that supposed to happen? If so how can I get the view vector from the camera? 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
