Re: [osg-users] light, normals
Hi, Jean-Sébastien Guay wrote: Hi Christian, my geometry has 9 vertices - i thought if i use a drawElement index with index swaps to revist a vertex, this would give me the opportunity to use more than one normal per vertex (there are reasons why i need this ;-). i now think the truth is, only real vertices in the vertexlist let me allow to do this. Yes, if you need hard edges, then you need different normals for the same vertex when it's part of a different face. But the way to express that with vertex arrays is to duplicate the vertex in the array and use a different normal. Your analysis seems correct. From what you say above, what you actually did was have a larger number of normals than vertices, thinking that then the extra normals would be used when the same vertex was used in a different primitive set. That doesn't work. When normals are used in BIND_PER_VERTEX mode, it's assumed that you have the same number of vertices as normals, and so the result was just that the extra normals were never used. (same with colors in the color array BTW) So to recap, if normals are used in BIND_PER_VERTEX mode, then vertex i is used with normal i. But vertex i and vertex j can be equal, with a different normal j. And then vertex i and vertex j can be part of different triangles (well, should, otherwise you have a degenerate triangle). At first this seems like a waste of memory, but the hardware is really optimized to work this way. Hope this helps, J-S What J-S says is right and would work fine if you want a single primitive. You can however avoid duplicating vertices if you are willing to make more primitives. Simple contrived example: say you want to draw a triangle and specify normals for both sides manually. (GL_TRIANGLES) Now you can make a single vertex array, normal array and drawelements va = [v1, v2, v3, v3, v2, v1] na = [n1, n1, n1, n2, n2, n2] de = [0, 1, 2, 3, 4, 5] and make a primitive out of this. Or, you can make a single vertex array, 2 normal arrays and 2 drawelements va = [v1, v2, v3] na1 = [n1, n1, n1] na2 = [n2, n2, n2] de1 = [0, 1, 2] de2 = [2, 1, 0] and make two primitives. In this way you can sometimes save some memory by having less vertices loaded up. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Remote execution and OSG
Hi all, maybe the first thing to do is test with some easy application, like xclock or something else to be sure your X forwarding is working... I've just tested yesterday, with "ssh -X" and it was working for me... But it's extremely low... Pierre. Le jeudi 14 mai 2009 à 21:45 +0100, Simon Hammett a écrit : > No idea, sry. > It's getting on for 15 years since I did any xlib programming. > > You could have a poke around in: > > src\osgViewer\GraphicsWindowX11.cpp > > and work backwards from there. > > 2009/5/14 : > > > > Already tried "xhost +".. No help.. > > > > What is so special about "osgkeyboardmouse, osgcompositeviewer, > > osgsidebyside, osgtexture3D, osgslice, and osgwindows" that would cause > > them not to work but other do? "osgviewer --window" seems to work fine.. > > Does this have something to do with the GraphicsContext? > > > > Paul P. > > > > > > - Original Message > > From: Simon Hammett > > To: OpenSceneGraph Users > > Sent: Thursday, May 14, 2009 2:58:09 PM > > Subject: Re: [osg-users] Remote execution and OSG > > > > Don't you have to grant access on your machine to remote connections? > > IIRC, try 'xhost +' on your machine before starting the program on the > > remote machine. > > > > 2009/5/14 : > >> > >> Yes, I am using Redhat Linux with OSG 2.9.3. > >> > >> Using "ssh -Y" didn't help... > >> > >> Also, as I pointed out in my last e-mail, I get this X11 connection > >> refused, however, the application still runs but FULL SCREEN instead of in > >> a window... > >> > >> Paul P. > >> > >> > >> - Original Message > >> From: "Thrall, Bryan" > >> To: OpenSceneGraph Users > >> Sent: Thursday, May 14, 2009 1:35:45 PM > >> Subject: Re: [osg-users] Remote execution and OSG > >> > >> paul1...@yahoo.com wrote on Thursday, May 14, 2009 12:28 PM: > >> > >>> I need to be able to run my OSG program remotely (from a different machine > >>> that where the display location). I'm using "ssh" to login to the remote > >>> location and have my "setenv DISPLAY" set back to my original computer > >>> (I've > >>> set xhost + on the server machine). > >>> > >>> When I do this, on SOME OSG examples, I'm getting: > >>> Xlib: connection to ":0.0" refused by server > >>> Xlib: No protocol specified > >>> > >>> Error: Unable to open display ":0.0". > >>> Error: unable to create graphics window > >>> > >>> I haven't narrowed down when I get this but it seems that I get it only > >>> when > >>> I run applications that create their own windows. I do not see this when > >>> running osgviewer in full screen mode nor with many of the other OSG > >>> examples. However, I do see this problem with osgkeyboardmouse, > >>> osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice, and > >>> osgwindows. > >>> In these cases, instead of opening up a window as I think these are > >>> supposed > >>> to do, it runs full screen. > >>> > >>> Any idea what is going on here? > >> > >> Not sure what's wrong with your DISPLAY, but 'ssh -Y' will tunnel the X > >> connection through ssh and set up the DISPLAY correctly (usually to > >> something like 'localhost:10.0') without you having to mess with it. > >> > >> You don't say, but I'm assuming you're running Linux or something like > >> that; OSG compiled for Windows doesn't do X forwarding :) > >> > >> -- > >> Bryan Thrall > >> FlightSafety International > >> bryan.thr...@flightsafety.com > >> ___ > >> 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 > >> > > > > > > > > -- > > http://www.ssTk.co.uk > > ___ > > 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 > > > > > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi, Mao wrote: Hi! Recently, our project is planning to migrate from mini to VPB. However, we encounter with several questions. 1. In the example of osgDEM, I infer that osgDEM processes tiff format only. But tiff uses 32-bit offset which limits its size to 4G bytes. Most of our data are ERDAS img file or rrd file, which are huge in size. Yesterday, we processed an img file of size 20G bytes, and gdal_translate it to a 21G bytes tiff. That confused me. How can VPB handle extra bytes? osgdem/virtualplanetbuilder can read all files that gdal can read, so have a look here: http://www.gdal.org/formats_list.html You can use the gdal tools to split your large data into multiple smaller geotiffs <2GB if you want. 2. Another thing is that, texture files we got sometimes are in pieces, and we should use gdal_merge.py to merge them into one big tiff. According to the source code, VPB can handle only one texture file. Can we use multiple texture files? It is better in pieces :) Smaller files, easier to handle. VPB can handle multiple texture files, you can even pass a directory name and it would use all the files in the directory. See here too: http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/ExampleClusterJPD 3. The last question is when applied with “--Terrain” or “—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate both texture and DEM data into one output file? And it seems that osg::HeightField does not provide height = getHieghtAt(terrain.x, terrain.y) method. Hi, --terrain works for me. You can have DEM layer + multiple texture layers. I can't answer about height_field. jp Thank you very much for listening! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] iv file not being read
Hello Abhinav, There is nothing for anyone to go on to even try to help you. The code snippet is not even osg code so no chance for us to know anything about what it does. * use a debugger to see what "readAll" returns and why * crank up OSG_NOTIFY_LEVEL * see Paul Martz top 10 debugging tips at http://www.skew-matrix.com/bb/viewtopic.php?f=6&t=5 cheers Mattias On 5/15/09, Abhinav Dubey wrote: > Hi, > i am trying to read an iv file but its not being read. the code i am using > is : > *** > SoInput sceneInput; > if ( !sceneInput.openFile( "plugins\\graphs\\myInventor.iv" ) ) { > QMessageBox::information(mInventorGrid[3], "Error", "Cannot open > file requested iv file"); > return; > } > > SoSeparator *sc_root = SoDB::readAll( &sceneInput ); >sc_root->ref(); > > Use one of the convenient SoQt viewer classes. > mViewer = new SoQtExaminerViewer(iv_widget); > mViewer->setSceneGraph(sc_root); > mViewer->setDecoration(false); > mViewer->show(); > *** > and the iv file named myInventor.iv has the following: > #Inventor V2.1 ascii > > Separator { > SoXipExaminer { > modeNONE > viewBoundingBox 230 0 0 0 > 0 227.785 0 0 > 0 0 42.1032 0 > -112.59 -117.21 50.3972 1 > complexity Complexity { > value 0.5 > textureQuality 0.5 > } > > orthoCamera DEF +0 OrthographicCamera { > } > > perspectiveCamera DEF +1 PerspectiveCamera { > position0.181952 88.5125 454.632 > orientation -0.494995 0.0901597 0.864206 0.470889 > nearDistance230.823 > farDistance 557.256 > focalDistance 394.04 > heightAngle 0.785398 > } > > borderNode SoXipViewportBorder { > fields [ SFColor activeColor, SFColor inactiveColor, ] > activeColor 0.7 0.7 0.7 > inactiveColor 0.7 0.7 0.7 > } > > cameraSwitchSwitch { > whichChild 1 > USE +0 > USE +1 > } > > } > SoXipLut { > fields [ SFEnum inputMode, SFEnum outputMode, SFShort bitsUsed, SFFloat > rampWidth, > SFFloat rampCenter, MFColor arrayColor, MFFloat arrayAlpha ] > inputMode TRAPEZOID > outputMode COLOR > bitsUsed12 > rampWidth 0.05 > rampCenter 0.009 > arrayColor [ ] > arrayAlpha [ ] > } > SoXipImage { > fields [ SoXipSFDataImage image ] > image "DATA" = > SoXipLoadDicom { > inputs [ MFString name ] > name"C:\Xip\examples\data\24884367.dcm" > outputs [ SoXipMFDataDicom dicom ] > } > . dicom > > } > } > *** > when i run the code it crashes at sc_Root.ref(); > plz help me out > ... > > > Thank you! > > Cheers, > Abhinav > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=12174#12174 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi, I can confirm it works well with many textures... Here's screenshot of some terrain build with 2 textures: http://perso.imerir.com/bourdin/wiki/doku.php/en/projet/massane The only problem I have is with Shapefile, but I'm using osggis for that... If you know how to use them with osgdem ? I'm interested... For the --terrain option, it works also very well, but I have to disable GL_ARB extension with my ATI otherwise it crashes. Pierre Le vendredi 15 mai 2009 à 09:08 +0200, J.P. Delport a écrit : > Hi, > > Mao wrote: > > Hi! Recently, our project is planning to migrate from mini to VPB. > > However, we encounter with several questions. > > > > > > > > 1. In the example of osgDEM, I infer that osgDEM processes tiff > > format only. But tiff uses 32-bit offset which limits its size to 4G > > bytes. Most of our data are ERDAS img file or rrd file, which are huge > > in size. Yesterday, we processed an img file of size 20G bytes, and > > gdal_translate it to a 21G bytes tiff. That confused me. How can VPB > > handle extra bytes? > > osgdem/virtualplanetbuilder can read all files that gdal can read, so > have a look here: > http://www.gdal.org/formats_list.html > > You can use the gdal tools to split your large data into multiple > smaller geotiffs <2GB if you want. > > > > > 2. Another thing is that, texture files we got sometimes are in > > pieces, and we should use gdal_merge.py to merge them into one big tiff. > > According to the source code, VPB can handle only one texture file. Can > > we use multiple texture files? > > It is better in pieces :) Smaller files, easier to handle. VPB can > handle multiple texture files, you can even pass a directory name and it > would use all the files in the directory. > > See here too: > http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/ExampleClusterJPD > > > > > 3. The last question is when applied with “--Terrain” or > > “—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate > > both texture and DEM data into one output file? And it seems that > > osg::HeightField does not provide height = getHieghtAt(terrain.x, > > terrain.y) method. > > Hi, --terrain works for me. You can have DEM layer + multiple texture > layers. I can't answer about height_field. > > jp > > > > > > > > > Thank you very much for listening! > > > > > > > > > > ___ > > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Remote execution and OSG
Hi, paul1...@yahoo.com wrote: Already tried "xhost +".. No help.. What is so special about "osgkeyboardmouse, osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice, and osgwindows" that would cause them not to work but other do? "osgviewer --window" seems to work fine.. Does this have something to do with the GraphicsContext? Not sure, but it looks like some code ignores the $DISPLAY setting and just tries to open :0.0. I can confirm that I get the same behaviour between two Debian machines: osgviewer cow.osg runs at a staggering 2fps osgkeyboardmouse fails with: No protocol specified Error: Unable to open display ":0.0". Error: unable to create graphics window. jp Paul P. - Original Message From: Simon Hammett To: OpenSceneGraph Users Sent: Thursday, May 14, 2009 2:58:09 PM Subject: Re: [osg-users] Remote execution and OSG Don't you have to grant access on your machine to remote connections? IIRC, try 'xhost +' on your machine before starting the program on the remote machine. 2009/5/14 : Yes, I am using Redhat Linux with OSG 2.9.3. Using "ssh -Y" didn't help... Also, as I pointed out in my last e-mail, I get this X11 connection refused, however, the application still runs but FULL SCREEN instead of in a window... Paul P. - Original Message From: "Thrall, Bryan" To: OpenSceneGraph Users Sent: Thursday, May 14, 2009 1:35:45 PM Subject: Re: [osg-users] Remote execution and OSG paul1...@yahoo.com wrote on Thursday, May 14, 2009 12:28 PM: I need to be able to run my OSG program remotely (from a different machine that where the display location). I'm using "ssh" to login to the remote location and have my "setenv DISPLAY" set back to my original computer (I've set xhost + on the server machine). When I do this, on SOME OSG examples, I'm getting: Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Error: Unable to open display ":0.0". Error: unable to create graphics window I haven't narrowed down when I get this but it seems that I get it only when I run applications that create their own windows. I do not see this when running osgviewer in full screen mode nor with many of the other OSG examples. However, I do see this problem with osgkeyboardmouse, osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice, and osgwindows. In these cases, instead of opening up a window as I think these are supposed to do, it runs full screen. Any idea what is going on here? Not sure what's wrong with your DISPLAY, but 'ssh -Y' will tunnel the X connection through ssh and set up the DISPLAY correctly (usually to something like 'localhost:10.0') without you having to mess with it. You don't say, but I'm assuming you're running Linux or something like that; OSG compiled for Windows doesn't do X forwarding :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean release
An other Interesting paper http://www.informatik.uni-rostock.de/~hc009/publications.html On Thu, May 14, 2009 at 11:53 AM, David Spilling wrote: > Kim, > > > it does sound difficult to implement as a general case. > > > Actually, I think that the only way to meet all current techniques with as > common a scenegraph structure as possible is to render the heightfield to > texture (generated somehow, e.g. FFT on CPU, sum of sines, FFT on GPU), then > use vertex texture fetch to draw the vertices (e.g. projective, tiled, > etc.). > > The main drawback (IMHO) is current performance : vertex texture fetch is > slow on many cards; even fewer seem to support GL_LINEAR in hardware (which > you need). Undoubtedly this will get better, but when I looked at this a > little while ago, it was sluggish in comparison to techniques not involving > VTF. > > 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 agree; vertex deformation by wakes is... uncommon (we've done it in the > past, but for very very application specific reasons that probably wouldn't > be appropriate). However applying a deformation to your _normal_ field works > easily, and works especially well at high altitudes in calm seas when you > can't / shouldn't be able to see the vertices anyway. It's equivalent in > construction to the way the surface wake foam textures work. > > One other point : for semi-infinite tiling oceans, have a look at the new > instancing stuff that I recently saw contributed into OSG. I haven't played > with yet it myself, but just repeating the base (high res) tile as an > instance is probably higher performance than having to bother with LOD, > skirts, and all the rest. > > Best regards, > > David > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- Yann Le Paih Keraudrono 56150 BAUD Portable: +33(0)610524356 lepaih.y...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi, Pierre Bourdin (gmail) wrote: Hi, I can confirm it works well with many textures... Here's screenshot of some terrain build with 2 textures: http://perso.imerir.com/bourdin/wiki/doku.php/en/projet/massane The only problem I have is with Shapefile, but I'm using osggis for that... If you know how to use them with osgdem ? I'm interested... sorry, I should have made it more clear that I meant gdal raster formats. I don't know of better way than osggis to include vector data. jp For the --terrain option, it works also very well, but I have to disable GL_ARB extension with my ATI otherwise it crashes. Pierre Le vendredi 15 mai 2009 à 09:08 +0200, J.P. Delport a écrit : Hi, Mao wrote: Hi! Recently, our project is planning to migrate from mini to VPB. However, we encounter with several questions. 1. In the example of osgDEM, I infer that osgDEM processes tiff format only. But tiff uses 32-bit offset which limits its size to 4G bytes. Most of our data are ERDAS img file or rrd file, which are huge in size. Yesterday, we processed an img file of size 20G bytes, and gdal_translate it to a 21G bytes tiff. That confused me. How can VPB handle extra bytes? osgdem/virtualplanetbuilder can read all files that gdal can read, so have a look here: http://www.gdal.org/formats_list.html You can use the gdal tools to split your large data into multiple smaller geotiffs <2GB if you want. 2. Another thing is that, texture files we got sometimes are in pieces, and we should use gdal_merge.py to merge them into one big tiff. According to the source code, VPB can handle only one texture file. Can we use multiple texture files? It is better in pieces :) Smaller files, easier to handle. VPB can handle multiple texture files, you can even pass a directory name and it would use all the files in the directory. See here too: http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/ExampleClusterJPD 3. The last question is when applied with “--Terrain” or “—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate both texture and DEM data into one output file? And it seems that osg::HeightField does not provide height = getHieghtAt(terrain.x, terrain.y) method. Hi, --terrain works for me. You can have DEM layer + multiple texture layers. I can't answer about height_field. jp Thank you very much for listening! ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple ClearNodes in a scene, or 2D layering of 3D geometry
Hi Chris, On Fri, May 15, 2009 at 2:10 AM, Chris 'Xenon' Hanson wrote: > I will expand on the abstract explanation, and then reveal my optimal > solution -- which > is a bit of a hack, but is still the most elegant. > > > Basically we have VPB terrain for a very large area, but low detail. Within > it, we have > a smaller world, which the user cannot leave. This terrain is also built with > VPB, at a > much higher detail. This small world needs to be rebuilt frequently with > different data, > and we don't wish to rebuild the entire surrounding world each time. this is > because the > surrounding world doesn't change, and we don't want to spend all the time > rebuilding the > surrounding world to the same degree of detail as the inset local world. It's > kind of like > a skydome/box/environment technique, but it's a world-dome/box/environment. > It has to be > rendered with Z-test and Z-write enabled to sort out self-occlusion, whereas > a skydome can > often skip Z-test/z-write as long as it's a sphere and you use backface > culling. Depth partioning then :-) > The solution is to render the surrounding world, then wipe the Z-buffer, > then render the > local world. this means that even if the local world terrain surface drops > below the > surrounding world in the middle, it still obscures the exterior world. Things > could get > weird close to the edge of the local world, but we prevent that from being an > issue by > restrictions on the local world and near-edge movement. > > What I did was this: > > Render surrounding world in RenderBin -3. > Create an empty piece of dummy Geometry (with a Geode) and render it in > RenderBin -2. > Render the local world in RenderBin -1. > > The dummy geometry has a draw callback on it that issues a raw OpenGL > glClear() only on > the Z-buffer channel. It doesn't disrupt the OpenGL state in any way, just > wipes the Z-buffer. > > It works great. no second cameras to track, no RTT, no goofy stuff. The only > cost is a > full-screen Z-clear operation. > > Thanks to everyone for their suggestions. So you're simulating using two slave Camera's for each of the depth ranges. osgViewer is capable of doing depth partioning although the osgdepthpartition example hasn't yet been ported across to take advantage of the flexibility of osgViewer, it is something on my TODO list. By putting the management of the dept partitioning into the viewer rather than the scene you remove viewing specific code form the scene graph, and make it possible to load any scene into the viewer and have it manage the depth partitioning automatically. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightwave multilayered textures and vertex map support?
Hi Gordon I have tried and didn´t get it to work. I knew that it worked with multilayered textures before but i don´t know if it is Lightwave that have changed in their format or if the importer in OpenSceneGraph have changed. thanks /Olle -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12187#12187 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about osgViewer::View::EventHandlers
HI Moji, On Thu, May 14, 2009 at 5:30 PM, Mojtaba Fathi wrote: > Also, there is no such removeEventHandler function in View class, which I > think could help me to solve the problem. In the svn/trunk version and 2.9.x series there is an View::removeEventHandler() implementation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Help: Using OSG To Build Tiled Display Wall
Hi, We are going to build our Tiled Display Wall (TDW) system. Is there any material about employing OSG to do so or to perform distributed rendering? Do I have to code a lot by using OSG APIs, or there are already some modules/frameworks to achieve this? You help will be appreciated. -- Jie Liu Visualization Research Group Center for Information Science, School of EECS, Room 2104, Science Building No.2, Peking University, Beijing 100871, China ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Remote execution and OSG
HI Paul, J.P, et. al, On Fri, May 15, 2009 at 8:56 AM, J.P. Delport wrote: > Not sure, but it looks like some code ignores the $DISPLAY setting and just > tries to open :0.0. > > I can confirm that I get the same behaviour between two Debian machines: > osgviewer cow.osg runs at a staggering 2fps > > osgkeyboardmouse fails with: > No protocol specified > Error: Unable to open display ":0.0". > Error: unable to create graphics window. The GraphicsContext::Traits structure is used to control how the graphics window is created, and in it's default state the display and screen settings (see osg::GraphicsContext::ScreenIndentifier) are 0:0. To override this default one needs to explictly call readDISPLAY() which reads the DISPLAY env variable to set the display and screen number. Now the osgView::setUpView*() methods all call readDISPLAY(), but if the example does use on of these methods, and instead creates the GraphicsWindow it requires directly use GraphicsContext::Traits without calling the readDISPLAY then it won't pick up your settings of this variable, so you'll get different behavior. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
HI Pierre, On Fri, May 15, 2009 at 8:24 AM, Pierre Bourdin (gmail) wrote: > For the --terrain option, it works also very well, but I have to disable > GL_ARB extension with my ATI otherwise it crashes. Could you try the OSG-2.8 or svn/trunk version of the OSG as there is crash fix that prevents problems with rendering VPB --terrain databases. The case of the crash was an bug in the set up of the VBO's, the ATI driver crashes if you put a VBO inside a display list. It was a bug putting the VBO's inside a display list so once this was fixed the crash went away. The ATI driver is still a bit buggy, but at least it's now working well with VPB terrain databases. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi Mao, On Fri, May 15, 2009 at 4:09 AM, Mao wrote: > 3. The last question is when applied with “--Terrain” or > “—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate both > texture and DEM data into one output file? And it seems that > osg::HeightField does not provide height = getHieghtAt(terrain.x, terrain.y) > method. --terrain will soon be the dafault for VirtualPlanetBuilder. When you output to a .ive then both the height fields and the texture will be stored together, when you select .osg as ouput the height fields will be stored in the .osg files, and the textures as external imagery tiles. As to why you aren't see a texture I cannot say. You really don't provide enough information to even guess what might be up. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: Using OSG To Build Tiled Display Wall
Hi Jie, On Fri, May 15, 2009 at 9:22 AM, Joe L wrote: > We are going to build our Tiled Display Wall (TDW) system. What dimensions? > Is there any material about employing OSG to do so or to perform distributed > rendering? > > Do I have to code a lot by using OSG APIs, or there are already some > modules/frameworks to achieve this? If you are using a cluster then a 3rd party library like VR Juggler or Equalizer is probably worth looking at. You could do the clustering yourself, but this will be more work. If you can drive the system entirely from one machine then you'll be able to just use the OSG's native multiple context/multi-threaded support built into osgVIewer. In terms of software and hardware this will be the most straight forward solution. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric wrote: > I do not understand why we only update the projectionOffset from the slave > camera and why we don't update the projection matrix itself. The slave uses a relative reference frame the camera's projection matrix is update on each new frame by multiplying the master's camer's projection matrix by the projection offset matrix of the slave. So there isn't any point modifying the slave's projection matrix as it'll be overritten anyway. In your example I wonder if the problem is down to your have two camera's, and master camera that is assigned to the graphics window so gets resized, and a slave camera that gets assigned to the also gets it's offset resized, putting these two resizes together you'll end up with a double resize. Could you changing you example so that the you have the viewer's master camera (not assigned to the graphics context) , then two slave cameras to see if it works fine. In terms of catching this particular usage model in the resize code... it's a bit awkward, if the master camera to a slave has been resized and the slave has a relative reference frame then it shouldn't be resized. This only works if the master camera shares the same graphics context, if it doesn't then you'll be a bit stuck as you'd have to apply the inverse of the master's projection matrix's resizing to the slaves. Perhaps this could be done by the resize code detecting a master/slave set up where double resizes are present, and then have inverse of the resizes to the master pass down to the slave. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions]osgParticle ParticleSystemandModularEmitterin different coordinate systems
Hi, Sorry to have dropped this on the floor; I missed your response below. I took a look at your examples, especially the one that is now broken. I see that what you were doing is quite similar to what the September patch does: construct a frame of reference for the ModularEmitter that is relative to ParticleSystem frame, even though it is rooted to the global frame in the scene graph. You end up doing the particle creation calculations in a frame that doesn't blow out float precision. The September code makes the assumption that the ModularEmitter and ParticleSystem are both in "real" coordinate frames, which seems reasonable to me. Both our methods require that the ParticleSystem be placed and moved to avoid precision errors. In FlightGear I manually change the coordinates of the particles when the ParticleSystem is moved. I suppose you might be able to get around this in some situations by playing with the velocity vector of the emitted particles, but I like my approach better because the ModularEmitter does not need to be managed; it can simply be attached to the object from which the particles are emitted. I recommend that you attach the ModularEmitter to your model. Jolley, Thomas P wrote: > So, where does that leave us? What breaks by reverting the September > changes on ModularEmitter.cpp? Do you have an example of your usage? > > Traversing the hierarchy to get double precision world matrices and > applying it to single precision particle systems causes precision > problems for my usage. Reverting the change helps me. One of the changes I made was to do the emitter particle placement calculations in double precision. In any case, someone has to manage the particle system so that the results will fit in single precision variables. Tim > > > Tom Jolley > > >> -Original Message- >> From: Tim Moore >> FYI, my change wasn't intended to solve particle precision >> problems by itself, merely support an approach where the >> particle system is not rooted in the world frame of >> reference. Application management of the particle system >> transform is still needed. Before my submission that seemed >> to be broken. >> >> Tim >> > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas for glow effects on 3D objects
Or you could just use a billboard glow texture, disable depth sorting and testing and render the glowing billboard last on top of everything else. This is the way we used to do it when we had no shaders and post processing Dimi - Original Message From: Art Tevs To: osg-users@lists.openscenegraph.org Sent: Friday, May 15, 2009 1:05:11 AM Subject: Re: [osg-users] Ideas for glow effects on 3D objects Hi Paul, as other Paul said, take a look into osgPPU. There I have an example showing exactly what you need. The example is simple and very easy to understand. You can take this as a starting point and then change it for your needs. Cheers, Art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12159#12159 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: Using OSG To Build Tiled Display Wall
Hi Robert, Thanks for you quick reply. In our plan, the TDW will have around 30 displays. Indeed, we have tried other solutions based on a smaller system ( 6 displays contained ). Do you mean that : If I would like to use OSG, I will have to additionally do the task management, network synchronization, and distributed rendering? Thanks 2009/5/15 Robert Osfield > Hi Jie, > > On Fri, May 15, 2009 at 9:22 AM, Joe L wrote: > > We are going to build our Tiled Display Wall (TDW) system. > > What dimensions? > > > Is there any material about employing OSG to do so or to perform > distributed > > rendering? > > > > Do I have to code a lot by using OSG APIs, or there are already some > > modules/frameworks to achieve this? > > If you are using a cluster then a 3rd party library like VR Juggler or > Equalizer is probably worth looking at. You could do the clustering > yourself, but this will be more work. > > If you can drive the system entirely from one machine then you'll be > able to just use the OSG's native multiple context/multi-threaded > support built into osgVIewer. In terms of software and hardware this > will be the most straight forward solution. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Jie Liu Visualization Research Group Center for Information Science, School of EECS, Room 2104, Science Building No.2, Peking University, Beijing 100871, China ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Robert, thank you for answering me but i'm confused I don't really understand what you want me to do on my example ? In fact the problem is that resizedImplementation function is called 1 time, then there is a loop on _cameras vector (filled with 2 cameras in my example, the main and the slave). During this loop, the projection is updated for the main camera then the offset projection is updated for the slave camera. After resizedImplementation function is finished, there is a call to void View::updateSlave(unsigned int i) function wich update my slave camera projection by multiplying the main camera projection matrix (wich is already updated) by the offset projection computed earlier. So the projection matrix from the slave camera is different from the main camera projection matrix. I hope I'm clear, but seems to me that it's very important to correct that. If it's help I achieve to avoid the weird behaviour by replacing in GraphicsContext.cpp : if (slave && camera->getReferenceFrame()==osg::Transform::RELATIVE_RF) { switch(view->getCamera()->getProjectionResizePolicy()) { case(osg::Camera::HORIZONTAL): slave->_projectionOffset *= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break; case(osg::Camera::VERTICAL): slave->_projectionOffset *= osg::Matrix::scale(1.0, aspectRatioChange,1.0); break; default: break; } } *by * if (slave && camera->getReferenceFrame()==osg::Transform::RELATIVE_RF) { switch(view->getCamera()->getProjectionResizePolicy()) { case(osg::Camera::HORIZONTAL): slave->_camera->getProjectionMatrix() *= osg::Matrix::scale(1.0/aspectRatioChange,1.0,1.0); break; case(osg::Camera::VERTICAL): slave->_camera->getProjectionMatrix() *= osg::Matrix::scale(1.0, aspectRatioChange,1.0); break; default: break; } } 2009/5/15 Robert Osfield > Hi Alexandre, > > > On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric > wrote: > > I do not understand why we only update the projectionOffset from the > slave > > camera and why we don't update the projection matrix itself. > > The slave uses a relative reference frame the camera's projection > matrix is update on each new frame by multiplying the master's camer's > projection matrix by the projection offset matrix of the slave. So > there isn't any point modifying the slave's projection matrix as it'll > be overritten anyway. > > In your example I wonder if the problem is down to your have two > camera's, and master camera that is assigned to the graphics window so > gets resized, and a slave camera that gets assigned to the also gets > it's offset resized, putting these two resizes together you'll end up > with a double resize. > > Could you changing you example so that the you have the viewer's > master camera (not assigned to the graphics context) , then two slave > cameras to see if it works fine. > > In terms of catching this particular usage model in the resize code... > it's a bit awkward, if the master camera to a slave has been resized > and the slave has a relative reference frame then it shouldn't be > resized. This only works if the master camera shares the same > graphics context, if it doesn't then you'll be a bit stuck as you'd > have to apply the inverse of the master's projection matrix's resizing > to the slaves. > > Perhaps this could be done by the resize code detecting a master/slave > set up where double resizes are present, and then have inverse of the > resizes to the master pass down to the slave. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: Using OSG To Build Tiled Display Wall
Hi Joe? Jie, could you please sign with your first name so I know which one to use when addressing you rather than having to do a best guess, thanks, On Fri, May 15, 2009 at 10:41 AM, Joe L wrote: > In our plan, the TDW will have around 30 displays. OK, you'll definitely need a cluster for this. > Do you mean that : > If I would like to use OSG, I will have to additionally do the task > management, network synchronization, and distributed rendering? The OSG doesn't provide this cluster manage functionality, it's focused on rendering on a single image system, albeit with capabilities of doing multi-thread, multi-screen output. The two options you have right now are to go with a distributed GL implementation such as Chromium, or a distribution application implementation such as facilitated by libs like Equalizer. There is a third possible solution would require mods to the core OSG, or at least subclasses from it, and is something I've been wondering about for a while. The approach would be to do a distributed render graph, where you do a cull traversal (or several cull traversal) on the master for the whole view frustum that gives you a list of drawables, modelview+projection matrices and state inheritance graph, then you broad cast this list to slaves on the cluster. These then traverse this rendering graph and cull out what leaves aren't in their local view frustum. On each slave you'd cache the state and geometry and update this only when the master changes their value, to avoid having to dispatch all this data on each new frame. The distributed render graph proposal above sits between the low level distributed GL approach and the high level distributed application approach like done with Equalizer. The distributed GL approach requires more network and CPU bandwidth, most doesn't require any application modifications to do the cluster, while the distributed application approach minimizes network bandwidth but does require you to design your application with the cluster in mind. The later approach is more work, but provides better scalability. The distributed render graph approach has the potentially of scaling reasonable well, while at the same time need little more than a cluster specific cluster configuration being used in the viewer, so once you have this inbuilt capability it's would be easy to move from a single desktop display to a cluster by just changing a viewer configuration file. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric wrote: > Hi Robert, > > thank you for answering me but i'm confused I don't really understand what > you want me to do on my example ? Make it work like the original osgwindows example - use two slave cameras rather than one master and one slave. I have lots of other work to do, and I'm really not well so can't take on extra work, please try out my suggestions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi All, After a long delay - health, submissions backlog and other work all got in the way of a quick turn around on this rc4, I've finally got tagging OpenScenGraph-2.8.1-rc4. You can download it from: http://www.openscenegraph.org/projects/osg/wiki/Downloads Please test. If things go smoothly with testing today and over the weekend I'll go for the final 2.8.1 release early next week. Please post your successes/failures to this thread. Thanks in advance with you help on testing on as many machines and OS combinations that you can lay your hands on. Robert. -- Change Log since 2.8.0 2009-05-14 17:26 robert * NEWS.txt, README.txt: Updated dates 2009-05-14 17:25 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHOR file 2009-05-14 17:18 robert * applications/osgversion/CMakeLists.txt, applications/osgversion/Contributors.cpp, applications/osgversion/osgversion.cpp: Moved the Contributors generation code out into a separate source file that is only compiled when OSG_MAINTAINER is enable via ccamke. This has been done to prevent build issues on some machines with compilers that chose a different local to the one that the contributors names are encoded. 2009-05-13 08:35 robert * src/OpenThreads/win32, src/OpenThreads/win32/Win32Thread.cpp: From Thibault Genessay, "On Windows, when a process tries to spawn one too many thread, _beginthreadex() fails but OpenThreads still waits on the startup Block before returning to the caller of OpenThreads::Thread::start(). This causes a deadlock. The return value of _beginthreadex() is actually checked, but after the call to OpenThreads::Block::block() so it is basically useless. Attached is a fix to move the check for the return value of _beginthreadex() before the call to block(), so that start() can return to the caller with a non-zero error code. This solves the problem for me." Merged from svn trunk using: svn merge -r 10190:10191 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/OpenThreads/win32 2009-05-12 11:15 robert * ChangeLog, NEWS.txt, README.txt: Updated ChangeLog and NEWS/READER for release candidate 2009-05-12 11:12 robert * src/osgWrappers/osgUtil/IntersectVisitor.cpp: Updated wrappers 2009-05-12 10:49 robert * src/osgWidget, src/osgWidget/WindowManager.cpp: From Fajran Iman Rusadi, fixed to handling of widget indices in insert and remove methods. Merged from svn/trunk using: svn merge -r 10181:10182 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgWidget 2009-05-08 12:38 robert * src/osgViewer/GraphicsWindowWin32.cpp: Added initializer for _mouseCursor 2009-05-08 07:49 robert * src/osgViewer/GraphicsWindowWin32.cpp: From Neil Groves, fixed unitialized variable 2009-05-07 15:59 robert * CMakeLists.txt: Updated release candidate to 4. 2009-05-07 15:14 robert * src/osgViewer/GraphicsWindowWin32.cpp: From Frederic Bouvier, workaround of setCursor problems under Windows. 2009-05-07 14:58 robert * src/osg/GraphicsContext.cpp: Fixed ABSOLUTE_RF slave camera resize policy, merged from svn trunk using: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/ 2009-05-07 13:24 robert * src/osgDB, src/osgDB/CMakeLists.txt, src/osgDB/DatabasePager.cpp, src/osgDB/Registry.cpp: From Stephan Huber, "while debugging a problem in finding plugins on OS X I discovered, that the conditional directives for setting the prepend-string in createLibraryNameForExtension were not in effect, because of the mixture of different #ifdef styles. I removed the conditional part for __APPLE__ completely to be more standard-conform with other platforms (plugins should be located in osgPlugins-X.X.X/). Because of the wrong syntax of the conditional compile the old code was not used anyway -- so no functional change. " Merged from svn/trunk using: svn merge -r 10149:10150 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgDB 2009-05-07 13:18 robert * src/osgViewer, src/osgViewer/GraphicsWindowWin32.cpp: From Chris Denham, fix for swapBuffers warning when window is minimized under Windows. svn merge -r 10146:10147 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgViewer/ 2009-05-07 09:47 robert * src/osgPlugins/pdf,
Re: [osg-users] resizedImplementation bug when resizing slave camera
When using 2 slave cameras instead of 1 main calera and 1 slave camera the resizing works perfectly. I was thinking that the viewer had to have 1 main camera and n slave camera, I was mistaken. I have one last question, when we call getCameraWithFocus on a viewer set up with 2 slaves camera and no main camera, wich one is returned ? Thank you for your support and I wish you a good recovery. 2009/5/15 Robert Osfield > HI Alexandre, > > On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric > wrote: > > Hi Robert, > > > > thank you for answering me but i'm confused I don't really understand > what > > you want me to do on my example ? > > Make it work like the original osgwindows example - use two slave > cameras rather than one master and one slave. > > I have lots of other work to do, and I'm really not well so can't take > on extra work, please try out my suggestions. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Hi! jojo wrote: > As I understand, the command camera->attach(osg::Camera::COLOR_BUFFER, > depth.get(),0,0); tells osg, that I want the color buffer of the camera to be > stored in the image depth. This works, but when I change it to > camera->attach(osg::Camera::DEPTH_BUFFER, depth.get(),0,0); I get the same > result. A colored picture. > > Regards, > jojo I've read your post with great interest! I work with the COLOR_BUFFER (for now...) and I've a question for you. I tried to reproduce your code in mine (thus I don't exactly do the same things) and it seems my _depth image (that I use to store colors...) is initialized at allocationImage but the buffer data is never refreshed. I tried: Code: _depth->allocateImage(vec->x(), vec->y(), 1, GL_COLOR, GL_INT); and Code: _depth->allocateImage(vec->x(), vec->y(), 1, GL_RGBA, GL_INT); Is there any instruction to do that that I skiped? Thanks! Max -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12203#12203 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Hi Max, I think you should use _depth->allocateImage(vec->x(), vec->y(), 1, GL_RGBA, GL_UNSIGNED_BYTE); instead of GL_INT because the color buffer of your graphics card has 8 bit per color channel. Regards, jojo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12205#12205 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: Using OSG To Build Tiled Display Wall
Hi, an interesting approach for a distributed rendering system is FlowVR... http://flowvr.sourceforge.net/ I know openscenegraph has been used with Delta3D team with CIGI Image Generator: http://cigi.sourceforge.net/ To not only advertise for concurrent project ;-) Pierre. Le vendredi 15 mai 2009 à 10:56 +0100, Robert Osfield a écrit : > Hi Joe? Jie, could you please sign with your first name so I know > which one to use when addressing you rather than having to do a best > guess, thanks, > > On Fri, May 15, 2009 at 10:41 AM, Joe L wrote: > > In our plan, the TDW will have around 30 displays. > > OK, you'll definitely need a cluster for this. > > > Do you mean that : > > If I would like to use OSG, I will have to additionally do the task > > management, network synchronization, and distributed rendering? > > The OSG doesn't provide this cluster manage functionality, it's > focused on rendering on a single image system, albeit with > capabilities of doing multi-thread, multi-screen output. > > The two options you have right now are to go with a distributed GL > implementation such as Chromium, or a distribution application > implementation such as facilitated by libs like Equalizer. > > There is a third possible solution would require mods to the core OSG, > or at least subclasses from it, and is something I've been wondering > about for a while. The approach would be to do a distributed render > graph, where you do a cull traversal (or several cull traversal) on > the master for the whole view frustum that gives you a list of > drawables, modelview+projection matrices and state inheritance graph, > then you broad cast this list to slaves on the cluster. These then > traverse this rendering graph and cull out what leaves aren't in their > local view frustum. On each slave you'd cache the state and geometry > and update this only when the master changes their value, to avoid > having to dispatch all this data on each new frame. > > The distributed render graph proposal above sits between the low level > distributed GL approach and the high level distributed application > approach like done with Equalizer. The distributed GL approach > requires more network and CPU bandwidth, most doesn't require any > application modifications to do the cluster, while the distributed > application approach minimizes network bandwidth but does require you > to design your application with the cluster in mind. The later > approach is more work, but provides better scalability. > > The distributed render graph approach has the potentially of scaling > reasonable well, while at the same time need little more than a > cluster specific cluster configuration being used in the viewer, so > once you have this inbuilt capability it's would be easy to move from > a single desktop display to a cluster by just changing a viewer > configuration file. > > Robert. > ___ > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: Using OSG To Build Tiled Display Wall
Hi, I am currently thinking about how to do a multi-display simulation with OSG that uses a single machine to feed all displays. The app I am currently working on requires multiple views, but is difficult to distribute across machines because of some randomness components in my graphics stuff. My simulation requires at least four projectors (or eight if necessary and possible). I am thinking about using a Nvidia Quadro Plex system http://www.nvidia.de/page/quadroplex.html. Has anyone here used heavy-duty graphics hardware to feed four or more views from one machine? What hardware setup do you use, and are you able to render reasonably complex scenes? Or can you point me in a good direction for more info? Looking forward to your responses - Martin[/url] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12206#12206 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Thanks. I tried but it does'nt change the results. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12208#12208 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
I have to install OpenSceneGraph on a RHEL 3.2 system. I used cmake 2.6.3 to setup the make system and started to compile. I got the error given below. What can be done to fix this? [ 0%] Building CXX object src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++:53: declaration of `int* __errno_location()' throws different exceptions /usr/include/bits/errno.h:38: than previous declaration `int* __errno_location() throw ()' make[2]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o] Error 1 make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] Error 2 make: *** [all] Error 2 *** The /usr/include/bits/errno.h file is given below with line 38 highlighted. /* Error constants. Linux specific version. Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ #ifdef _ERRNO_H # undef EDOM # undef EILSEQ # undef ERANGE # include /* Linux has no ENOTSUP error code. */ # define ENOTSUP EOPNOTSUPP /* Linux also had no ECANCELED error code. Since it is not used here we define it to an invalid value. */ # ifndef ECANCELED # define ECANCELED 125 # endif # ifndef __ASSEMBLER__ /* Function to get address of global `errno' variable. */ *extern int *__errno_location (void) __THROW __attribute__ ((__const__));* # if !defined _LIBC || defined _LIBC_REENTRANT /* When using threads, errno is a per-thread value. */ # define errno (*__errno_location ()) # endif # endif /* !__ASSEMBLER__ */ #endif /* _ERRNO_H */ #if !defined _ERRNO_H && defined __need_Emath /* This is ugly but the kernel header is not clean enough. We must define only the values EDOM, EILSEQ and ERANGE in case __need_Emath is defined. */ # define EDOM 33 /* Math argument out of domain of function. */ # define EILSEQ 84 /* Illegal byte sequence. */ # define ERANGE 34 /* Math result not representable. */ #endif /* !_ERRNO_H && __need_Emath */ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with FBOs when taking high resolution screenshots.
Hi again, I'm now doing a check for the maximum texture size and clamping the screenshot size to be no greater than that. I have now found a new problem in that I can't always take a screenshot at the maximum resolution. This seems to be dependent on the complexity of the loaded scene graph, so I'm guessing at a video memory error. The behavior is that for a given (high, as in 8192x6000) resolution I get the correct image with a simple model, but I'm getting a black image when taking a screenshot of a complex model. I have a vague recollection that I saw something about being able to check if the FBO is correctly allocated and ready before using it, but after quite a bit of searching I haven't been able to find it again. If anyone knows if this is easily checkable I would much appreciate a pointer in the right direction. Regards, and thank. Jesper D. Thomsen From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay [jean-sebastien.g...@cm-labs.com] Sent: Thursday, May 14, 2009 4:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problems with FBOs whentaking high resolution screenshots. Hello Jesper, > Thank you very much, I suspected it was something like that. Do you know if > there another standard way of making high resolution renderings via OSG that > isn't hit by the graphics card texture size limitations? You can do tiling - take multiple screenshots, each using the maximum size the video card supports, using appropriate camera positions that, once assembled together into one image, will give you the complete image. Using slave cameras in an osgViewer::View can help with this, and you can have a look at osgViewer::View::setUpViewAcrossAllScreens() for inspiration on how to set up those slave cameras. > Otherwise I'll just have to implement the checking mechanism you gave me and > limit the maximum size for the less capable graphics cards. That could be a good first step. Hope this helps, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Hi, I think you should use GL_LUMINANCE instead of GL_RGBA too. Best regards Raymond Johannes Leidheiser wrote: Hi Max, I think you should use _depth->allocateImage(vec->x(), vec->y(), 1, GL_RGBA, GL_UNSIGNED_BYTE); instead of GL_INT because the color buffer of your graphics card has 8 bit per color channel. Regards, jojo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12205#12205 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi, Following method is from ive plugin, ReaderWriterIVE.cpp. Is #if 1 forgotten here? In some other methods ive::Exception is caught within the plugin. In this method, however, the exception goes out of the plugin and has to be handled in the application. virtual ReadResult readNode(std::istream& fin, const Options* options) const { #if 1 ive::DataInputStream in(&fin, options); return in.readNode(); #else try{ // Create datainputstream. ive::DataInputStream in(&fin, options); return in.readNode(); } catch(ive::Exception e) { return e.getError(); } #endif } tugkan Hi All, After a long delay - health, submissions backlog and other work all got in the way of a quick turn around on this rc4, I've finally got tagging OpenScenGraph-2.8.1-rc4. You can download it from: http://www.openscenegraph.org/projects/osg/wiki/Downloads Please test. If things go smoothly with testing today and over the weekend I'll go for the final 2.8.1 release early next week. Please post your successes/failures to this thread. Thanks in advance with you help on testing on as many machines and OS combinations that you can lay your hands on. Robert. -- Change Log since 2.8.0 2009-05-14 17:26 robert * NEWS.txt, README.txt: Updated dates 2009-05-14 17:25 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHOR file 2009-05-14 17:18 robert * applications/osgversion/CMakeLists.txt, applications/osgversion/Contributors.cpp, applications/osgversion/osgversion.cpp: Moved the Contributors generation code out into a separate source file that is only compiled when OSG_MAINTAINER is enable via ccamke. This has been done to prevent build issues on some machines with compilers that chose a different local to the one that the contributors names are encoded. 2009-05-13 08:35 robert * src/OpenThreads/win32, src/OpenThreads/win32/Win32Thread.cpp: From Thibault Genessay, "On Windows, when a process tries to spawn one too many thread, _beginthreadex() fails but OpenThreads still waits on the startup Block before returning to the caller of OpenThreads::Thread::start(). This causes a deadlock. The return value of _beginthreadex() is actually checked, but after the call to OpenThreads::Block::block() so it is basically useless. Attached is a fix to move the check for the return value of _beginthreadex() before the call to block(), so that start() can return to the caller with a non-zero error code. This solves the problem for me." Merged from svn trunk using: svn merge -r 10190:10191 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/OpenThreads/win32 2009-05-12 11:15 robert * ChangeLog, NEWS.txt, README.txt: Updated ChangeLog and NEWS/READER for release candidate 2009-05-12 11:12 robert * src/osgWrappers/osgUtil/IntersectVisitor.cpp: Updated wrappers 2009-05-12 10:49 robert * src/osgWidget, src/osgWidget/WindowManager.cpp: From Fajran Iman Rusadi, fixed to handling of widget indices in insert and remove methods. Merged from svn/trunk using: svn merge -r 10181:10182 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgWidget 2009-05-08 12:38 robert * src/osgViewer/GraphicsWindowWin32.cpp: Added initializer for _mouseCursor 2009-05-08 07:49 robert * src/osgViewer/GraphicsWindowWin32.cpp: From Neil Groves, fixed unitialized variable 2009-05-07 15:59 robert * CMakeLists.txt: Updated release candidate to 4. 2009-05-07 15:14 robert * src/osgViewer/GraphicsWindowWin32.cpp: From Frederic Bouvier, workaround of setCursor problems under Windows. 2009-05-07 14:58 robert * src/osg/GraphicsContext.cpp: Fixed ABSOLUTE_RF slave camera resize policy, merged from svn trunk using: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/ 2009-05-07 13:24 robert * src/osgDB, src/osgDB/CMakeLists.txt, src/osgDB/DatabasePager.cpp, src/osgDB/Registry.cpp: From Stephan Huber, "while debugging a problem in finding plugins on OS X I discovered, that the conditional directives for setting the prepend-string in createLibraryNameForExtension were not in effect, because of the mixture of different #ifdef styles. I removed the conditional part for __APPLE__ completely to be more standard-conform with other platforms (plugins should be located in osgPlugins-X.X.X/). Because of the wrong syntax of the conditional compile the old code wa
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
I commented out line 53 in OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++ and the compilation continued to the following error: [ 34%] Building CXX object src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o In file included from /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/LightSpacePerspectiveShadowMap:23, from /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgShadow/LightSpacePerspectiveShadowMap.cpp:18: /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique: In member function `virtual osgShadow::ViewDependentShadowTechnique::ViewData* osgShadow::ProjectionShadowMap::initViewDependentData(osgUtil::CullVisitor*, osgShadow::ViewDependentShadowTechnique::ViewData*)': /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique:152: ` struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ProjectionShadowMap:77: within this context /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique:152: ` struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ProjectionShadowMap:77: within this context make[2]: *** [src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o] Error 1 make[1]: *** [src/osgShadow/CMakeFiles/osgShadow.dir/all] Error 2 make: *** [all] Error 2 On Fri, May 15, 2009 at 1:38 PM, John Ivar Haugland wrote: > I have to install OpenSceneGraph on a RHEL 3.2 system. I used cmake 2.6.3 > to setup the make system and started to compile. I got the error given > below. What can be done to fix this? > > [ 0%] Building CXX object > src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++:53: > declaration > of `int* __errno_location()' throws different exceptions > /usr/include/bits/errno.h:38: than previous declaration `int* > __errno_location() throw ()' > make[2]: *** > [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o] Error 1 > make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] > Error 2 > make: *** [all] Error 2 > > *** > The /usr/include/bits/errno.h file is given below with line 38 > highlighted. > > /* Error constants. Linux specific version. > Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc. > This file is part of the GNU C Library. > > The GNU C Library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > The GNU C Library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with the GNU C Library; if not, write to the Free > Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA > 02111-1307 USA. */ > > #ifdef _ERRNO_H > > # undef EDOM > # undef EILSEQ > # undef ERANGE > # include > > /* Linux has no ENOTSUP error code. */ > # define ENOTSUP EOPNOTSUPP > > /* Linux also had no ECANCELED error code. Since it is not used here > we define it to an invalid value. */ > # ifndef ECANCELED > # define ECANCELED 125 > # endif > > # ifndef __ASSEMBLER__ > /* Function to get address of global `errno' variable. */ > *extern int *__errno_location (void) __THROW __attribute__ ((__const__));* > > # if !defined _LIBC || defined _LIBC_REENTRANT > /* When using threads, errno is a per-thread value. */ > # define errno (*__errno_location ()) > # endif > # endif /* !__ASSEMBLER__ */ > #endif /* _ERRNO_H */ > > #if !defined _ERRNO_H && defined __need_Emath > /* This is ugly but the kernel header is not clean enough. We must > define only the values EDOM, EILSEQ and ERANGE in case __need_Emath is > defined. */ > # define EDOM 33 /* Math argument out of domain of function. */ > # define EILSEQ 84 /* Illegal byte sequence. */ > # define ERANGE 34 /* Math result not representable. */ > #endif /* !_ERRNO_H && __need_Emath */ > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] iv file not being read
Did you build or install one of the required 3rd Part libraries fro the Inventor plug-in ? ( see OSG281\src\osgPlugins\Inventor\README.txt) Also did increase the OSG Notify level to debug to see what OSG may be telling you about the issue ? And the other normal debug technique did you step in to the OSG code to see where its failing on the read ? Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mattias Helsing Sent: Friday, May 15, 2009 3:11 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [build] iv file not being read Hello Abhinav, There is nothing for anyone to go on to even try to help you. The code snippet is not even osg code so no chance for us to know anything about what it does. * use a debugger to see what "readAll" returns and why * crank up OSG_NOTIFY_LEVEL * see Paul Martz top 10 debugging tips at http://www.skew-matrix.com/bb/viewtopic.php?f=6&t=5 cheers Mattias On 5/15/09, Abhinav Dubey wrote: > Hi, > i am trying to read an iv file but its not being read. the code i am > using is : > *** > SoInput sceneInput; > if ( !sceneInput.openFile( "plugins\\graphs\\myInventor.iv" ) ) { > QMessageBox::information(mInventorGrid[3], "Error", "Cannot > open file requested iv file"); > return; > } > > SoSeparator *sc_root = SoDB::readAll( &sceneInput ); >sc_root->ref(); > > Use one of the convenient SoQt viewer classes. > mViewer = new SoQtExaminerViewer(iv_widget); > mViewer->setSceneGraph(sc_root); > mViewer->setDecoration(false); > mViewer->show(); > *** > and the iv file named myInventor.iv has the following: > #Inventor V2.1 ascii > > Separator { > SoXipExaminer { > modeNONE > viewBoundingBox 230 0 0 0 > 0 227.785 0 0 > 0 0 42.1032 0 > -112.59 -117.21 50.3972 1 > complexity Complexity { > value 0.5 > textureQuality 0.5 > } > > orthoCamera DEF +0 OrthographicCamera { > } > > perspectiveCamera DEF +1 PerspectiveCamera { > position0.181952 88.5125 454.632 > orientation -0.494995 0.0901597 0.864206 0.470889 > nearDistance230.823 > farDistance 557.256 > focalDistance 394.04 > heightAngle 0.785398 > } > > borderNode SoXipViewportBorder { > fields [ SFColor activeColor, SFColor inactiveColor, ] > activeColor 0.7 0.7 0.7 > inactiveColor 0.7 0.7 0.7 > } > > cameraSwitchSwitch { > whichChild 1 > USE +0 > USE +1 > } > > } > SoXipLut { > fields [ SFEnum inputMode, SFEnum outputMode, SFShort bitsUsed, > SFFloat rampWidth, > SFFloat rampCenter, MFColor arrayColor, MFFloat arrayAlpha ] > inputMode TRAPEZOID > outputMode COLOR > bitsUsed12 > rampWidth 0.05 > rampCenter 0.009 > arrayColor [ ] > arrayAlpha [ ] > } > SoXipImage { > fields [ SoXipSFDataImage image ] > image "DATA" = > SoXipLoadDicom { > inputs [ MFString name ] > name"C:\Xip\examples\data\24884367.dcm" > outputs [ SoXipMFDataDicom dicom ] > } > . dicom > > } > } > *** > when i run the code it crashes at sc_Root.ref(); plz help me out ... > > > Thank you! > > Cheers, > Abhinav > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=12174#12174 > > > > > > ___ > 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightwave multilayered textures and vertex mapsupport?
Hi Olle, hasd to ask, as its scary how many folks don't even try to a basic thing like trying it first :( I have not worked directly with Lightwave for a long know, so I'm not user if the format has evolved, I don't remember see any major submissions for the format [ but that's no guarantee there was not : ) ] Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Olle Ekberg Sent: Friday, May 15, 2009 4:14 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Lightwave multilayered textures and vertex mapsupport? Hi Gordon I have tried and didn´t get it to work. I knew that it worked with multilayered textures before but i don´t know if it is Lightwave that have changed in their format or if the importer in OpenSceneGraph have changed. thanks /Olle -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12187#12187 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi John, Curious, this code has been in the OSG code for many many years and no one had tripped over it till now... In this case the extern in errno; line doesn't look like it's required at all. I've removed it and things still compare. I note from you follow up email this work for you too. I can only presume the line was due to a copy and paste from Sproc implementation that does use errno. This fix is now checked into the OSG-2.8 and svn/trunk. Robert. On Fri, May 15, 2009 at 12:38 PM, John Ivar Haugland wrote: > I have to install OpenSceneGraph on a RHEL 3.2 system. I used cmake 2.6.3 > to setup the make system and started to compile. I got the error given > below. What can be done to fix this? > > [ 0%] Building CXX object > src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++:53: > declaration > of `int* __errno_location()' throws different exceptions > /usr/include/bits/errno.h:38: than previous declaration `int* > __errno_location() throw ()' > make[2]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o] > Error 1 > make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] Error > 2 > make: *** [all] Error 2 > > *** > The /usr/include/bits/errno.h file is given below with line 38 highlighted. > > /* Error constants. Linux specific version. > Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc. > This file is part of the GNU C Library. > > The GNU C Library is free software; you can redistribute it and/or > modify it under the terms of the GNU Lesser General Public > License as published by the Free Software Foundation; either > version 2.1 of the License, or (at your option) any later version. > > The GNU C Library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > > You should have received a copy of the GNU Lesser General Public > License along with the GNU C Library; if not, write to the Free > Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA > 02111-1307 USA. */ > > #ifdef _ERRNO_H > > # undef EDOM > # undef EILSEQ > # undef ERANGE > # include > > /* Linux has no ENOTSUP error code. */ > # define ENOTSUP EOPNOTSUPP > > /* Linux also had no ECANCELED error code. Since it is not used here > we define it to an invalid value. */ > # ifndef ECANCELED > # define ECANCELED 125 > # endif > > # ifndef __ASSEMBLER__ > /* Function to get address of global `errno' variable. */ > extern int *__errno_location (void) __THROW __attribute__ ((__const__)); > > # if !defined _LIBC || defined _LIBC_REENTRANT > /* When using threads, errno is a per-thread value. */ > # define errno (*__errno_location ()) > # endif > # endif /* !__ASSEMBLER__ */ > #endif /* _ERRNO_H */ > > #if !defined _ERRNO_H && defined __need_Emath > /* This is ugly but the kernel header is not clean enough. We must > define only the values EDOM, EILSEQ and ERANGE in case __need_Emath is > defined. */ > # define EDOM 33 /* Math argument out of domain of function. */ > # define EILSEQ 84 /* Illegal byte sequence. */ > # define ERANGE 34 /* Math result not representable. */ > #endif /* !_ERRNO_H && __need_Emath */ > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
GL_LUMINANCE is for gray scale images. For example if you want to save the depth buffer. Besides you should post a little bit more code. I don't know how much experience your have with open scene graph. Maybe you didn't call the frame() method of your viewer, the camera is not attached to a node or maybe there is just nothing to see in the viewing frustum? Did you display the camera normaly which means with turned off offscreen rendering? Regards, Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12216#12216 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi Tugkan, Well spotted, this is just a debugging change that is no longer required so I've reverted to the old try version and checked in the change to svn/trunk. However, this debugging block only exits in the svn/trunk version of the OSG, not the OSG-2.8 branch, so 2.8.1-rc4 shouldn't have it in it. I presume you are using the svn/trunk or one of the 2.9.x series? Robert. On Fri, May 15, 2009 at 1:02 PM, Tugkan Calapoglu wrote: > Hi, > > Following method is from ive plugin, ReaderWriterIVE.cpp. Is #if 1 forgotten > here? In some other methods ive::Exception is caught within the plugin. In > this method, however, the exception goes out of the plugin and has to be > handled in the application. > > virtual ReadResult readNode(std::istream& fin, const Options* options) const > { > #if 1 > ive::DataInputStream in(&fin, options); > return in.readNode(); > #else > try{ > // Create datainputstream. > ive::DataInputStream in(&fin, options); > > return in.readNode(); > } > catch(ive::Exception e) > { > return e.getError(); > } > #endif > } > > > tugkan > >> Hi All, >> >> After a long delay - health, submissions backlog and other work all >> got in the way of a quick turn around on this rc4, I've finally got >> tagging OpenScenGraph-2.8.1-rc4. You can download it from: >> >> http://www.openscenegraph.org/projects/osg/wiki/Downloads >> >> Please test. If things go smoothly with testing today and over the >> weekend I'll go for the final 2.8.1 release early next week. Please >> post your successes/failures to this thread. >> >> Thanks in advance with you help on testing on as many machines and OS >> combinations that you can lay your hands on. >> Robert. >> >> -- Change Log since 2.8.0 >> >> 2009-05-14 17:26 robert >> >> * NEWS.txt, README.txt: Updated dates >> >> 2009-05-14 17:25 robert >> >> * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHOR file >> >> 2009-05-14 17:18 robert >> >> * applications/osgversion/CMakeLists.txt, >> applications/osgversion/Contributors.cpp, >> applications/osgversion/osgversion.cpp: Moved the Contributors >> generation code out into a separate source file that is only >> compiled when OSG_MAINTAINER is enable via ccamke. This has been >> done to prevent build issues on some machines with compilers that >> chose a different local to the one that the contributors names >> are encoded. >> >> 2009-05-13 08:35 robert >> >> * src/OpenThreads/win32, src/OpenThreads/win32/Win32Thread.cpp: >> From Thibault Genessay, "On Windows, when a process tries to >> spawn one too many thread, >> _beginthreadex() fails but OpenThreads still waits on the startup >> Block before returning to the caller of >> OpenThreads::Thread::start(). >> This causes a deadlock. The return value of _beginthreadex() is >> actually checked, but after the call to >> OpenThreads::Block::block() so >> it is basically useless. >> >> Attached is a fix to move the check for the return value of >> _beginthreadex() before the call to block(), so that start() can >> return to the caller with a non-zero error code. This solves the >> problem for me." >> >> Merged from svn trunk using: >> >> svn merge -r 10190:10191 >> >> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/OpenThreads/win32 >> >> 2009-05-12 11:15 robert >> >> * ChangeLog, NEWS.txt, README.txt: Updated ChangeLog and >> NEWS/READER for release candidate >> >> 2009-05-12 11:12 robert >> >> * src/osgWrappers/osgUtil/IntersectVisitor.cpp: Updated wrappers >> >> 2009-05-12 10:49 robert >> >> * src/osgWidget, src/osgWidget/WindowManager.cpp: From Fajran Iman >> Rusadi, fixed to handling of widget indices in insert and remove >> methods. Merged from svn/trunk using: >> >> svn merge -r 10181:10182 >> >> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgWidget >> >> 2009-05-08 12:38 robert >> >> * src/osgViewer/GraphicsWindowWin32.cpp: Added initializer for >> _mouseCursor >> >> 2009-05-08 07:49 robert >> >> * src/osgViewer/GraphicsWindowWin32.cpp: From Neil Groves, fixed >> unitialized variable >> >> 2009-05-07 15:59 robert >> >> * CMakeLists.txt: Updated release candidate to 4. >> >> 2009-05-07 15:14 robert >> >> * src/osgViewer/GraphicsWindowWin32.cpp: From Frederic Bouvier, >> workaround of setCursor problems under Windows. >> >> 2009-05-07 14:58 robert >> >> * src/osg/GraphicsContext.cpp: Fixed ABSOLUTE_RF slave camera >> resize policy, merged from svn trunk using: >> >> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/ >> >> 2009-05-07 13:24 robert >> >> * src/osgDB, src/osgDB/CMakeLists.txt, src/osgDB
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi John, The code is valid, but your compiler does seem to be tripping over the code which suggest a compile bug. Which version of gcc do you have on your system? Robert. On Fri, May 15, 2009 at 1:11 PM, John Ivar Haugland wrote: > I commented out line 53 in > OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++ > and the compilation continued to the following error: > > [ 34%] Building CXX object > src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o > In file included from > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/LightSpacePerspectiveShadowMap:23, > from > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgShadow/LightSpacePerspectiveShadowMap.cpp:18: > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique: > In > member function `virtual > osgShadow::ViewDependentShadowTechnique::ViewData* > osgShadow::ProjectionShadowMap > ShadowProjectionAlgorithmClass>::initViewDependentData(osgUtil::CullVisitor*, > osgShadow::ViewDependentShadowTechnique::ViewData*)': > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique:152: > ` > struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ProjectionShadowMap:77: > within > this context > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique:152: > ` > struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ProjectionShadowMap:77: > within > this context > make[2]: *** > [src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o] > Error 1 > make[1]: *** [src/osgShadow/CMakeFiles/osgShadow.dir/all] Error 2 > make: *** [all] Error 2 > > > On Fri, May 15, 2009 at 1:38 PM, John Ivar Haugland > wrote: >> >> I have to install OpenSceneGraph on a RHEL 3.2 system. I used cmake >> 2.6.3 to setup the make system and started to compile. I got the error given >> below. What can be done to fix this? >> >> [ 0%] Building CXX object >> src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o >> >> /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++:53: >> declaration >> of `int* __errno_location()' throws different exceptions >> /usr/include/bits/errno.h:38: than previous declaration `int* >> __errno_location() throw ()' >> make[2]: *** >> [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o] Error 1 >> make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] >> Error 2 >> make: *** [all] Error 2 >> >> *** >> The /usr/include/bits/errno.h file is given below with line 38 >> highlighted. >> >> /* Error constants. Linux specific version. >> Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc. >> This file is part of the GNU C Library. >> >> The GNU C Library is free software; you can redistribute it and/or >> modify it under the terms of the GNU Lesser General Public >> License as published by the Free Software Foundation; either >> version 2.1 of the License, or (at your option) any later version. >> >> The GNU C Library is distributed in the hope that it will be useful, >> but WITHOUT ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> Lesser General Public License for more details. >> >> You should have received a copy of the GNU Lesser General Public >> License along with the GNU C Library; if not, write to the Free >> Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA >> 02111-1307 USA. */ >> >> #ifdef _ERRNO_H >> >> # undef EDOM >> # undef EILSEQ >> # undef ERANGE >> # include >> >> /* Linux has no ENOTSUP error code. */ >> # define ENOTSUP EOPNOTSUPP >> >> /* Linux also had no ECANCELED error code. Since it is not used here >> we define it to an invalid value. */ >> # ifndef ECANCELED >> # define ECANCELED 125 >> # endif >> >> # ifndef __ASSEMBLER__ >> /* Function to get address of global `errno' variable. */ >> extern int *__errno_location (void) __THROW __attribute__ ((__const__)); >> >> # if !defined _LIBC || defined _LIBC_REENTRANT >> /* When using threads, errno is a per-thread value. */ >> # define errno (*__errno_location ()) >> # endif >> # endif /* !__ASSEMBLER__ */ >> #endif /* _ERRNO_H */ >> >> #if !defined _ERRNO_H && defined __need_Emath >> /* This is ugly but the kernel header is not clean enough. We must >> define only the values EDOM, EILSEQ and ERANGE in case __need_Emath is >> defined. */ >> # define EDOM 33 /* Math argument out of domain of function. */ >> # define EILSEQ 84 /* Illegal byte sequence. */ >> # define ERANGE 34 /* Math result not representable. */ >> #endif /
Re: [osg-users] light, normals
Hi, i wanna thank the two posters for clarifying which different approaches are possible for this issue, because problems like that weren't covered in the basic opengl books i have read. Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12220#12220 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
I moved the struct OSGSHADOW_EXPORT ViewData: public osg::Referenced from the protected to the public interface of the class ViewDependentShadowTechnique and the compilation continued 100%. ( I had to disable curl because of old version of it on RHEL3) On Fri, May 15, 2009 at 2:11 PM, John Ivar Haugland wrote: > I commented out line 53 in > OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++ > and the compilation continued to the following error: > > [ 34%] Building CXX object > src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o > In file included from > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/LightSpacePerspectiveShadowMap:23, > from > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgShadow/LightSpacePerspectiveShadowMap.cpp:18: > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique: > In >member function `virtual > osgShadow::ViewDependentShadowTechnique::ViewData* >osgShadow::ProjectionShadowMap > ShadowProjectionAlgorithmClass>::initViewDependentData(osgUtil::CullVisitor*, >osgShadow::ViewDependentShadowTechnique::ViewData*)': > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique:152: > ` >struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ProjectionShadowMap:77: > within >this context > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ViewDependentShadowTechnique:152: > ` >struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/include/osgShadow/ProjectionShadowMap:77: > within >this context > make[2]: *** > [src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o] > Error 1 > make[1]: *** [src/osgShadow/CMakeFiles/osgShadow.dir/all] Error 2 > make: *** [all] Error 2 > > > On Fri, May 15, 2009 at 1:38 PM, John Ivar Haugland < > john.haugl...@gmail.com> wrote: > >> I have to install OpenSceneGraph on a RHEL 3.2 system. I used cmake >> 2.6.3 to setup the make system and started to compile. I got the error given >> below. What can be done to fix this? >> >> [ 0%] Building CXX object >> src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o >> /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/OpenThreads/pthreads/PThread.c++:53: >> declaration >> of `int* __errno_location()' throws different exceptions >> /usr/include/bits/errno.h:38: than previous declaration `int* >> __errno_location() throw ()' >> make[2]: *** >> [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/PThread.o] Error 1 >> make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] >> Error 2 >> make: *** [all] Error 2 >> >> *** >> The /usr/include/bits/errno.h file is given below with line 38 >> highlighted. >> >> /* Error constants. Linux specific version. >> Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc. >> This file is part of the GNU C Library. >> >> The GNU C Library is free software; you can redistribute it and/or >> modify it under the terms of the GNU Lesser General Public >> License as published by the Free Software Foundation; either >> version 2.1 of the License, or (at your option) any later version. >> >> The GNU C Library is distributed in the hope that it will be useful, >> but WITHOUT ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> Lesser General Public License for more details. >> >> You should have received a copy of the GNU Lesser General Public >> License along with the GNU C Library; if not, write to the Free >> Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA >> 02111-1307 USA. */ >> >> #ifdef _ERRNO_H >> >> # undef EDOM >> # undef EILSEQ >> # undef ERANGE >> # include >> >> /* Linux has no ENOTSUP error code. */ >> # define ENOTSUP EOPNOTSUPP >> >> /* Linux also had no ECANCELED error code. Since it is not used here >> we define it to an invalid value. */ >> # ifndef ECANCELED >> # define ECANCELED 125 >> # endif >> >> # ifndef __ASSEMBLER__ >> /* Function to get address of global `errno' variable. */ >> *extern int *__errno_location (void) __THROW __attribute__ ((__const__)); >> * >> >> # if !defined _LIBC || defined _LIBC_REENTRANT >> /* When using threads, errno is a per-thread value. */ >> # define errno (*__errno_location ()) >> # endif >> # endif /* !__ASSEMBLER__ */ >> #endif /* _ERRNO_H */ >> >> #if !defined _ERRNO_H && defined __need_Emath >> /* This is ugly but the kernel header is not clean enough. We must >> define only the values EDOM, EILSEQ and ERANGE in case __need_Emath is >> defined. */ >> # define EDOM 33 /* Math argument out of domain of function. */ >> # define
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Right, I am using the latest svn version. Hi Tugkan, Well spotted, this is just a debugging change that is no longer required so I've reverted to the old try version and checked in the change to svn/trunk. However, this debugging block only exits in the svn/trunk version of the OSG, not the OSG-2.8 branch, so 2.8.1-rc4 shouldn't have it in it. I presume you are using the svn/trunk or one of the 2.9.x series? Robert. On Fri, May 15, 2009 at 1:02 PM, Tugkan Calapoglu wrote: Hi, Following method is from ive plugin, ReaderWriterIVE.cpp. Is #if 1 forgotten here? In some other methods ive::Exception is caught within the plugin. In this method, however, the exception goes out of the plugin and has to be handled in the application. virtual ReadResult readNode(std::istream& fin, const Options* options) const { #if 1 ive::DataInputStream in(&fin, options); return in.readNode(); #else try{ // Create datainputstream. ive::DataInputStream in(&fin, options); return in.readNode(); } catch(ive::Exception e) { return e.getError(); } #endif } tugkan Hi All, After a long delay - health, submissions backlog and other work all got in the way of a quick turn around on this rc4, I've finally got tagging OpenScenGraph-2.8.1-rc4. You can download it from: http://www.openscenegraph.org/projects/osg/wiki/Downloads Please test. If things go smoothly with testing today and over the weekend I'll go for the final 2.8.1 release early next week. Please post your successes/failures to this thread. Thanks in advance with you help on testing on as many machines and OS combinations that you can lay your hands on. Robert. -- Change Log since 2.8.0 2009-05-14 17:26 robert * NEWS.txt, README.txt: Updated dates 2009-05-14 17:25 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHOR file 2009-05-14 17:18 robert * applications/osgversion/CMakeLists.txt, applications/osgversion/Contributors.cpp, applications/osgversion/osgversion.cpp: Moved the Contributors generation code out into a separate source file that is only compiled when OSG_MAINTAINER is enable via ccamke. This has been done to prevent build issues on some machines with compilers that chose a different local to the one that the contributors names are encoded. 2009-05-13 08:35 robert * src/OpenThreads/win32, src/OpenThreads/win32/Win32Thread.cpp: From Thibault Genessay, "On Windows, when a process tries to spawn one too many thread, _beginthreadex() fails but OpenThreads still waits on the startup Block before returning to the caller of OpenThreads::Thread::start(). This causes a deadlock. The return value of _beginthreadex() is actually checked, but after the call to OpenThreads::Block::block() so it is basically useless. Attached is a fix to move the check for the return value of _beginthreadex() before the call to block(), so that start() can return to the caller with a non-zero error code. This solves the problem for me." Merged from svn trunk using: svn merge -r 10190:10191 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/OpenThreads/win32 2009-05-12 11:15 robert * ChangeLog, NEWS.txt, README.txt: Updated ChangeLog and NEWS/READER for release candidate 2009-05-12 11:12 robert * src/osgWrappers/osgUtil/IntersectVisitor.cpp: Updated wrappers 2009-05-12 10:49 robert * src/osgWidget, src/osgWidget/WindowManager.cpp: From Fajran Iman Rusadi, fixed to handling of widget indices in insert and remove methods. Merged from svn/trunk using: svn merge -r 10181:10182 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgWidget 2009-05-08 12:38 robert * src/osgViewer/GraphicsWindowWin32.cpp: Added initializer for _mouseCursor 2009-05-08 07:49 robert * src/osgViewer/GraphicsWindowWin32.cpp: From Neil Groves, fixed unitialized variable 2009-05-07 15:59 robert * CMakeLists.txt: Updated release candidate to 4. 2009-05-07 15:14 robert * src/osgViewer/GraphicsWindowWin32.cpp: From Frederic Bouvier, workaround of setCursor problems under Windows. 2009-05-07 14:58 robert * src/osg/GraphicsContext.cpp: Fixed ABSOLUTE_RF slave camera resize policy, merged from svn trunk using: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/ 2009-05-07 13:24 robert * src/osgDB, src/osgDB/CMakeLists.txt, src/osgDB/DatabasePager.cpp, src/osgDB/Registry.cpp: From Stephan Huber, "while debugging a problem in finding plugins on OS X I discovered, that the conditional directives for setting the prepend-string in createLibraryNameForExtension were not in effect, because of the mixture of different #ifdef styles.
Re: [osg-users] VPB stuff
Hi Robert, is it the expected comportement ? machine=DELL-VOSTRO-02 running task=tasks/build_subtile_L2_X3_Y1/build_subtile_L5_X31_Y14.task Error: :0.0 no Pbuffer support in GLX available. libGL error: drmGetMagic failed libGL error: reverting to (slow) indirect rendering Warning: detected OpenGL error 'invalid enumerant' at DestinationTile::createStateSet() machine=DELL-VOSTRO-02 completed Building a terrain with 2.8 release on linux 32 bits ubuntu... I'll try with the brand new OpenScenGraph-2.8.1-rc4 later this afternoon. Pierre. Le vendredi 15 mai 2009 à 09:28 +0100, Robert Osfield a écrit : > HI Pierre, > > On Fri, May 15, 2009 at 8:24 AM, Pierre Bourdin (gmail) > wrote: > > For the --terrain option, it works also very well, but I have to disable > > GL_ARB extension with my ATI otherwise it crashes. > > Could you try the OSG-2.8 or svn/trunk version of the OSG as there is > crash fix that prevents problems with rendering VPB --terrain > databases. The case of the crash was an bug in the set up of the > VBO's, the ATI driver crashes if you put a VBO inside a display list. > It was a bug putting the VBO's inside a display list so once this was > fixed the crash went away. The ATI driver is still a bit buggy, but > at least it's now working well with VPB terrain databases. > > Robert. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Hi Johannes, Uhm, it's a little confusing who you are addressing with 'you'. You do that twice and I think you mean 2 different people... Anyway, I was trying to help in another direction. I have indeed used GL_LUMINANCE for grabbing depth images. I guess I was mislead somehow by the subject of the message, as well as the lack of context because the history is not in the messages. good luck Raymond Johannes Leidheiser wrote: GL_LUMINANCE is for gray scale images. For example if you want to save the depth buffer. Besides you should post a little bit more code. I don't know how much experience your have with open scene graph. Maybe you didn't call the frame() method of your viewer, the camera is not attached to a node or maybe there is just nothing to see in the viewing frustum? Did you display the camera normaly which means with turned off offscreen rendering? Regards, Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12216#12216 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi John, On Fri, May 15, 2009 at 1:41 PM, John Ivar Haugland wrote: > I moved the struct OSGSHADOW_EXPORT ViewData: public osg::Referenced from > the protected to the public interface of the class > ViewDependentShadowTechnique and the compilation continued 100%. ( I had to > disable curl because of old version of it on RHEL3) What versions of gcc and libcurl on your system do you have? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi robert, something isn't right with the last thing I said, when creating a new osgViewer::View a main camera is created by default, so it's not possible to have 2 slave cameras only and no main camera, am I right ? My goal is to have only 2 camera not matter if they are both slaves or main and slave but they have to get the same projection matrix when resizing. With you recommandation there is in fact 3 cameras (2 slave and 1 main default created). What is the problem with changing the part of code I previously spoke about ?? 2009/5/15 Alexandre Amalric > When using 2 slave cameras instead of 1 main calera and 1 slave camera the > resizing works perfectly. > > I was thinking that the viewer had to have 1 main camera and n slave > camera, I was mistaken. > > I have one last question, when we call getCameraWithFocus on a viewer set > up with 2 slaves camera and no main camera, wich one is returned ? > > Thank you for your support and I wish you a good recovery. > > > 2009/5/15 Robert Osfield > >> HI Alexandre, >> >> >> On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric >> wrote: >> > Hi Robert, >> > >> > thank you for answering me but i'm confused I don't really understand >> what >> > you want me to do on my example ? >> >> Make it work like the original osgwindows example - use two slave >> cameras rather than one master and one slave. >> >> I have lots of other work to do, and I'm really not well so can't take >> on extra work, please try out my suggestions. >> >> Robert. >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > > -- > Alexandre AMALRIC Ingénieur R&D > === > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi Pierre, You are getting an OpenGL related error which clearly isn't good as is something you need to look at. What hardware + drivers are you using? Robert. On Fri, May 15, 2009 at 1:43 PM, Pierre Bourdin (gmail) wrote: > Hi Robert, > is it the expected comportement ? > > > machine=DELL-VOSTRO-02 running > task=tasks/build_subtile_L2_X3_Y1/build_subtile_L5_X31_Y14.task > Error: :0.0 no Pbuffer support in GLX available. > libGL error: drmGetMagic failed > libGL error: reverting to (slow) indirect rendering > Warning: detected OpenGL error 'invalid enumerant' at > DestinationTile::createStateSet() > machine=DELL-VOSTRO-02 completed > > > > Building a terrain with 2.8 release on linux 32 bits ubuntu... > > I'll try with the brand new OpenScenGraph-2.8.1-rc4 later this > afternoon. > > Pierre. > Le vendredi 15 mai 2009 à 09:28 +0100, Robert Osfield a écrit : >> HI Pierre, >> >> On Fri, May 15, 2009 at 8:24 AM, Pierre Bourdin (gmail) >> wrote: >> > For the --terrain option, it works also very well, but I have to disable >> > GL_ARB extension with my ATI otherwise it crashes. >> >> Could you try the OSG-2.8 or svn/trunk version of the OSG as there is >> crash fix that prevents problems with rendering VPB --terrain >> databases. The case of the crash was an bug in the set up of the >> VBO's, the ATI driver crashes if you put a VBO inside a display list. >> It was a bug putting the VBO's inside a display list so once this was >> fixed the crash went away. The ATI driver is still a bit buggy, but >> at least it's now working well with VPB terrain databases. >> >> Robert. > > 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 > > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, I'm afraid others will have to pick up this thread to answer your questions. Robert. On Fri, May 15, 2009 at 1:51 PM, Alexandre Amalric wrote: > Hi robert, > > something isn't right with the last thing I said, when creating a new > osgViewer::View a main camera is created by default, so it's not possible to > have 2 slave cameras only and no main camera, am I right ? > > My goal is to have only 2 camera not matter if they are both slaves or main > and slave but they have to get the same projection matrix when resizing. > With you recommandation there is in fact 3 cameras (2 slave and 1 main > default created). > > What is the problem with changing the part of code I previously spoke about > ?? > > 2009/5/15 Alexandre Amalric >> >> When using 2 slave cameras instead of 1 main calera and 1 slave camera the >> resizing works perfectly. >> >> I was thinking that the viewer had to have 1 main camera and n slave >> camera, I was mistaken. >> >> I have one last question, when we call getCameraWithFocus on a viewer set >> up with 2 slaves camera and no main camera, wich one is returned ? >> >> Thank you for your support and I wish you a good recovery. >> >> >> 2009/5/15 Robert Osfield >>> >>> HI Alexandre, >>> >>> On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric >>> wrote: >>> > Hi Robert, >>> > >>> > thank you for answering me but i'm confused I don't really understand >>> > what >>> > you want me to do on my example ? >>> >>> Make it work like the original osgwindows example - use two slave >>> cameras rather than one master and one slave. >>> >>> I have lots of other work to do, and I'm really not well so can't take >>> on extra work, please try out my suggestions. >>> >>> Robert. >>> ___ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> -- >> Alexandre AMALRIC Ingénieur R&D >> === >> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille >> http://www.pixxim.fr > > > > -- > Alexandre AMALRIC Ingénieur R&D > === > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] getting extra attributes from .flt to osg/ive
> When you say "I cant find this data being written out", what are you > referring to? Do you mean written to a .osg/.ive file, or a .flt file? I'm > pretty sure the lat/long in the header node's UserData does get written out > to the .flt header record during export, though I could be mistaken. I am refering to the UserData being written out to the .osg/ive file. > If you mean it isn't written to .osg/.ive... You can derive any class from > Referenced and attach it as UserData to any Object, but the data can only be > exported to .osg/.ive if it is a class that the .osg/.ive plugins know > about, of course. I would assume the loc class used to store the lat/lon was a standard osg class and would be written out to osg/ive. If it isnt, are you saying that if I used an Array, for example, it would be written out? I was unable to find where the userdata was retrieved within the osg/ive exporter, but I didn't look that much. :) Should I assume that idea 1 would not be an advisable route to try and take? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12228#12228 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi, gcc --version gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-56) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The libcurl version is 7.10.6. I have also compiled QT4.5.1 on this platform. QT compiled without errors when I added the include path /usr/kerberos/include. On Fri, May 15, 2009 at 2:46 PM, Robert Osfield wrote: > Hi John, > > On Fri, May 15, 2009 at 1:41 PM, John Ivar Haugland > wrote: > > I moved the struct OSGSHADOW_EXPORT ViewData: public osg::Referenced from > > the protected to the public interface of the class > > ViewDependentShadowTechnique and the compilation continued 100%. ( I had > to > > disable curl because of old version of it on RHEL3) > > What versions of gcc and libcurl on your system do you have? > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi John, On Fri, May 15, 2009 at 1:59 PM, John Ivar Haugland wrote: > gcc --version > gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-56) > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > The libcurl version is 7.10.6. I have also compiled QT4.5.1 on this > platform. QT compiled without errors when I added the include path > /usr/kerberos/include. It's nice that QT compiles but it doesn't really help us here. Having to move the View into the public part of the class is down to a bug in the compiler, other compilers, including later version of gcc work fine. The class design of keeping implementation details protected is appropriate so it's note something I want to change just to workaround a old broken compiler, so finding a another workaround which is less intrusive to the design would be appropriate. Would the use of friend help in this context? W.r.t libcurl build issues, I've been looking at whether cmake can be used to check for specific version or later but I can't find any support for this. We might be able to write out own compile test against the libcurl header to check if the features we require are present. Could you re-enable the build of libcurl plugin and then post the compile errors that are emitted, this will tell us what features we need to test against. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] huds on multiple cameras
Hi, I have 2 windows, each with its own camera/viewport. I need to display a different hud on each camera. What's the best solution for this. I looked at the hud example, but there is only one hud and it is added to the scene, and therefore gets displayed on each camera. Any suggestion would be appreciated. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12231#12231 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi Robert, Le vendredi 15 mai 2009 à 13:51 +0100, Robert Osfield a écrit : > Hi Pierre, > > You are getting an OpenGL related error which clearly isn't good as is > something you need to look at. Yep ,but the terrain is built and rendering is slow and popping but correct... > > What hardware + drivers are you using? I'll tell you more precisely at the end of the afternoon, cause I can't get the machine for now... But the graphic board is an integrated ATI Radeon Xpress 1150... The drivers are probably from before September 08... Sorry, I couldn't find another machine for a quick compatibility test Pierre > > Robert. > > On Fri, May 15, 2009 at 1:43 PM, Pierre Bourdin (gmail) > wrote: > > Hi Robert, > > is it the expected comportement ? > > > > > > machine=DELL-VOSTRO-02 running > > task=tasks/build_subtile_L2_X3_Y1/build_subtile_L5_X31_Y14.task > > Error: :0.0 no Pbuffer support in GLX available. > > libGL error: drmGetMagic failed > > libGL error: reverting to (slow) indirect rendering > > Warning: detected OpenGL error 'invalid enumerant' at > > DestinationTile::createStateSet() > > machine=DELL-VOSTRO-02 completed > > > > > > > > Building a terrain with 2.8 release on linux 32 bits ubuntu... > > > > I'll try with the brand new OpenScenGraph-2.8.1-rc4 later this > > afternoon. > > > > Pierre. > > Le vendredi 15 mai 2009 à 09:28 +0100, Robert Osfield a écrit : > >> HI Pierre, > >> > >> On Fri, May 15, 2009 at 8:24 AM, Pierre Bourdin (gmail) > >> wrote: > >> > For the --terrain option, it works also very well, but I have to disable > >> > GL_ARB extension with my ATI otherwise it crashes. > >> > >> Could you try the OSG-2.8 or svn/trunk version of the OSG as there is > >> crash fix that prevents problems with rendering VPB --terrain > >> databases. The case of the crash was an bug in the set up of the > >> VBO's, the ATI driver crashes if you put a VBO inside a display list. > >> It was a bug putting the VBO's inside a display list so once this was > >> fixed the crash went away. The ATI driver is still a bit buggy, but > >> at least it's now working well with VPB terrain databases. > >> > >> Robert. > > > > 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 > > > > > > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Decals on terrain
Hi, Anyone has a good example on how to render decals on a terrain (for scorch mark, tracks, etc). For example, I want to put a scorch mark on a wall of a building, but I don't want it to potrude over the edges of the wall; it should be clipped to the edge of the wall. Any idea or (better yet) an example would be appreciated. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12234#12234 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGViewer Camera Coordinate System, elevation
Hi Chris, I'd say JP is right, an elevation of 0.0253 sounds like you have a geographic map (x = lon, y = lat, z = meters scaled to degrees). Rebuilding with --geocentric should get you geocentric coords. Jason On Fri, May 15, 2009 at 2:48 AM, J.P. Delport wrote: > Hi, > > did you build your DB with --geocentric? > > jp > > Chris 'Xenon' Hanson wrote: > >> I've noticed that when using VPB terrain, the coordinates of the >> OSGViewer Camera as >> determined by Camera::getViewMatrixAsLookAt(eye,dir,up) appear to be in >> the same >> coordinate system as the terrain. For example, my terrain was built from >> Lat/Lon/Elev(m) >> data, and the camera X and Y are showing Latitude and Longitude. >> >> Which is great, but I'm wondering how that happened, as I expected the >> Camera to likely >> be working in ECEF/geocentric Cartesian X/Y/Z coords. Does the camera >> magically just pick >> up the Coordinate System from the first file loaded by osgViewer, or >> what's the rule? >> >> Also, I noticed the elevation/Z of the camera (which I expected to be in >> the 3000m range >> for the Colorado Rocky Mountains) are more like 0.0253 (as confirmed by >> saving an >> animation path from osgViewer). What units is this in, as it doesn't seem >> to jive with >> what I saw elsewhere? >> >> > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. MailScanner thanks Transtec > Computers for their support. > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] iv file not being read
Hi Abhinav, i am trying to read an iv file but its not being read. the code i am using is : *** SoInput sceneInput; if ( !sceneInput.openFile( "plugins\\graphs\\myInventor.iv" ) ) { QMessageBox::information(mInventorGrid[3], "Error", "Cannot open file requested iv file"); return; } SoSeparator *sc_root = SoDB::readAll( &sceneInput ); sc_root->ref(); Use one of the convenient SoQt viewer classes. mViewer = new SoQtExaminerViewer(iv_widget); mViewer->setSceneGraph(sc_root); mViewer->setDecoration(false); mViewer->show(); *** That's OpenInventor (and some Qt) code. Are you using OSG or OpenInventor? This is an OSG mailing list, and though OSG has an .iv loader, we can't help you debug OpenInventor code. Please go to the appropriate forum/mailing list for 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
Re: [osg-users] light, normals
Hi JP, and make two primitives. By two primitives, do you mean two osg::Geometry objects sharing the same vertex array? (as opposed to two PrimitiveSets in the same osg::Geometry, which is what he was trying to do...) Yes, that's true and clever, I hadn't thought of that. Thanks for your insight, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi J-S, Jean-Sébastien Guay wrote: Hi JP, and make two primitives. By two primitives, do you mean two osg::Geometry objects sharing the same vertex array? (as opposed to two PrimitiveSets in the same osg::Geometry, which is what he was trying to do...) Yes, that's true and clever, I hadn't thought of that. Sorry, "primitives" is a bit vague. I normally make separate (sometimes to set e.g. renderbin number on each) osg::Geometry, each with single addPrimitiveSet. I have not tried multiple addPrimitiveSet on single geometry, but think/hope it should also be OK and share the vertex array. jp Thanks for your insight, J-S -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decals on terrain
Multi-texturing is one of the traditional and straight forward ways to do that Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Guy Volckaert Sent: Friday, May 15, 2009 9:21 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Decals on terrain Hi, Anyone has a good example on how to render decals on a terrain (for scorch mark, tracks, etc). For example, I want to put a scorch mark on a wall of a building, but I don't want it to potrude over the edges of the wall; it should be clipped to the edge of the wall. Any idea or (better yet) an example would be appreciated. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12234#12234 ___ 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.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, something isn't right with the last thing I said, when creating a new osgViewer::View a main camera is created by default, so it's not possible to have 2 slave cameras only and no main camera, am I right ? Of course, an osgViewer::View will always have a main camera. This is the camera that is used for user interaction, etc. But it does not render anything, only the two slaves have GraphicsContexts attached. Check it out, try view->getCamera()->getGraphicsContext(), you will get 0, but if you try it on both slaves you will get a valid GraphicsContext (it could be the same one). So your goal of having only 2 cameras rendering will be met by this setup. The slave cameras render using view and projection matrix offsets from the master camera, and user interaction (say using a camera manipulator) moves the main camera's view matrix and thus affects the slaves indirectly. Hope this clears things up, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi jean-sébastien, Your explanation is very clear. My problem is that when I configure my application like that (2 slaves cameras) I have a lot of weird behaviour (some of my models aren't displayed, interraction with mouse and keyboard are odd), so I found a much simple solution wich is to set my own resize callback to my graphic context. In my resize implementation I directly update the projection matrix from the slave camera and I don't update the _projectionOffset wich for me is useless. I still think that future osg version should correct the default resizeimplementation because this behaviour seems very strange to me, maybe am I the only one to think so ;-) 2009/5/15 Jean-Sébastien Guay > Hi Alexandre, > > something isn't right with the last thing I said, when creating a new >> osgViewer::View a main camera is created by default, so it's not possible to >> have 2 slave cameras only and no main camera, am I right ? >> > > Of course, an osgViewer::View will always have a main camera. This is the > camera that is used for user interaction, etc. But it does not render > anything, only the two slaves have GraphicsContexts attached. Check it out, > try view->getCamera()->getGraphicsContext(), you will get 0, but if you try > it on both slaves you will get a valid GraphicsContext (it could be the same > one). > > So your goal of having only 2 cameras rendering will be met by this setup. > The slave cameras render using view and projection matrix offsets from the > master camera, and user interaction (say using a camera manipulator) moves > the main camera's view matrix and thus affects the slaves indirectly. > > Hope this clears things up, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.webhop.org/ > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decals on terrain
Hi Gordan, Multitexturing would apply if the scorch marks are permanent. In my situation I want to fire several gun rounds and only display a scorch mark where the wall was hit. Then they would fade out over time. I think this is usually done by adding a extra quad slightly in front of the wall. BUt the polygon needs to be clipped "somehow" to avoid it from potruding the edges. Adding decals on the terrains is a little more complicated because the quad needs to be broken up into multiple polygons to follow the relief of the terrain. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12242#12242 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] huds on multiple cameras
Hello Guy, I have 2 windows, each with its own camera/viewport. I need to display a different hud on each camera. What's the best solution for this. I looked at the hud example, but there is only one hud and it is added to the scene, and therefore gets displayed on each camera. You have a few options: 1. you can use a different node mask on each HUD, and then set the traversal mask on each camera to traverse only the appropriate HUD. The drawback here is that you have a limited number of bits in the node mask, so if you're also using it for other things, you could run out. But it's really easy to implement, no change to the hierarchy is needed. 2. you can add the HUD directly as child of the camera, instead of in the scene graph lower down. That way only the appropriate camera will traverse each HUD (since a given HUD is not a child of both cameras, only one). osg::Camera is a Group which renders what's under it. That's what we do here for elements which need to be seen in only one view. There's one problem with that, it's that if you have callbacks somewhere on the HUD's nodes, they won't be called, because the callbacks are only checked on nodes under the View's SceneData (which your HUD can't be in, because then it would be seen by both cameras). You can solve this by having a different SceneData for both views, where the common scene is somewhere lower in the graph. SceneData1 (group) HUD1 camera HUD1 contents Main scene SceneData2 (group) HUD2 camera HUD2 contents Main scene (same as in SceneData1) There may be other options, but those are generally the two most convenient. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi JP, Sorry, "primitives" is a bit vague. I normally make separate (sometimes to set e.g. renderbin number on each) osg::Geometry, each with single addPrimitiveSet. I have not tried multiple addPrimitiveSet on single geometry, but think/hope it should also be OK and share the vertex array. Yes all primitive sets in an osg::Geometry use the same vertex array, but then you can only have one normal array (it's setNormalArray() and not addNormalArray()), so you have to go back to what I said and duplicate vertices to be able to get the effect the OP wanted... That's what I meant. Both solutions are good, it depends on how much duplication will result (for my solution) and how many and how large osg::Geometry objects you will get (for your solution). In general video cards work best with rather large batches of geometry sent in one shot, so I expect the duplication scenario to be a bit faster, but it depends on the bottleneck of course. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hi Alexandre, In my resize implementation I directly update the projection matrix from the slave camera and I don't update the _projectionOffset wich for me is useless. Why don't you update the projection matrix of the master camera? If both slave cameras render to the same GraphicsContext (i.e. are in the same window) then it's the right thing to do. You shouldn't touch the slave cameras' projection matrices, only the master camera's projection matrix and the slave cameras' projection offsets. I still think that future osg version should correct the default resizeimplementation because this behaviour seems very strange to me, maybe am I the only one to think so ;-) Well if you mean that it doesn't do the right thing when you have one master camera and one slave camera, both with graphics contexts, then you're right, but that's expected because it's not a valid use case. You should use a master camera with no graphics context, and two slave cameras with graphics contexts (perhaps the same one). See the code for osgViewer::View::setUpViewOnAllScreens() for an example of this. Perhaps a test could be added to catch that kind of utilization and warn the user that their view's camera setup is invalid. Go back to my previous message, really it makes sense. You have the master camera which in this case is only there to represent the viewer's position. So that's what the CameraManipulator acts upon, but it has no GraphicsContext so it doesn't render anything by itself. And then you have two slave cameras which have viewpoints and projections offset from the master camera, and which do the actual rendering, hence they have GraphicsContexts. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi Robert, Here are the error messages from ReaderWriterCURL: [ 81%] Building CXX object src/osgPlugins/curl/CMakeFiles/osgdb_curl.dir/ReaderWriterCURL.o /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp: In member function `osgDB::ReaderWriter::ReadResult osg_curl::EasyCurl::read(const std::string&, const std::string&, osg_curl::EasyCurl::StreamObject&, const osgDB::ReaderWriter::Options*)': /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:160: ` CURLINFO_HTTP_CONNECTCODE' undeclared (first use this function) /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:160: (Each undeclared identifier is reported only once for each function it appears in.) /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:164: ` CURLINFO_RESPONSE_CODE' undeclared (first use this function) /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:200: ` curl_easy_strerror' undeclared (first use this function) make[2]: *** [src/osgPlugins/curl/CMakeFiles/osgdb_curl.dir/ReaderWriterCURL.o] Error 1 make[1]: *** [src/osgPlugins/curl/CMakeFiles/osgdb_curl.dir/all] Error 2 make: *** [all] Error 2 Regarding the build error I got on when "OSGSHADOW_EXPORT ViewData: public osg::Referenced " was in the protected area. Is this the only place with a construction like this in OSG? If you find a solution like you mention (friend class) this is ok for me at least. Have a good weekend!!! On Fri, May 15, 2009 at 3:14 PM, Robert Osfield wrote: > Hi John, > > On Fri, May 15, 2009 at 1:59 PM, John Ivar Haugland > wrote: > > gcc --version > > gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-56) > > Copyright (C) 2002 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is > NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > > > The libcurl version is 7.10.6. I have also compiled QT4.5.1 on this > > platform. QT compiled without errors when I added the include path > > /usr/kerberos/include. > > It's nice that QT compiles but it doesn't really help us here. Having > to move the View into the public part of the class is down to a bug in > the compiler, other compilers, including later version of gcc work > fine. The class design of keeping implementation details protected is > appropriate so it's note something I want to change just to workaround > a old broken compiler, so finding a another workaround which is less > intrusive to the design would be appropriate. Would the use of > friend help in this context? > > W.r.t libcurl build issues, I've been looking at whether cmake can be > used to check for specific version or later but I can't find any > support for this. We might be able to write out own compile test > against the libcurl header to check if the features we require are > present. Could you re-enable the build of libcurl plugin and then > post the compile errors that are emitted, this will tell us what > features we need to test against. > > Thanks, > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Understanding OSG : plugins runtime loading question
Hi all, thinking for hours and digging my problem, I have a choice to make, but I think some external advices could be useful : I you need to load dynamically some DLL (as osg plugins) but theses DLL have no similar I/O (so make each one inherit from a base class have no sense), how will you do ? I'm thinking in the calssical loadLibrary and getProcAdress for each one, ... but if you know or think in an other solution, I would be very interested to hear it. Thanks. Regards, Vincent 2009/5/14 Vincent Bourdier > Hi Art, > > This is not the same thing ? > > Case 1 : > static variable in the dll, calling the register -> add on declaration. > when the dll is loaded, the static member is initialized, so the register > call the dll variable constructor and add it on its available dll stack (see > RegisterReaderWriterProxy implementation) > > Case 2: > in the dll constructor I call the registry->intance()::register(this) which > does the same thing :stack the dll. > > Thanks, >Vincent. > > 2009/5/14 Art Tevs > > Hi Vincent, >> >> >> Vincent.B wrote: >> > Okay, so I implement a myClass in the core, and I declare a static >> myClass mycalss in my DLL. >> > >> > so, I can call with the static implementation, the methods I want in the >> DLL from my core. >> > >> >> Not really, you implement a static/global variable, which will then >> initialize your class. Here is a code example, which is a standard C++ and >> it will initialize your objects when loading the dll: >> >> Code: >> >> >> #include >> >> class myClass >> { >> myClass() >> { >>Registry::registerMe(this); >> } >> }; >> >> static myClass g_myclass; >> >> >> >> >> This should be almost enough to achieve what you want. >> >> >> > >> > A last point I would like to understand : >> > >> > in each plugin, there is the "magic" : >> > REGISTER_OSGPLUGIN(...) >> > >> > #define REGISTER_OSGPLUGIN(ext, classname) >> > extern "C" void osgdb_##ext(void) {} >> > static osgDB::RegisterReaderWriterProxy >> g_proxy_##classname; >> > >> >> So as you see REGISTER_OSGPLUGIN do exactly the same, what you can see >> from the code above. >> >> What is this extra function osgdb_ext(){} good for, I do not know. Maybe >> the idea was to implement some extra procedures inside of the dll, so that >> they could manually be called when loading the dll. >> >> cheers, >> art >> >> -- >> Read this topic online here: >> http://forum.openscenegraph.org/viewtopic.php?p=12093#12093 >> >> >> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to increase rotation
Thanks alot for your input. It was really helpful. I tracked the TrackballManipulator func you mentioned and managed to find the func responsible of the rotation void Quat::makeRotate() in there the angle passed to cos() and sin() was halfed. I multiplied this by 4 and got what i was after. Best regards and many thanls Fad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12246#12246 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Understanding OSG : plugins runtime loading question
Hi Vincent, Vincent.B wrote: > Hi all, > If you need to load dynamically some DLL (as osg plugins) but theses DLL have > no similar I/O (so make each one inherit from a base class have no sense), > how will you do ? > > I'm thinking in the calssical loadLibrary and getProcAdress for each one, ... > but if you know or think in an other solution, I would be very interested to > hear it. > In windows world each dll can have an entry point. This is a C function, which will be called on dll loading. In unix world, I am not sure if there exists default entry point routines, I think yes, but I am not sure. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12249#12249 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] iv file not being read
1st Question is Did you build one of the required 3rparty libraries you need for the inventor plugin ? See OpenSceneGraph\src\osgPlugins\Inventor\README.txt 2nd Question is did you turn up the Notify Level to see what why it may be failing or did you step into the code to see why its failing ? __ Gordon Tomlinson gor...@gordontomlinson.com IM: gordon3db...@3dscenegraph.com www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mattias Helsing Sent: Friday, May 15, 2009 3:11 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [build] iv file not being read Hello Abhinav, There is nothing for anyone to go on to even try to help you. The code snippet is not even osg code so no chance for us to know anything about what it does. * use a debugger to see what "readAll" returns and why * crank up OSG_NOTIFY_LEVEL * see Paul Martz top 10 debugging tips at http://www.skew-matrix.com/bb/viewtopic.php?f=6&t=5 cheers Mattias On 5/15/09, Abhinav Dubey wrote: > Hi, > i am trying to read an iv file but its not being read. the code i am using > is : > *** > SoInput sceneInput; > if ( !sceneInput.openFile( "plugins\\graphs\\myInventor.iv" ) ) { > QMessageBox::information(mInventorGrid[3], "Error", "Cannot open > file requested iv file"); > return; > } > > SoSeparator *sc_root = SoDB::readAll( &sceneInput ); >sc_root->ref(); > > Use one of the convenient SoQt viewer classes. > mViewer = new SoQtExaminerViewer(iv_widget); > mViewer->setSceneGraph(sc_root); > mViewer->setDecoration(false); > mViewer->show(); > *** > and the iv file named myInventor.iv has the following: > #Inventor V2.1 ascii > > Separator { > SoXipExaminer { > modeNONE > viewBoundingBox 230 0 0 0 > 0 227.785 0 0 > 0 0 42.1032 0 > -112.59 -117.21 50.3972 1 > complexity Complexity { > value 0.5 > textureQuality 0.5 > } > > orthoCamera DEF +0 OrthographicCamera { > } > > perspectiveCamera DEF +1 PerspectiveCamera { > position0.181952 88.5125 454.632 > orientation -0.494995 0.0901597 0.864206 0.470889 > nearDistance230.823 > farDistance 557.256 > focalDistance 394.04 > heightAngle 0.785398 > } > > borderNode SoXipViewportBorder { > fields [ SFColor activeColor, SFColor inactiveColor, ] > activeColor 0.7 0.7 0.7 > inactiveColor 0.7 0.7 0.7 > } > > cameraSwitchSwitch { > whichChild 1 > USE +0 > USE +1 > } > > } > SoXipLut { > fields [ SFEnum inputMode, SFEnum outputMode, SFShort bitsUsed, SFFloat > rampWidth, > SFFloat rampCenter, MFColor arrayColor, MFFloat arrayAlpha ] > inputMode TRAPEZOID > outputMode COLOR > bitsUsed12 > rampWidth 0.05 > rampCenter 0.009 > arrayColor [ ] > arrayAlpha [ ] > } > SoXipImage { > fields [ SoXipSFDataImage image ] > image "DATA" = > SoXipLoadDicom { > inputs [ MFString name ] > name"C:\Xip\examples\data\24884367.dcm" > outputs [ SoXipMFDataDicom dicom ] > } > . dicom > > } > } > *** > when i run the code it crashes at sc_Root.ref(); > plz help me out > ... > > > Thank you! > > Cheers, > Abhinav > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=12174#12174 > > > > > > ___ > 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
Re: [osg-users] Understanding OSG : plugins runtime loading question
Hi Art, I need to make these lib (dll/so) for linux and window at least, so I need common behavior. I'm thinking a mix of the inheriting class and the osg plugin registry behavior with the template static register method ... (note so understandable I think) that is to say, may be a mix of all these way can bring me to a good solution .. Still here if you have suggestion or ideas Thanks every one, still good to have quality help here :-) Regards, Vincent. 2009/5/15 Art Tevs > Hi Vincent, > > > > Vincent.B wrote: > > Hi all, > > If you need to load dynamically some DLL (as osg plugins) but theses DLL > have no similar I/O (so make each one inherit from a base class have no > sense), how will you do ? > > > > I'm thinking in the calssical loadLibrary and getProcAdress for each one, > ... but if you know or think in an other solution, I would be very > interested to hear it. > > > > > In windows world each dll can have an entry point. This is a C function, > which will be called on dll loading. In unix world, I am not sure if there > exists default entry point routines, I think yes, but I am not sure. > > cheers, > art > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=12249#12249 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Hi John, On Fri, May 15, 2009 at 3:13 PM, John Ivar Haugland wrote: > [ 81%] Building CXX object > src/osgPlugins/curl/CMakeFiles/osgdb_curl.dir/ReaderWriterCURL.o > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp: > In > member function `osgDB::ReaderWriter::ReadResult > osg_curl::EasyCurl::read(const std::string&, const std::string&, > osg_curl::EasyCurl::StreamObject&, const osgDB::ReaderWriter::Options*)': > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:160: > ` > CURLINFO_HTTP_CONNECTCODE' undeclared (first use this function) > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:160: > (Each > undeclared identifier is reported only once for each function it appears > in.) > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:164: > ` > CURLINFO_RESPONSE_CODE' undeclared (first use this function) > /private/jiha/shivr/JIHA/OSG/OpenSceneGraph-2.8.1-rc4/src/osgPlugins/curl/ReaderWriterCURL.cpp:200: > ` > curl_easy_strerror' undeclared (first use this function) > make[2]: *** I've found libcurl 7.10.4 and 7.10.8 on the libcurl website, but no 7.10.6. 7.10.8 doesn't have the curl_easy_strerror and this is easy to avoid using by the other codes are a bit more awkward. I have experiment with a compile tests but as yet haven't got CMake to do what I want. Ideally we'd be able to get the libcurl plugin working with this older version of libcurl. > [src/osgPlugins/curl/CMakeFiles/osgdb_curl.dir/ReaderWriterCURL.o] Error 1 > make[1]: *** [src/osgPlugins/curl/CMakeFiles/osgdb_curl.dir/all] Error 2 > make: *** [all] Error 2 > Regarding the build error I got on when "OSGSHADOW_EXPORT ViewData: public > osg::Referenced " was in the protected area. Is this the only place with a > construction like this in OSG? If you find a solution like you mention > (friend class) this is ok for me at least. Have a good weekend!!! The OSG uses lots of nested protected struct/classes. The only thing that might be usually is that the subclasses of the main class also subclass the nested class. This is perfectly valid C++ though. What is biting us here is that g++ 3.2 is not able to cope properly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Q: how do I render an object only to the depth buffer, not to the color buffer?
Hi everyone, I've searched the mailing list but could not find an answer or clue for the solution to my problem. In principle, the issue seems simple to me but I find it hard to come up with an OSG solution. I would like to start my rendering with an object that does write to the depth buffer but does not write to the color buffer. I expect that I need to do something about the color mask but that is a camera setting. Can anyone point me in the right direction? Thanks a lot, best regards Raymond ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with my cubemap
Jean-Sébastien Guay wrote: If there *is* a special format for a cube map contained in a .dds file, perhaps the OSG .dds loader doesn't handle it correctly? I don't know, but you could investigate by checking the code. Again, perhaps someone else has more insight into this. DDS files can contain multi-surface images, including cube maps. The problem is that there is currently no Image class in OSG that will hold a cube map, so there is no way for the .dds plugin to return a cube map. I had a similar problem when I wrote the .vtf loader for Valve textures. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Well apparently I did achieve to set up my application with 2 slave camera, but there is one last problem, I'm using a shader for my sky sphere wich isn't working when using 2 slave cameras, has anyone already had trouble with shaders and slave camera ? 2009/5/15 Jean-Sébastien Guay > Hi Alexandre, > > In my resize implementation I directly update the projection matrix from >> the slave camera and I don't update the _projectionOffset wich for me is >> useless. >> > > Why don't you update the projection matrix of the master camera? If both > slave cameras render to the same GraphicsContext (i.e. are in the same > window) then it's the right thing to do. You shouldn't touch the slave > cameras' projection matrices, only the master camera's projection matrix and > the slave cameras' projection offsets. > > I still think that future osg version should correct the default >> resizeimplementation because this behaviour seems very strange to me, maybe >> am I the only one to think so ;-) >> > > Well if you mean that it doesn't do the right thing when you have one > master camera and one slave camera, both with graphics contexts, then you're > right, but that's expected because it's not a valid use case. You should use > a master camera with no graphics context, and two slave cameras with > graphics contexts (perhaps the same one). See the code for > osgViewer::View::setUpViewOnAllScreens() for an example of this. > > Perhaps a test could be added to catch that kind of utilization and warn > the user that their view's camera setup is invalid. > > Go back to my previous message, really it makes sense. You have the master > camera which in this case is only there to represent the viewer's position. > So that's what the CameraManipulator acts upon, but it has no > GraphicsContext so it doesn't render anything by itself. And then you have > two slave cameras which have viewpoints and projections offset from the > master camera, and which do the actual rendering, hence they have > GraphicsContexts. > > Hope this helps, > > > 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 > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] shadowVolme bugs
Hi all, I am trying to create a shadowed scene by using osg::shadowVolme technique but I have noticed that when the objects in the scene are moving their shadows still unchanged? I have also another a problem with SoftShadowMap technique. My application crashes when it uses the SoftShadowMap technique to render the scene. I am using the version 2.6 of OSG. Any one has an idea about these problems? Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VRML plugin
Hi all, Given that the VRML plugin is a bit of work to compile due to the dependence on a very old version of OpenVRML, I've built a binary packages of OpenVRML-0.14.3 for Win32 Visual Studio .NET 2003 and Visual Studio 2005, and Mac OS X 10.4 32-bit universal. The binaries are here for your pleasure: http://www.artoolworks.com/dist/openvrml/0.14.3/ I also note that previous discussion about why the VRML plugin couldn't be updated to a newer version of OpenVRML centred on the boost dependency. I'm sure that thats much less of an issue now that we have boost binaries for most Linux distros, plus Windows and Mac. http://www.boostpro.com/download http://pdb.finkproject.org/pdb/browse.php?summary=boost Of course, the bigger issue with the VRML plugin is that it doesn't support any sort of animation. OpenVRML 0.14.3 supports animation including animated textures. Does anyone here have a good knowledge of the VRML, good enough to add support for importing VRML animations from OpenVRML nodes? Regards, Philip Lamb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Animated textures
Hi all, I have a request from a user for support for animated textures in an OSG model. They're doing their modelling in 3DS Max and exporting to OSG via the 3DS exported plugin, to native .osg format. 1) Is it straightforward to use animated textures in OSG (for example in VRML, one can specify an mpeg file as a texture and animation just works)? 2) If yes, is there a straightforward workflow from modelling tools to OSG to include animated textures? Post-processing of exported files is also fine. Regards Philip Lamb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Animation in COLLADA files supported?
Hi all, I have a question about which plugins support files that include animations. I have experimented with the COLLADA plugin, but it appears that as of OSG 2.8.1-RC3 and COLLADA DOM 1.4, animation in .dae files doesn't carry through to the scene graph. Does anyone have any suggestions as to whether animations in .dae files should be supported (and if I'm doing something wrong)? Can anyone else share their preferred workflow for getting animations out of modelling applications and into OSG? The artist I'm trying to support uses Cinema 4D. Our backup is exporting to VRML2 and doing a second rendering pass using libopenvrml-gl outside OSG. Thanks in advance, Phil Lamb. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate four tagged
Ho John, On Fri, May 15, 2009 at 3:32 PM, Robert Osfield wrote: > I've found libcurl 7.10.4 and 7.10.8 on the libcurl website, but no > 7.10.6. 7.10.8 doesn't have the curl_easy_strerror and this is easy > to avoid using by the other codes are a bit more awkward. I've worked out how to use the lib version in the source itself to switch off use of features that more modern features. The modified ReaderWriterCURL.cpp is attached. These changes are also checked into svn/trunk and the OSG-2.8 branch. Could you please test these out on your system? Thanks, Robert. /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2008 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.org website. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * OpenSceneGraph Public License for more details. */ #include #include #include #include #include #include #include #include #include #include "ReaderWriterCURL.h" using namespace osg_curl; // // StreamObject // EasyCurl::StreamObject::StreamObject(std::ostream* stream1, const std::string& cacheFileName): _stream1(stream1), _cacheFileName(cacheFileName) { _foutOpened = false; } void EasyCurl::StreamObject::write(const char* ptr, size_t realsize) { if (_stream1) _stream1->write(ptr, realsize); if (!_cacheFileName.empty()) { if (!_foutOpened) { osg::notify(osg::INFO)<<"Writing to cache: "<<_cacheFileNamegetAuthenticationMap() : osgDB::Registry::instance()->getAuthenticationMap(); if(!proxyAddress.empty()) { osg::notify(osg::INFO)<<"Setting proxy: " username + colon + details->password); curl_easy_setopt(_curl, CURLOPT_USERPWD, password.c_str()); _previousPassword = password; // use for https. // curl_easy_setopt(_curl, CURLOPT_KEYPASSWD, password.c_str()); #if LIBCURL_VERSION_NUM >= 0x070a07 if (details->httpAuthentication != _previousHttpAuthentication) { curl_easy_setopt(_curl, CURLOPT_HTTPAUTH, details->httpAuthentication); _previousHttpAuthentication = details->httpAuthentication; } #endif } else { if (!_previousPassword.empty()) { curl_easy_setopt(_curl, CURLOPT_USERPWD, 0); _previousPassword.clear(); } #if LIBCURL_VERSION_NUM >= 0x070a07 // need to reset if previously set. if (_previousHttpAuthentication!=0) { curl_easy_setopt(_curl, CURLOPT_HTTPAUTH, 0); _previousHttpAuthentication = 0; } #endif } curl_easy_setopt(_curl, CURLOPT_URL, fileName.c_str()); curl_easy_setopt(_curl, CURLOPT_WRITEDATA, (void *)&sp); CURLcode res = curl_easy_perform(_curl); curl_easy_setopt(_curl, CURLOPT_WRITEDATA, (void *)0); if (res==0) { #if LIBCURL_VERSION_NUM >= 0x070a07 long code; if(!proxyAddress.empty()) { curl_easy_getinfo(_curl, CURLINFO_HTTP_CONNECTCODE, &code); } else { curl_easy_getinfo(_curl, CURLINFO_RESPONSE_CODE, &code); } //If the code is greater than 400, there was an error if (code >= 400) { osgDB::ReaderWriter::ReadResult::ReadStatus status; //Distinguish between a client error and a server error if (code < 500) { //A 400 level error indicates a client error status = osgDB::ReaderWriter::ReadResult::FILE_NOT_FOUND; } else { //A 500 level error indicates a server error status = osgDB::ReaderWriter::ReadResult::ERROR_IN_READING_FILE; } osgDB::ReaderWriter::ReadResult rr(status); //Add the error code to the ReadResult std::stringstream message; message << "error code = " << code; rr.message() = message.str(); return rr; } #endif // Store the mime-type, if any. (Note: C
Re: [osg-users] huds on multiple cameras
Hi Guy, To further expand on J-S suggestions, there are four ways of doing HUDs, Camera in a scene graph, a slave Camera in the Viewer, an separate View in a CompositeViewer or as a Camera attached to the GraphicsWindow. There is an osghud example illustrates the first three of this options. The on screen stats and help event handlers built into osgViewer demonstate a hud in the GraphicsWindow. Robert. On Fri, May 15, 2009 at 2:16 PM, Guy Volckaert wrote: > Hi, > > I have 2 windows, each with its own camera/viewport. I need to display a > different hud on each camera. What's the best solution for this. I looked at > the hud example, but there is only one hud and it is added to the scene, and > therefore gets displayed on each camera. > > Any suggestion would be appreciated. > > Cheers, > Guy > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=12231#12231 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Q: how do I render an object only to the depth buffer, not to the color buffer?
HI Raymond, You simple disable the writes to the colour buffer using the osg::ColorMask StateAttribute. Robert. On Fri, May 15, 2009 at 3:33 PM, Raymond de Vries wrote: > Hi everyone, > > I've searched the mailing list but could not find an answer or clue for the > solution to my problem. > > In principle, the issue seems simple to me but I find it hard to come up > with an OSG solution. I would like to start my rendering with an object that > does write to the depth buffer but does not write to the color buffer. I > expect that I need to do something about the color mask but that is a camera > setting. > > Can anyone point me in the right direction? > > Thanks a lot, best regards > Raymond > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Animation in COLLADA files supported?
Philip Lamb wrote: Hi all, I have a question about which plugins support files that include animations. I have experimented with the COLLADA plugin, but it appears that as of OSG 2.8.1-RC3 and COLLADA DOM 1.4, animation in .dae files doesn't carry through to the scene graph. Does anyone have any suggestions as to whether animations in .dae files should be supported (and if I'm doing something wrong)? I don't believe there is currently any support in the .dae plugin for animations. I think there is some work going on in this direction (using the osgAnimation node kit), but it's not ready yet. Can anyone else share their preferred workflow for getting animations out of modelling applications and into OSG? The artist I'm trying to support uses Cinema 4D. Our backup is exporting to VRML2 and doing a second rendering pass using libopenvrml-gl outside OSG. I think COLLADA is still the best way to do this, but at the moment, it takes a bit of extra work beyond what OSG provides (we use a home-built COLLADA loader). I think Delta3D does this with Cal3D and ReplicantBody, but I'm not sure exactly what their art path is. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with my cubemap
On Fri, May 15, 2009 at 3:34 PM, Jason Daly wrote: > Jean-Sébastien Guay wrote: >> >> If there *is* a special format for a cube map contained in a .dds file, >> perhaps the OSG .dds loader doesn't handle it correctly? I don't know, but >> you could investigate by checking the code. Again, perhaps someone else has >> more insight into this. >> > > DDS files can contain multi-surface images, including cube maps. The > problem is that there is currently no Image class in OSG that will hold a > cube map, so there is no way for the .dds plugin to return a cube map. Indeed there isn't a osg::Image class that does cube maps yet. I have been pondering on this issue for a quite while as this topic does occasionally come up. The way to tackle is to have an osg::CompositeImage/ImageList/ImageArray subclass from osg::Image that provides a list of images that can be assigned to a osg::Texture. One would want to scoop up the needs of the texture array support at the same time. Ideally we'd have an ImageBase class rather than subclassing from Image or refactor Image so it's a base class, and then have concrete implementations subclass from this. It's kinda awkward to undertake such a refactoring now though. A template for an ImageArray class could be the ImageSequence class that already holds a list of images internally. Others are welcome to dive in an add this ImageArray class ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Animated textures
Hi Philip, A while back I add the osg::ImageSequence class for stepping through a series of images. Have a look at the osgimagesequence example. It's similar to having assigning a movie to a texture using the quicktime/ffmpeg plugin but offers better support for hand building the animation sequences. Robert. On Fri, May 15, 2009 at 4:13 PM, Philip Lamb wrote: > Hi all, > > I have a request from a user for support for animated textures in an OSG > model. They're doing their modelling in 3DS Max and exporting to OSG via the > 3DS exported plugin, to native .osg format. > > 1) Is it straightforward to use animated textures in OSG (for example in > VRML, one can specify an mpeg file as a texture and animation just works)? > 2) If yes, is there a straightforward workflow from modelling tools to OSG > to include animated textures? Post-processing of exported files is also > fine. > > Regards > > Philip Lamb > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Animated textures
Philip Lamb wrote: Hi all, I have a request from a user for support for animated textures in an OSG model. They're doing their modelling in 3DS Max and exporting to OSG via the 3DS exported plugin, to native .osg format. 1) Is it straightforward to use animated textures in OSG (for example in VRML, one can specify an mpeg file as a texture and animation just works)? The xine and ffmpeg plugins support reading movie files into an ImageStream, which can be attached to OSG texture objects. I don't think any of the model plugins currently support this directly, though, so you'll have to do some work in the application. The osg and ive plugins (these are the native OSG ASCII and binary formats, respectively) support ImageSequences (which is a subclass of ImageStream), so there may be a conversion path that you could use where you end up with a .ive file that has the animated textures you want. I'm not sure what steps would be involved, though. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB stuff
Hi Pierre, I'm currently using a ATI 4670 graphics card under Kubuntu 9.04 and osgdem/vpb has been working fine for me. > fglrxinfo display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Radeon HD 4670 OpenGL version string: 2.1.8591 Robert. On Fri, May 15, 2009 at 4:31 PM, Pierre BOURDIN wrote: > OK I got the complete config now: > Linux DELL-VOSTRO-02 2.6.24-22-generic #1 SMP Mon Nov 24 18:32:42 UTC 2008 > i686 GNU/Linux > > ==/proc/version (17:14)== > Linux version 2.6.24-22-generic (bui...@vernadsky) (gcc version 4.2.3 > (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Mon Nov 24 18:32:42 UTC 2008 > > ==gcc --version== > gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3) > Copyright © 2007 Free Software Foundation, Inc. > > ==/usr/bin/fglrxinfo== > libGL: XF86DRIGetClientDriverName: 8.47.3 fglrx (screen 0) > libGL: OpenDriver: trying /usr/lib/dri/fglrx_dri.so > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 5, (OK) > drmOpenByBusid: Searching for BusID PCI:1:5:0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 5, (OK) > drmOpenByBusid: drmOpenMinor returns 5 > drmOpenByBusid: drmGetBusid reports PCI:1:5:0 > display: :0.0 screen: 0 > OpenGL vendor string: ATI Technologies Inc. > OpenGL renderer string: ATI Radeon Xpress Series > OpenGL version string: 2.1.7412 Release > > ==osgversion== > OpenSceneGraph Library 2.8.1 > > ==VPBMASTER== > With the brand nw osg 2.8.1-rc4: > make MassaneRange > preparing Massane range... > -d data_massane/elev_cata_25.dem > --layer layeNumber=0 > -t data_massane/cata_25.tif > --layer layeNumber=2 > -t data_massane/cata_05.tif > -o database/massane_range.ive > Adding terrainTile > DataSet::assignDestinationCoordinateSystem() : assigning first source file > as the destination coordinate system > DataSet::generateTasks_new > AR=2.948815 C1=3 R1=1 > Computed maximum source level = 5 > Selected single split at 2 > AR=2.948815 C1=3 R1=1 > Task directory already created > Log directory already created > totalNumOfTasksSansRoot = 3 > Generated tasks file = build_master.tasks > Setting up MachinePool to use all 2 cores on this machine. > Begining run > scheduling task : tasks/build_root_L0_X0_Y0.task > machine=DELL-VOSTRO-02 running task=tasks/build_root_L0_X0_Y0.task > scheduling task : tasks/build_subtile_L1_X0_Y0.task > machine=DELL-VOSTRO-02 running task=tasks/build_subtile_L1_X0_Y0.task > scheduling task : tasks/build_subtile_L1_X1_Y0.task > scheduling task : tasks/build_subtile_L1_X2_Y0.task > Error: :0.0 no Pbuffer support in GLX available. > Error: :0.0 no Pbuffer support in GLX available. > libGL error: drmGetMagic failed > libGL error: reverting to (slow) indirect rendering > libGL error: drmGetMagic failed > libGL error: reverting to (slow) indirect rendering > > I'll try to update the drivers.. > > Pierre. > 2009/5/15 Pierre Bourdin (gmail) >> >> Hi Robert, >> Le vendredi 15 mai 2009 à 13:51 +0100, Robert Osfield a écrit : >> > Hi Pierre, >> > >> > You are getting an OpenGL related error which clearly isn't good as is >> > something you need to look at. >> >> Yep ,but the terrain is built and rendering is slow and popping but >> correct... >> > >> > What hardware + drivers are you using? >> >> I'll tell you more precisely at the end of the afternoon, cause I can't >> get the machine for now... >> >> But the graphic board is an integrated ATI Radeon Xpress 1150... >> >> The drivers are probably from before September 08... >> >> Sorry, I couldn't find another machine for a quick compatibility test >> >> Pierre >> >> > >> > Robert. >> > >> > On Fri, May 15, 2009 at 1:43 PM, Pierre Bourdin (gmail) >> > wrote: >> > > Hi Robert, >> > > is it the expected comportement ? >> > > >> > > >> > > machine=DELL-VOSTRO-02 running >> > > task=tasks/build_subtile_L2_X3_Y1/build_subtile_L5_X31_Y14.task >> > > Error: :0.0 no Pbuffer support in GLX available. >> > > libGL error: drmGetMagic failed >> > > libGL error: reverting to (slow) indirect rendering >> > > Warning: detected OpenGL error 'invalid enumerant' at >> > > DestinationTile::createStateSet() >> > > machine=DELL-VOSTRO-02 completed >> > > >> > > >> > > >> > > Building a terrain with 2.8 release on linux 32 bits ubuntu... >> > > >> > > I'll try with the brand new OpenScenGraph-2.8.1-rc4 later this >> > > afternoon. >> > > >> > > Pierre. >> > > Le vendredi 15 mai 2009 à 09:28 +0100, Robert Osfield a écrit : >> > >> HI Pierre, >> > >> >> > >> On Fri, May 15, 2009 at 8:24 AM, Pierre Bourdin (gmail) >> > >> wrote: >> > >> > For the --terrain option, it works also very well, but I have to >> > >> > disable >> > >> > GL_ARB extension with my ATI otherwise it crashes. >> > >> >> > >> Could you try the OSG-2.8 or svn/trunk version of the OSG as there is >> > >> crash fix that prevents problems with rendering VPB --terrain >> > >> databases. The case of the crash was an bu
Re: [osg-users] Problem with my cubemap
Robert Osfield wrote: A template for an ImageArray class could be the ImageSequence class that already holds a list of images internally. Others are welcome to dive in an add this ImageArray class ;-) I thought about it while I was writing the .vtf loader, but I was under time pressure, and the Image code was fairly complex at first look, so it kind of scared me off :-) --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with my cubemap
Hello Robert, I've originally contributed the .dds cubemap loading capability that you rejected. From that time I've been merging my changes with the latest head. Cubemaps can still be loaded succesfully, but I agree that it may be better to split osg::Image into multiple classes for the different osg::Textures that it feeds. Are you envisioning a separate Image class for each Texture class? Side note: Last week I ran into a problem with cubemaps in the osgOcean example which turned out to be a pixelformat problem. The osgOcean example uses 6 separate images of which one image has a different pixel format. My osg::Image class supporting cubemaps has only one pixelformat for all 6 data planes and this caused a problem when copying the six images into the single cubemap image. kind regards, Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12269#12269 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
jojo wrote: > GL_LUMINANCE is for gray scale images. For example if you want to save the > depth buffer. Ok, thus, I should use GL_RGBA. jojo wrote: > > Besides you should post a little bit more code. I don't know how much > experience your have with open scene graph. Maybe you didn't call the frame() > method of your viewer, the camera is not attached to a node or maybe there is > just nothing to see in the viewing frustum? > My camera is attached to the root of the scene graph. I retrieve the image during the rendering loop (it's true I didn't do it at first...), thus after 5 viewer.frame ('cause I setted it at 5). There is something to see from my camera. jojo wrote: > > Did you display the camera normaly which means with turned off offscreen > rendering? > However, I don't know what you mean here, it seems to be a key point... I've read things about pre-render, but you don't do any, right? Here's a bit of my code: I create the camera: Code: ref_ptr MyPTMutils::createCamera(Matrix& cameraIntrinsic, Matrix& cameraPosition) { // parameters for MyPTM double width = cameraIntrinsic(0, 2)*2; double height = cameraIntrinsic(1, 2)*2; double fy = cameraIntrinsic(1, 1); // create camera for MyPTM ref_ptr new_camera = new Camera(); new_camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); new_camera->setViewport(0, 0, width, height); new_camera->setProjectionMatrixAsPerspective((360./PI)*atan(height/(2*fy)) , (double)width/height, 1.0, 1000.0); new_camera->setViewMatrix(Matrix::inverse(cameraPosition)); return (new_camera); } I modify the camera (I know this can seem strange out of the context): Code: MyPTM::MyPTM(Geode* _arg_geode, std::string imgpath , int _arg_textureUnit, float focal, Quat &rotation, Vec3d position) { ref_ptr img = osgDB::readImageFile(imgpath); cu = img->s(); cv = img->t(); Vec2f *vec = new Vec2f(cu,cv); MyPTMutils::setClosestPowerOfTwo(vec); ... _camera = MyPTMutils::createCamera(cameraIntrinsic, transform); _texture = new Texture2D(osgDB::readImageFile(imgpath)); _camera->setReferenceFrame(Transform::ABSOLUTE_RF); _camera->setDataVariance(Object::DYNAMIC); _depth = new Image(); _depth->allocateImage(vec->x(), vec->y(), 1, GL_RGBA, GL_UNSIGNED_BYTE); _camera->attach(osg::Camera::COLOR_BUFFER, _depth.get(),0,0); And the print: Code: float* bl = (float*)(_depth->data()); osgDB::writeImageFile(*_depth.get(),"depth.png"); This makes me think: why a float* ? And the main Code: MyPTM* myptm2 = new MyPTM((Geode*) (root->getChild(2)), "../Media/Data_Calibrage/Image/IMG_5316_small.jpg", 0, 720.0, r, camposition); myptm2->_camera->setView(&viewer); viewer.addSlave(myptm2->_camera.get()); viewer.setSceneData( root.get()); viewer.realize(); int once = 0; while( !viewer.done() ) { viewer.frame(); if (once == 50) myptm2->printDepthImage(); once++; } -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12271#12271 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
I forgot: thanks for everything! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12272#12272 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] No texture loaded on 3d model with osgViewer
Hi, I am trying to load a .3ds model using osgViwer. Now i am getting the model on screen but without textures! I read somewhere in the forum that i need to set the path so that osg finds the images needed (please correct me if i am wrong) and iread as well that i will need to add -t myTexture.jpg into the command line. Well, i tried both but still no luck. Is there anything i am missing in here? Regards Fad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12273#12273 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadowVolme bugs
Hello Bilal, code comments in the ShadowVolume class suggest that it is still a work in progress. However it seems that it is no longer actively developed and still has some unsolved bugs. Cheers, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12274#12274 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with my cubemap
HI Roland, On Fri, May 15, 2009 at 4:40 PM, Roland Smeenk wrote: > I've originally contributed the .dds cubemap loading capability that you > rejected. From that time I've been merging my changes with the latest head. > Cubemaps can still be loaded succesfully, but I agree that it may be better > to split osg::Image into multiple classes for the different osg::Textures > that it feeds. Are you envisioning a separate Image class for each Texture > class? No, my proposal of an osg::ImageArray class would need to be compatible with all Texture types. Not all would know enough about it to make use of it. My thought was the the osg::Image base classes sizes/type data pointers would be assigned to one of the osg::Image that the ImageArray manages so that a simple Texture2D texture would just select one of them, but a TextureCubeMap could go look for images 0,1,2,3,4,5, etc. > Side note: > Last week I ran into a problem with cubemaps in the osgOcean example which > turned out to be a pixelformat problem. The osgOcean example uses 6 separate > images of which one image has a different pixel format. My osg::Image class > supporting cubemaps has only one pixelformat for all 6 data planes and this > caused a problem when copying the six images into the single cubemap image. In the context of the osg::ImageArray class you'd probably want a function for querying of all the images are compatible, and perhaps a function for making them all the same. Possible texture cube map would also need to be written to cope between with different pixel formats. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] camera switching on a given view...
All, I have a question regarding camera switching in a particular view. I'm currently using the composite viewer where each view is set up in a separate window (via the call to view->setUpViewInWindow()). For a particular view(window), I need to swap from one camera to another upon request. Perusing through the examples and archives, I was unable to find any information on how I would accomplish this. I tried using view->setCamera() to swap out the current camera with another but this killed the view window. Can something like this be done or is it beyond the scope of the viewer paradigm? Thanks for any help. -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] No texture loaded on 3d model with osgViewer
Try setting the OSG_NOTIFY_LEVEL and see what error messages you are getting. That should tell you if it can find the texture and where it is looking. http://www.openscenegraph.org/projects/osg/wiki/Support/TipsAndTricks Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12281#12281 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] huds on multiple cameras
Hi again, I tried J-S 's suggestion about attaching the hud camera to a slave camera, but that did not work (i.e the scene is rendered, but there is not hud). viewer.getSlave( 0 )._camera->addChild( hudCamera ); Note that adding the hud camera to the scene (like in the hud example) did work in my test app. Is there something that need to be set in the hud camera to be able to attach it to the another camera? Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12282#12282 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] resizedImplementation bug when resizing slave camera
Hello Alexandre, Well apparently I did achieve to set up my application with 2 slave camera, but there is one last problem, I'm using a shader for my sky sphere wich isn't working when using 2 slave cameras, has anyone already had trouble with shaders and slave camera ? Do you mean that (for example) lighting calculations give the wrong results? IIRC, if you need the projection/view matrix then you can't use the built-in uniform from OpenGL, because that will be your slave camera's projection/view matrix. You need the master view's matrices, which means you'll have to copy the master camera's matrices into uniforms each frame. If that wasn't the problem, you'll have to be more clear. What do you mean by "a shader which isn't working"? How is it not working? Hope this helps, 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