Re: [osg-users] remove a view from a CompositeViewer
Hi gambr I had similar issues when adding/removing views from composite viewer. Finally my crashes were solved by stopping and restarting Threading ! The code then looks like this: Code: // adding m_Viewer.stopThreading(); m_Viewer.addView( a new view pointer ); m_Viewer.startThreading(); // removing m_Viewer.stopThreading(); m_Viewer.removeView( an existing view pointer ); m_Viewer.startThreading(); Regards Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57572#57572 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecated Indices in the Geometry class
Hi Stan, On 4 December 2013 18:00, Stan Coleby stan.col...@calabiyausystems.comwrote: Robert, Thank you for the wonderful job that you have been doing on OSG. I have been using it for over 10 years. Thanks. I am trying to update my application from 3.0.1 to 3.2.1 and discovered that osg::geometry class has deprecated the indices capabilities. I think that functionally that has been around for years should not be quickly eliminated like this. The functionality has been deprecated for YEARS. All the documentation in the osg::Geometry class has made it clear that you shouldn't use these deprecated functionality. The OSG has had to had to emulate indices functionality as modern OpenGL doesn't support it at. I have for YEARS being telling members of the community that do not use indices as they are deprecated and the emulation is very costly on CPU overhead. For YEARS I have been saying that my plan was to remove this functionality. When I did eventually remove it I did it discussing the changes fully with the community. I couldn't have been more public about seeking of feedback from the community. When I removed the functionality I provided an automatic conversion of old data with the deprecated functionality across to the compliant osg::Geometry. I also provided a subclass from osg::Geometry that provides the old API as before but within a deprecated_osg namespace. Go look at the include/osg/Geometry header. This is going to cost me a lot of time redesigning everything. I'm sorry but we can't improve the OSG by holding it back to those who ignore calls to avoid deprecated functionality. There was plenty of warning over the years and explanation of the issues. Making changes doesn't normally involve massive changes, the rest of the community has coped fine. My application deals with large amounts of lidar data. (22 million points per scan, 20-50 scans per scene; that’s a 1B points). In order to do this I have to cache and swap data a lot. I am using your IVE file to quickly move data in and out of memory. By removing the indices from osg::geometry, the OSG and IVE files will explode to 4 X the size and take 4 X longer to swap in and out. I only store the points once and use the indices to create the polygonal geometries when I need then. Not everything is always being displayed. I rely on osg::geometry as a data storage object in memory everywhere. It sounds like you are doing something wrong with how you represent your data. osg::Geometry supports glDrawElements via the osg::DrawElements primitive set, this has always been available and has long be the recommend way to pass indices to OpenGL - it's fully supported by all modern variants of OpenGL and OpenGL ES. Using vertex indices has never actually been supported by OpenGL, even OpenGL 1.0, but used by possible to use display lists and glBegin/glEnd to mimic it. glBegin/glEnd is no longer support so the OSG had to emulate it in software expanding all vertex indices arrays to non index arrays on the fly. This consumed memory and introduce a high CPU overhead. It was a really bad for performance and why it was so strongly recommended not use use vertex indices. I know that I can use the deprecated_osg::Geomerty in the short term but please consider creating a new osg::IndicesGeometry class to preserve functionality of Indices in the OSG and IVE files and don’t explode the data until it is needed by OpenGL. I think the explosion of the data into OpenGL is best served inside the IndicesGeometry class allowing applications to manage the data in Indices form. Vertex indices are a BAD BAD BAD solution. I STRONGLY recommend you ditch the idea that they are worthy of keeping, especially if you want to efficiently move lots of data from disk, to main memory to GPU. Please spend the time to understand how OpenGL and the OSG use vertex arrays, vertex buffer objects and the indexed primitive sets. These all work together an enable very efficient data managent without the need for big CPU overheads. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDEM] calculate height above ellipsoid in vertex shader
Hi Sebastian, Personally I'd subclass from osgTerrain::GeometryTechnique and pass a FloatArray as a vertex attrib array or tex coord array and store the heights there. Robert. On 4 December 2013 13:23, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi, I have a osgDEM produced geocentric database. I looked into the geometryTechnique implementation to see if I somehow can access the height of the vertices above the ellipsoid in the vertex shader. Unfortunately I don't have any idea how to calculate this from the give matrices. Is this information somehow available at all? My plan is to overwrite some of the functionality in the geometryTechnique to pass the appropriate matrices to the shader. Anyone having an idea? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to getting the number of vertices
Hi Kim, You should have the source code to the OSG, so just search through the sources of use osgUtil::Statistics, this will show exactly how it's used to get the onscreen stats that you see in osgviewer when you press 's' several times. Robert. On 6 December 2013 07:08, Kim JongBum osgfo...@tevs.eu wrote: i tried the osgUtil::Statistics class to get the number of vertices. but i couldn't make it. could u get me example of source? i would appreciate it thanks guys -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57571#57571 ___ 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] remove a view from a CompositeViewer
Hi Gianni, The stack trace for OSG-3.2 suggests that removed View's Camera is still assigned to the Geometry context, and you change to setGraphicsContext(0) address this. The CompositeViewer::removeView(..) should probably do the reset of the Camera so they are no longer assigned to GraphicsContext's, however, this would force applications to have to reassign the view's Camera to the GraphicsContext. The other alternative would be to reset the NodeMask of the Camera to 0x0 so it's not rendered. The OSG-3.1.4 crash looks likely to be a dangling pointer or an accessing an empty array, this code no longer exists so unlikely to be an issue for OSG-3.2 and svn/trunk. Robert. On 5 December 2013 16:09, Gianni Ambrosio ga...@vi-grade.com wrote: Hi All, in case this solution may be useful for others, I fixed the crash just setting the graphics context of the removing view to 0: view-getCamera()-setGraphicsContext(0); I also tried to stop camera threads but I got a null OperationThread so that would not help much. Waiting for Robert's opinion, I would leave with this fix in my application. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57560#57560 ___ 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] [osgDEM] calculate height above ellipsoid in vertex shader
Sabastian, osgEarth does more or less what Robert describes. We encode each vert's height value (and unit vector) in a vertex attribute. On Dec 6, 2013 5:43 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Sebastian, Personally I'd subclass from osgTerrain::GeometryTechnique and pass a FloatArray as a vertex attrib array or tex coord array and store the heights there. Robert. On 4 December 2013 13:23, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi, I have a osgDEM produced geocentric database. I looked into the geometryTechnique implementation to see if I somehow can access the height of the vertices above the ellipsoid in the vertex shader. Unfortunately I don't have any idea how to calculate this from the give matrices. Is this information somehow available at all? My plan is to overwrite some of the functionality in the geometryTechnique to pass the appropriate matrices to the shader. Anyone having an idea? ___ 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] [osgDEM] calculate height above ellipsoid in vertex shader
Am 06.12.2013 13:14, schrieb Glenn Waldron: Sabastian, osgEarth does more or less what Robert describes. We encode each vert's height value (and unit vector) in a vertex attribute. Thank you Glenn. Are the vertices relative to the Ellipsoid? Or can you point me to the sources where I can check it myself? cheers Sebastian On Dec 6, 2013 5:43 AM, Robert Osfield robert.osfi...@gmail.com mailto:robert.osfi...@gmail.com wrote: Hi Sebastian, Personally I'd subclass from osgTerrain::GeometryTechnique and pass a FloatArray as a vertex attrib array or tex coord array and store the heights there. Robert. On 4 December 2013 13:23, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: Hi, I have a osgDEM produced geocentric database. I looked into the geometryTechnique implementation to see if I somehow can access the height of the vertices above the ellipsoid in the vertex shader. Unfortunately I don't have any idea how to calculate this from the give matrices. Is this information somehow available at all? My plan is to overwrite some of the functionality in the geometryTechnique to pass the appropriate matrices to the shader. Anyone having an idea? ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] [osgDEM] calculate height above ellipsoid in vertex shader
Hi Robert, Hi Sebastian, Personally I'd subclass from osgTerrain::GeometryTechnique and pass a FloatArray as a vertex attrib array or tex coord array and store the heights there. Okay, that would double the data then. I'm a bit nervous about adding more vertex attributes as I already have a lot of data per vertex. Is there any option where I could pass the ModelMatrix (not the ModelViewMatrix) in a draw callback or something? The thing is that I might need more than simply the height, but probably the complete world-space vertex. As I wrote before I guess the precision is lost when using the osg_ViewMatrixInverse * ModelVIewMatrix, so moving this calculation to the CPU would help a lot. Robert. On 4 December 2013 13:23, Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de wrote: Hi, I have a osgDEM produced geocentric database. I looked into the geometryTechnique implementation to see if I somehow can access the height of the vertices above the ellipsoid in the vertex shader. Unfortunately I don't have any idea how to calculate this from the give matrices. Is this information somehow available at all? My plan is to overwrite some of the functionality in the geometryTechnique to pass the appropriate matrices to the shader. Anyone having an idea? ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] [osgDEM] calculate height above ellipsoid in vertex shader
Hi, I'm facing the same problem, and I can't pre-compute vertex attributes on CPU because my vertex are moved by the shader him-self (displacement mapping). I've tried to use double matrices, but these leads to a lot of compatibility problem. Since the precision problem is in the temporary computation and not in the final result (result values are small and fit well in a 32 bits float) I precompute (on CPU) lot of values in a 2048 (or 4096) pixels wide Texture1D. In the shader I have only to read in this look-up-table. There are some limitations (linear sampling, max input value in look up table...) but for my problem, it works very well. Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57581#57581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDEM] calculate height above ellipsoid in vertex shader
The heights are relative to the ellipsoid, yes. I can send you a code link when I get back (in on the road atm). On Dec 6, 2013 7:55 AM, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Am 06.12.2013 13:14, schrieb Glenn Waldron: Sabastian, osgEarth does more or less what Robert describes. We encode each vert's height value (and unit vector) in a vertex attribute. Thank you Glenn. Are the vertices relative to the Ellipsoid? Or can you point me to the sources where I can check it myself? cheers Sebastian On Dec 6, 2013 5:43 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Sebastian, Personally I'd subclass from osgTerrain::GeometryTechnique and pass a FloatArray as a vertex attrib array or tex coord array and store the heights there. Robert. On 4 December 2013 13:23, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi, I have a osgDEM produced geocentric database. I looked into the geometryTechnique implementation to see if I somehow can access the height of the vertices above the ellipsoid in the vertex shader. Unfortunately I don't have any idea how to calculate this from the give matrices. Is this information somehow available at all? My plan is to overwrite some of the functionality in the geometryTechnique to pass the appropriate matrices to the shader. Anyone having an idea? ___ 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 listosg-users@lists.openscenegraph.orghttp://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
[osg-users] About UTF-8 display
Hello all, This is my first time to use this. I faced some problem about display UTF-8 character like alpha and beta in OSG. Can any one give some idea? Thank you so much! The code was like this //-- osg::ref_ptrosgText::Text text = new osgText::Text; text-setFont(CAMBRIA.TTC); //text-setFont( font.get() ); text-setColor( white ); text-setCharacterSize( characterSize ); text-setPosition(OsgFunc::arrowArcTextPosition(centerPoint,centerPoint+osg::Vec3(-30,0,0),centerPoint+v)+osg::Vec3d(0,-5,1)); text-setAxisAlignment( osgText::Text::SCREEN ); text-setText( \x03b20,osgText::String::ENCODING_UTF8 ); geode-addDrawable( text.get() ); //-- Any idea will be greatly appreciated! Thank you so much! Litao Shen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG logo, now in 3D!
I was surprised to find that there is no 3D version of the OpenSceneGraph logo, at least not in the osg-data repository. I think OSG has been around long enough to deserve a 3D logo, so I had one of our artists whip up something. Here are two versions of the logo as osgb files. One is normal and the other has a black outline around the geometry. Normal: http://goo.gl/XgpjUQ Outline: http://goo.gl/IM6RKB Feel free to use these models however you like or add it to the osg-data repo. The model was created with 3ds Max and exported using the osgmaxexp exporter. You can find the 3ds Max file in the examples/logo folder of the osgmaxexp project (http://sourceforge.net/projects/osgmaxexp/). Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
