Re: [osg-users] request for small change in StandardShadowMap.cpp
Hi Nick,
I haven't worked with osgShadow for over a year so it's not fresh in
my mind. There are mechanisms for override the state management in
osgShadow but I don't recall how widely they are implemented amongst
the shadow techniques.
With the proposed change, with the explicit osg::Group::traverse()
method there must be a reason why this was done but without a code
review and trawl through the svn logs I can't provide the answer. In
general overriding the management of osg::Program and other
osg::StateSet setting shouldn't require lots of hacks, so if a
particular ShadowTechnique is failing in this respect then perhaps
this needs looking at.
Robert.
Robert.
On 1 May 2015 at 17:15, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Robert,
I posted a while ago a question how to get the osg::Program associated with
the shaders from the StandardShadowMap in order to extend. And it is localy
defined as you can see in the code. However I found a workaround, by
extending the ShadowingScene and catch the StateSet from the Cull traversal.
But, this will not work since the line below. Here is my proposed change, it
will not hurt anyone I think - these ShadowMap* classes are
over-encapsulated in my opinion.
void StandardShadowMap::ViewData::cullShadowReceivingScene( )
{
_cv-pushStateSet( _stateset.get() );
#if 0
_st-getShadowedScene()-osg::Group::traverse( *_cv );
#else
_st-getShadowedScene()-traverse( *_cv );
#endif
_cv-popStateSet();
}
It will be nice if this forcing of osg::Group::traverse is replaced by
ordinary traverse thus anyone can re-write and extend. What you think?
Please let me know and thanks a bunch as always!
Nick
--
trajce nikolov nick
___
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] request for small change in StandardShadowMap.cpp
Hi Robert,
thanks for the reply. Well, I spent quite a good amount of time to
understand how it works and it all points to the StandardShadowMap, the
call I posted. This shadowmap technique allows you to attach shaders to it
through the interface, but the program is set localy again for a local
_stateset that is pushed through the CullVisitor in a cull stage. All I
need is reference to this local instance of the Program. Perhaps, maybe
introduce a method getProgram() which again will not hurt anyone.
Also, I can not think of any special reason to specialize the traverse call
to osg::Group then forbid the extension
Any further thoughts?
Nick
On Fri, May 1, 2015 at 6:50 PM, Robert Osfield robert.osfi...@gmail.com
wrote:
Hi Nick,
I haven't worked with osgShadow for over a year so it's not fresh in
my mind. There are mechanisms for override the state management in
osgShadow but I don't recall how widely they are implemented amongst
the shadow techniques.
With the proposed change, with the explicit osg::Group::traverse()
method there must be a reason why this was done but without a code
review and trawl through the svn logs I can't provide the answer. In
general overriding the management of osg::Program and other
osg::StateSet setting shouldn't require lots of hacks, so if a
particular ShadowTechnique is failing in this respect then perhaps
this needs looking at.
Robert.
Robert.
On 1 May 2015 at 17:15, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Robert,
I posted a while ago a question how to get the osg::Program associated
with
the shaders from the StandardShadowMap in order to extend. And it is
localy
defined as you can see in the code. However I found a workaround, by
extending the ShadowingScene and catch the StateSet from the Cull
traversal.
But, this will not work since the line below. Here is my proposed
change, it
will not hurt anyone I think - these ShadowMap* classes are
over-encapsulated in my opinion.
void StandardShadowMap::ViewData::cullShadowReceivingScene( )
{
_cv-pushStateSet( _stateset.get() );
#if 0
_st-getShadowedScene()-osg::Group::traverse( *_cv );
#else
_st-getShadowedScene()-traverse( *_cv );
#endif
_cv-popStateSet();
}
It will be nice if this forcing of osg::Group::traverse is replaced by
ordinary traverse thus anyone can re-write and extend. What you think?
Please let me know and thanks a bunch as always!
Nick
--
trajce nikolov nick
___
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
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] request for small change in StandardShadowMap.cpp
Hi Robert,
I posted a while ago a question how to get the osg::Program associated with
the shaders from the StandardShadowMap in order to extend. And it is localy
defined as you can see in the code. However I found a workaround, by
extending the ShadowingScene and catch the StateSet from the Cull
traversal. But, this will not work since the line below. Here is my
proposed change, it will not hurt anyone I think - these ShadowMap* classes
are over-encapsulated in my opinion.
void StandardShadowMap::ViewData::cullShadowReceivingScene( )
{
_cv-pushStateSet( _stateset.get() );
#if 0
_st-getShadowedScene()-osg::Group::traverse( *_cv );
#else
_st-getShadowedScene()-traverse( *_cv );
#endif
_cv-popStateSet();
}
It will be nice if this forcing of osg::Group::traverse is replaced by
ordinary traverse thus anyone can re-write and extend. What you think?
Please let me know and thanks a bunch as always!
Nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request for small change in StandardShadowMap.cpp
Hi NIck, On 1 May 2015 at 19:11, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi again Robert, I took a closer look into ShadowedScene::traverse and you are right. The reason to force osg::Group::traverse is to allow to call this from the ShadowedTechnique, to avoid recursive calls of the same. So I am going to ask if you can expose the local osg::Program through an interface, that is easier .. What you think? I am not in position to do a code review of osgShadow right now, so can't provide any guidance right away. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request for small change in StandardShadowMap.cpp
Okay ... if you find in any case 5 minutes, attached are the proposed mods.
Thanks as always!
Nick
On Fri, May 1, 2015 at 8:16 PM, Robert Osfield robert.osfi...@gmail.com
wrote:
Hi NIck,
On 1 May 2015 at 19:11, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi again Robert,
I took a closer look into ShadowedScene::traverse and you are right. The
reason to force osg::Group::traverse is to allow to call this from the
ShadowedTechnique, to avoid recursive calls of the same.
So I am going to ask if you can expose the local osg::Program through an
interface, that is easier .. What you think?
I am not in position to do a code review of osgShadow right now, so
can't provide any guidance right away.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
StandardShadowMap
Description: Binary data
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 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.
*
* ViewDependentShadow codes Copyright (C) 2008 Wojciech Lewandowski
* Thanks to to my company http://www.ai.com.pl for allowing me free this work.
*/
#include osgShadow/StandardShadowMap
#include osg/PolygonOffset
#include osg/ComputeBoundsVisitor
#include osgShadow/ShadowedScene
#include osg/Geode
#include osg/Geometry
#include osg/CullFace
#include osg/AlphaFunc
#include osg/Point
#include stdio.h
using namespace osgShadow;
#define DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR 0
#define FRAGMENT_SHADERS_ONLY 1
StandardShadowMap::StandardShadowMap():
BaseClass(),
_polygonOffsetFactor( 1.1f ),
_polygonOffsetUnits( 4.0f ),
_textureSize( 1024, 1024 ),
_baseTextureUnit( 0 ),
_shadowTextureUnit( 1 ),
_baseTextureCoordIndex( 0 ),
_shadowTextureCoordIndex( 1 )
{
#if FRAGMENT_SHADERS_ONLY
_mainFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
// following expressions are auto modified - do not change them: \n
// gl_TexCoord[0] 0 - can be subsituted with other index \n
\n
float DynamicShadow( ); \n
\n
uniform sampler2D baseTexture; \n
\n
void main(void) \n
{ \n
vec4 colorAmbientEmissive = gl_FrontLightModelProduct.sceneColor; \n
// // Add ambient from Light of index = 0\n
// colorAmbientEmissive += gl_FrontLightProduct[0].ambient; \n
vec4 color = texture2D( baseTexture, gl_TexCoord[0].xy ); \n
color *= mix( colorAmbientEmissive, gl_Color, DynamicShadow() ); \n
#if DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR
color.xy = abs( dFdy( gl_TexCoord[1].xy / gl_TexCoord[1].w ) )* 1024.0; \n
color.z = color.y; \n
color.x = color.z; \n
color.y = color.z; \n
color.a = 1.0; \n
#endif
//float fog = clamp((gl_Fog.end - gl_FogFragCoord)*gl_Fog.scale, 0.,1.);\n
//color.rgb = mix( gl_Fog.color.rgb, color.rgb, fog ); \n
gl_FragColor = color; \n
} \n );
_shadowFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
// following expressions are auto modified - do not change them: \n
// gl_TexCoord[1] 1 - can be subsituted with other index \n
\n
uniform sampler2DShadow shadowTexture; \n
\n
float DynamicShadow( ) \n
{ \n
return shadow2DProj( shadowTexture, gl_TexCoord[1] ).r;\n
} \n );
_shadowVertexShader = NULL;
Re: [osg-users] request for small change in StandardShadowMap.cpp
Hi again Robert,
I took a closer look into ShadowedScene::traverse and you are right. The
reason to force osg::Group::traverse is to allow to call this from the
ShadowedTechnique, to avoid recursive calls of the same.
So I am going to ask if you can expose the local osg::Program through an
interface, that is easier .. What you think?
Nick
On Fri, May 1, 2015 at 7:24 PM, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Robert,
thanks for the reply. Well, I spent quite a good amount of time to
understand how it works and it all points to the StandardShadowMap, the
call I posted. This shadowmap technique allows you to attach shaders to it
through the interface, but the program is set localy again for a local
_stateset that is pushed through the CullVisitor in a cull stage. All I
need is reference to this local instance of the Program. Perhaps, maybe
introduce a method getProgram() which again will not hurt anyone.
Also, I can not think of any special reason to specialize the traverse
call to osg::Group then forbid the extension
Any further thoughts?
Nick
On Fri, May 1, 2015 at 6:50 PM, Robert Osfield robert.osfi...@gmail.com
wrote:
Hi Nick,
I haven't worked with osgShadow for over a year so it's not fresh in
my mind. There are mechanisms for override the state management in
osgShadow but I don't recall how widely they are implemented amongst
the shadow techniques.
With the proposed change, with the explicit osg::Group::traverse()
method there must be a reason why this was done but without a code
review and trawl through the svn logs I can't provide the answer. In
general overriding the management of osg::Program and other
osg::StateSet setting shouldn't require lots of hacks, so if a
particular ShadowTechnique is failing in this respect then perhaps
this needs looking at.
Robert.
Robert.
On 1 May 2015 at 17:15, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Robert,
I posted a while ago a question how to get the osg::Program associated
with
the shaders from the StandardShadowMap in order to extend. And it is
localy
defined as you can see in the code. However I found a workaround, by
extending the ShadowingScene and catch the StateSet from the Cull
traversal.
But, this will not work since the line below. Here is my proposed
change, it
will not hurt anyone I think - these ShadowMap* classes are
over-encapsulated in my opinion.
void StandardShadowMap::ViewData::cullShadowReceivingScene( )
{
_cv-pushStateSet( _stateset.get() );
#if 0
_st-getShadowedScene()-osg::Group::traverse( *_cv );
#else
_st-getShadowedScene()-traverse( *_cv );
#endif
_cv-popStateSet();
}
It will be nice if this forcing of osg::Group::traverse is replaced by
ordinary traverse thus anyone can re-write and extend. What you think?
Please let me know and thanks a bunch as always!
Nick
--
trajce nikolov nick
___
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
--
trajce nikolov nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request for small source change in StandardShadowMap
Hi Nick, There isn't any way of me judging changes I haven't seen. In general if there is part of the OSG that isn't able to do what a users need it to do but a small change that is consistent with the overall design can achieve this then I'll be open to considering it to be merged. However, I have to see the code to know. It could also be that what you are trying to do can be done without any mods. Robert. On 14 April 2014 19:58, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, I am not sure if you are familiar with this code ( I bet You are ;-) ). I have a case where I want to mix shaders with the one that are provided to this class and I need access through the interface to the osg::Program which holds these shaders and it is instantiated locally in the scope of some method - StandardShadowMap.cpp Line: 544. I would welcome something like getProgram() and expose this object to the interface. Are you friendly to such a change - it won't brake anything. Please let me know Nick -- trajce nikolov nick ___ 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] request for small source change in StandardShadowMap
Hi Robert, let me do the changes then and I will send them to You so You decide. And thanks! Nick On Thu, Apr 17, 2014 at 10:44 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Nick, There isn't any way of me judging changes I haven't seen. In general if there is part of the OSG that isn't able to do what a users need it to do but a small change that is consistent with the overall design can achieve this then I'll be open to considering it to be merged. However, I have to see the code to know. It could also be that what you are trying to do can be done without any mods. Robert. On 14 April 2014 19:58, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, I am not sure if you are familiar with this code ( I bet You are ;-) ). I have a case where I want to mix shaders with the one that are provided to this class and I need access through the interface to the osg::Program which holds these shaders and it is instantiated locally in the scope of some method - StandardShadowMap.cpp Line: 544. I would welcome something like getProgram() and expose this object to the interface. Are you friendly to such a change - it won't brake anything. Please let me know Nick -- trajce nikolov nick ___ 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] request for small source change in StandardShadowMap
Hi Robert, I am not sure if you are familiar with this code ( I bet You are ;-) ). I have a case where I want to mix shaders with the one that are provided to this class and I need access through the interface to the osg::Program which holds these shaders and it is instantiated locally in the scope of some method - StandardShadowMap.cpp Line: 544. I would welcome something like getProgram() and expose this object to the interface. Are you friendly to such a change - it won't brake anything. Please let me know Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Request for assistance to embark into PhD
Hello, Being a software engineer, I did my final project study in 3D animation and virtual reality visualization using OpenSceneGraph. Today I want to prepare my thesis in augmented reality. I'm looking for a good topic to prepare in 3 years. What are the themes of current research linking OpenSceneGraph and augmented reality? can you suggest me some possible topics ... for my future thesis? Thank you in advance ! Alji Mohamed ALJI Blog http://aljilogy.blogspot.fr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56939#56939 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for assistance to embark into PhD
Hi, On Wed, Oct 23, 2013 at 10:51 AM, Mohamed Alji osgfo...@tevs.eu wrote: ** Hello, Being a software engineer, I did my final project study in 3D animation and virtual reality visualization using OpenSceneGraph. Today I want to prepare my thesis in augmented reality. I'm looking for a good topic to prepare in 3 years. What are the themes of current research linking OpenSceneGraph and augmented reality? can you suggest me some possible topics ... for my future thesis? Thank you in advance ! Alji Speaking as someone who did a PhD in virtual reality/computer graphics before, I think you need to look at it from a different angle. Don't look at What topic I can use OSG for. That isn't really interesting at all from a research point of view - OSG is a technology, a tool if you want. If you start with that, you are putting yourself into a really difficult position later on when you will have to explain your actual research contribution in your thesis. We engineers often fall into a trap of building contraptions - but that is engineering, not research. Find an open problem in AR and try to solve that. If you can use OSG to help you, great. If not, well, tough, but the research is the first goal, not to use OSG. I suggest that you speak to your future thesis director (did you find one already?) first - they could help you both by having an overview of the state of the art in the field you are looking at and by knowing what the requirements for a good thesis are. Good luck! Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for assistance to embark into PhD
Hi, Very good point, you are right. OSG is a technology , I have to see it as a tool in my research. Where can I find an open AR problem ? where am I supposed to look ? How to do that ? ps: I found a thesis director, I will speak to him later today. Thank you! Cheers, Mohamed Mohamed ALJI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56944#56944 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for assistance to embark into PhD
Hi, On Wed, Oct 23, 2013 at 12:28 PM, Mohamed Alji osgfo...@tevs.eu wrote: ** Hi, Very good point, you are right. OSG is a technology , I have to see it as a tool in my research. Keep that in mind - it is easy to slip into the engineering mindset and just do some coding or whatever - but that isn't really research and a lot of people get burned by that. They arrive to the thesis defence with a mountain of code, but nothing really new, scientifically speaking. Where can I find an open AR problem ? where am I supposed to look ? How to do that ? Well ... I think that the best thing to do is to look for books, papers, theses etc. in the field you want to work in. That will give you the idea what is known and is considered the state of the art. It takes time, because you must first understand the field sufficiently to essentially know what you don't know :) Then you can pick a problem to work on. Your thesis advisor/director and senior researchers in the lab you are going to do the doctorate at could help you a lot there. Typically they might have a topic or problem for you to work on already. Also don't worry too much about the topic you may be asked to write on your PhD application - one usually puts there something extremely generic, because you won't know a good problem to work on before you have done about a year of research in the field! ps: I found a thesis director, I will speak to him later today. I think that is the best thing to do. J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request new frame manually
Thank you, Robert! it worked well. for the record, the correct call is made on osg::View Code: _view-requestRedraw() I am puzzled how i could have missed the method in the sources :? Cheers, Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45791#45791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] request new frame manually
Hello world! Until recently i had been using Code: _viewer-setRunFrameScheme(osgViewer::ViewerBase::CONTINUOUS); but then i switched to Code: _viewer-setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); and now i have a minor problem with window refresh. This should be fairly simple to do, i think, i just can't find the proper method to do so - how do i request a osg::View to refresh ? (or it's camera, or whole composite viewer - i don't care) i've been searching the documentation as well as this forum with no success. There is a GLUT method that i am familiar with - glutPostRedisplay() - is there any OSG equivalent? I am running some lengthy ray tracing computation and when it finishes, i need the window that the result is displayed in to refresh. Thank you in advance! Cheers, Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45774#45774 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request new frame manually
Hi Audrey, I haven't tried exactly what you are doing but you could try : _viewer-requestRedraw(); This method is inherited from osgGA::GUIActionAdapter. Robert. On 26 February 2012 15:31, Andrey Ibe xry...@gmail.com wrote: Hello world! Until recently i had been using Code: _viewer-setRunFrameScheme(osgViewer::ViewerBase::CONTINUOUS); but then i switched to Code: _viewer-setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); and now i have a minor problem with window refresh. This should be fairly simple to do, i think, i just can't find the proper method to do so - how do i request a osg::View to refresh ? (or it's camera, or whole composite viewer - i don't care) i've been searching the documentation as well as this forum with no success. There is a GLUT method that i am familiar with - glutPostRedisplay() - is there any OSG equivalent? I am running some lengthy ray tracing computation and when it finishes, i need the window that the result is displayed in to refresh. Thank you in advance! Cheers, Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45774#45774 ___ 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] request
hello world___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On Fri, Jan 27, 2012 at 9:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: ... Curiously running separate contexts via separate applications has in the past shown good scalability so I suspect the driver contention is something per application specific. Along these lines I do wonder if running separate processes for each context rather than separate threads might help avoid the contention. Unfortunately the OSG's osgViewer design is based around the lightweight data sharing that threading provides over use of separate processes, and OpenThreads is geared up for creation and management of threads rather than processes. I looked into this a bit and couldn't conclude that running in separate processes makes much of a difference. The best I could say is that the applications would sometimes show the expected (i.e., single screen) frame rate, but would then fall into periods of the lower frame rate seen in the multi-threaded case. I don't have anything genlocked, so the programs weren't synchronized. I believe that the high rates were achieved when the programs happened to be making their OpenGL calls at different times, but then due to a scheduling artifact they started overlapping their graphics calls. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
As a side note: if you were using vbo's instead of display lists for drawing i think you werent get into this problem in first place, as with vbos 5500 draw calls would happily kill your performance even on one screen, so you have to optimize your models. Nvidia drivers are great at optimizing consecutive calls to draw display lists so they become cheap as dirt and you can do thousands of them, may be this fails on multiple screen setups? 26.01.2012, 23:12, Jason Daly jd...@ist.ucf.edu: On 01/26/2012 01:02 PM, Tim Moore wrote: That is what I found at the time of that thread, testing with some models supplied by NIST. Newer hardware is highly optimized for massive geometry. For the record, I don't think the problem is bus contention, but lock contention in the NVidia driver. The amount of bus traffic involved in the OpenGL command stream is tiny. Thanks for that. A couple of people have mentioned bringing this to NVidia's attention. We'll probably end up doing that. The key to OpenGL performance in the 21st century is reducing the number of OpenGL function calls to a minimum... so says Captain Obvious. I'm glad the mesh optimizers turned out to be useful! Yeah, once you get down to the data itself, it ends up being pretty obvious (5,500 draw calls runs slower than 9 draw calls? Really? :-) ). There was a bit of digging to do before we got to that point, though. At the outset, we originally thought that an OpenGL program wasn't showing the same problem that an OSG program was, which pointed the blame at OSG. Turns out that we weren't doing an apples-to-apples comparison with the data sets. It wasn't until we could get precisely the same set of data into the OpenGL program that we could start looking at the data itself as the culprit. Definitely a big thanks for the mesh optimizers. I was all set to start writing something myself, but then I realized they were already there :-) Btw, the Linux tool oprofile is mentioned later in the thread, but I find the newer tool perf to be more useful. Thanks, I'll check that out. --J ___ 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] Request for input
Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 1/27/2012 7:17 AM, Paul Martz wrote: Sd is the size of the drawing commands in bytes gDebugger might be able to help you estimate this too. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. 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] Request for input
On 1/27/2012 7:17 AM, Paul Martz wrote: Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Upon rereading this, a few corrections: Bb FPS = -- Nw * (Nd * Sd + O) And note that Bb is bandwidth in bytes/sec, of course (not bytes). Anyhow, this is all just back of the napkin stuff. With a little more effort I imagine you can refine the formula, and of course you have access to the actual data and values. I'd be interested in hearing if this line of investigation confirms the bus limitation theory. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 04:38 AM, Sergey Polischuk wrote: As a side note: if you were using vbo's instead of display lists for drawing i think you werent get into this problem in first place, as with vbos 5500 draw calls would happily kill your performance even on one screen, so you have to optimize your models. Nvidia drivers are great at optimizing consecutive calls to draw display lists so they become cheap as dirt and you can do thousands of them, may be this fails on multiple screen setups? Hi, Sergey, I did play around with VBO vs. display lists early on. It didn't really change the performance much regardless of which I used. Keep in mind that this is all static geometry which is going to be resident on the GPU. I don't think modern drivers would distinguish much between VBO's in STATIC_DRAW mode and display lists. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, Paul, As Tim pointed out earlier, the more limiting resource is likely to be lock contention in the NVidia driver instead of bus contention. Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex (PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset, so it's even wider (500 MB/sec * 16) per card. Also, the NIST machine's FSB is limited to 1.6 GT/sec, which is less than the 5 GT/sec that PCI-e provides. Given that the data is static (we're not transferring any vertex data over the bus, just making glDrawElements calls to VBOs in STATIC_DRAW mode), I doubt that the OpenGL command stream is going to be getting anywhere near the actual bus bandwidth. On 01/27/2012 09:17 AM, Paul Martz wrote: Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -Paul ___ 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] Request for input
Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. -Paul On 1/27/2012 11:40 AM, Jason Daly wrote: Hi, Paul, As Tim pointed out earlier, the more limiting resource is likely to be lock contention in the NVidia driver instead of bus contention. Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex (PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset, so it's even wider (500 MB/sec * 16) per card. Also, the NIST machine's FSB is limited to 1.6 GT/sec, which is less than the 5 GT/sec that PCI-e provides. Given that the data is static (we're not transferring any vertex data over the bus, just making glDrawElements calls to VBOs in STATIC_DRAW mode), I doubt that the OpenGL command stream is going to be getting anywhere near the actual bus bandwidth. On 01/27/2012 09:17 AM, Paul Martz wrote: Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -Paul ___ 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 -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 02:12 PM, Paul Martz wrote: Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. Hi, Paul, I'm not dismissing your post at all. It's certainly worth thinking about the overall bandwidth, and how much of it might be consumed by the GL command stream. I like your equation as a general guideline. One just has to keep in mind that 500MB/sec is the bandwidth for a single PCI-e 2.0 lane. Most graphics cards get 8 lanes, if not 16, and that's per card. You also have to account for the CPU interconnect bandwidth, which may put an upper limit on how much data you can transfer with multiple cards (theoretically 12.8GB/s on this hardware). In this particular case, I think Tim is right. There's not enough data in the command stream to get near the bus bandwidth. In this case, there are two 8x PCI-e cards (total of 8GB/s bandwidth) feeding 4 GPU's (two QuadroPlex D2 units). Using your figures: 2 * 8 * 500 MB/s - = 5648 Hz 4 * ( (5500 * 64 B) + 2048 B) So, unless I'm missing something, the problem must be elsewhere :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi All, I haven't chipped in so far as I haven't really too much to add to the investigation. My sense from own tests and looking at others over the years is that looks to be contention in the drivers that leads to poor scaling. Reducing the amount of data and commands being pushed in each context's OpenGL fifio does seem to help avoid the contention, but doesn't seem to be able to remove it entirely. Curiously running separate contexts via separate applications has in the past shown good scalability so I suspect the driver contention is something per application specific. Along these lines I do wonder if running separate processes for each context rather than separate threads might help avoid the contention. Unfortunately the OSG's osgViewer design is based around the lightweight data sharing that threading provides over use of separate processes, and OpenThreads is geared up for creation and management of threads rather than processes. Perhaps one test one could do is create multiple processes at a very high level in the application and then run a separate scene graph and viewer within each of these processes. It wouldn't scale well in terms of CPU performance as the cache coherency would be rather shot to shreds, but it might just get around the driver contention. If we can confirm a driver contention that rapping at NVidia and AMD's door would be the appropriate thing to do. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hello Jason, On Jan 27, 2012, at 1:37 PM, Jason Daly wrote: On 01/27/2012 02:12 PM, Paul Martz wrote: Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. Hi, Paul, I'm not dismissing your post at all. It's certainly worth thinking about the overall bandwidth, and how much of it might be consumed by the GL command stream. I like your equation as a general guideline. One just has to keep in mind that 500MB/sec is the bandwidth for a single PCI-e 2.0 lane. Most graphics cards get 8 lanes, if not 16, and that's per card. You also have to account for the CPU interconnect bandwidth, which may put an upper limit on how much data you can transfer with multiple cards (theoretically 12.8GB/s on this hardware). In this particular case, I think Tim is right. There's not enough data in the command stream to get near the bus bandwidth. In this case, there are two 8x PCI-e cards (total of 8GB/s bandwidth) feeding 4 GPU's (two QuadroPlex D2 units). Using your figures: 2 * 8 * 500 MB/s - = 5648 Hz 4 * ( (5500 * 64 B) + 2048 B) So, unless I'm missing something, the problem must be elsewhere :-) We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 04:17 PM, Doug McCorkle wrote: We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Hi, Doug, It may not have been easy to find in the mountain of text from the original post, but I did end up writing a multithreaded pure OpenGL program in an effort to eliminate OSG as the culprit. Since we ultimately ended up getting a similar frame rate drop in both OSG and OpenGL, we pretty much have eliminated OSG as the culprit. One of the issues that I ran into in my investigation was that the problem was closely tied to the structure of the data itself. My original OpenGL program only loaded .obj files at first. However, the process of converting the original .ive file to .obj disturbed the structure of the data, and caused the OpenGL program to behave differently. Unless I can load the exact data structure that OSG is loading into the VR Juggler example, I'm afraid I'd run into the same problem. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On Jan 27, 2012, at 4:12 PM, Jason Daly wrote: On 01/27/2012 04:17 PM, Doug McCorkle wrote: We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Hi, Doug, It may not have been easy to find in the mountain of text from the original post, but I did end up writing a multithreaded pure OpenGL program in an effort to eliminate OSG as the culprit. Since we ultimately ended up getting a similar frame rate drop in both OSG and OpenGL, Interesting. I did not catch that comment in your earlier posts. I will need to go back and read those posts more carefully to look at the data structure issues you are referring to. we pretty much have eliminated OSG as the culprit. This is an interesting problem. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, JP, On 01/26/2012 01:53 AM, J.P. Delport wrote: very interesting and thorough investigation. I can't really add anything and unfortunately don't have representative hardware to test on. It would be interesting to see if different bus configs (motherboards/chipsets) make any difference. The target hardware is a dual Xeon system with a 5400 chipset (the last chipset with a FSB) and a pair of QuadroPlex D2's. I've been working on an Alienware desktop with an X58 chipset and two GeForce 260's. One would expect that the X58 with its QPI interconnect would succumb to bus contention later than the 5400 (the specs say so, at least), but on the largest data set, it appears that the X58 is still having the scaling problem, while on the workstation, the bottleneck has moved elsewhere. I also would not rule out the NVidia driver doing silly things. I remember once looking at some of the glue code for the binary blob and seeing TLB flushes that caused a Xenomai kernel to fail ito timing in interesting ways. Have you tried OProfile to get some idea of time spent in the driver? I'm not familiar with OProfile. I'll take a look. Thanks for the reply! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hello, This may be relevant: Memory Speed, QPI and Multicore http://www.masm32.com/board/index.php?PHPSESSID=afe5222fb85c769a44da28f1eb5d4b82topic=17296.0 Peter - Original Message - From: Jason Daly jd...@ist.ucf.edu To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, January 26, 2012 6:49 PM Subject: Re: [osg-users] Request for input Hi, JP, On 01/26/2012 01:53 AM, J.P. Delport wrote: very interesting and thorough investigation. I can't really add anything and unfortunately don't have representative hardware to test on. It would be interesting to see if different bus configs (motherboards/chipsets) make any difference. The target hardware is a dual Xeon system with a 5400 chipset (the last chipset with a FSB) and a pair of QuadroPlex D2's. I've been working on an Alienware desktop with an X58 chipset and two GeForce 260's. One would expect that the X58 with its QPI interconnect would succumb to bus contention later than the 5400 (the specs say so, at least), but on the largest data set, it appears that the X58 is still having the scaling problem, while on the workstation, the bottleneck has moved elsewhere. I also would not rule out the NVidia driver doing silly things. I remember once looking at some of the glue code for the binary blob and seeing TLB flushes that caused a Xenomai kernel to fail ito timing in interesting ways. Have you tried OProfile to get some idea of time spent in the driver? I'm not familiar with OProfile. I'll take a look. Thanks for the reply! --J ___ 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] Request for input
On Wed, Jan 25, 2012 at 10:59 PM, Jason Daly jd...@ist.ucf.edu wrote: Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. I've been working on a project for NIST recently. For background, you might find this osg-users thread from December 2010 useful: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/63954/focus=64014 Briefly, an OSG-based test application loads a scene and displays it in a window on one or more screens (Single Viewer, multiple slave cameras, one GPU and context per screen). The problem was that a single screen would draw the scene at a given frame rate, but as additional screens were added, the frame rate would drop significantly (427 fps on one screen, 396 fps on two, 291 on four). ... At this point, I started looking for something else to blame. Examining the data set itself, I discovered that it was composed of about 5500 triangle strips, none of which were longer than 112 vertices (the data set had about 600,000 vertices total). There were only about 10 different StateSets in the scene, so state changes aren't a problem. After some digging, I found the MeshOptimizers portion of osgUtil::Optimizer, and based on a message I found from Jean-Sebastian, I tried a pass of VERTEX_PRETRANSFORM | INDEX_MESH | VERTEX_POSTTRANSFORM, followed by another pass of MERGE_GEODES | MERGE_GEOMETRY. This reduced the number of draw calls from around 5500 to 9, and completely eliminated the scalability problem for both the OSG test program, and the pure OpenGL program. This leads me to believe that bus contention was causing the lack of scalability. As more screens were added, the thousands of draw calls required by the unoptimized data set couldn't fit within the bus bandwidth, effectively causing the draw calls to take longer. The unoptimized data, only requiring 9 draw calls per screen, could easily fit. That is what I found at the time of that thread, testing with some models supplied by NIST. Newer hardware is highly optimized for massive geometry. For the record, I don't think the problem is bus contention, but lock contention in the NVidia driver. The amount of bus traffic involved in the OpenGL command stream is tiny. So, here are our questions. Does it make sense that bus contention would be causing the lack of scalability? Are the mesh optimizations mentioned above the most effective way to solve the problem? Are there any cases where the mesh optimizations wouldn't be sufficient, and additional steps would need to be taken (I briefly mentioned state changes above, which could be problematic, anything else)? Why doesn't the 64x data set seem to scale as well as the 1x and 8x data sets (does this indicate that the bottleneck has moved from the bus to somewhere else)? Any thoughts on these issues or other thoughts you could provide would be very valuable. The key to OpenGL performance in the 21st century is reducing the number of OpenGL function calls to a minimum... so says Captain Obvious. I'm glad the mesh optimizers turned out to be useful! Btw, the Linux tool oprofile is mentioned later in the thread, but I find the newer tool perf to be more useful. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/26/2012 01:01 PM, Peter Kilpatrick wrote: Hello, This may be relevant: Memory Speed, QPI and Multicore http://www.masm32.com/board/index.php?PHPSESSID=afe5222fb85c769a44da28f1eb5d4b82topic=17296.0 Hi, Peter, So the lesson there is to ensure that your RAM is running at optimal timings before blaming the bus. I'll look into that, thanks! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/26/2012 01:02 PM, Tim Moore wrote: That is what I found at the time of that thread, testing with some models supplied by NIST. Newer hardware is highly optimized for massive geometry. For the record, I don't think the problem is bus contention, but lock contention in the NVidia driver. The amount of bus traffic involved in the OpenGL command stream is tiny. Thanks for that. A couple of people have mentioned bringing this to NVidia's attention. We'll probably end up doing that. The key to OpenGL performance in the 21st century is reducing the number of OpenGL function calls to a minimum... so says Captain Obvious. I'm glad the mesh optimizers turned out to be useful! Yeah, once you get down to the data itself, it ends up being pretty obvious (5,500 draw calls runs slower than 9 draw calls? Really? :-) ). There was a bit of digging to do before we got to that point, though. At the outset, we originally thought that an OpenGL program wasn't showing the same problem that an OSG program was, which pointed the blame at OSG. Turns out that we weren't doing an apples-to-apples comparison with the data sets. It wasn't until we could get precisely the same set of data into the OpenGL program that we could start looking at the data itself as the culprit. Definitely a big thanks for the mesh optimizers. I was all set to start writing something myself, but then I realized they were already there :-) Btw, the Linux tool oprofile is mentioned later in the thread, but I find the newer tool perf to be more useful. Thanks, I'll check that out. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, On 26/01/2012 20:02, Tim Moore wrote: Btw, the Linux tool oprofile is mentioned later in the thread, but I find the newer tool perf to be more useful. niiice, new tools :) I've used gprof2dot with oprofile before to get a nice graphic view of execution. I see it supports perf too now, yay. http://code.google.com/p/jrfonseca/wiki/Gprof2Dot#linux_perf jp Tim ___ 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Request for input
Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. I've been working on a project for NIST recently. For background, you might find this osg-users thread from December 2010 useful: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/63954/focus=64014 Briefly, an OSG-based test application loads a scene and displays it in a window on one or more screens (Single Viewer, multiple slave cameras, one GPU and context per screen). The problem was that a single screen would draw the scene at a given frame rate, but as additional screens were added, the frame rate would drop significantly (427 fps on one screen, 396 fps on two, 291 on four). Given that the scene is identical and static, four contexts on four GPUs should be able to draw at or at least very nearly the same rate as one screen on one GPU. Based on initial tests (including running a non-OSG, OpenGL-based program), we first suspected that the problem had to do with thread contention inside of OSG itself. To get to the bottom of this, I added a per-thread logging mechanism to OpenThreads::PThread, which allowed each thread to output to a unique file. Using this, I added some timing code at various places in the rendering process. I started with timing the various Operations at the high level, then I started digging into the various function calls, placing timing code at the important points along the way. I eventually drilled all the way down to PrimitiveSet::draw(), and at that level, it became obvious that the code that was taking all of the time (and not scaling well to multiple screens) was the OpenGL draw call itself. For example, on one screen a given PrimitiveSet would take 0.05 ms, and on two screens, it would take 0.11 ms on the first screen and 0.12 ms on the second (roughly twice the amount of time). At this point it was beginning to look like it wasn't OSG's fault. To be sure, I decided to write a pure multithreaded OpenGL program from scratch. I tried to keep the rendering structure the same as OSG (without the scene graph structure, or the update and cull traversals, of course). I wrote enough of a .osg file loaded so that I could load the same data with the same structure, and produce the same OpenGL command stream when drawing a frame as OSG does (verified with gDEBugger). Once this was complete, we saw a similar lack of scalability as additional screens were added (708 fps on one screen, 702 fps on two, 376 fps on four). At this point, I started looking for something else to blame. Examining the data set itself, I discovered that it was composed of about 5500 triangle strips, none of which were longer than 112 vertices (the data set had about 600,000 vertices total). There were only about 10 different StateSets in the scene, so state changes aren't a problem. After some digging, I found the MeshOptimizers portion of osgUtil::Optimizer, and based on a message I found from Jean-Sebastian, I tried a pass of VERTEX_PRETRANSFORM | INDEX_MESH | VERTEX_POSTTRANSFORM, followed by another pass of MERGE_GEODES | MERGE_GEOMETRY. This reduced the number of draw calls from around 5500 to 9, and completely eliminated the scalability problem for both the OSG test program, and the pure OpenGL program. This leads me to believe that bus contention was causing the lack of scalability. As more screens were added, the thousands of draw calls required by the unoptimized data set couldn't fit within the bus bandwidth, effectively causing the draw calls to take longer. The unoptimized data, only requiring 9 draw calls per screen, could easily fit. To demonstrate this effectively, I created a variation of the original OSG test program that would run render the original test data for a given time period, then run a configurable set of optimization passes, and then render the optimized data for a given time period. It then reported the pre-optimization and post-optimization frame rates. We also tried amplifying the data by essentially instancing it 8 times and 64 times (not using instanced drawing, just drawing multiple copies of the same data). We ran the new OSG test app, applying the same optimizations as mentioned above, as well as running the same data (both unoptimized and optimized) through the pure OpenGL program. I've attached the timings for two complete runs. The 1x and 8x data sets appear to scale well in all cases, except for one anomalous case where the fps drops from 76.77 fps on three screens to 53.26 on four (the subsequent run only drops to 70.89, so this may not be a real problem). The 64x data sets are more interesting. The OpenGL program clearly scales well (almost perfectly, in fact) on the optimized data. The OSG program doesn't scale as well, dropping to
Re: [osg-users] Request for input
On 01/25/2012 04:59 PM, Jason Daly wrote: Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. I should also mention that the source code and data sets used in this work can be made available if anyone would like to try these tests on their own hardware. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi Jason, Any thoughts on these issues or other thoughts you could provide would be very valuable. I don't have that much to add. I commend you on your investigations, you really went to the crux of the problem and kept at it until you found the answer. The mesh optimizers I've mentioned in the past (and I was tipped off to them by others, so it's not my own idea :-) ) really helped in the problem cases I was investigating too. I think it's really easy for modeling programs to produce bad data, and it's really hard in general to see that it's bad data until it's too late. Some bad aspects of the data can be dealt with by doing a post-optimization on the artists' data, but some bad aspects are very hard to automatically optimize and so require knowledge. Us 3D programmers have this task in addition to all our programming duties, we have to educate the data producers and others to be able to make good data! :-) ---(aside)--- As a side note, I think OSG suffers a bit from not having a blessed content creation pipeline. It allows implementers and users total flexibility, but also in so doing assumes a lot of knowledge that might not be there or take a long time to acquire, and indirectly promotes unoptimized bad data as described above. At a minimum, I would see benefit to adding a) a set of standard export plugins for the most popular 3D modeling applications (3DSMax, Maya, Blender) which all give the same results and have the same options. b) a standard optimizer that produces optimized models and textures. This optimizer would essentially be a beefed up osgconv that would do some optimizations automatically. These would need to be maintained beside OSG itself so that people who download OSG will immediately know they can use them, instead of explicitly having to know they exist and searching for them (like the current Maya, Max and Blender plugins). It's a large task, but I think it's totally worth it. ---(/aside)--- I think the remaining case that is not scaling well might indeed be down to some other part of OSG or the OpenGL driver that is being exercised more in that example than in others. Hard to say really, but if it's a plausible use case you can probably use the same methodology you used to investigate the previous issue, and you'll find the cause. J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, On 26/01/2012 01:20, Jason Daly wrote: On 01/25/2012 04:59 PM, Jason Daly wrote: Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. very interesting and thorough investigation. I can't really add anything and unfortunately don't have representative hardware to test on. It would be interesting to see if different bus configs (motherboards/chipsets) make any difference. I also would not rule out the NVidia driver doing silly things. I remember once looking at some of the glue code for the binary blob and seeing TLB flushes that caused a Xenomai kernel to fail ito timing in interesting ways. Have you tried OProfile to get some idea of time spent in the driver? I should also mention that the source code and data sets used in this work can be made available if anyone would like to try these tests on their own hardware. I suggest sending your test apps with your report to NVidia. rgds jp --J ___ 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request: bool Polytope.contains(another_polytope)
Hi Jefferson, Like Gordon says, if you need the function then the thing to do is implement it and submit it. I'm not hear to take end users feature requests and then go a implement them for free. I have bucket load of work to do, working well over my forty hour week every week, with many of these hours doing project maintenance and support work without financial return, the simply is no scope for doing extra stuff just out of kind heartedness - I do strangely enough have a life outside the OSG. Robert. On Wed, Dec 3, 2008 at 8:10 PM, Jefferson Pinheiro [EMAIL PROTECTED] wrote: Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ 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] Request: bool Polytope.contains(another_polytope)
I understand. About my other question then, there is currently no workaround to test collision between two polytopes? I tried polytope.contains(polytope2.getReferenceVertexList()) but it doesn't seems to work either (always returning false). Any other ideas? On Thu, Dec 4, 2008 at 7:05 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Jefferson, Like Gordon says, if you need the function then the thing to do is implement it and submit it. I'm not hear to take end users feature requests and then go a implement them for free. I have bucket load of work to do, working well over my forty hour week every week, with many of these hours doing project maintenance and support work without financial return, the simply is no scope for doing extra stuff just out of kind heartedness - I do strangely enough have a life outside the OSG. Robert. On Wed, Dec 3, 2008 at 8:10 PM, Jefferson Pinheiro [EMAIL PROTECTED] wrote: Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ 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 -- Jefferson Pinheiro (51) 9192 3535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Request: bool Polytope.contains(another_polytope)
Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request: bool Polytope.contains(another_polytope)
Rather than asking Robert to implement this function you could implent it your self as you have the source and contribute it back to the OSG source and community for which we would all be grateful Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jefferson Pinheiro Sent: Wednesday, December 03, 2008 3:11 PM To: OpenSceneGraph Users Subject: [osg-users] Request: bool Polytope.contains(another_polytope) Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request: bool Polytope.contains(another_polytope)
Alas, I lack the knowledge to do that. On Wed, Dec 3, 2008 at 6:25 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Rather than asking Robert to implement this function you could implent it your self as you have the source and contribute it back to the OSG source and community for which we would all be grateful *Gordon* __ *Gordon Tomlinson* *Product Manager 3D **Email * : gtomlinson @ overwatch.textron.com __ *(C): (+1) 571-265-2612 (W)**: (+1) 703-437-7651* Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - *Master Tambo Tetsura* -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jefferson Pinheiro *Sent:* Wednesday, December 03, 2008 3:11 PM *To:* OpenSceneGraph Users *Subject:* [osg-users] Request: bool Polytope.contains(another_polytope) Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jefferson Pinheiro (51) 9192 3535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
Hi Roland, I've made an update and I am trying to build the Collada plugin (under WinXP using VS8), I first noticed that you've added some dependencies to it for the dynamic build : libxml2 pcrecpp-d pcre-d I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug versions of the libs, should it be better to ask for pcre.lib and pcrecpp.lib ? On Mon, Nov 24, 2008 at 4:28 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
Serge, I just changed the CMake files so I could develop the dae plugin in debug mode with a statically linked DOM. The CMake files still need to be changed so the user may specify the location of these dependencies (both debug and releas) by hand. Another possibility would be to automatically use the external-libs in the Collada DOM directory. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: maandag 1 december 2008 11:03 To: OpenSceneGraph Users Subject: Re: [osg-users] Request for testing Collada/dae plugin changes Hi Roland, I've made an update and I am trying to build the Collada plugin (under WinXP using VS8), I first noticed that you've added some dependencies to it for the dynamic build : libxml2 pcrecpp-d pcre-d I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug versions of the libs, should it be better to ask for pcre.lib and pcrecpp.lib ? On Mon, Nov 24, 2008 at 4:28 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph .org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
If I link the DOM dynamically I don't need to set these targets here, right ? (like in the previous version of the CMakeList.txt) I am also having links errors like that : 2daeReader.obj : error LNK2019: unresolved external symbol char const * const COLLADA_TYPE_INSTANCE_RIGID_BODY (?COLLADA_TYPE_INSTANCE_RIGID_BODY@@3PBDB) referenced in function public: bool __thiscall osgdae::daeReader::convert(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@osgdae@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @[EMAIL PROTECTED]@2@@std@@@Z) I'll try to update my DOM to see if it works, it still depends on the 1.4.1 version, not the 1.5 ? On Mon, Dec 1, 2008 at 11:13 AM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Serge, I just changed the CMake files so I could develop the dae plugin in debug mode with a statically linked DOM. The CMake files still need to be changed so the user may specify the location of these dependencies (both debug and releas) by hand. Another possibility would be to automatically use the external-libs in the Collada DOM directory. -- Roland -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Serge Lages *Sent:* maandag 1 december 2008 11:03 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] Request for testing Collada/dae plugin changes Hi Roland, I've made an update and I am trying to build the Collada plugin (under WinXP using VS8), I first noticed that you've added some dependencies to it for the dynamic build : libxml2 pcrecpp-d pcre-d I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug versions of the libs, should it be better to ask for pcre.lib and pcrecpp.lib ? On Mon, Nov 24, 2008 at 4:28 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
If I link the DOM dynamically I don't need to set these targets here, right ? (like in the previous version of the CMakeList.txt) Hmm, not sure. I am also having links errors like that : 2daeReader.obj : error LNK2019: unresolved external symbol char const * const COLLADA_TYPE_INSTANCE_RIGID_BODY (?COLLADA_TYPE_INSTANCE_RIGID_BODY@@3PBDB) referenced in function public: bool __thiscall osgdae::daeReader::convert(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@osgdae@@[EMAIL PROTECTED]@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@2@@std@@@Z) Linking statically solved this for me. I'll try to update my DOM to see if it works, it still depends on the 1.4.1 version, not the 1.5 ? The plugin is still using DOM 2.1 that supports Collada version 1.4.1 An official DOM for Collada 1.5 is not released yet and I don't think we want to use the SVN Head for 1.5 support. -- Roland On Mon, Dec 1, 2008 at 11:13 AM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Serge, I just changed the CMake files so I could develop the dae plugin in debug mode with a statically linked DOM. The CMake files still need to be changed so the user may specify the location of these dependencies (both debug and releas) by hand. Another possibility would be to automatically use the external-libs in the Collada DOM directory. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: maandag 1 december 2008 11:03 To: OpenSceneGraph Users Subject: Re: [osg-users] Request for testing Collada/dae plugin changes Hi Roland, I've made an update and I am trying to build the Collada plugin (under WinXP using VS8), I first noticed that you've added some dependencies to it for the dynamic build : libxml2 pcrecpp-d pcre-d I was wondering why do you ask for pcrecpp-d and pcre-d ? It's the debug versions of the libs, should it be better to ask for pcre.lib and pcrecpp.lib ? On Mon, Nov 24, 2008 at 4:28 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph .org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Serge Lages http://www.tharsis-software.com This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for testing Collada/dae plugin changes
On Mon, Dec 1, 2008 at 11:31 AM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: If I link the DOM dynamically I don't need to set these targets here, right ? (like in the previous version of the CMakeList.txt) Hmm, not sure. I am also having links errors like that : 2daeReader.obj : error LNK2019: unresolved external symbol char const * const COLLADA_TYPE_INSTANCE_RIGID_BODY (?COLLADA_TYPE_INSTANCE_RIGID_BODY@@3PBDB) referenced in function public: bool __thiscall osgdae::daeReader::convert(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@osgdae@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @[EMAIL PROTECTED]@2@@std@@@Z) Linking statically solved this for me. Erf... But if I don't want to link statically, there's no solution ? I'll try to update my DOM to see if it works, it still depends on the 1.4.1 version, not the 1.5 ? The plugin is still using DOM 2.1 that supports Collada version 1.4.1 An official DOM for Collada 1.5 is not released yet and I don't think we want to use the SVN Head for 1.5 support. Ok, so I have the correct version, I'll compile the static version of the DOM. If we don't have any solution for the dynamic version of the library, we should add a note to say that the static version is needed to build the plugin. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Request for testing Collada/dae plugin changes
Hello osg-users, Robert just merged my changes for the Collada/dae plugin as posted on osg-submission: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph .org/2008-November/002883.html You are kindly invited to test the improved plugin. -- Roland This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
