Re: [osg-users] osgGlut does not build
Hi Bruce, OpenSceneGraph now has a osgviewerGLUT example. The ancient osgGLUT library really isn't worth looking at as it dates back to a time before time forgot. Robert. On Thu, May 28, 2009 at 6:51 PM, Clay, Bruce bc...@ball.com wrote: I can not get the osgGlut viewer to build either. The error list is attached below. I am using Visual Studio 2005 and compiling against OSG 2.8.1, OpenThreads and Producer both pulled with svn today. Several of the errors in this list come from STL Any thoughts? Bruce Error 1 error C2039: 'getPrims' : is not a member of 'osgUtil::RenderStage' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 626 Error 2 error C2039: 'getPrims' : is not a member of 'osgUtil::RenderStage' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 647 Error 3 error C2039: 'setTextureModeToInherit' : is not a member of 'osg::StateSet' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1122 Error 4 error C2679: binary '' : no operator found which takes a right-hand operand of type 'osg::LineSegment::vec_type' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1271 Error 5 error C2679: binary '' : no operator found which takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1294 Error 6 error C2679: binary '' : no operator found which takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1301 Error 7 error C2248: 'osg::AnimationPath::ControlPoint::_position' : cannot access protected member declared in class 'osg::AnimationPath::ControlPoint' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1370 Error 8 error C2679: binary '' : no operator found which takes a right-hand operand of type 'const osg::Vec3d' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1370 Error 9 error C2248: 'osg::AnimationPath::ControlPoint::_rotation' : cannot access protected member declared in class 'osg::AnimationPath::ControlPoint' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1370 Error 10 error C3083: 'PrimtiveValueMap': the symbol to the left of a '::' must be a type f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 11 error C2039: 'iterator' : is not a member of 'osgUtil::Statistics' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 12 error C2133: 'pItr' : unknown size f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 13 error C2512: 'std::iterator' : no appropriate default constructor available f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 14 error C2582: 'operator =' function is unavailable in 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1770 Error 15 error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'std::iterator' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1771 Error 16 error C2675: unary '++' : 'std::iterator' does not define this operator or a conversion to a type acceptable to the predefined operator f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1772 Error 17 error C2819: type 'std::iterator' does not have an overloaded member 'operator -' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1774 Error 18 error C2039: 'second' : is not a member of 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1774 Error 19 error C2228: left of '.first' must have class/struct/union f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1774 Error 20 error C2819: type 'std::iterator' does not have an overloaded member 'operator -' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1775 Error 21 error C2039: 'second' : is not a member of 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1775 Error 22 error C2228: left of '.second' must have class/struct/union f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1775 Error 23 error C2819: type 'std::iterator' does not have an overloaded member 'operator -' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1776 Error 24 error C2039: 'first' : is not a member of 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1776 Error 25 error C2582: 'operator =' function is unavailable in 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1784 Error
Re: [osg-users] Hope this is the right way to post this (osgEphemeris problem with simple example)
Hi Don, Last month I had a quick trial of adding Cmake support to osgEmpheris. This version I worked I've put into svn up on openscenegraph.org, this builds with the latest OSG. svn co http://www.openscenegraph.org/svn/osgEphemeris/trunk/ osgEphemeris I did the port to CMake by am not the original author, nor have used osgEphemeris in projects before so I'm afraid I can't provide my assistance with it's usage. Robert. On Thu, May 28, 2009 at 7:18 PM, Don Dakin donald.da...@aero.bombardier.com wrote: Hi Richard, I have not yet come to compiling any example/sample code to check these features out. I stopped at trying with the simple example when it did not work. I could try it with codeing it up but that would require more time. If there is no quick answer to this working using osgviewer then I will put this on the back burner and try an example with some code when I have the time to look into that. Thanks again Don. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13120#13120 ___ 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] Drawing a point
HI Moji,
You are falling foul of small feature culling as your bounding volume
has zero size. You can disable small feature culling by doing:
viewer.getCamera()-setCullingMode(
viewer.getCamera()-getCullingMode()
~osg::CullSettings::SMALL_FEATURE_CULLING);
Robert.
On Thu, May 28, 2009 at 11:04 PM, Mojtaba Fathi modjta...@yahoo.com wrote:
Hi all
Accept my apology for such a simple question. I want to display two
coincident points at (0,0,0). I use code like this:
int main()
{
osgViewer::Viewer viewer;
osg::ref_ptrosg::Group root (new osg::Group);
osg::ref_ptrosg::Geode geode (new osg::Geode());
osg::ref_ptrosg::Geometry geometry (new osg::Geometry());
osg::ref_ptrosg::Vec3Array vertices (new osg::Vec3Array());
vertices-push_back (osg::Vec3 ( 0.0, 0.0, 0.0));
vertices-push_back (osg::Vec3 ( 0.0, 0.0, 0.0));
geometry-setVertexArray (vertices.get());
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POINTS,0,vertices-size()));
osg::Point *point=new osg::Point;
point-setSize(4);
root-getOrCreateStateSet()-setAttribute(point);
geode-addDrawable (geometry.get());
root-addChild(geode.get());
viewer.setSceneData( root.get() );
return (viewer.run());
}
But it displays nothing. I think it relates to BoundingBox and culling, so
what should I do to display two coincident points at (0,0,0)? And how to do
it for just one point?
Regards, Moji
___
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] Looking for GLSL Parallax Occlusion Mapping
Hi Chris, you could be interested by the work of Kevin Boulanger http://www.kevinboulanger.net/grass.html For a parallax sample using GLSL there are probably a lot of samples on ATI or Nvidia developper site, but maybe you'll find some interesting demo on ozone3d: http://www.ozone3d.net/demos_projects/index.php?lang=2 Pierre. Le jeudi 28 mai 2009 à 13:54 -0600, Chris 'Xenon' Hanson a écrit : I've tried posting this a couple of times, and it disappears. It went through yesterday as a reply to a test post, so I'm going to try again with the proper subject. I'm looking to add extra visual realism to surfaces using shaders. Grass, gravel and dirt are some of the obvious candidates, but there could be others. I am hoping to use a type of Parallax Mapping. I have a few algorithms of basic Parallax Mapping, but they fall apart at glancing angles close to the ground (where the user viewpoint will frequently be). Tatarchuk's Parallax Occlusion Mapping: http://ati.amd.com/developer/SIGGRAPH05/Tatarchuk-ParallaxOcclusionMapping-Sketch-print.pdf http://ati.amd.com/developer/gdc/Tatarchuk-ParallaxOcclusionMapping-FINAL_Print.pdf http://ati.amd.com/developer/gdc/2006/GDC06-Tatarchuk-Parallax_Occlusion_Mapping.pdf Seems to solve many of the issues. The GDC 06 paper with the allegedly improved algorithm only talks about HLSL and DirectX. I'm interested in checking this algorithm out to see how it performs (I'm designing shaders in RenderMonkey) but I've had a hard time finding working GLSL source for anything newer than the original Parallax Shader from 04 and earlier. I don't want to write and debug an implementation from scratch just to find out it doesn't do the job, so I was hoping to find a working implementation somewhere, but am not finding one. Anyone seen one? It looks like a heck of a technique and could really be used to great purpose in landscapes, and well, just about anything with surface detail. Anyone know where to find something like this? Also, I'm interested in other sources of canned shaders. I'm not trying to do cutting-edge research, I'm just trying to apply the best available technology to a visualization problem to give the best results without reinventing the wheel. 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] add/remove camera crash
Hi Robert, I have played with that thing a bit. But without success so far. The first thought is: Should the Render Stage have a reference to the camera instead of just a pointer? Since the RenderStage relies on the Camera being present, this appears to be the /right/ way to get that. ... but then we have a cylclic reference count loop: Camera-RenderCache-RenderStage-back to Camera. So, should we cache the render stages for the cameras somewhere different. May be also in the cull visitor? That would probably break the reference cycle?! Does this sound reasonable? Other thoughts? Beside that, I have also observed that caching Render stages by the Camera itself is probably not sufficient. We may have two post render Cameras with relative transforms referenced through more than one node path. But these will end up rendered with the same render stage instance. True? If so you will not see every such Camera rendered correctly. Only the last one traversed by the cull visitor will render correctly. True? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak problem
Hi Amujika, There is what reference counting is for - to automatically manage memory like this. You don't really provide enough information about how you are defining and using this m_geom pointer so we can only guess at what the problem might be. If you aren't using ref_ptr for m_geom you certainly should be. Robert. On Fri, May 29, 2009 at 9:43 AM, Andoni Mujika amuj...@vicomtech.org wrote: Hi, In my programm I have this line inside the viewer's loop: m_geom = (osg::Vec3Array*) ((dynamic_castosg::Vec3Array* (m_NewGeom)-clone(osg::CopyOp::DEEP_COPY_ARRAYS))); The memory used increases untill the programm fails. I tried delete m_geom, m_geom-clear() and m_geom-erase but it didn't work. How can I release this memory? Thanks, Amujika ___ 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] add/remove camera crash
Hi Mathias, 2009/5/29 Mathias Fröhlich m.froehl...@science-computing.de: Should the Render Stage have a reference to the camera instead of just a pointer? Since the RenderStage relies on the Camera being present, this appears to be the /right/ way to get that. Um not quite as you provide the answer why not... ... but then we have a cylclic reference count loop: Camera-RenderCache-RenderStage-back to Camera. So, should we cache the render stages for the cameras somewhere different. May be also in the cull visitor? That would probably break the reference cycle?! Does this sound reasonable? Other thoughts? Use a observer_ptrCamera instead of a Camera*, or register the RenderStage as an Observer of the Camera parent so RenderStage gets called when Camera gets deleted. Eitherway this is all a bit moot as if the Camera is being deleted the RenderStage will be deleted along with... so you really are just hiding the problem. The problem is that you can't delete an object whilest another thread is still using it. The easiest way to address this is to stop the threading. The more complex way is to synchronize the threads in some fasion. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
For a parallax sample using GLSL there are probably a lot of samples on ATI or Nvidia developper site, but maybe you'll find some interesting demo on ozone3d: n Strangely that preview for Parallax Bump Mapping demo says Source Code: [YES] but when you go to the detail page and download the demo ( ParallaxMapping_Demo.zip ) there is no source code to be seen. I am also looking for this rendering technique to make some realistic rendering of coins with an embossed imprint. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] add/remove camera crash
On Friday 29 May 2009, Robert Osfield wrote: Hi Mathias, 2009/5/29 Mathias Fröhlich m.froehl...@science-computing.de: Should the Render Stage have a reference to the camera instead of just a pointer? Since the RenderStage relies on the Camera being present, this appears to be the /right/ way to get that. Um not quite as you provide the answer why not... ... but then we have a cylclic reference count loop: Camera-RenderCache-RenderStage-back to Camera. So, should we cache the render stages for the cameras somewhere different. May be also in the cull visitor? That would probably break the reference cycle?! Does this sound reasonable? Other thoughts? Use a observer_ptrCamera instead of a Camera*, or register the RenderStage as an Observer of the Camera parent so RenderStage gets called when Camera gets deleted. The observer_ptr is not thread safe! There is a race between asking the observer_ptr if it is valid and the object you have no counted reference on being deleted before accessing it. And there is no atomic way to get a ref_ptr from an observed_ptr without that race. The std::weak_ptr concept where you can get a ref_ptr by the weak_ptr.lock() method in an atomic way would provide a thread safe way to use that. Not yet thought about how and if the existing observed_ptr could be changed to make that safe. My implementation of such a referenced/weak pointer thing is completely different than what is currently in osg. Eitherway this is all a bit moot as if the Camera is being deleted the RenderStage will be deleted along with... so you really are just hiding the problem. The problem is that you can't delete an object whilest another thread is still using it. The easiest way to address this is to stop the threading. The more complex way is to synchronize the threads in some fasion. So, I wonder how is this solved for models that are being deleted by a Paged model? Should this already work? Just wondering if I can safely use pre/post Cameras in paged models? What am I missing here in the thread picture? Also I thought that in the concrete problem. The event stage (as well as the update stage) is something that is serialized enough to modify the scenegraph (may be also throwing away a Camera)? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak problem
Hi Amujika, There really is nothing anybody can say to help given the scant details of what you are doing. Robert. On Fri, May 29, 2009 at 11:04 AM, Andoni Mujika amuj...@vicomtech.org wrote: Hi Robert, Sorry for not being very precise. I also tried osg::ref_ptr. Now, the code looks like this: osg::ref_ptrosg::Vec3Array m_geom; m_geom = (osg::Vec3Array*) ((dynamic_castosg::Vec3Array* (m_NewGeom)-clone(osg::CopyOp::DEEP_COPY_ARRAYS))); the memory grows and grows... Thank you, Amujika ___ 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] memory leak problem
Hi Robert, Sorry for not being very precise. I also tried osg::ref_ptr. Now, the code looks like this: osg::ref_ptrosg::Vec3Array m_geom; *m_geom = (osg::Vec3Array*) ((dynamic_castosg::Vec3Array*** (m_NewGeom)-clone(osg::CopyOp::DEEP_COPY_ARRAYS))); the memory grows and grows... Thank you, Amujika * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak problem
Andoni Mujika wrote: Hi Robert, Sorry for not being very precise. I also tried osg::ref_ptr. Now, the code looks like this: osg::ref_ptrosg::Vec3Array m_geom; /m_geom = (osg::Vec3Array*) ((dynamic_castosg::Vec3Array*// (m_NewGeom)-clone(osg::CopyOp::DEEP_COPY_ARRAYS))); the memory grows and grows... / Are you developing on Linux? If so, you might want to give valgrind a try and specifically its 'massif' tool. This allows you to track memory usage during a programs run and can (in principle) provide you with information where all the memory you're seeing was allocated. Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] set type of atomic operations via CMake?
Hi, El Viernes 29 Mayo 2009ES 13:18:07 Mathias Fröhlich escribió: So is there a way to force this setting via CMake? Or use the chosen SDK when compiling the atomic-test? I tried some stuff, but didn't succeed. Currently not. I was struggling with a simliar issue this week (http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg27737.html) so I wrote a little patch in order to have the possibility of at least deactivating the use of those instructions manually. The patch respects current behaviour by default, but creates a new boolean switch in order to deactivate manually those operations if it's needed. I can post it in case it's useful to you. Regards, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Transparency and hdr texture
Hi, Does anyone know an image format storing high dynamic range values (32 bits per pixel) and transparency ? Thanks, Josselin This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
I think I got it with the sources when I tried... You should probably contact the webmaster of the ozone web site. Pierre. Le vendredi 29 mai 2009 à 11:28 +0200, Christian Buchner a écrit : For a parallax sample using GLSL there are probably a lot of samples on ATI or Nvidia developper site, but maybe you'll find some interesting demo on ozone3d: n Strangely that preview for Parallax Bump Mapping demo says Source Code: [YES] but when you go to the detail page and download the demo ( ParallaxMapping_Demo.zip ) there is no source code to be seen. I am also looking for this rendering technique to make some realistic rendering of coins with an embossed imprint. Christian 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] Dragger snap to grid / raster
20 pixel is only a value.. i want to implement a snapping grid for a dragger how can i set the snapping to dragger? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13173#13173 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::ref_ptr used anymore
Hi, Thanks for the replies. They really clarified a lot. Looks like for small pointer, it's all or none deal, e.g. it's best to use them every time a reference to the pointed object is needed. Thank you! Cheers, Rabbi -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13175#13175 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
Christian Buchner wrote: Strangely that preview for Parallax Bump Mapping demo says Source Code: [YES] but when you go to the detail page and download the demo ( ParallaxMapping_Demo.zip ) there is no source code to be seen. I am also looking for this rendering technique to make some realistic rendering of coins with an embossed imprint. Here is a link to NVidia's bump mapping demo, which also includes the simple parallax mapping technique (I don't know why folks have such a hard time finding this, it took me about five seconds). This demo uses GLSL, so it should be easy to integrate into whatever you're trying to do. There are a lot of other examples on this page as well. http://developer.download.nvidia.com/SDK/9.5/Samples/samples.html#glsl_bump_mapping --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Access vertices and faces after load the model
Thrall, Bryan wrote:
Paul Martz wrote on Thursday, May 28, 2009 4:50 PM:
You use a NodeVisitor to walk your scene graph and look for Geodes,
then iterate over the Drawables that are attached to the Geodes, using
dynamic_cast to access the Drawable as a Geometry.
Even better, I notice osg::Drawable has asGeometry(), which is cheaper
than dynamic_cast :)
Wow, I wasn't expecting the difference to be this large, as virtual
function calls aren't completely free either:
16:51|p...@tabu:~ cat t.cpp
// g++ -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB
#include osgDB/ReadFile
#include sys/time.h
float
timediff(struct timeval t0, struct timeval t1)
{
return 1000 * (t1.tv_sec - t0.tv_sec) + (t1.tv_usec - t0.tv_usec) /
1000.0;
}
int main()
{
osg::Group* cow = (osg::Group*)osgDB::readNodeFile(cow.osg);
osg::Geode* geode = (osg::Geode*)cow-getChild(0);
osg::Drawable *draw = geode-getDrawable(0);
boolisgeom = true;
int i;
struct timeval t0, t1, t2;
const int N = 10;
gettimeofday(t0, NULL);
for (i = 0; i N; i++)
isgeom = isgeom (draw-asGeometry() != NULL);
gettimeofday(t1, NULL);
for (i = 0; i N; i++)
isgeom = isgeom (dynamic_castosg::Geometry*(draw) != NULL);
gettimeofday(t2, NULL);
printf(%d\n, isgeom); // need to use isgeom, as otherwise it
might be optimized away
printf(asGeometry(): %.3f ms\n, timediff(t0, t1));
printf(dynamic_cast(): %.3f ms\n, timediff(t1, t2));
}
16:52|p...@tabu:~ g++ -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/
-losg -losgDB
16:52|p...@tabu:~ ./t
1
asGeometry(): 1.181 ms
dynamic_cast(): 3.945 ms
16:52|p...@tabu:~ g++ -O3 -o t t.cpp -I ~/osg2.8/include/ -L
~/osg2.8/lib/ -losg -losgDB
16:52|p...@tabu:~ ./t
1
asGeometry(): 0.839 ms
dynamic_cast(): 3.611 ms
16:52|p...@tabu:~
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency and hdr texture
josselin.pe...@lcpc.fr wrote: Hi, Does anyone know an image format storing high dynamic range values (32 bits per pixel) and transparency ? I believe OSG supports OpenEXR, which was designed by Industrial Light and Magic for this purpose. I think it supports both half-float and float formats, and it's probably the highest-quality format for HDR pictures. There is also the HDR format, but I think it only does RGBE, not float. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] add/remove camera crash
Hi Mathias, 2009/5/29 Mathias Fröhlich m.froehl...@science-computing.de: There is a race between asking the observer_ptr if it is valid and the object you have no counted reference on being deleted before accessing it. And there is no atomic way to get a ref_ptr from an observed_ptr without that race. I went for a lightweight observer implementation, rather than go the route of requiring ref_ptr construction for access like std::weak_ptr requires. The later is more robust in the presence of threading, but slower. To make a thread safe implementation we'd need to add a mutex into the observer to protect access to _ptr and add a ref_ptr as the accessors. Right now one should obviously take care of what contexts you use observer_ptr. Using the Observer interface doesn't have this problem though, as one could easily manage the thread safe on the observer side. For this particular problem observer_ptr isn't appropriate - it's the Camera that owns the RenderStage that needs to be managed correctly. The problem is that you can't delete an object whilest another thread is still using it. The easiest way to address this is to stop the threading. The more complex way is to synchronize the threads in some fasion. So, I wonder how is this solved for models that are being deleted by a Paged model? Should this already work? Just wondering if I can safely use pre/post Cameras in paged models? What am I missing here in the thread picture? Interesting issue. Normally nodes don't make it into the rendering backend, but in scene graph Camera's are the exception, the StateSet and Drawable are all reference counted in the rendering backend so that aren't effected by the possibility of scene graph elements being deleted which the draw traversal is running. So potentially one could have a Camera node removed during update such as pageing that overlaps with the draw traversal when running in DrawThreadPerContext and CullDrawThreadPerContext. The CullDrawThreadPerContext and SingleThreaded models won't be affected as the draw traversals won't be affected. Also I thought that in the concrete problem. The event stage (as well as the update stage) is something that is serialized enough to modify the scenegraph (may be also throwing away a Camera)? Removing a Camera that is being used in a rendering thread will be unsafe no matter when it's done. Right now the way to avoid problems is use CullDrawThreadPerContext/SingleThreaded or stop threading when removing Cameras. To allow us to remove Camera's from the scene graph whilst the draw thread is still running will require the draw thread to take a reference to Camera while it's being used. It might be possible to tweak the osgViewer::Renderer so that it keeps tabs on what RenderStage and associated Camera's are in action and to take a reference where appropriate. Perhaps RenderStage itself could be tweaked to allow on to increment/decrement the ref count of all associated Camera's under the control of the Renderer. Perhaps another tweak might be to have the whole Rendering backend manage the reference counts for StateSet and Drawables as well as Camera in a high level way, as then we could toggle on/off the reference counting when we need it rather than have it on even when it isn't neccessary - such as in SingleThreaded and CullDrawThreadPerContext threading models. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Access vertices and faces after load the model
Touché! :-) Cheers, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Thrall, Bryan Paul Martz wrote on Thursday, May 28, 2009 4:50 PM: You use a NodeVisitor to walk your scene graph and look for Geodes, then iterate over the Drawables that are attached to the Geodes, using dynamic_cast to access the Drawable as a Geometry. Even better, I notice osg::Drawable has asGeometry(), which is cheaper than dynamic_cast :) -- 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
Re: [osg-users] osg::ref_ptr used anymore
I used to tell people once you become familiar with ref_ptrs, you'll learn where you need them and where you don't, and you can get away with using regular C/C++ pointers in some cases. I've stopped telling people this, because I have caught myself multiple times using regular C/C++ pointers, then later changing the code and assuming it was ref counted, and therefore introducing a leak. Yes, it's best to always use ref_ptr. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Rabbi Robinson Sent: Friday, May 29, 2009 8:38 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osg::ref_ptr used anymore Hi, Thanks for the replies. They really clarified a lot. Looks like for small pointer, it's all or none deal, e.g. it's best to use them every time a reference to the pointed object is needed. Thank you! Cheers, Rabbi -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13175#13175 ___ 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] Accessing Texture Indices
omaralvi wrote: Hello guys, I am new to osg. I have loaded an obj file using osgDB but I don't know how to access vertex and texture indices. I can get the vertex array from the geometry using pGeo.get()-getVertexArray() method but pGeo.get()-getVertexIndices() returns null. I cant figure out how the indices are stored for the vertices and the texture. The model is loaded and displayed fine so there is definitely a problem in the way I am accessing the data. Would really appreciate any help. Thanks Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it out. -- Post generated by Mail2Forum Hi I'm new to OSG and having the same problem. check this website, it may helpful. http://delta3d.wiki.sourceforge.net/Accessing+Underlying+OpenSceneGraph+Geometry -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13183#13183 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Access vertices and faces after load the model
Paul Melis wrote on Friday, May 29, 2009 9:55 AM: Thrall, Bryan wrote: Paul Martz wrote on Thursday, May 28, 2009 4:50 PM: You use a NodeVisitor to walk your scene graph and look for Geodes, then iterate over the Drawables that are attached to the Geodes, using dynamic_cast to access the Drawable as a Geometry. Even better, I notice osg::Drawable has asGeometry(), which is cheaper than dynamic_cast :) Wow, I wasn't expecting the difference to be this large, as virtual function calls aren't completely free either: ... 16:52|p...@tabu:~ ./t 1 asGeometry(): 1.181 ms dynamic_cast(): 3.945 ms 16:52|p...@tabu:~ g++ -O3 -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB 16:52|p...@tabu:~ ./t 1 asGeometry(): 0.839 ms dynamic_cast(): 3.611 ms 16:52|p...@tabu:~ That's even more impressive than I was expecting! -- 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
Re: [osg-users] Access vertices and faces after load the model
Hello Guys, To my original problem. I found a website which is quite useful and works. Just in case others may need it. http://delta3d.wiki.sourceforge.net/Accessing+Underlying+OpenSceneGraph+Geometry Thank you! Cheers, Xin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13184#13184 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
Jason Daly wrote: Christian Buchner wrote: Strangely that preview for Parallax Bump Mapping demo says Source Code: [YES] but when you go to the detail page and download the demo ( ParallaxMapping_Demo.zip ) there is no source code to be seen. I am also looking for this rendering technique to make some realistic rendering of coins with an embossed imprint. Here is a link to NVidia's bump mapping demo, which also includes the simple parallax mapping technique (I don't know why folks have such a hard time finding this, it took me about five seconds). This demo uses GLSL, so it should be easy to integrate into whatever you're trying to do. There are a lot of other examples on this page as well. http://developer.download.nvidia.com/SDK/9.5/Samples/samples.html#glsl_bump_mapping Yes, but I don't think that's the New and Improved version -- Parallax Occlusion Mapping. There are several Parallax Mapping sources out there, but basic PM falls apart visually at low view angles, whereas POM does much better. --J -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
Chris 'Xenon' Hanson wrote: Yes, but I don't think that's the New and Improved version -- Parallax Occlusion Mapping. No, it's not. I was replying to Christian's message for his coin rendering application. There are several Parallax Mapping sources out there, but basic PM falls apart visually at low view angles, whereas POM does much better. Indeed. Was the gamedev.net article I sent any use? I still think you'll find that translating HLSL to GLSL isn't as hard as it sounds. The only issues I can think of will be the extra functionality that the .fx files provide (multiple passes/techniques, etc), but OSG should let you handle these pretty easily if you're just writing an application. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Inserting a Switch node into the SG
What you have looks basically right, except I don't understand why you have: ref_ptrGroup group = new Group; switchnode-addChild(group.get()); That seems unnecessary to the task at hand. How are you determining that you are getting the wrong results? What you show as the result seems impossible for the code you've posted, as 'parent' only adds one child: the switch. Inserting a node above another node is a common task and one that is somewhat error-prone to implement. I've often wondered if it would make sense to have Node methods for insertAbove() and insertBelow(). This was a feature in PEI VisKit and we made frequent use of it at my old employer. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] smooth angle on normal calculation
Hi, iam looking for a function that calculates normals by given smooth angle or is it already implemented? Thank you! Cheers, Matthias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13188#13188 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] smooth angle on normal calculation
There is the osgUtil SmoothingVisitor, which will compute a normal per vertex by averaging the facet normals of shared polygons. Will that do what you want? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Matthias Asselborn Sent: Friday, May 29, 2009 10:40 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] smooth angle on normal calculation Hi, iam looking for a function that calculates normals by given smooth angle or is it already implemented? Thank you! Cheers, Matthias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13188#13188 ___ 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] Looking for GLSL Parallax Occlusion Mapping
Jason Daly wrote: Indeed. Was the gamedev.net article I sent any use? I still think you'll find that translating HLSL to GLSL isn't as hard as it sounds. The only issues I can think of will be the extra functionality that the .fx files provide (multiple passes/techniques, etc), but OSG should let you handle these pretty easily if you're just writing an application. I haven't tried yet. I am still getting the confidence up to try to tackle the conversion. --J -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgGlut does not build
Thanks Robert. I updated my source tree and found the program you mentioned. For some odd reason I am getting links error from gz and ive plug-ins for various methods that are in the zlib123 libraries. I have tried both zlibstat.lib and zlibwapi.lib and get the same errors both ways. If I open the libraries in the debugger I can see the strings (i.e inflate, inflateEnd inflateinit2 etc). I have checked the path to the libraries several times and I am not getting a library not found error. Is there a different ZLIB library that I should be using? Bruce -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, May 29, 2009 3:29 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgGlut does not build Hi Bruce, OpenSceneGraph now has a osgviewerGLUT example. The ancient osgGLUT library really isn't worth looking at as it dates back to a time before time forgot. Robert. On Thu, May 28, 2009 at 6:51 PM, Clay, Bruce bc...@ball.com wrote: I can not get the osgGlut viewer to build either. The error list is attached below. I am using Visual Studio 2005 and compiling against OSG 2.8.1, OpenThreads and Producer both pulled with svn today. Several of the errors in this list come from STL Any thoughts? Bruce Error 1 error C2039: 'getPrims' : is not a member of 'osgUtil::RenderStage' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 626 Error 2 error C2039: 'getPrims' : is not a member of 'osgUtil::RenderStage' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 647 Error 3 error C2039: 'setTextureModeToInherit' : is not a member of 'osg::StateSet' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1122 Error 4 error C2679: binary '' : no operator found which takes a right-hand operand of type 'osg::LineSegment::vec_type' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1271 Error 5 error C2679: binary '' : no operator found which takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1294 Error 6 error C2679: binary '' : no operator found which takes a right-hand operand of type 'osg::Vec3' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1301 Error 7 error C2248: 'osg::AnimationPath::ControlPoint::_position' : cannot access protected member declared in class 'osg::AnimationPath::ControlPoint' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1370 Error 8 error C2679: binary '' : no operator found which takes a right-hand operand of type 'const osg::Vec3d' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1370 Error 9 error C2248: 'osg::AnimationPath::ControlPoint::_rotation' : cannot access protected member declared in class 'osg::AnimationPath::ControlPoint' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1370 Error 10 error C3083: 'PrimtiveValueMap': the symbol to the left of a '::' must be a type f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 11 error C2039: 'iterator' : is not a member of 'osgUtil::Statistics' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 12 error C2133: 'pItr' : unknown size f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 13 error C2512: 'std::iterator' : no appropriate default constructor available f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1769 Error 14 error C2582: 'operator =' function is unavailable in 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1770 Error 15 error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'std::iterator' (or there is no acceptable conversion) f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1771 Error 16 error C2675: unary '++' : 'std::iterator' does not define this operator or a conversion to a type acceptable to the predefined operator f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1772 Error 17 error C2819: type 'std::iterator' does not have an overloaded member 'operator -' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1774 Error 18 error C2039: 'second' : is not a member of 'std::iterator' f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1774 Error 19 error C2228: left of '.first' must have class/struct/union f:\Projects\LIDAR\osgGLUT\src\osgGLUT\Viewer.cpp 1774 Error 20 error C2819: type 'std::iterator' does not have an overloaded member 'operator -'
Re: [osg-users] osgGlut does not build
Hi Bruce, For some odd reason I am getting links error from gz and ive plug-ins for various methods that are in the zlib123 libraries. I have tried both zlibstat.lib and zlibwapi.lib and get the same errors both ways. If I open the libraries in the debugger I can see the strings (i.e inflate, inflateEnd inflateinit2 etc). I have checked the path to the libraries several times and I am not getting a library not found error. Is there a different ZLIB library that I should be using? Perhaps you still have the old dependencies from OSG pre-1.9 days? The dependencies have been updated a few times since then, so perhaps they're using functions that were not in previous versions. See http://www.openscenegraph.org/projects/osg/wiki/Downloads/Dependencies for how to get up to date prebuilt dependencies for your compiler. 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] Can I change the plugin directory structure?
Thanks for the help guys, and the reminder to check the previous posts and the web-site. UNFORTUNATELY: Being able to run an example directly from Visual Studio (using Set As Active Project and pressing F5) is another issue. You need to first run at least the ALL_BUILD target, so that all plugins will be built. That's because none of the OSG DLLs or examples have the plugins as dependencies, as it should be - the plugins are dynamically loaded, and as such no executable can know /a/ /priori/ which plugins it will need, it all depends on what is loaded either from the command line or the code. Once you've run the ALL_BUILD target (or INSTALL, which depends on ALL_BUILD) then the examples will find the plugins just fine, you can run them with F5 no problem. I am not finding this to be the case. When running with F5 or Ctrl-F5, VS runs the example from where it compiled to, NOT where the INSTALL project sends it. In my case, bin\Release\. I have built all the plugins, and the go to bin\Release\..\osgPlugins-2.x.x\, which appears to be in the wrong relative place (one directory too high) for osgDB to find it. I am not sure where the extra ..\ is coming from, does any one know? Something else that I thought would be nice is if the examples knew where the sample data is. That way it could set the working directory for debugging to where the samples are, and it should just run when you hit F5 (or Ctrl-F5). Just set your CMAKE_INSTALL_PREFIX to some directory where you want the latest OSG binaries+libs+headers to be placed ... Unfortunately this does not do it either, it creates the osgPlugins-2.x.x whether I want it or not. Then just copy the right version of the OSG DLLs into your app's bin directory (with its executable) and the osgPlugins-VERSION directory there too (with the plugins inside the directory). ...somepath/bin/myapp.exe ...somepath/bin/osg.dll ...somepath/bin/all other dlls you need ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll ...somepath/bin/osgPlugins-x.y.z/all other plugins you need Well, there is the rub. To keep from having to do all this manually, I created a bat file to do the copying for me. Whenever either one of us upgrades OSG, we have to remember to go and change that bat file to include the new version number. Just one more thing to forget to do. Thanks, and sorry for the whining. I love OSG and all this community does. If it is just a matter of changing something somewhere on my end, please let me know. -- Rick On Fri, May 29, 2009 at 6:46 AM, James Killian james_kill...@hotmail.comwrote: Sorry about that... I did fix, and then I had to forward an email to Rick about the osgParticle (as I had to use html to preserve the diagram's spacing) I have now switched it back to plain text. Thanks for letting me know. (there are too few of us in the dark side for microsoft to do something about it) : ( I have recopied email in plain text below: James Killian - Original Message - From: James Killian james_kill...@hotmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Cc: Rick Pingry rpin...@gmail.com Sent: Thursday, May 28, 2009 10:25 PM Subject: Re: [osg-users] Can I change the plugin directory structure? Then just copy the right version of the OSG DLLs into your app's bin directory (with its executable) and the osgPlugins-VERSION directory there too (with the plugins inside the directory). .somepath/bin/myapp.exe .somepath/bin/osg.dll .somepath/bin/all other dlls you need .somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll .somepath/bin/osgPlugins-x.y.z/all other plugins you need I should review the code as I suspect it uses relative paths to retrieve the plugins. If so, there should be a clause that client code must not dominate the CWD as ours currently does. One thing I know for sure is that this path setup does not work right with our game in its current state. Thanks for taking the time out to explain. Hopefully we may find a better solution. James Killian - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Thursday, May 28, 2009 8:07 PM Subject: Re: [osg-users] Can I change the plugin directory structure? Hello Rick, I have noticed that for the past little while the plugins are compiled to their own directory with the version number. I am not quite sure why this is beneficial, it seems like you would always want the plugins compiled with the version of OSG you have compiled, and it seems that having them in the same folder with the other binaries ensures that the proper dll's will be found. Well, copying the plugins into the same directory as your application ensures that *some* *version* of the plugin will be found, not necessarily the right one (unless you're extra careful). There have been enough cases in the past of people only updating the main OSG DLLs, omitting to also update the plugins,
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hi, I have just been bitten by and wasted hours on with this 'issue' with VC++ 2005 . As noted you cannot mix vectors across Release Mode libraries that uses STL vector compiled with _SECURE_SCL=0 (mine) and Release Mode libraries e.g OSG ) compiled _SECURE_SCL=1 ( the default). It causes all sorts of mysterious crashes... Arrrgh! Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13196#13196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I change the plugin directory structure?
I am not finding this to be the case. When running with F5 or Ctrl-F5, VS runs the example from where it compiled to, NOT where the INSTALL project sends it. In my case, bin\Release\. I'm not able to reproduce this problem, Rick. To test, I blew away my installed OSG (deleted C:\Program Files\OpenSceneGraph), went into VS, set osganimate as the active project, brought up Properties and specified OSG_NOTIFY_LEVEL=DEBUG_FP in the environment, then I hit ctrl-f5 to run. The program ran fine and displayed the models. I exited and examined the console output. There, I saw osgDB looking for the .osg plugin, and it found and used my build dir\bin\osgPlugins-2.9.5\osgdb_osg.dll. You say your examples are in bin\Release. This is not the case for me; there is no bin\Release in my build dir. The release build of my osganimate.exe file is in my build dir\bin. Not sure why yours would be elsewhere, but this appears to be the source of your problem. What CMake variables did you change from their default? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
Hi Chris -- What do you know, another opportunity to discuss BRDF textures. (I mentioned this to Christian in a separate thread when he was looking for ways to draw realistic coins with relief detail.) The good news about BRDFs is that they were covered in the orange book, so GLSL source should be available at the book's web site: http://www.3dshaders.com/home/ (I know it was in the first edition, not sure about the second). Also, BRDFs handle your low angle-of-incidence issue cleanly. The bad news is that generating the BRDF texture images is no easy task. About the time I left HP, I believe they were working on patenting a machine for snapping BRDF texture images from actual small-ish 3D objects. The machine was a small dome about a meter in diameter. Of course, you could capture the images using screen shots of a virtual object and thereby avoid the need for any such physical hardware. Feel free to pick my (or Mike Weiblen's) brain on this, as we both have some familiarity with the algorithm. (Go Colorado OSG Users!) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for GLSL Parallax Occlusion Mapping
Christian Buchner wrote: I think I will try my luck with an ARB fragment and vertex shader extension that implements parallax occlusion mapping with offset limiting. Link follows. http://web.archive.org/web/20060207121301/http://www.infiscape.com/doc/parallax_mapping.pdf The advantage is that I might get this to work on Intel integrated graphics even. Suit yourself :-) If I remember correctly, it's only about six lines of GLSL code in the fragment shader. Actually, looking at the link, it should be pretty easy to translate that asm code into GLSL code as well. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Inserting a Switch node into the SG
Hi Paul,
Thanks for the reply,
What you have looks basically right, except I don't
understand why you have:
ref_ptrGroup group = new Group;
switchnode-addChild(group.get());
That seems unnecessary to the task at hand.
Yes, I had tried a few semi-random things to try to understand
what was happening and inadvertantly included one of them
in my posting. What I should have posted is this:
ref_ptrSwitch switchnode = new Switch;
string name = node-getName();
switchnode-setName(name);
switchnode-addChild(node);
Group* parent = node-getParent(0);
parent-addChild(switchnode.get());
parent-removeChild(node);
How are you determining that you are getting the wrong
results? What you
show as the result seems impossible for the code you've
posted, as 'parent'
only adds one child: the switch.
I saved the scenegraph to a file and looked at it.
This is the scene graph before:
Group {
name mviewConeGroup
nodeMask 0x
cullingActive TRUE
num_children 1
Group {
name multiviewCone1
nodeMask 0x
cullingActive TRUE
num_children 1
...
Switch {
name mviewConeGroup
nodeMask 0x
cullingActive TRUE
NewChildDefaultValue 0
ValueList {
0
}
num_children 1
Group {
name mviewConeGroup_old
nodeMask 0x
cullingActive TRUE
}
}
The children of mviewConeGroup (Group2 in the example in my earlier post)
are not under mviewConeGroup_old, as I expected they would be.
Thanks
Jim
Inserting a node above another node is a common task and one that is
somewhat error-prone to implement. I've often wondered if it
would make
sense to have Node methods for insertAbove() and
insertBelow(). This was a
feature in PEI VisKit and we made frequent use of it at my
old employer.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FirstPersonManipulator
Hi,
i included the following lines in my applicationcode:
#include ../include/FirstPersonManipulator.h
viewer.setCameraManipulator(new osgGA::FirstPersonManipulator);
and got:
1 Creating library D:\workspace\test-osg\sln\graz\Debug\graz.lib and object
D:\workspace\test-osg\sln\graz\Debug\graz.exp
1graz5.obj : warning LNK4217: locally defined symbol
??0firstpersonmanipula...@osgga@@q...@_n@Z (public: __thiscall
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)) imported in
function _main
1graz5.obj : warning LNK4217: locally defined symbol
?classn...@firstpersonmanipulator@osgGA@@UBEPBDXZ (public: virtual char const *
__thiscall osgGA::FirstPersonManipulator::className(void)const ) imported in
function [thunk]:public: virtual char const * __thiscall
osgGA::FirstPersonManipulator::className`vtordisp{4294967292,0}' (void)const
(?classn...@firstpersonmanipulator@osgGA@@$4p...@a@BEPBDXZ)
1graz5.obj : error LNK2019: unresolved external symbol __declspec(dllimport)
protected: void __thiscall osgGA::FirstPersonManipulator::`vbase
destructor'(void) (__imp_??_dfirstpersonmanipula...@osgga@@IAEXXZ) referenced
in function protected: virtual void * __thiscall
osgGA::FirstPersonManipulator::`scalar deleting destructor'(unsigned int)
(??_gfirstpersonmanipula...@osgga@@maep...@z)
1FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for
`osg::Object'} (__imp_??_7firstpersonmanipula...@osgga@@6bobj...@osg@@@)
referenced in function public: __thiscall
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for
`osg::Drawable::EventCallback'}
(__imp_??_7firstpersonmanipula...@osgga@@6beventcallb...@drawable@osg@@@)
referenced in function public: __thiscall
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for
`osg::NodeCallback'}
(__imp_??_7firstpersonmanipula...@osgga@@6bnodecallb...@osg@@@) referenced in
function public: __thiscall
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) const osgGA::FirstPersonManipulator::`vbtable'{for
`osg::Drawable::EventCallback'}
(__imp_??_8firstpersonmanipula...@osgga@@7beventcallb...@drawable@osg@@@)
referenced in function public: __thiscall
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) const osgGA::FirstPersonManipulator::`vbtable'{for
`osg::NodeCallback'}
(__imp_??_8firstpersonmanipula...@osgga@@7bnodecallb...@osg@@@) referenced in
function public: __thiscall
osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)
(??0firstpersonmanipula...@osgga@@q...@_n@Z)
1D:\workspace\test-osg\sln\graz\Debug\graz.exe : fatal error LNK1120: 6
unresolved externals
is it possible to try this manipulator without building a new osgViewer?
Thank you!
Cheers,
Christian
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13200#13200
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] UserData
Hi, What's the best way to pass user data to all nodes and drawables. For example, lets assumes I have 2 cameras (left right). Each camera points to the same scene. When rendering the left camera, I want the the nodes and drawables to use userdata1, and when rendering the right camera I want the nodes and drawables to use userdata2. The goal is to pass thread safe data during the rendering of each camera without having to use a mutext or a critical section to access the data. Since each camera has its own user data copy it should be thread safe. I know that the RenderInfo contains a userdata ptr, but I don't know how to use it as decribed above. Any suggestions are appreciated. Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13202#13202 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Inserting a Switch node into the SG
How are you determining that you are getting the wrong results? What you show as the result seems impossible for the code you've posted, as 'parent' only adds one child: the switch. I saved the scenegraph to a file and looked at it. When are you doing the file write? I'm concerned that some other code might be operating on your scene graph between when you load it and when you write it out. If I were you, I'd write it out twice, first at the top of the code you originally posted, and second at the bottom, so you get an unambiguous before and after shot of exactly what that one function is changing. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
