Re: [osg-users] OSGViewer Camera Coordinate System, elevation
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
Re: [osg-users] Question about osgViewer::View::EventHandlers
Hi J-S I did what you suggested and now it's working fine. Thnaks for your help and explanation. Moji the Great --- On Thu, 5/14/09, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Subject: Re: [osg-users] Question about osgViewer::View::EventHandlers To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Thursday, May 14, 2009, 9:21 PM Hi Moji, So is there any specific reason for using ref_ptr instead of observer_ptr in definition of osgViewer::View::EventHandlers? The viewer owns the event handlers, thus ref_ptr is the right choice. The normal usage of an event handler is: viewer-addEventHandler(new MyEventHandler); and thus the use of ref_ptr is appropriate in that case. Perhaps one solution would be to move the event handler functionality of your wrapper class into another internal class, add that event handler to the viewer and then use ref_ptr on your viewer but observer_ptr on your event handler. There would then be no ref_ptr cycles. Hope this helps, J-S -- __ Jean-Sebastien Guay jean-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] 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 paul1...@yahoo.com: 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 s.d.hamm...@googlemail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org 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 paul1...@yahoo.com: 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 bryan.thr...@flightsafety.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org 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=6t=5
cheers
Mattias
On 5/15/09, Abhinav Dubey dubey.abhin...@gmail.com 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 ]
nameC:\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 s.d.hamm...@googlemail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org 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 paul1...@yahoo.com: 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 bryan.thr...@flightsafety.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org 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 david.spill...@gmail.comwrote: 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 xe...@alphapixel.com 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 modjta...@yahoo.com 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 jpdelp...@csir.co.za 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) pierre.bour...@imerir.com 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 sherlock...@gmail.com 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 liujie...@gmail.com 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 alex.pix...@gmail.com 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 arti_t...@yahoo.de 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 robert.osfi...@gmail.com Hi Jie, On Fri, May 15, 2009 at 9:22 AM, Joe L liujie...@gmail.com 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 robert.osfi...@gmail.com
Hi Alexandre,
On Fri, May 15, 2009 at 9:55 AM, Alexandre Amalric
alex.pix...@gmail.com 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 RD
===
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 liujie...@gmail.com 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 alex.pix...@gmail.com 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 robert.osfi...@gmail.com HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com 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 RD === 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 liujie...@gmail.com 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/errno.h /* 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 was not
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::ProjectionShadowMapMinimalBoundsBaseClass, 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/errno.h /* 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=6t=5
cheers
Mattias
On 5/15/09, Abhinav Dubey dubey.abhin...@gmail.com 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 ]
nameC:\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 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/errno.h /* 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 tug...@vires.com 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
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 john.haugl...@gmail.com 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::ProjectionShadowMapMinimalBoundsBaseClass, 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/errno.h /* 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
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 john.haugl...@gmail.com 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::ProjectionShadowMapMinimalBoundsBaseClass, 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/errno.h /* 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
Re: [osg-users] VPB stuff
Hi Robert, is it the expected comportement ? log 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 /log 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) pierre.bour...@imerir.com 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 john.haugl...@gmail.com 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 alex.pix...@gmail.com 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 robert.osfi...@gmail.com HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com 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 RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === 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) pierre.bour...@imerir.com wrote: Hi Robert, is it the expected comportement ? log 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 /log 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) pierre.bour...@imerir.com 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 alex.pix...@gmail.com 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 alex.pix...@gmail.com 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 robert.osfi...@gmail.com HI Alexandre, On Fri, May 15, 2009 at 10:41 AM, Alexandre Amalric alex.pix...@gmail.com 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 RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === 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 robert.osfi...@gmail.comwrote: Hi John, On Fri, May 15, 2009 at 1:41 PM, John Ivar Haugland john.haugl...@gmail.com 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 john.haugl...@gmail.com 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) pierre.bour...@imerir.com wrote: Hi Robert, is it the expected comportement ? log 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 /log 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) pierre.bour...@imerir.com 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 jpdelp...@csir.co.za 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 jean-sebastien.g...@cm-labs.com 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 RD === 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 robert.osfi...@gmail.comwrote: Hi John, On Fri, May 15, 2009 at 1:59 PM, John Ivar Haugland john.haugl...@gmail.com 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 vincent.bourd...@gmail.com
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 arti_t...@yahoo.de
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 Registry
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::RegisterReaderWriterProxyclassname
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] [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=6t=5
cheers
Mattias
On 5/15/09, Abhinav Dubey dubey.abhin...@gmail.com 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 ]
nameC:\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 arti_t...@yahoo.de 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 john.haugl...@gmail.com 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 jean-sebastien.g...@cm-labs.com 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 RD === 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
robert.osfi...@gmail.com 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 osgDB/FileUtils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgDB/Registry
#include iostream
#include sstream
#include fstream
#include curl/curl.h
#include curl/types.h
#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: _cacheFileNamestd::endl;
_fout.open(_cacheFileName.c_str(), std::ios::out | std::ios::binary);
_foutOpened = true;
}
if (_fout)
{
_fout.write(ptr, realsize);
}
}
}
std::string EasyCurl::getResultMimeType(const StreamObject sp) const
{
return sp._resultMimeType;
}
size_t EasyCurl::StreamMemoryCallback(void *ptr, size_t size, size_t nmemb, void *data)
{
size_t realsize = size * nmemb;
StreamObject* sp = (StreamObject*)data;
sp-write((const char*)ptr, realsize);
return realsize;
}
///
//
// EasyCurl
//
EasyCurl::EasyCurl()
{
osg::notify(osg::INFO)EasyCurl::EasyCurl()std::endl;
_previousHttpAuthentication = 0;
_curl = curl_easy_init();
curl_easy_setopt(_curl, CURLOPT_USERAGENT, libcurl-agent/1.0);
curl_easy_setopt(_curl, CURLOPT_WRITEFUNCTION, StreamMemoryCallback);
curl_easy_setopt(_curl, CURLOPT_FOLLOWLOCATION, 1);
}
EasyCurl::~EasyCurl()
{
osg::notify(osg::INFO)EasyCurl::~EasyCurl()std::endl;
if (_curl) curl_easy_cleanup(_curl);
_curl = 0;
}
osgDB::ReaderWriter::ReadResult EasyCurl::read(const std::string proxyAddress, const std::string fileName, StreamObject sp, const osgDB::ReaderWriter::Options *options)
{
const osgDB::AuthenticationMap* authenticationMap = (options options-getAuthenticationMap()) ?
options-getAuthenticationMap() :
osgDB::Registry::instance()-getAuthenticationMap();
if(!proxyAddress.empty())
{
osg::notify(osg::INFO)Setting proxy: proxyAddressstd::endl;
curl_easy_setopt(_curl, CURLOPT_PROXY, proxyAddress.c_str()); //Sets proxy address and port on libcurl
}
const osgDB::AuthenticationDetails* details = authenticationMap ?
authenticationMap-getAuthenticationDetails(fileName) :
0;
// configure/reset authentication if required.
if (details)
{
const std::string colon(:);
std::string password(details-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);
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 guy.volcka...@meggitt.com 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 ree...@xs4all.nl 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 jd...@ist.ucf.edu 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 p...@eden.net.nz 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 pierre.bour...@imerir.com 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) pierre.bour...@imerir.com 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) pierre.bour...@imerir.com wrote: Hi Robert, is it the expected comportement ? log 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 /log 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) pierre.bour...@imerir.com 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
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_ptrCamera 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_ptrCamera 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_ptrosg::Image 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 roland.sme...@tno.nl 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
Re: [osg-users] VRML plugin
Hi Philip, 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. That, and the fact that OSG now supports a newer version of the COLLADA plugin which also has a dependency on boost, so there's precedent... I'm not sure the argument is valid anymore, and I'm pretty sure that if someone wanted to update the plugin and build scripts to be able to use a newer version of OpenVRML it would be accepted. 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
