Re: [osg-users] Can I change the plugin directory structure?
There is one direction that I am tempted to pursue... my initial post was that we cannot run OSG using the plugin folder structure as is. When I saw your initial post I manually copied over to the directory structure you said where the plugin folder is in the same path as the bin. The problem is the plugins did not get loaded doing it this way... I have not investigated why yet, but I believe it is because we manipulate the current working directory to our art content folder. If osgRegistry tries to obtain the plugins via relative path or current working directory it would then fail. If all my guesses are correct then maybe there could be some DLL_OnProcessAttach that could cache the CWD before we go and change it. Rick was almost persuaded to use the OSG workflow, but this issue made it too overwhelming to pursue. I may go in this direction if it is easy to determine. I guess the main reason I would want to go in this way... is to offer a solution that could benefit many. - Original Message - From: "Jean-Sébastien Guay" To: "OpenSceneGraph Users" Sent: Thursday, June 04, 2009 3:28 PM Subject: Re: [osg-users] Can I change the plugin directory structure? > Hi James, > > > In short... I do not want to challenge the current workflow of either > > paradigms, but rather describe how both are well-defined, and maybe > > there are others out there who would like to see how we are doing it, > > when/if we offer a submission. > > Thanks for explaining where you're coming from. It's good to take a step > back and see what developers do with the dependencies that their > products use. > > Sure, if you want to add a few options to the CMake scripts, you're > welcome to submit them. As I said, if you find them useful then surely > others will too. > > The current setup is kind of geared towards providing a good > "out-of-the-box" experience, so new users don't have too many surprises, > and also so that the setup is as similar as possible across platforms. > If there are too many if(win32) paths in the cmake scripts then it makes > them harder to support and keep in line with the mainline developments. > Some are inevitable, but it's a good idea to keep them to a minimum. > > Thanks, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] get the x-axis angle of a rotation
> regarding your last post, did you mean that you also tried to extract angles from a rotation with the website's "matrixToEuler" or a similar approach, but you encountered problems that were depended on your current camera-orientation? It was quat to Euler http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/index.htm > i'm not sure what you are meaning with "..it was not a success.." > does the attachment you included work, and won't it suffers from symptoms, like described above? The code is correct to the best of knowledge and of the tests I did, it worked well. The problem is that it wasn't compatible to the needs of what I needed to do. It has been over a year since I had dealt with it, and so I don't quite remember the details except to say that it appeared to always interpret the delta's from a global orientation perspective. What I needed is the deltas from its current local perspective, so for example if I just turned the yaw, and watched the numbers... it looked correct. The same is true for the pitch and roll where I would start from the global orientation and turn one axis exclusively. Now lets say I apply a 45 angle pitch and then apply a pure yaw rotation from this new orientation the Euler angles would interpret that both yaw and pitch were changing, because from a global orientation they were. Once I figured out that this wasn't what I needed I finally saw the beauty of the quaternion and the code snip that I initially sent is what I use today. - Original Message - From: "Christian Sam" To: Sent: Thursday, June 04, 2009 1:51 PM Subject: Re: [osg-users] get the x-axis angle of a rotation > Hi james, > > regarding your last post, did you mean that you also tried to extract angles from a rotation with the website's "matrixToEuler" or a similar approach, but you encountered problems that were depended on your current camera-orientation? > > i think the same happened to me: i wanted to get the pitch-angle of the camera-orientation, to adjust the camera looking straight forward in certain cases. (think of some: reset view, but only for the pitch angle). i encountered that multiplying with the inverse rotation matrix of that angle didn't work if a left or right camera-rotation has been done before. > (actualy these negative-effects were only obvious when left/right rotation was larger than 45°. so i don't know if also minor yaw-rotations did harm, or only rotations exceeding a 45° threshold) > > in the end, it put out that i had to build the adjustment-rotation matrix not with the pitch but the roll angle of the current camera-rotation in cases of previous left/right camera-rotations from 45° to 135° (respectively -45° to -135°) > > 3.) > i'm not sure what you are meaning with "..it was not a success.." > does the attachment you included work, and won't it suffers from symptoms, like described above? > > > Thanks in advance, > Christian > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=13519#13519 > > > > > > ___ > 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] get the x-axis angle of a rotation
Oh my... been there done that... I actually took the Euler angle approach
first too, and it actually started to work until I started to do rolls
starting from a position where the tail to nose was no longer in orientation
alignment. Many hours were spent getting Euler to work... now perhaps you
need not work with true 3d roll controls, and it may work out. But
ultimately I had to keep things stored as quats until the last moment when I
extracted a frame's slice of delta offsets. Good luck, and I hope you do
not fall in the same pitfalls as I.
I have included all my Euler work in text attachment... it was not a
success, but is a good learning experience and probably worth a look:
James Killian
- Original Message -
From: "Christian Sam"
To:
Sent: Wednesday, June 03, 2009 7:15 PM
Subject: Re: [osg-users] get the x-axis angle of a rotation
Hi,
i had to do a little further research on the web because first i didn't
understand what your code-snippet is doing. i found a website which
describes the whole topic:
"http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToEuler/index.htm";
thank you james and max for posting the clues/code.
Christian
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13462#13462
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
/*
http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/index.htm
heading = atan2(2*qy*qw-2*qx*qz , 1 - 2*qy^2 - 2*qz^2)
attitude = asin(2*qx*qy + 2*qz*qw)
bank = atan2(2*qx*qw-2*qy*qz , 1 - 2*qx^2 - 2*qz^2)
except when qx*qy + qz*qw = 0.5 (north pole)
which gives:
heading = 2 * atan2(x,w)
bank = 0
and when qx*qy + qz*qw = -0.5 (south pole)
which gives:
heading = -2 * atan2(x,w)
bank = 0
*/
void QuatToEulerAngles (const osg::Quat &q,double &heading,double &attitude,double &bank)
{
const osg::Quat q1(q.z(),q.y(),q.x(),q.w());
double test = q1.x()*q1.y() + q1.z()*q1.w();
if (test > 0.499)
{ // singularity at north pole
//heading = 2 * atan2(q1.x(),q1.w());
heading = atan2(q1.x(),q1.w());
attitude = M_PI/2;
bank = 0;
return;
}
if (test < -0.499)
{ // singularity at south pole
//heading = -2 * atan2(q1.x(),q1.w());
heading = atan2(q1.x(),q1.w());
attitude = - M_PI/2;
bank = 0;
return;
}
double sqw = q1.w()*q1.w();
double sqx = q1.x()*q1.x();
double sqy = q1.y()*q1.y();
double sqz = q1.z()*q1.z();
double unit = sqx + sqy + sqz + sqw; // if normalised is one, otherwise
is correction factor
#if 0 //This is the original
heading = atan2(2*q1.y()*q1.w()-2*q1.x()*q1.z() , 1 - 2*sqy - 2*sqz);
attitude = asin(2*test);
bank = atan2(2*q1.x()*q1.w()-2*q1.y()*q1.z() , 1 - 2*sqx - 2*sqz);
#else //This one is optimized
heading = atan2(2*q1.y()*q1.w()-2*q1.x()*q1.z() , sqx - sqy - sqz +
sqw);
attitude = asin(2*test/unit);
//attitude = asin(2*qx*qy + 2*qz*qw)
//attitude = asin((2*q1.x()*q1.y()) + (2*q1.z()*q1.w()));
bank = atan2(2*q1.x()*q1.w()-2*q1.y()*q1.z() , -sqx + sqy - sqz + sqw);
#endif
}
//This does some minor variation of the result to conform to how I work with
the Vec3
osg::Vec3d QuatToEulerAngles (const osg::Quat &q1)
{
double heading,attitude,bank;
QuatToEulerAngles(q1,heading,attitude,bank);
//attitude hack...
//Not sure why attitude gives a smaller range so I'm scaling it here: :(
attitude*=2;
//Not sure why these are shuffled around
return osg::Vec3d(bank+M_PI,attitude+M_PI,heading+M_PI);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] get the x-axis angle of a rotation
This is how I do it... not sure if it is best, but it works for me:
Everyone feel free to poke holes at this, as I'd like to know what is best. ;)
The context of this code is for flight dynamics and the class natively works
with m_QuatToUse. It only extracts frame size delta's in a form of yaw pitch
and roll, but everything is preserved in quats.
osg::Vec3d ComputeAngularDistance(const osg::Vec3d &lookDir,const osg::Vec3d
&UpDir)
{
osg::Vec3d ret(0.0,0.0,0.0);
//Default 0,1,0 Yaw,Pitch,Roll
//Look up negative, down positive
//Look left negative right positive
//printf("\r %f %f %f camera
",lookDir[0],lookDir[1],lookDir[2]);
osg::Vec3d CurrentOrientation(m_QuatToUse.conj()*lookDir);
//printf("\r %f %f %f ship
",CurrentOrientation[0],CurrentOrientation[1],CurrentOrientation[2]);
ret[0]=atan2(CurrentOrientation[0],CurrentOrientation[1]); //Angle in radians
if (CurrentOrientation[1]>0.0)
ret[1]=atan2(CurrentOrientation[2],CurrentOrientation[1]); //Angle in radians
else
ret[1]=atan2(CurrentOrientation[2],-(CurrentOrientation[1])); //Angle in
radians
osg::Vec3d RollOrientation(m_QuatToUse.conj()*UpDir);
//printf("\r %f %f %f ship
",RollOrientation[0],RollOrientation[1],RollOrientation[2]);
ret[2]=atan2(RollOrientation[0],RollOrientation[2]); //Angle in radians
//printf("\r %f degrees ",RAD_2_DEG(RollOffset));
return ret;
}
- Original Message -
From: "Christian Sam"
To:
Sent: Wednesday, June 03, 2009 6:59 AM
Subject: [osg-users] get the x-axis angle of a rotation
> Hi,
>
> i have a manipulator which stores the rotation in a quaternion. i would like
> to extract the angle of the, in matrix-words, x-axis of that rotation.
> (think of a firstperson-view - i would like to extract the angle which
> defines how much i look up/down)
>
> is there an easy way to get this done?
>
>
> Thanks in advance,
> Christian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13417#13417
>
>
>
>
>
> ___
> 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] Can I change the plugin directory structure?
Jean, Thanks for taking the time to go over some of the finer points of the default workflow with version dll's etc. I have been tracking this thread from the beginning and I think I have a better understanding of both work flow cases. I'd like to point out the work flow that Rick and I are used to is closely related to work flow we have done for our other work, which in short is very close to the native way Visual Studio lays out the projects. I think it is safe to say that the work flow we use is every bit as well-defined as OSG versioning method. In our case, we have shipped about 10 products over the past 9 years using the "VS" methods, and so it makes it difficult to push a well-defined solution to the way-side to something which is not familiar to us. I know exactly what Rick is after, and I may have a run with the cmake scripts... I did find a way to enable precompiled headers which I know *everyone* is against, but hey we are ambitious engineers who know how to use them. > : ) The workflow we use is not for the light-hearted, and may require a run with the dependency walker... but really, Rick and I have been using the work flow we have now since OSG 1.2 and it has worked well with OSG even at present, so perhaps there are others who are also a custom to the Visual Studio way of doing things... and maybe it would be worth a submission effort (rather than a hack) for them. In short... I do not want to challenge the current workflow of either paradigms, but rather describe how both are well-defined, and maybe there are others out there who would like to see how we are doing it, when/if we offer a submission. James Killian - Original Message - From: "Jean-Sébastien Guay" To: "OpenSceneGraph Users" Sent: Tuesday, June 02, 2009 6:12 PM Subject: Re: [osg-users] Can I change the plugin directory structure? Hi Rick, I don't think I quite communicated what I meant to say in the end there. I am not super bothered by the whole naming thing, just a bit irritated and in my organization I think it causes more problems that it is worth. I was hoping that perhaps with the power of CMake that someone had already provided a way to disable this feature that works well for so many but not for us. Apparently that is not the case, and that is ok. Perhaps we can help to write it if we get a chance. That would be great, but I think you don't consider the benefits of the current scheme compared to the numerous e-mails about mixed-up versions simply because you weren't there back then. It's very much a case where there was a problem reported by lots of users, a technological solution was put in place, and the problem is basically non-existent now that it has. So please consider that. I'm sure others would also benefit from you adding a switch to disable usage of the osgPlugins-x.y.z directory, but I don't know what Robert would think of that since it's pretty much transparent to end-users but cuts down significantly on support. But then again, there's precedent in the versioning of DLLs (osgXY-osg.dll) which can be disabled if you want, so perhaps that would be accepted too. I'm just an end-user like you in this regard, I don't have any say in what goes into OSG or not, but I think adding a switch to disable that would be a step backward. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::ref_ptr<> used anymore
The real question is -- does boost even offer a smart pointer type that replicates ref_ptr, or is all this a pointless exercise? I've stepped through ref_ptr code before and it does seem similar to intrusive and perhaps shared as well. I have also discovered a few matrix classes that are public one of which is optimized SSE and SSE2, where some of the benchmark code pointed out a standard to work with them among several offered (including Microsoft's). The most attractive thing about standards like std::, boost, and tr1, is that they are tested extensively by a wider c++ community and so they must be pretty darn robust and more versatile, but more important if you are like me and code for more platforms other than osg, you'll find it extremely useful to be able to transfer knowledge of one standard and apply it to multiple projects with completely different environments. James Killian - Original Message - From: "Chris 'Xenon' Hanson" To: "OpenSceneGraph Users" Sent: Sunday, May 31, 2009 8:21 PM Subject: Re: [osg-users] osg::ref_ptr<> used anymore Judd Tracy wrote: Boost only needs to be installed if you use certain features. Shared pointers is not one of those features in which it needs to be installed. I like boost myself, and have used parts of it in different projects. But, I want to clarify the sense of "installed" here. I'd differentiate the multiple meanings of "installed" into headers-installed and libraries-installed. To use any part of boost in your code, you (the person compiling the boost-using project) must have the boost development kit with headers installed. This is one component that OSG doesn't currently require. It's pretty version-safe -- generally if you require boost x.y.z, any version > than that should be fine. Judd is right in that most of boost does its magic at compile-time and doesn't need binary libraries at link-time. However, it seems it is still possible to get in trouble when you mix binaries compiled by different people who used different versions of boost -- whether they were using compile-time or link-time portions of boost. Because OSG incorporates other third-party libraries (such as Collada) that incorporate boost and are difficult for individual OSG developers or the project maintainers to recompile every time something changes, we've run afoul of this problem and are gun-shy. The real question is -- does boost even offer a smart pointer type that replicates ref_ptr, or is all this a pointless exercise? -- 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 ___ 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
Yes, it's best to always use ref_ptr. I would agree with that if it means when working with osg classes / foundation. Not ALL pointers need a reference count like those which are private (not intended to be shared), that's one reason why boost created the scoped pointer... too bad all the c++ programmers I know never use them. I use them faithfully (but not when using osg classes). James Killian - Original Message - From: "Paul Martz" To: Sent: Friday, May 29, 2009 10:21 AM Subject: 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 ___ 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?
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" To: "OpenSceneGraph Users" Cc: "Rick Pingry" 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/ .somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll .somepath/bin/osgPlugins-x.y.z/ " 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, and then running into an application crash (because of ABI changes between versions) that motivated Robert to do something better. Using the osgPlugins-VERSION subdirectory ensures that OSG will find the *right* *version* of the plugins. Since OSG (specifically osgDB::Registry) knows its own version, it can look in the right directory for the plugins. > I know when I try to run any of the example > projects from Visual Studio, that it always complains about the plugins > not being there until I copy them all over to the bin directory where > the other binaries are. Perhaps I am doing something wrong and I am > missing some really cool feature related to having them in their own > version labeld directory? Yep, they're not meant to be in the same directory as the main OSG DLLs, they're meant to be in the osgPlugins-VERSION directory under that. Running the INSTALL target from Visual Studio will give you that automatically. 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 have several versions of OSG on my machine, for different projects, > and I want to avoid the DLL hell that might arise from having an > environment variable or whatever telling me where they go. 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/ ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll ...somepath/bin/osgPlugins-x.y.z/ > Is there a way to tell CMake to just put > all the binaries in the same directory? Yes, it's called the INSTALL target. Just set your CMAKE_INSTALL_PREFIX to some directory where you want the latest OSG binaries+libs+headers to be placed, generate the project files, and run the INSTALL target from the Visual Studio solution. Same goes for Unix - set CMAKE_INSTALL_PREFIX, generate the make
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/ ..somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll ..somepath/bin/osgPlugins-x.y.z/ " 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, and then running into an application crash (because of ABI changes between versions) that motivated Robert to do something better. Using the osgPlugins-VERSION subdirectory ensures that OSG will find the *right* *version* of the plugins. Since OSG (specifically osgDB::Registry) knows its own version, it can look in the right directory for the plugins. > I know when I try to run any of the example > projects from Visual Studio, that it always complains about the plugins > not being there until I copy them all over to the bin directory where > the other binaries are. Perhaps I am doing something wrong and I am > missing some really cool feature related to having them in their own > version labeld directory? Yep, they're not meant to be in the same directory as the main OSG DLLs, they're meant to be in the osgPlugins-VERSION directory under that. Running the INSTALL target from Visual Studio will give you that automatically. 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 have several versions of OSG on my machine, for different projects, > and I want to avoid the DLL hell that might arise from having an > environment variable or whatever telling me where they go. 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/ ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll ...somepath/bin/osgPlugins-x.y.z/ > Is there a way to tell CMake to just put > all the binaries in the same directory? Yes, it's called the INSTALL target. Just set your CMAKE_INSTALL_PREFIX to some directory where you want the latest OSG binaries+libs+headers to be placed, generate the project files, and run the INSTALL target from the Visual Studio solution. Same goes for Unix - set CMAKE_INSTALL_PREFIX, generate the makefiles, and run 'make install'. Incidentally, this has been discussed a lot in the past, so searching the archives would have turned up all this info, but perhaps in a more fragmented fashion (across many posts), so I thought I'd sum it all up as direct replies to your questions. It's also discussed in the Platform Specifics/Visual Studio page on the Wiki (see the last section, called "Important note about plugins"). http://www.openscenegraph.org/projects/osg/wiki/Support/Platfo
Re: [osg-users] [osg-submissions] [osgParticle] osgParticle ParticleSystem andModularEmitterin different coordinate systems
Sorry that we are so late to chime in on this thread, but I'd like to post a response to the content presented here in hopes to help others, and perhaps fix code as well. Rick is the original author of the client particle system code we use for our game. I have passed this thread to him and here is his response: Rick: As for the particle system structure, mine is arranged like the last one on that email you showed me: Group--+ | +--MatrixTransform 1--+ | | | +--Geode of main Body | | | +--Modular Emitter | +--Geode for particles | +--ParticleSystemUpdater Except I think he had a typo. The ParticleSystemUpdater, if I understand it correctly, is a Drawable, so it is actually a child of the Geode. The one that I have is a ParticleSystem. Perhaps I am wrong and the PartilceSystemUpdater is something else. Anyway, mine looks like this right now: Group--+ | +--MatrixTransform 1--+ | | | +--Geode of main Body | | | +--ParticleEffect (Modular Emitter?) | +--Geode for particles--+ | +--ParticleSystem (ParticleSystemUpdater?) So perhaps there is something else to look at here. We could also just make the little fix you found for the time being and be done with it. Perhaps we should shoot off an email in response and ask the question of the OSG community? Jolley, Thomas P Thu, 23 Apr 2009 09:17:36 -0700 Hi Robert, > -Original Message- > From: Robert Osfield > > Hi Tom, > > I wouldn't expect the cessnafire.osg model to work under a > moving MatrixTransform, this is a known attribute of > osgParticle - you have to move the ParticleSystem outside of > any moving models, you can't leave it from within the moving > subgraph otherwise the particles get transformed twice. This is how it worked before the September change. With the change it sort of works under a MatrixTransform. The change seems to undo any MatrixTransforms above the particle system. I don't know enough about what Tim was trying to correct but it looks almost like "fixing" this attribute of osgParticle. > > The osgparticleeffects example illustrates how to handling > moving models and particle systems. I'll take a closer look at this example. I'll see if I can come up with some examples that demonstrate the problem I'm running into. > > In your own case I don't know what to make of the issues, > could it be that you aren't constructing your particle system > appropriately for moving models, or is it that you have a > genuine precision issue that is unrelated to the moving model > issue? Tim's submission was intended to address some of the > precisions issues, so it's disappointing that in some usage > case it might have made things worse. Reverting this change > would break the problem Tim was trying to solve though, so > I'm very reluctant to do this without clear illustration of > problems and a solution that addresses both the issues you > are seeing and the ones that Tim was seeing. My construction and rearangement of a model like cessnafire.osg worked just fine before the September change. I had no particle placement or precision issues precisely because of how I rearanged the model and added additional MatrixTransforms above the ModularEmitters and Geodes with Particles. I suppose a picture is worth a thousand words. Original graph Group -+ | +--Geode of main Body | +--Modular Emitter | +--Geode for particles | +--ParticleSystemUpdater Modified graph Group--+ | +--MatrixTransform 1--+ | | | +--Geode of main Body | +--MatrixTransform 2--+ | | | +--Modular Emitter | +--MatrixTransform 3--+ | | | +--Geode for particles | +--ParticleSystemUpdater With the modified graph I set the model position and attitude with MT1. I set MT3 to a translation where the model will be used and do not update it. MT2 uses the rotation of MT1 and the translation is set to MT1's translation minus MT3's translation. This keeps everything well withing single precision values and avoids the known attibute of osgParticle you described above. With the September change I need to modify the original model as follows: Group--+ | +--MatrixTransform 1--+ | | | +--Geode of main Body | | | +--Modular Emitter | +--Geode for particles | +--ParticleSystemUpdat
Re: [osg-users] [osg-submissions][osgParticle] Something fishy with ModularEmitter.cpp 8881
I have forwarded to users as requested. In particular it "appears" to be this line 96 P->setPosition(P->getPosition() * worldToPs); If I remove this line the problem goes away... (work in progress...) - Original Message - From: "Robert Osfield" To: "OpenSceneGraph Submissions" Sent: Thursday, May 21, 2009 8:48 AM Subject: Re: [osg-submissions] Something fishy with ModularEmitter.cpp 8881 Hi James, There must be a difference in the way you are using osgParticle from what the examples are doing that is triggering this problem as the examples didn't break with this change (r8881) from Tim Moore. Tim's submission included other modifications to osgParticle, these are also a topic for current discussion on another thread. So it looks like Tim's changes fix some issues, but introduce new ones. The final solution may well be to refactor the code in osgParticle for tracking coordinate systems. Unfortunately I'm not an expert on osgParticle so am very much in the same boat as yourself and others in terms of having to read the code to understand how it works - this means I can't just pinpoint a problem and come up with a quick solution. Could join the existing osg-users thread on problems in osgParticle or start a new one, so the discussion can go on with a wider coverage, osg-submissions really is just for submissions. Cheers, Robert. On Thu, May 21, 2009 at 3:37 AM, James Killian wrote: > After a solid week of continuous builds I have finally found the code change > which breaks are game. See picture. > > In this picture, before build 8881 (Which is only the ModularEmitter > change)... I shoot the upper ship and the particals are only emitted from > that position... With the 8881 change the particals are being emitted from > both that position and the position of the ship below. I was hoping this > information may be enough to investigate the 8881 change submitted to see if > it is sound... I'm going to review our code stress from the game end and see > if perhaps there is something we are doing wrong as well. Now that we have > narrowed it down, hopefully the cause will reveal itself very soon. > > > ___ > osg-submissions mailing list > osg-submissi...@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
I would like to take a moment to show a snap shot of how these optimizations have impacted our game. To interpret the data, they show frames per second where the first column keeps an average of the lowest times, the middle keeps the overall average, and the right keeps track for the highest times. We do at least 3 runs to get a good solid average. Here is the fps without any of the SSE optimizations: Framerates: (23.3, 41.3, 54.2) Framerates: (27.5, 41.9, 50.4) Framerates: (30.6, 41.8, 53.3) AVERAGE:(27.1, 41.7, 52.6) Here is my submissions with SSE optimizations Framerates: (30.2, 48.7, 58.1) Framerates: (30.9, 49.6, 60.5) Framerates: (36.8, 50.0, 60.5) AVERAGE:(32.6, 49.4, 59.7) Here is a combination of my Submission and Mathias submission VS 9 (current) "..\Game Scripts\Miramar_001.lua" -perf 0 60 0 -stats 10 60 VS9_Perf.txt Framerates: (40.9, 53.2, 65.6) Framerates: (34.5, 50.3, 60.9) Framerates: (39.5, 49.9, 63.2) AVERAGE:(38.3, 51.1, 63.2) So basically in this test, both of our optimizations have yielded a solid +10 fps for this machine. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Thanks for posting this link. I'll definitely want to look at this. James Killian - Original Message - From: "Benjamin Eikel" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, August 05, 2008 3:11 AM Subject: Re: [osg-users] Using SSE within OSG Hello, some days ago I stumbled upon a library: liboil [1]. Maybe some of the routines implemented there could be used for OSG. The library contains different functions (e. g. arithmetic ones) that are optimized for different processeor architectures (it uses SSE or Altivec for example). Maybe using these functions would be easier than implementing them anew. Functions needed by OSG which are not yet part of liboil might be added to it. Regards, Benjamin [1] http://liboil.freedesktop.org/wiki/ ___ 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] Using SSE within OSG
Thanks for the reply. The delay of review will buy me some time to present the aligned matrixf. It is true that these maths are not the largest bottleneck even for our game, but they still are significant! especially during heavy use of collision detection. I would like to know if Mathias submission would be considered now as 99% of it is a c solution to reduce the number of multiplies needed. It did bring the numbers down in our game too. If so, I would like to write SSE forms of these new functions (e.g. preMultTranslate) to the aligned matrixf and make them run even faster. I would be interested in pursuing the traversal related methods, but I have a feeling the solution would entail a design solution with C and not an SSE one; However, if performance increase is not the top priority on anyone's list I'd be willing to look into this and see if I can help. James Killian - Original Message - From: Robert Osfield To: "OpenSceneGraph Users" Sent: Sunday, Aug 3, 2008 05:58 AM Subject: Re: [osg-users] Using SSE within OSG Hi Guys, I've read through the correspondence on this issue, but won't dive in with reviewing submissions on this topic till well after 2.6.0 is out the door. As a general note, there seems to be two related topics - data alignment and then SSE instructions, they are of course related but I'd suggest we tackle them separately. As another general note, in my experience the most common bottleneck of scene graph based applications is that of CPU memory bandwidth, maths functions are much less of a bottleneck, and there cost in fact largely hidden by the cost of waiting for the cache to be filled. The performance profiles provided in this threaded suggest this as well - with the traversal related methods being the biggest bottleneck. How to address this bottleneck is a topic for another thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Ok I thought it was the collision detection but that is not the case here are some of the numbers with collision disabled: CS:EIP Symbol + Offset 64-bit Timer samples 0x10083cc0 osg::Group::traverse 1434 0x10083d60 osg::Group::computeBound 1391 0x10099ca0 osg::Matrixf::mult 833 0x1001a9d0 osg::PositionAttitudeTransform::accept 409 0x10099370 osg::Matrixf::preMult 407 0x1000e840 osg::AnimationPathCallback::update 352 0x1009bb50 osg::Node::dirtyBound 340 0x100dcee0 osg::Transform::computeBound 318 0x100a9df0 osg::PositionAttitudeTransform::computeLocalToWorldMatrix 294 0x100126f0 osg::AnimationPath::getInterpolatedControlPoint 285 0x10009c70 osg::AnimationPathCallback::setPause 251 0x1000c8e0 osg::StateSet::requiresUpdateTraversal 228 12 functions, 806 instructions, Total: 6542 samples, 50.85% of samples in the module, 16.36% of total session samples Ok here is with collision detection: === CS:EIP Symbol + Offset 64-bit Timer samples 0x10083cc0 osg::Group::traverse 1382 0x10083d60 osg::Group::computeBound 1237 0x10099ca0 osg::Matrixf::mult 924 0x10099370 osg::Matrixf::preMult 600 0x1001a9d0 osg::PositionAttitudeTransform::accept 394 0x1000e840 osg::AnimationPathCallback::update 292 0x100dcee0 osg::Transform::computeBound 284 0x1009bb50 osg::Node::dirtyBound 280 0x100126f0 osg::AnimationPath::getInterpolatedControlPoint 274 0x100a9df0 osg::PositionAttitudeTransform::computeLocalToWorldMatrix 230 0x10009c70 osg::AnimationPathCallback::setPause 225 0x10002e00 osg::Matrixf::preMult 210 12 functions, 846 instructions, Total: 6332 samples, 51.35% of samples in the module, 15.83% of total session samples Here is with both matrixf and invert4x4 optimized: = CS:EIP Symbol + Offset 64-bit Timer samples 0x10083cb0 osg::Group::traverse 1362 0x10083d50 osg::Group::computeBound 1142 0x1009a180 osg::Matrixf::mult 922 0x1001ac70 osg::PositionAttitudeTransform::accept 381 0x1000e650 osg::AnimationPathCallback::update 354 0x100dcf30 osg::Transform::computeBound 306 0x1009bcf0 osg::Node::dirtyBound 274 0x100124f0 osg::AnimationPath::getInterpolatedControlPoint 257 0x1009a340 osg::Matrixf::invert_4x3 252 0x10009bb0 osg::GraphicsContext::ScreenIdentifier::~ScreenIdentifier 248 0x100a9b20 osg::PositionAttitudeTransform::computeLocalToWorldMatrix 245 0x10002d00 osg::Matrixf::preMult 214 0x10002c70 osg::Matrixf::preMult 197 0x1000c6b0 osg::StateSet::requiresUpdateTraversal 178 14 functions, 829 instructions, Total: 6332 samples, 54.18% of samples in the module, 15.84% of total session samples For the optimized profile it did push down the Invert4x4 way to the bottom (I did not want to show that here). If you want the complete list let me know and I'll resend as attachments. Actually you cannot really use this to see how much better the performance is, because the Matrixf Mult is still needed just as much, the actual way to tell would be to show the framerate of the game; however here is where I can show the optimization: Avarage time using the D3DXMATRIX class: 402.54 Avarage time using the SPMatrix class:277.69 Avarage time using the Matrixf class:297.40 Avarage time using the ScalarDP class:400.21 Avarage time using the DPMatrix class:1418.11 Avarage time using the Matrixd class:471.69 Here is the result for postMult where matrixf use to be the same as Matrixd. The 277.69 is what would have been for Matrixf is it was aligned. Avarage time using the D3DXMATRIX class: 1035.63 Avarage time using the SPMatrix class:365.36 Avarage time using the Matrixf class:706.09 Avarage time using the ScalarDP class:664.13 Avarage time using the DPMatrix class:2052.29 Avarage time using the Matrixd class:2125.93 Here is the results for Invert4x4 where Matrixf also was the same as Marixd, and the 365 is what it would have been if the data was aligned. This stress code is part of the matlib2 with a little tweaking of the osg code to add into the mix. James Killian - Original Message - From: "Mathias Fröhlich" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, July 29, 2008 10:14 AM Subject: Re: [osg-users] Using SSE within OSG James, On Tuesday 29 July 2008 16:59, James Killian wrote: Paul asked me the same question a few days ago, and I just realized that we took that offline so I'll repost here: One of the things I should add is the actual profile dump, since that shows a more comprehensive picture. The actual game demo is free to download and play here: http://www.fringe-online.com/ The current installer of the game does not have my optimization in it yet, but it should be noted even with the optimization the postmult is still at the top. The Invert4x4() however got pushed way down to the bottom (which is great). I
Re: [osg-users] Using SSE within OSG
Thanks for the reply. We could resolve this argument if any one of the "low level masters" cares to email me offline [EMAIL PROTECTED], but I'd be open to believe an argument could be made for the context of moving around large amounts of data. In regards to moving data, SSE/SSE2 is really better suited for code which requires a lot of math like 3d computations. Perhaps the heart of SSE would be the packed multiply and add, where it can do 4 multiplies and 4 adds in one clock cycle (or a half cycle if paired properly). Thus, code which requires heavy math like many of the OSG matrix computations could really benefit from it. I would profile cases like this against hand written assembly since this is what OSG would care about. I looked at the assembly code produced by VS 9 for the optimized matrixf multiply, and I could not have scheduled it better myself by hand. - Original Message - From: "Gordon Tomlinson" <[EMAIL PROTECTED]> To: "'OpenSceneGraph Users'" Sent: Tuesday, July 29, 2008 2:58 PM Subject: Re: [osg-users] Using SSE within OSG > HI > > I can only go buy our low level masters and their profiling shows that the > hand road asm'ed SSE code is significantly fasted than MS VS compiled code > > Obviously this our experience in our environments and we computationally > heavily and moving and editing terra-bytes of data around in real-time > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of James > Killian > Sent: Tuesday, July 29, 2008 11:38 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Using SSE within OSG > > > Sorry... > > I interpreted Gordon's response as follows: > MS does a poor job (insert here with compiling SSE intrinsics), as a result > most of his SSE is asm'ed. > The asm'ed approach is where you don't trust the compiler to do the right > thing with intrinsics, where it has the flexibility of scheduling and > assigning registers etc. > > I disagree with "MS does a poor job compiling intrinsic code", and that you > should not *ever need to resort to __asm anymore. > *this is not absolute, there was once a rare case where we found a strange > anomaly, but later solved by doing an un-intuitive c code change > > >Do you find that MS compilers will produce SSE vectorised code > >_without_ > use of intrinsics or raw __asm? > Ah this is a tricky question. There is in fact an option in VS 8 and VS 9 > project settings to generate SSE or SSE2 code. What this does is that it > will evaluate c code and try to use SSE for it. I was surprised to find > that this actually lowered the performance of c code, especially c code for > matrixf. I'm so glad that the project settings for osg do not turn this on, > and I'd recommend not using that, but instead write intrisics ourselves for > places that need it. > > I hope this clears things up. > > > - Original Message - > From: "David Spilling" <[EMAIL PROTECTED]> > To: "OpenSceneGraph Users" > Sent: Tuesday, July 29, 2008 10:17 AM > Subject: Re: [osg-users] Using SSE within OSG > > > > James, > > > > > > > I have to disagree, using VS 7 and up to VS 9. > > > > > > Just to clarify - what are you disagreeing with? Do you find that MS > > compilers will produce SSE vectorised code _without_ use of intrinsics or > > raw __asm? > > > > David > > > > > -- -- > > > > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
" Ok, you can do here much for the collision detection. I expect that you should optimize that algorithmically and gain magnitudes without sse. " You are probably right, but Rick is the OSG guru in the team, and I do not understand osg that well yet as most of my time has been spent developing other aspects of the game. My strength lies with general purpose optimizing code, and so this helps our game tremendously. The least I can do is contribute this to the community and hope others get a boost as well. " So the question is more if such optimizations will bring performance improvements for the usual scenegraph case. " When I get home tonight I'll disable the collision detection and run the profiler again, and post the results, hopefully that data should answer this question. - Original Message - From: "Mathias Fröhlich" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, July 29, 2008 10:14 AM Subject: Re: [osg-users] Using SSE within OSG James, On Tuesday 29 July 2008 16:59, James Killian wrote: > Paul asked me the same question a few days ago, and I just realized that we > took that offline so I'll repost here: > One of the things I should add is the actual profile dump, since that shows > a more comprehensive picture. The actual game demo is free to download and > play here: > http://www.fringe-online.com/ > > The current installer of the game does not have my optimization in it yet, > but it should be noted even with the optimization the postmult is still at > the top. The Invert4x4() however got pushed way down to the bottom (which > is great). I'll post my profiles when I get home. > > > -snip- - >- --- > That is a good question, and I believe the answer is collision detection. > I should disable it and run the numbers again to confirm. All ships fire > machine guns at a fast rate, and each bullet that gets close enough to a > bounding box/sphere region has to go through the osg code to get the > precise point where it hit. Rick would probably have a better explanation > of this and other factors since he coded the bulk of the collision > detection (and osg integration). Most of my time development in the game > has been spent on the physics and flight dynamics (and now optimization). > > It may turn out that we could find some caching technique to reduce the > collision stress (like the KBDtree), but in the mean time, matrix > optimizations can benefit the whole community if we do them right, and I > would like to make some contribution to the community. Ok, you can do here much for the collision detection. I expect that you should optimize that algorithmically and gain magnitudes without sse. So the question is more if such optimizations will bring performance improovements for the usual scenegraph case. 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. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Sorry... I interpreted Gordon's response as follows: MS does a poor job (insert here with compiling SSE intrinsics), as a result most of his SSE is asm'ed. The asm'ed approach is where you don't trust the compiler to do the right thing with intrinsics, where it has the flexibility of scheduling and assigning registers etc. I disagree with "MS does a poor job compiling intrinsic code", and that you should not *ever need to resort to __asm anymore. *this is not absolute, there was once a rare case where we found a strange anomaly, but later solved by doing an un-intuitive c code change >Do you find that MS compilers will produce SSE vectorised code _without_ use of intrinsics or raw __asm? Ah this is a tricky question. There is in fact an option in VS 8 and VS 9 project settings to generate SSE or SSE2 code. What this does is that it will evaluate c code and try to use SSE for it. I was surprised to find that this actually lowered the performance of c code, especially c code for matrixf. I'm so glad that the project settings for osg do not turn this on, and I'd recommend not using that, but instead write intrisics ourselves for places that need it. I hope this clears things up. - Original Message - From: "David Spilling" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, July 29, 2008 10:17 AM Subject: Re: [osg-users] Using SSE within OSG > James, > > > > I have to disagree, using VS 7 and up to VS 9. > > > Just to clarify - what are you disagreeing with? Do you find that MS > compilers will produce SSE vectorised code _without_ use of intrinsics or > raw __asm? > > David > > ___ > 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] Using SSE within OSG
I have to disagree, using VS 7 and up to VS 9. It has done a terrific job with the instruction scheduling. We use to use that technique of asm back when P3's MMX were around and we had VS 6. We had one engineer who would use DOS and MASM. Times have changed (we had to let him go), intrinsics have proved to optimize quite well as we use the AMD code analyzer to confirm that the U and V pipes remain full due to well scheduled placement of the instructions. I should add that we avoid using any MMX instructions like the plague now days. - Original Message - From: "Gordon Tomlinson" <[EMAIL PROTECTED]> To: "'OpenSceneGraph Users'" Sent: Tuesday, July 29, 2008 8:56 AM Subject: Re: [osg-users] Using SSE within OSG > MS does a very poor job, > > I know most of our SSE is asm'ed > > > > _ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David > Spilling > Sent: Tuesday, July 29, 2008 9:11 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Using SSE within OSG > > > Benjamin, > > > > > may I suggest that you check the assembler code that the compilers create > when > compiling the OSG code? > > > > ... g++ with -march=core2 -O3 (see man page for description > of parameters) the compiler automatically uses SSE > > > I don't have much recent Linux/gcc experience, but can certainly attest that > the MS compilers don't do a good job of spotting SSE vectorisation > possibilities, even when you tell them to optimise with them (and this is > from reading the generated ssembler). In MS you can insert SSE intrinsics , > which still allow the compiler to optimise the execution order and > memory/register usage e.g. based on cycle counts. > > I understand (from other sources) that the Intel vectorising compilers are > much better at this, naturally. > > Perhaps this is then all only aMS/Windows thing? > > David > > > > > > ___ > 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] Using SSE within OSG
Paul asked me the same question a few days ago, and I just realized that we took that offline so I'll repost here: One of the things I should add is the actual profile dump, since that shows a more comprehensive picture. The actual game demo is free to download and play here: http://www.fringe-online.com/ The current installer of the game does not have my optimization in it yet, but it should be noted even with the optimization the postmult is still at the top. The Invert4x4() however got pushed way down to the bottom (which is great). I'll post my profiles when I get home. -snip--- --- That is a good question, and I believe the answer is collision detection. I should disable it and run the numbers again to confirm. All ships fire machine guns at a fast rate, and each bullet that gets close enough to a bounding box/sphere region has to go through the osg code to get the precise point where it hit. Rick would probably have a better explanation of this and other factors since he coded the bulk of the collision detection (and osg integration). Most of my time development in the game has been spent on the physics and flight dynamics (and now optimization). It may turn out that we could find some caching technique to reduce the collision stress (like the KBDtree), but in the mean time, matrix optimizations can benefit the whole community if we do them right, and I would like to make some contribution to the community. - Original Message - From: "Paul Melis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 28, 2008 9:05 AM Subject: [Fwd: Re: [osg-users] [osg-submissions] Matrixf multiply Optimization] > Hi James, > > I noted you posts on the osg-users list on the Matrix multiplication > optimizations using SSE. > You mention "Our game uses approximately 25% of all processing to these > functions [...]". What on earth takes up so much matrix computing time > in your game? > > Regards, > Paul > -snip--- --- - Original Message - From: "Mathias Fröhlich" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, July 29, 2008 9:31 AM Subject: Re: [osg-users] Using SSE within OSG Hi, On Tuesday 29 July 2008 15:18, James Killian wrote: > I 100% agree with that as that is the first thing I did. For the matrixf > mult I got 50% improvement with aligned data and 35% with unaligned. For > the Invert4x4 I got 80% improvement with aligned and 70% aligned with > unaligned. I've submitted this code in as it was the most time spent in > the profiles of our game. I wonder what your scenegraph looks like. Why do you have that much matrix operations? Where are they called from? Why do you need that many inverted matrices? Also the invert method makes me wonder. As far as I can tell, you do not need inverted matrices to do cull and draw. At least not in a magnitude that makes that method appear in profiles. Do you compute intersection tests where you need that inverse? And what kind of matrices are in your code that you really need the full 4x4 inverse? Almost alway the cheaper 3x4 variant can be used for usual transforms. Well, I ask that because I get the impression that the real botteneck - where you can gain much performance - is somwhere different. 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. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
I heard that the Intel C++ compiler is able to optimize even better. Furthermore the use of profiling first is a good approach. Maybe it would be reasonable to compare profiling data of the Math/Vector/Matrix classes with and without compiler optimizations and see if some bottlenecks disappear when using the optimizations. I 100% agree with that as that is the first thing I did. For the matrixf mult I got 50% improvement with aligned data and 35% with unaligned. For the Invert4x4 I got 80% improvement with aligned and 70% aligned with unaligned. I've submitted this code in as it was the most time spent in the profiles of our game. While I am here I think whatever we do we should have CMake have an option to compile using SSE, and provide alternative c code for those who do not want it. Actually, one of the techniques we use at work we handled the case during when SSE2 was only available to some machines, where we wrote the main loop to do the bulk of the work and the remainder loop do finish the work in c code. We could then macro out the main loop for those who didn't have SSE2 as it fell to the remainder code which then did the entire loop. I believe the time has passed to make SSE and SSE2 distinction, so either someone can support SSE2, or they use the c code version. It should be implied that people who write SSE/SSE2 have tested against the c code and have seen a significant gain in performance before considering to use. James Killian - Original Message - From: "Benjamin Eikel" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, July 29, 2008 7:28 AM Subject: Re: [osg-users] Using SSE within OSG Am Dienstag, 29. Juli 2008 14:04:59 schrieb David Spilling: Dear All, [...] Any other suggestions? *Question 3 : (possibly the biggest) Should the core OSG include SSE?* There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the "use the source" argument may be trickier when many might not know much SSE. Hello David, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? I have not done it for the OSG code, but for another project I have done some time ago. There I tried to optimize the performance for composing depth-buffer attached images for sort-last rendering. Somehow I was not able to be much better than the compiler was. In some rare cases my procedures were faster, but most of the time the compiler was the winner. The code created by the compilers consider so many things - e. g. branch prediction by the processer, code reordering - that it is quite hard for a human programmer to beat them. For example if you use g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE or even SSE2, 3dNOW!, etc. instructions. In some cases the compiler generates much better assembler code than a normal programmer would do. There are some case though were manual improvements could yield better results. I heard that the Intel C++ compiler is able to optimize even better. Furthermore the use of profiling first is a good approach. Maybe it would be reasonable to compare profiling data of the Math/Vector/Matrix classes with and without compiler optimizations and see if some bottlenecks disappear when using the optimizations. Regards, Benjamin So - your opinion, experience and suggestions welcome! David ___ 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] KdTree support now checked in
You know, to be honest I never really cared about what the values meant, but more about the percentage, and I probably should have showed the other numbers to get a full picture. Anyhow I found some info on what those values are I'll paste here: "In time-based profiling, the application to be analyzed is run at full speed on the same machine that is running AMD CodeAnalyst. Time-based samples (collected at predetermined intervals) can be used to identify possible bottlenecks, execution penalties, or optimization opportunities. The numbers are called timer samples. It is not often that I get opportunities to optimize code, but I can say that I've had success with this tool in the past. One of the greatest moments it helped me was when I was writing a reverb effect, and it identified the bottleneck being one line of code (normalize), when I optimized that line it took a dramatic effect of using 40% cpu to 2! - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, July 17, 2008 7:46 AM Subject: Re: [osg-users] KdTree support now checked in > On Thu, Jul 17, 2008 at 1:31 PM, James Killian > <[EMAIL PROTECTED]> wrote: > > The actual data comes from using the Amd Code Analyzer, while running the > > game. > > But what do the values mean? ms? number of times called? number of > astronauts in orbit at any one time? > ___ > 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] KdTree support now checked in
Ooops sorry, there is a game http://www.fringe-online.com/ which makes full use of collision detection (anyone can download the install). The test I am running has 10 ships (5 red, 5 blue) that are all shooting at each other. I guess what make these numbers special to me is that for every aspect of the game, this code is the most frequent called, and by a significant amount. Therefore, I'm going to look for any optimization opportunities (such as the KDTree) to help. The actual data comes from using the Amd Code Analyzer, while running the game. James Killian - Original Message - From: Adrian Egli OpenSceneGraph (3D) To: OpenSceneGraph Users Sent: Thursday, July 17, 2008 2:27 AM Subject: Re: [osg-users] KdTree support now checked in Sorry, i don't really understand where the bench come from. what did you messured, linesegement intersection visitor? 2008/7/17 James Killian <[EMAIL PROTECTED]>: I've got some numbers that are interesting: In a build before KDTree.. Matrixd::mult was the most used method: 1367 Matrixd::Mult 1080 Matrixd::makeidentity 982 Group Traverse With KDTree on here is how the numbers stand: 1305 Group::Traverse 1228 Matrix::mult 990 Compute Bound 776 Transform::Compute Bound 728 MatricsD::Make Identity So we can see how the KDTree has brought down the number of Matrixd::Mults, and so now Group Traverse can do more iterations. James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Saturday, July 12, 2008 10:46 AM Subject: Re: [osg-users] KdTree support now checked in Hi Adrian, It's great to hear you getting better performance. How much is down to more efficient intersections vs other changes to the OSG I cannot say - you'd need to profile the relative costs of intersections/cull and draw traversals etc. KdTree are only used in intersections, so it doesn't change the cull and draw traversals at all. It's not something that is likely to help much anyway, as the OpenGL pipeline is geared up to handling a moderate number of relatively large sets of geometry, and rarely is the actual geometry a bottleneck so it doesn't pay to just a do fine grained view frustum culling. Intersections a completely different matter - ray intersection strongly favour fine grained representations, hence why KdTree work so well. Robert. On Sat, Jul 12, 2008 at 4:41 PM, Adrian Egli OpenSceneGraph (3D) <[EMAIL PROTECTED]> wrote: Hi Robert, i tested the whole afternoon with a really big terrain database (city of cannes). i rebuild our internet based visualisation plugin with latest openscenegraph (SVN of this morning) and the performance with the kdTree datastructure enabled is much better than with elder OSG version. i don't yet understand why the performance is much faster, of course the new database pager concept could be responsable for the behaviour but i don't think so. now the frame rate is really constant, no longer view dependent for our motion model, also for the terrain manipulator. each of this motion model are using intersection visitor, may this was the reason why the frame rate was never constant, was view angle dependant. one pixel changed and the frame could dorp down or vise versa. but know the frame rate is nearly constant, for this huge database. of course still view dependant, but little change doesn't no longer change the frame rate (60/20) between small changes, this isn't question of culling,... i guess this was the intersection test, if we passed through a huge object, the fps drops down. this is greate. next question. do you use the KDTree to cull objects against the frustum. big objects (Triangles could better culled) if we can intersect easely a plane against the kdtree. /adrian 2008/7/12 Robert Osfield <[EMAIL PROTECTED]>: Hi J-S, On Sat, Jul 12, 2008 at 1:09 AM, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote: > I think I may be able to help a bit regarding the higher-level setup > and > bookkeeping changes needed to speed things up on that regard. One thing > I > noticed before is that creating a new Intersector and > IntersectionVisitor > each time is costly, and instead keeping static or cached instances and > using the reset() and setStart()/setEnd() methods is faster. There may > be > some other similar things that can be done too, we'll see what I can > dig > up. It's interesting how different bottlenecks pop
Re: [osg-users] KdTree support now checked in
I've got some numbers that are interesting: In a build before KDTree.. Matrixd::mult was the most used method: 1367 Matrixd::Mult 1080 Matrixd::makeidentity 982 Group Traverse With KDTree on here is how the numbers stand: 1305 Group::Traverse 1228 Matrix::mult 990 Compute Bound 776 Transform::Compute Bound 728 MatricsD::Make Identity So we can see how the KDTree has brought down the number of Matrixd::Mults, and so now Group Traverse can do more iterations. James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Saturday, July 12, 2008 10:46 AM Subject: Re: [osg-users] KdTree support now checked in Hi Adrian, It's great to hear you getting better performance. How much is down to more efficient intersections vs other changes to the OSG I cannot say - you'd need to profile the relative costs of intersections/cull and draw traversals etc. KdTree are only used in intersections, so it doesn't change the cull and draw traversals at all. It's not something that is likely to help much anyway, as the OpenGL pipeline is geared up to handling a moderate number of relatively large sets of geometry, and rarely is the actual geometry a bottleneck so it doesn't pay to just a do fine grained view frustum culling. Intersections a completely different matter - ray intersection strongly favour fine grained representations, hence why KdTree work so well. Robert. On Sat, Jul 12, 2008 at 4:41 PM, Adrian Egli OpenSceneGraph (3D) <[EMAIL PROTECTED]> wrote: Hi Robert, i tested the whole afternoon with a really big terrain database (city of cannes). i rebuild our internet based visualisation plugin with latest openscenegraph (SVN of this morning) and the performance with the kdTree datastructure enabled is much better than with elder OSG version. i don't yet understand why the performance is much faster, of course the new database pager concept could be responsable for the behaviour but i don't think so. now the frame rate is really constant, no longer view dependent for our motion model, also for the terrain manipulator. each of this motion model are using intersection visitor, may this was the reason why the frame rate was never constant, was view angle dependant. one pixel changed and the frame could dorp down or vise versa. but know the frame rate is nearly constant, for this huge database. of course still view dependant, but little change doesn't no longer change the frame rate (60/20) between small changes, this isn't question of culling,... i guess this was the intersection test, if we passed through a huge object, the fps drops down. this is greate. next question. do you use the KDTree to cull objects against the frustum. big objects (Triangles could better culled) if we can intersect easely a plane against the kdtree. /adrian 2008/7/12 Robert Osfield <[EMAIL PROTECTED]>: Hi J-S, On Sat, Jul 12, 2008 at 1:09 AM, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote: > I think I may be able to help a bit regarding the higher-level setup > and > bookkeeping changes needed to speed things up on that regard. One thing > I > noticed before is that creating a new Intersector and > IntersectionVisitor > each time is costly, and instead keeping static or cached instances and > using the reset() and setStart()/setEnd() methods is faster. There may > be > some other similar things that can be done too, we'll see what I can > dig > up. It's interesting how different bottlenecks pop up, in this case creating objects on the heap is clearly showing itself as a bottleneck whereas the old brute force intersection code was so slow that this wasn't a significant factor. Caching visitors and intersectors can certainly help, although one does need to be careful about threading issues with doing this, as the IntersectionVisitor and Intersectors aren't thread safe, so you'd need a cached instance per thread. Optimization could possibly be done with the data structure used to store the intersection results, this would unfortunately break the API compatibility. Changing that Intersector's are cloned might also help performance when dealing with scene graphs have transform - the clone is required to move the intersector into the local coordinate system of transforms subgraph. There other things one can do like grouping intersectors, or using intersection coherency. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o
Re: [osg-users] Please test SVN of OpenSceneGraph
VS9 compiled fine (using cmake 2.6) James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Friday, July 11, 2008 2:38 PM Subject: [osg-users] Please test SVN of OpenSceneGraph Hi All, I'm winding up towards the OpenSceneGraph-2.5.4 developer release, all the major changes are now checked in, so it's time to make sure that things are compiling and running sensible across platforms. If things look good then I'll tag 2.5.4 tomorrow. Once 2.5.4 is out the way my plan is to seriously look at osgWidget inclusion in to SVN trunk, so testing osgWidget and feedback on it would be very useful. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INSTALL include pdb's
Just so there is no confusion (with others reading this), the .pdb filename must match the filename of the dll or exe that is associated with it; so Osgviewer.exe or OsgViewer.dll will have to change their name! I can see it now someone will glv (get latest version) and see the name has changed and wonder why as they change it back. I hope people are reading my posts so that they will not be confused... I'll put comments in the Cmake script. If anyone reading this disagrees with this change please post. Ok, that should be easy enough to do. I have yet to do any OSG submissions. I'll have to read up on the protocol... (might as well start on this now with something simple now) :) Thanks for the heads up! - Original Message - From: "Philip Lowman" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Friday, July 11, 2008 8:47 AM Subject: Re: [osg-users] INSTALL include pdb's > Is there a linking flag you can use to change the generated .pdb filename > in Visual Studio? If so, you could simply use CMake to tweak the targets > that have conflicting names (see set_target_properties() command) > > > .. Original Message ... > On Thu, 10 Jul 2008 22:45:13 -0500 "James Killian" > <[EMAIL PROTECTED]> wrote: > > > >Thanks for response... I'll look into that... but first there is a bigger > problem with osgviewer. I'll have to double check, but by default the > Applications osgviewer and osgViewer (dll) writing the same pdb file to the > same place, and guess which one get overwritten (No windows does not allow > case sensitive duplicate files)... Yep the DLL one, the one I need to see > in my call stack crash. G > > > >I think the Application osgviewer project name should be renamed, or these > .exe files build their pdbs to a different folder (preferably renamed). > Can someone verify this is a legitimate problem... thanks. > >Jean? > > > >James Killian > > > >- Original Message - > >From: Philip Lowman > >To: OpenSceneGraph Users > >Sent: Thursday, July 10, 2008 9:52 PM > >Subject: Re: [osg-users] INSTALL include pdb's > > > >On Thu, Jul 10, 2008 at 10:40 PM, James Killian > <[EMAIL PROTECTED]> wrote: > > > >Hmmm no one has responded... I can figure out where in cmake to make the > change, if I add it would anyone have any objections? > >(If no one responds... I'll assume its fine to add) > > > >I believe you'll want to have a look at the INSTALL(FILES...) and/or > ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD COMMAND) commands as > possibilities. If you end up needing ADD_CUSTOM_COMMAND consider using > "cmake -E copy_if_different" instead of "copy". I'm out of town and don't > have access to a VS development environment otherwise I think I could come > up with something for you. > > > >This may also not be a bad feature to add to CMake itself if simply > deploying the PDB files alongside the debug DLL file buys you this > functionality. > > > >-- > >Philip Lowman > > > >--- > > > >___ > >osg-users mailing list > >osg-users@lists.openscenegraph.org > >http://lists.openscenegraphorg/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 > -- > Philip Lowman > ___ > 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] INSTALL include pdb's
Thanks for response... I'll look into that... but first there is a bigger problem with osgviewer. I'll have to double check, but by default the Applications osgviewer and osgViewer (dll) writing the same pdb file to the same place, and guess which one get overwritten (No windows does not allow case sensitive duplicate files)... Yep the DLL one, the one I need to see in my call stack crash. G I think the Application osgviewer project name should be renamed, or these .exe files build their pdbs to a different folder (preferably renamed). Can someone verify this is a legitimate problem... thanks. Jean? James Killian - Original Message - From: Philip Lowman To: OpenSceneGraph Users Sent: Thursday, July 10, 2008 9:52 PM Subject: Re: [osg-users] INSTALL include pdb's On Thu, Jul 10, 2008 at 10:40 PM, James Killian <[EMAIL PROTECTED]> wrote: Hmmm no one has responded... I can figure out where in cmake to make the change, if I add it would anyone have any objections? (If no one responds... I'll assume its fine to add) I believe you'll want to have a look at the INSTALL(FILES...) and/or ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD COMMAND) commands as possibilities. If you end up needing ADD_CUSTOM_COMMAND consider using "cmake -E copy_if_different" instead of "copy". I'm out of town and don't have access to a VS development environment otherwise I think I could come up with something for you. This may also not be a bad feature to add to CMake itself if simply deploying the PDB files alongside the debug DLL file buys you this functionality. -- Philip Lowman -- ___ 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] INSTALL include pdb's
Hmmm no one has responded... I can figure out where in cmake to make the change, if I add it would anyone have any objections? (If no one responds... I'll assume its fine to add) James Killian - Original Message - From: "James Killian" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, July 10, 2008 10:12 AM Subject: [osg-users] INSTALL include pdb's Is it possible to have all the pdb files copied when building the INSTALL project? Sure would be nice to see the symbols when I get a crash. Thanks. P.S. Maybe this should be an option for those who don't want them copied ___ 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] INSTALL include pdb's
Is it possible to have all the pdb files copied when building the INSTALL project? Sure would be nice to see the symbols when I get a crash. Thanks. P.S. Maybe this should be an option for those who don't want them copied ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The growing draw bar in the stats handler
nope if I ever do I'll post back To me all the times I've used it... it appeared to work flawlessly. - Original Message - From: "Rick Pingry" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, July 10, 2008 9:28 AM Subject: Re: [osg-users] The growing draw bar in the stats handler > I have dual NVIDIA GeForce 8400 GS cards in an SLI configuration. > > James, Are you seeing the long orange bar in the stats window? > > On Thu, Jul 10, 2008 at 10:23 AM, James Killian <[EMAIL PROTECTED]> > wrote: > > > > > I have ran Rick's app on my machine (using XP, dual monitors, and NVidia > > 6200) I did not see any of these problems. > > > > - Original Message - > > From: "Wojciech Lewandowski" <[EMAIL PROTECTED]> > > To: "OpenSceneGraph Users" > > Sent: Thursday, July 10, 2008 5:00 AM > > Subject: Re: [osg-users] The growing draw bar in the stats handler > > > > > > > Hi Rick and Robert, > > > > > > I mentioned this problem few months ago. Happened on Windows XP and > > Vista. > > > It seemed to dissapear with more recent NVidia drivers though (ver 169.xx > > > and larger). I don't remember exactly but I think it was present only on > > > dual monitors. Do you by any chance have dual view config ? > > > > > > Cheers, > > > Wojtek Lewandowski > > > > > > > > > > The short bars are probably the initial state of the bars that haven't > > > > been initialized yet. > > > > > > > > As for your single really long bar, this suggests that the GPU is > > > > stalled doing something for a very long time... > > > > > > > > It could possibly be a bug in the stats collection. The stats > > > > collection has been working fine for a year now, so I don't think > > > > there is a problem on the OSG side, but perhaps you've uncovered a bug > > > > in the driver. > > > > > > > > Robert. > > > > > > > > On Thu, Jul 10, 2008 at 3:14 AM, <[EMAIL PROTECTED]> wrote: > > > >> Something else I noticed that I thought was strange was that the > > orange > > > >> GPU > > > >> bar has 8 short blocks all drawn in the first frame. I have included > > an > > > >> image to show. What does this mean? When I look at a smaller model, > > the > > > >> Orange block fills alll along the lower bar. > > > >> > > > >> > > > >> > > > >> On Wed, Jul 9, 2008 at 9:46 PM, <[EMAIL PROTECTED]> wrote: > > > >>> > > > >>> Hello all, > > > >>> > > > >>> I recently added a stats handler to our game viewer. Something I > > > >>> noticed > > > >>> is that if you have the stats window open, showing the bars, that the > > > >>> draw > > > >>> bar grows and grows. The framerate starts dropping and gets slower. > > If > > > >>> I > > > >>> turn the bars off, the framerate returns to 60. When I turn the bars > > > >>> back > > > >>> on, the draw bar is suddenly back where it was when I turned it off, > > and > > > >>> starts growing again. > > > >>> > > > >>> I noticed this does not happen if I have a fairly trivial model, and > > it > > > >>> does not happen in osgviewer at all (as far as I can tell), using the > > > >>> same > > > >>> model I had in my game viewer. What could I be doing wrong? > > > >>> > > > >>> Thanks > > > >>> -- Rick > > > >> > > > >> > > > >> -- > > > >>>> Rick > > > >> Check us out at http://fringe-online.com/ > > > >> ___ > > > >> osg-users mailing list > > > >> osg-users@lists.openscenegraph.org > > > >> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > >> > > > >> > > > > ___ > > > > osg-users mailing list > > > > osg-users@lists.openscenegraph.org > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > ___ > > > 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 > > > > > > -- > >> Rick > Check us out at http://fringe-online.com/ > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The growing draw bar in the stats handler
I have ran Rick's app on my machine (using XP, dual monitors, and NVidia 6200) I did not see any of these problems. - Original Message - From: "Wojciech Lewandowski" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, July 10, 2008 5:00 AM Subject: Re: [osg-users] The growing draw bar in the stats handler > Hi Rick and Robert, > > I mentioned this problem few months ago. Happened on Windows XP and Vista. > It seemed to dissapear with more recent NVidia drivers though (ver 169.xx > and larger). I don't remember exactly but I think it was present only on > dual monitors. Do you by any chance have dual view config ? > > Cheers, > Wojtek Lewandowski > > > > The short bars are probably the initial state of the bars that haven't > > been initialized yet. > > > > As for your single really long bar, this suggests that the GPU is > > stalled doing something for a very long time... > > > > It could possibly be a bug in the stats collection. The stats > > collection has been working fine for a year now, so I don't think > > there is a problem on the OSG side, but perhaps you've uncovered a bug > > in the driver. > > > > Robert. > > > > On Thu, Jul 10, 2008 at 3:14 AM, <[EMAIL PROTECTED]> wrote: > >> Something else I noticed that I thought was strange was that the orange > >> GPU > >> bar has 8 short blocks all drawn in the first frame. I have included an > >> image to show. What does this mean? When I look at a smaller model, the > >> Orange block fills alll along the lower bar. > >> > >> > >> > >> On Wed, Jul 9, 2008 at 9:46 PM, <[EMAIL PROTECTED]> wrote: > >>> > >>> Hello all, > >>> > >>> I recently added a stats handler to our game viewer. Something I > >>> noticed > >>> is that if you have the stats window open, showing the bars, that the > >>> draw > >>> bar grows and grows. The framerate starts dropping and gets slower. If > >>> I > >>> turn the bars off, the framerate returns to 60. When I turn the bars > >>> back > >>> on, the draw bar is suddenly back where it was when I turned it off, and > >>> starts growing again. > >>> > >>> I noticed this does not happen if I have a fairly trivial model, and it > >>> does not happen in osgviewer at all (as far as I can tell), using the > >>> same > >>> model I had in my game viewer. What could I be doing wrong? > >>> > >>> Thanks > >>> -- Rick > >> > >> > >> -- > Rick > >> Check us out at http://fringe-online.com/ > >> ___ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > >> > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ > 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] Rendering performance issues
I am so glad that someone else is getting the same results as we are. I've seen these same kind of gaps with our game and they come and go as I have not been able to nail down the cause for them yet. My guess is that there is some external CPU I/O activity which is causing this, especially if the graph representation works like a profiler class. The last time I profiled (I think around 8482) the threads looked very clean especially with minimal critical section usage. I guess the question for you, is can you profile your external CPU activity? I use QueryPerformanceCount() and clock the time used for external code. I know for instance that collision detection has been expensive, and thus causes the gaps. Aside from this, if you have a Win32 platform you may use SystemInternals tools like process monitor (formerly known as filemon) to ensure your app is not doing some unexpected I/O operation. I know for instance that the trailed smoke particle effect will continuously reload the image file everytime it is used... I wouldn't have found this if it wasn't for filemon. Perhaps there is some other implicit I/O surprise which is happening to you. I hope you can rule out the external workload, because perhaps there is some performance change that we all can benefit from. :) - Original Message - From: "Bob Balfour" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Monday, July 07, 2008 5:37 PM Subject: [osg-users] Rendering performance issues > I'm experiencing some performance peculiarities that I don't quite > understand. My platform is an HP Blackbird, Vista OS, 4-CPU, 2 NVidia > 8800, OSG2.4. > > I have attached 4 timing images: > > The first image (vsyncOFF-1GPU.jpg) shows the timing rendering 1 slave > camera on an extended (2880x900) dual-monitor on a single Nvidia card. > Note the 211Hz rendering rate with VSync off and the substantial > Draw/GPU overlap. [Note that in all of these timing tests none of the > CPUs appeared more than 50% loaded.] This is the type of performance I > was anticipating. > > Now all I did was turn on Vsync. The second image > (vsyncON-app-long.jpg) now shows a 60Hz rendering rate as expected (with > a delay after GPU waiting for VSync), but no Draw/GPU overlap, there's > even a slight gap between the two? Why is this different now? > > Now I flew thru the scene to a point where the Draw became quite small. > The third image (vsyncON-app-short.jpg) shows the Cull,Draw,GPU all > <1.0, but I'm only achieving a 46Hz rendering rate because of the > considerable gap between Draw and GPU. Why is the GPU now being delayed > so much after Draw?? It's almost like the GPU is stuck starting out > there mid-frame? > > Now I turned VSync back OFF, but this time rendered TWO slave cameras > (each 2880x900, one on each Nvidia card), and the same effect appeared > (see the forth image vsyncOFF-2GPUs.jpg) where the GPUs are being > delayed to mid-frame, and there is quite a delay after the GPUs complete > (which should not be there with VSync OFF?). Because of these > substantial delays which I don't understand, performance has degraded > considerably from my initial test image, which had good overlap and no > delays. > > Is there any explanation for this, and can the delays be eliminated and > performance improved? > > Also, is there a purpose/need for VSync using LCD flatpanel monitors or > DLP projectors? > > Thanks. > > Bob. > -- > > Robert E. Balfour, Ph.D. > Exec. V.P. & CTO, BALFOUR Technologies LLC > 960 So. Broadway, Suite 108, Hicksville NY 11801 > Phone: (516)513-0030 Fax: (516)513-0027 email: [EMAIL PROTECTED] > /"Solutions in four dimensions" with *fourDscape*®/ > > > ___ > 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] Update Optimization
Speaking of the timing stats, I've been using the stat class with our game and it looks like so: || <-- event | | <-- update ? | cull | | Draw | --- gpu--- | | gpu | The interesting thing about this is that there is a space gap between the update and the cull. Not sure yet if this is due to sleep or due to code workload. In the worse case all these bars are spread out where there are gaps in between each (I'm guessing cpu workload). James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Friday, July 04, 2008 11:35 AM Subject: Re: [osg-users] Update Optimization Opps typo... You *haven't* said anything about what you do in the update other that update positions. You need to provide us with far more info about what you are doing, including actual timing stats on the operations. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS9
Oooops black on black... I've reposted this too Thanks for this info... I checked the projects by hand and sure enough all the optimization settings were incorrect. I simply fixed them and viola back in business!! - Original Message - From: "James Killian" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Wednesday, July 02, 2008 10:58 PM Subject: Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS9 Thanks for this info... I checked the projects by hand and sure enough all the optimization settings were incorrect. I simply fixed them and viola back in business!! James Killian - Original Message - From: Paul Martz To: 'OpenSceneGraph Users' Sent: Tuesday, July 01, 2008 4:45 PM Subject: Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS9 Do you get the same behavior if you generate fresh VS9 project files with cmake, instead of generating VS7.1 files and converting them? I'm not sure this will have any effect, but it seems like it might be worth a shot... -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Pingry Sent: Tuesday, July 01, 2008 3:14 PM To: OpenSceneGraph Users Subject: [osg-users] Performance hit caused by porting from VS 7.1 to VS 9 Hello All, We have succesfully ported from OSG 1.2 to the newest SVN version (well, almost newest, I think we are on 8512 at the moment). Thanks again for all the fantastic forum support. We have been using VS 7.1 for all of our work so far, but since we were missing a well build freetype library, I figured it was time to make the jump there as well. I downloaded VS 9 express and ran CMake to build OSG. All built just fine. The converter in VS 9 converted all of the projects without fuss, and I was able to get it all compiling and running pretty easily. Unfortunately, I am seeing this 30% drop in framerate :(. I was seeing about 28-30 fps (yes, I know, I have some scene optimizing to do) with the VS 7.1 build, which dropped to 20-21 fps using VS 9 express. Has anyone seen anything like that before? Am I missing some setting somewhere? Perhaps the converter in VS 9 does not like me? Any ideas? -- Thanks >> Rick Check us out at http://fringe-online.com/ -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG thread profiling results are in!!
Gahhh... thanks for the heads up... @#$#@ Microsoft... I've disabled html and going to use plain text from now on. - Original Message - From: "Paul Speed" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, July 03, 2008 3:54 AM Subject: Re: [osg-users] OSG thread profiling results are in!! > You are sending in code again. ;) > -Paul > > James Killian wrote: > > > > " > > We are using some particle effects pretty heavily, and we noticed (using > > filemon) that the smoke image file is being read over and over again, > > many times (perhaps once per frame). Is this possible? We are going to > > look into that next. Maybe we can cache the single image (state set)? > > " > > > > I found a way to cache the images. The Registry in osgDB has the > > ability to set options. It appears that _options is NULL by default, > > the options have a CACHE_IMAGES flag to use along with others. This > > works against any code that uses readImage(filename). There are others > > to explore too: > > > > Does anyone have any experience with using these options? is there any > > others that should or should not be used? > > > > > > > > James Killian > > > > - Original Message - > > *From:* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > *To:* OpenSceneGraph Users <mailto:osg-users@lists.openscenegraph.org> > > *Sent:* Wednesday, July 02, 2008 2:11 PM > > *Subject:* Re: [osg-users] OSG thread profiling results are in!! > > > > Hi Robert, > > > > I got the stats handler working on our scene and displaying. I am > > not sure I understand what the different numbers mean and how I > > might work with them. I can see the optimization effort is a big > > deal. I know it is beyond the scope of this group. Are there any > > resources out there to look at? > > > > I have finished the work you had already mentioned, like using png > > rather than bmp everywhere. We are also working on making sure our > > images are as small as possible. We are also going to work on using > > LOD. Since we are in space and most ships are far away, we are sure > > we can make a big jump there. I used osgUtil::Optimizer and that > > game me a few more frames. > > > > What are some other suggestions? > > > > We are using some particle effects pretty heavily, and we noticed > > (using filemon) that the smoke image file is being read over and > > over again, many times (perhaps once per frame). Is this possible? > > We are going to look into that next. Maybe we can cache the single > > image (state set)? > > > > Thanks > > -- Rick > > > > On Sat, Jun 28, 2008 at 11:55 AM, Robert Osfield > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > On Sat, Jun 28, 2008 at 4:35 PM, James Killian > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > > wrote: > > > The thread profiler does provide detailed information of > > every threaded > > > activity at any given time. I just wish there was some way > > to present the > > > information given that would be more meaningful to the group. > > > > > > What would be great is to have a big balanced scene that can > > put OSG Viewer > > > to the test in a way where it puts equal intense stress on > > update, culling, > > > and draw dispatch. What I'd hope to see is the draw dispatch > > be on a > > > separate thread, where that thread showed mostly I/O > > activity, and the cpu > > > activity on other threads. > > > > The osgViewer::StatsHandler will display update, event, cull, draw > > dispatch on all systems and draw GPU stats. The GPU stats > > require an > > OpenGL extension that I've only seen Nvidia implement so far, so you > > won't see this stats printed out on all systems. > > > > Also record a camera path/game sequence that you can use for > > benchmarking so that every run the app does the same thing, then > > you'll be able to study the effects that changes you make have on > > final performance. You'll also be able to study the abo
Re: [osg-users] OSG thread profiling results are in!!
" We are using some particle effects pretty heavily, and we noticed (using filemon) that the smoke image file is being read over and over again, many times (perhaps once per frame). Is this possible? We are going to look into that next. Maybe we can cache the single image (state set)? " I found a way to cache the images. The Registry in osgDB has the ability to set options. It appears that _options is NULL by default, the options have a CACHE_IMAGES flag to use along with others. This works against any code that uses readImage(filename). There are others to explore too: Does anyone have any experience with using these options? is there any others that should or should not be used? James Killian - Original Message - From: [EMAIL PROTECTED] To: OpenSceneGraph Users Sent: Wednesday, July 02, 2008 2:11 PM Subject: Re: [osg-users] OSG thread profiling results are in!! Hi Robert, I got the stats handler working on our scene and displaying. I am not sure I understand what the different numbers mean and how I might work with them. I can see the optimization effort is a big deal. I know it is beyond the scope of this group. Are there any resources out there to look at? I have finished the work you had already mentioned, like using png rather than bmp everywhere. We are also working on making sure our images are as small as possible. We are also going to work on using LOD. Since we are in space and most ships are far away, we are sure we can make a big jump there. I used osgUtil::Optimizer and that game me a few more frames. What are some other suggestions? We are using some particle effects pretty heavily, and we noticed (using filemon) that the smoke image file is being read over and over again, many times (perhaps once per frame). Is this possible? We are going to look into that next. Maybe we can cache the single image (state set)? Thanks -- Rick On Sat, Jun 28, 2008 at 11:55 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: On Sat, Jun 28, 2008 at 4:35 PM, James Killian <[EMAIL PROTECTED]> wrote: > The thread profiler does provide detailed information of every threaded > activity at any given time. I just wish there was some way to present the > information given that would be more meaningful to the group. > > What would be great is to have a big balanced scene that can put OSG Viewer > to the test in a way where it puts equal intense stress on update, culling, > and draw dispatch. What I'd hope to see is the draw dispatch be on a > separate thread, where that thread showed mostly I/O activity, and the cpu > activity on other threads. The osgViewer::StatsHandler will display update, event, cull, draw dispatch on all systems and draw GPU stats. The GPU stats require an OpenGL extension that I've only seen Nvidia implement so far, so you won't see this stats printed out on all systems. Also record a camera path/game sequence that you can use for benchmarking so that every run the app does the same thing, then you'll be able to study the effects that changes you make have on final performance. You'll also be able to study the above stats to where the problems occur in your scene. As a small note, the OSG in CullDrawThreadPerContext, DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext run graphics in a separate thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- >> Rick Check us out at http://fringe-online.com/ -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS9
Thanks for this info... I checked the projects by hand and sure enough all the optimization settings were incorrect. I simply fixed them and viola back in business!! James Killian - Original Message - From: Paul Martz To: 'OpenSceneGraph Users' Sent: Tuesday, July 01, 2008 4:45 PM Subject: Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS9 Do you get the same behavior if you generate fresh VS9 project files with cmake, instead of generating VS7.1 files and converting them? I'm not sure this will have any effect, but it seems like it might be worth a shot... -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Pingry Sent: Tuesday, July 01, 2008 3:14 PM To: OpenSceneGraph Users Subject: [osg-users] Performance hit caused by porting from VS 7.1 to VS 9 Hello All, We have succesfully ported from OSG 1.2 to the newest SVN version (well, almost newest, I think we are on 8512 at the moment). Thanks again for all the fantastic forum support. We have been using VS 7.1 for all of our work so far, but since we were missing a well build freetype library, I figured it was time to make the jump there as well. I downloaded VS 9 express and ran CMake to build OSG. All built just fine. The converter in VS 9 converted all of the projects without fuss, and I was able to get it all compiling and running pretty easily. Unfortunately, I am seeing this 30% drop in framerate :(. I was seeing about 28-30 fps (yes, I know, I have some scene optimizing to do) with the VS 7.1 build, which dropped to 20-21 fps using VS 9 express. Has anyone seen anything like that before? Am I missing some setting somewhere? Perhaps the converter in VS 9 does not like me? Any ideas? -- Thanks >> Rick Check us out at http://fringe-online.com/ -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering to multiple graphics cards
That is very interesting... your symptoms sound very familiar. I also tested
on Vista 64, but for me it was built for 32 bit and only for one monitor. It
would display some initial frames lock up then crash, where on other machines
using XP it ran fine. I know that I've had earlier builds that ran fine with
Vista 64, but I believe they were all single threaded builds.
James Killian
- Original Message -
From: Wojciech Lewandowski
To: OpenSceneGraph Users
Sent: Monday, June 30, 2008 9:24 AM
Subject: Re: [osg-users] Rendering to multiple graphics cards
Hi Everyone,
I have done some OSG testing with Vista 64 bit + 2 x GeForce 8800 GTS 320 MB
+ 3 monitors. I have attached only 3 monitors but I am sure 4 would work either.
Unfortunately results are mixed. I was able to start osgviewer and our demo
app on 3 monitors. I was able to get some visual but after few frames driver
was dying and after few moments Vista popped up with msgbox that graphics
driver failed but now it is ok (or something like this). I may not have the
power supply decent enough to provide the stable current so this crash could be
power related. I will try to arrange some heavy duty power supply and redo the
tests again later this week. Anyway it looks like at this stage results are
more promising than with XP and two different GeForces.
Cheers,
Wojtek
- Original Message -
From: Wojciech Lewandowski
To: OpenSceneGraph Users
Sent: Monday, June 30, 2008 10:34 AM
Subject: Re: [osg-users] Rendering to multiple graphics cards
Thanks, Bob.
This is a relief ;-). I don't have the acces to similar Vista setup yet.
Will try to grab two boards and do the checks this week.Will post a meesage
with results when I am done.
Thanks again.
Wojtek
- Original Message -
From: Bob Balfour
To: OpenSceneGraph Users
Sent: Sunday, June 29, 2008 2:32 AM
Subject: Re: [osg-users] Rendering to multiple graphics cards
I have two Nvidia 8800 cards on a Windows Vista platform (HP), and
setting traits->screenNum to 0 or 1 as Robert indicated does send the rendering
to the appropriate graphics cards. I used code very similar to the osgcamera
example, multipleWindowMultipleCameras method.
Does anyone have experience setting up a 4-monitor (each 1440x900) system
on Windows Vista? I have 2 osgcameras/contexts rendering left-half/right-half
of the scene. With 2 Nvidia graphics cards both in dual-head mode, if I render
each camera to a viewport 2880x900 I'm hoping that the scene will be spread
properly over the 4 monitors (will try it shortly once I round up four HD
monitors), without configuring the "extending the desktop" option in Windows,
which seems to take considerable resources in the dwm.exe task ("dynamic window
manager"), which appears to have an OSG rendering performance impact. Anyone
have similar experience here, or other configuration suggestions?
Thanks.
Bob.
--
Wojciech Lewandowski wrote:
Hi Bob,
Seems like you asked related question to mine. I would be very
interested in your results. I tried to run osgviewer on two graphics boards
withour success. But I was on XP and boards were different. I have not given up
completely, hoping that Vista or identical cards may work. Then I have read
your post and I see that you have exactly such setup. Does osgviewer outputs to
monitors cards attached to both cards ?
Cheers,
Wojtek
Hi Bob,
Using the screenNum set to 0 or 1 should select the appropriate card.
When you run osgviewer on your system it should open up two
windows/two slave cameras automatically, press 'f' to toggle off full
screen to see the actual windows.
Robert.
On Tue, Jun 24, 2008 at 8:56 PM, Bob Balfour <[EMAIL PROTECTED]>
wrote:
I also have an HP Windows (Vista) box with 2 Nvidia graphics cards
(independent, not SLI-configured). In order to configure two
osg::cameras,
each one rendering to its own specific Nvidia card, how do you
specify a
camera graphics context for a specific graphics card. Is it simply
specifying the appropriate traits->screenNum, or does it take more
than
that? Has anyone done this in Windows Vista?
Thanks.
Bob.
--
Robert E. Balfour, Ph.D.
Exec. V.P. & CTO, BALFOUR Technologies LLC
960 So. Broadway, Suite 108, Hicksville NY 11801
Phone: (516)513-0030 Fax: (516)513-0027 email: [EMAIL PROTECTED]
"Solutions in four dimensions" with fourDscape(R)
___
Re: [osg-users] OSG thread profiling results are in!!
Thanks for the feedback. I'll start with these areas as you suggested and see what numbers I am getting. The thread profiler does provide detailed information of every threaded activity at any given time. I just wish there was some way to present the information given that would be more meaningful to the group. What would be great is to have a big balanced scene that can put OSG Viewer to the test in a way where it puts equal intense stress on update, culling, and draw dispatch. What I'd hope to see is the draw dispatch be on a separate thread, where that thread showed mostly I/O activity, and the cpu activity on other threads. Well anyhow... I got my work cut out for me now... thanks again. James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Saturday, June 28, 2008 4:22 AM Subject: Re: [osg-users] OSG thread profiling results are in!! Hi James, I've read your emails but I'm afraid the stats mean absolutely nothing do me. One will really need to be find out what parts of the OSG i.e. what function calls are the current bottleneck. As general note, performance optimization with scene graphs as almost always an issue of improving the balance of the scene graph, be it update, cull, draw dispatch or draw GPU, it's almost always a poor scene graph that is at fault. You can often improve performance by 10x and more by simply fixing the scene graph. Doing low level code optimization will rarely get you anything like the performance improvement that you'd get by just fixing the scene graph. Given this, diving into low level profiling could well be a case of not seeing the wood from the trees. So I'd recommend if you want your app to go faster start with the basics, are your CPU or GPU limited. Then are you update, cull or draw dispatch limited? Then depending upon what results you get consider why the scene graph itself is making things so slow. This process will typically lead you to things you can do to your scene graph to fix the performance bottleneck, and all this without touching the actual code. Performance optimization is huge topic, but hopefully I'll have given you a little pointer to priorities I'd apply. Robert. On Sat, Jun 28, 2008 at 4:12 AM, James Killian <[EMAIL PROTECTED]> wrote: Here are some interesting profile results from the threaded profiler. First here is the ground work: OSG SVN 8482 using VS 7.1 with threading enabled (interlocked config). The actual client code tested that pushes some stress on osg is our game which anyone can download here http://www.fringe-online.com/.So I run this and measure the thread performance using Intel's thread compiler. So far, our client code main loop is very similar to how it is in the osg viewer (no fancy optimizations). There are 2 machines I have tested now... I'll post a copy of a different message I sent a few days ago here (to keep all info in this thread) ---snip Robert, This proposal you mention for 2.6 will it help balance the cpu workload against the gpu I/O bottleneck? I've been doing some osg performance benchmark research on thread synchronization using the Intel Threaded compiler, and so far the results are looking really good except for a 26% over-utilization due to sleeping. I do want to say awesome job to those responsible for threading, the amount of critical section use looked very good! All the worker threads also had good profiling results. The ultimate test I want to try today deals with an intentional GPU bottleneck... where I have a quadcore that pipes graphics out a PCI graphics card. If anyone is interested I'll post these test results. I know now that using a quad core there is lack of parallelization (e.g. 25% 85% 15% 15%), but that is a different battle for a different time. I do want to get to the bottom of the profiling and determine how well the workload is balanced against the gpu i/o, and see if there is some opportunity for optimization here. -snip Today I have the numbers from the souped up machine with a poor poor pci graphics card. The first thing to note is that the game never exceeded 18% cpu usage!! When I profiled 65% of the main thread was devoted to "serial" time and the bulk of the cpu time was on *this thread* and PrintSchedulingInfo [20] thread. The thread 20 showed 21% contributed to blocking, but the rest of it was active. The rest of the threads (like with my machine) looked really good! it is just too bad they don't do much work. Realistically my machine at work is not typical due to the pci graphics, but it did put good stresses to show where the I/O bottle neck is (on the main thread). My machine at home is a dual p 2.4 with NVidia GeForce 5900XT. When testing other games on my h
Re: [osg-users] multi threaded with slave camera and fbo
I have started a new thread called OSG thread profiling results are in!! This will have those test results. James Killian - Original Message - From: "Cedric Pinson" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, June 26, 2008 4:33 PM Subject: Re: [osg-users] multi threaded with slave camera and fbo Your mails are black so i need to select the test to read it. Anyway i am interested by all result you have. If you can post them Cedric James Killian wrote: I too find some interesting issues with this thread. :) Robert, This proposal you mention for 2.6 will it help balance the cpu workload against the gpu I/O bottleneck? I've been doing some osg performance benchmark research on thread synchronization using the Intel Threaded compiler, and so far the results are looking really good except for a 26% over-utilization due to sleeping. I do want to say awesome job to those responsible for threading, the amount of critical section use looked very good! All the worker threads also had good profiling results. The ultimate test I want to try today deals with an intentional GPU bottleneck... where I have a quadcore that pipes graphics out a PCI graphics card. If anyone is interested I'll post these test results. I know now that using a quad core there is lack of parallelization (e.g. 25% 85% 15% 15%), but that is a different battle for a different time. I do want to get to the bottom of the profiling and determine how well the workload is balanced against the gpu i/o, and see if there is some opportunity for optimization here. - Original Message - *From:* Robert Osfield <mailto:[EMAIL PROTECTED]> *To:* OpenSceneGraph Users <mailto:osg-users@lists.openscenegraph.org> *Sent:* Thursday, June 26, 2008 7:06 AM *Subject:* Re: [osg-users] multi threaded with slave camera and fbo Hi Guys, I've just skimmed through this thread. Interesting issues :-) Wojtek explanations of the double buffered SceneView is spot on, in this case leading to two FBO's, Creation of two FBO's for RTT is something I've been aware of since the inception of the DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext, but as yet haven't had the opportunity to refactor the code to avoid it. The problem actually stems from the reuse of SceneView to do something that it was never intended to handle, and in terms of osgViewer implementation SceneView was used simply because it was the line of least resistance i.e. it worked and code be adapted to help speed up the implementation of osgViewer, and mostly it's actually worked out ok, the stop gap has worked out pretty well. However, it has always been my plan to rewrite the osgViewer::Renderer so that it doesn't use SceneView at all, let alone double buffering them, instead it's my plan to use a single CullVisitor which alternately populates double buffered RenderStage. This approach would be far leaner and less obfusticated, and we should be able to clean up some of the artefacts as well. The downside is by not using SceneView we'll loose all the stereo rendering support, so instead we'll need to refactor osgViewer so that stereo rendering is done at the viewer level i.e. using slave cameras - this means more coding work, but the actually end result would be far better both design wise as well as in flexibility and performance. I just need to time to go off and do this work, I might be able to get it done for 2.6, but spare time certainly isn't something that I'm blessed with right now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org <mailto:osg-users@lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ 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] OSG thread profiling results are in!!
Here are some interesting profile results from the threaded profiler. First here is the ground work: OSG SVN 8482 using VS 7.1 with threading enabled (interlocked config). The actual client code tested that pushes some stress on osg is our game which anyone can download here http://www.fringe-online.com/.So I run this and measure the thread performance using Intel's thread compiler. So far, our client code main loop is very similar to how it is in the osg viewer (no fancy optimizations). There are 2 machines I have tested now... I'll post a copy of a different message I sent a few days ago here (to keep all info in this thread) ---snip Robert, This proposal you mention for 2.6 will it help balance the cpu workload against the gpu I/O bottleneck? I've been doing some osg performance benchmark research on thread synchronization using the Intel Threaded compiler, and so far the results are looking really good except for a 26% over-utilization due to sleeping. I do want to say awesome job to those responsible for threading, the amount of critical section use looked very good! All the worker threads also had good profiling results. The ultimate test I want to try today deals with an intentional GPU bottleneck... where I have a quadcore that pipes graphics out a PCI graphics card. If anyone is interested I'll post these test results. I know now that using a quad core there is lack of parallelization (e.g. 25% 85% 15% 15%), but that is a different battle for a different time. I do want to get to the bottom of the profiling and determine how well the workload is balanced against the gpu i/o, and see if there is some opportunity for optimization here. -snip Today I have the numbers from the souped up machine with a poor poor pci graphics card. The first thing to note is that the game never exceeded 18% cpu usage!! When I profiled 65% of the main thread was devoted to "serial" time and the bulk of the cpu time was on *this thread* and PrintSchedulingInfo [20] thread. The thread 20 showed 21% contributed to blocking, but the rest of it was active. The rest of the threads (like with my machine) looked really good! it is just too bad they don't do much work. Realistically my machine at work is not typical due to the pci graphics, but it did put good stresses to show where the I/O bottle neck is (on the main thread). My machine at home is a dual p 2.4 with NVidia GeForce 5900XT. When testing other games on my home machine I get great frame rate, so my goal will be to osg's performance to something comparable. Aside from the threading profiler, I have tested AMD code analyst to find the most frequent called code, and for osg 1.2 it turned out to be the Matrix Multiply. Aside from that OSG itself took a significant bulk of the CPU workload. This AMD profiler works differently in that it does not count sleeping or I/O time, but rather keeps note of the most frequent called. At some point I'll retest for code optimizations, but not yet... the real gain now is to balance the CPU rendering against it sending to GPU. It would be great if I can find a solution that can benefit the whole osg community (all platforms). If anyone has an interest in faster performance using the new osgViewer please share with me some ideas thanks. I can track where bottlenecks are, but working out a good solution will take some time to learn. I'll need to profile with VS 9 and OpenMP to see if this helps. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
We are going to move to VS 9, we have been wanting to do that for a long time now. Aside from osg not building, I overlooked the OpenMP option available to VS 8 and 9. We want high performance from osg so, *hopefully OpenMP will help. I am going to start a thread on performance here real soon for anyone interested. Perhaps there should be plans to ditch 7.1 if no one is using it now. Thanks for explaining the install... I was right clicking on ALL_BUILD and then INSTALL, but I suppose I could just do INSTALL, if it breaks it will not start copying. *OpenMP has not been easy/intuitive to use with unpredictable performance results. James Killian - Original Message - From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Friday, June 27, 2008 8:17 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hi James, Good to see that things are starting to work for you. I guess VS7.1 is a less tested compiler as it's getting a bit old. I have no interest in getting it to work personally as I don't use it, and I suspect that's Mathias's case too. If you want to make it work under 7.1, you're welcome to try and submit the necessary changes. Oh yes, and the projects which are dependent on Open Threads and OSG now include the build directory, so while I do not quite understand the install workflow that you were saying it appears that we can build the solution without needing to do anything with install. To me the install is a folder which is ran last where, once the build has built successfully I click the install to put the stuff together, and then our client code includes and links to this folder... that way when the code breaks the install folder is still fine from the previous successful session. Yes, that's one of the advantages of doing an install. You seem to be doing the install manually from what I understand of your paragraph above though, and you don't need to. In CMake, there's a setting called CMAKE_INSTALL_PREFIX. Set that to wherever you want the bin/, include/, lib/ etc directories to be, and then after generating the project files, open the solution and build the INSTALL project (right-click it and select "build"). That will automatically build everything (as the INSTALL project is dependent on all the other projects) and then copy all the needed files to the directories under your CMAKE_INSTALL_PREFIX automatically. Note that you need to right-click the INSTALL project and build it, because by default it's skipped (for people who don't want to do that). So just doing a "build solution" won't run the INSTALL target. Doing an INSTALL is only of benefit for apps that depend on OSG, not for the OSG build itself. Anything that's in the OSG solution file will find the necessary headers and libs automatically without needing an INSTALL. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash with CompositeViewer on Win32
CMake just used this, even when later updates to the CMake build where checked in that fixed problems here the old erroneous Config was not replaced. This is true for 2.4.8, it continued to fail the "am I win32 interlocked" test (probably because this result was already cached)... So I also had to purge my cache and start over. I have not tested this case for 2.6 James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Friday, June 27, 2008 4:04 AM Subject: Re: [osg-users] Crash with CompositeViewer on Win32 On Fri, Jun 27, 2008 at 9:49 AM, Serge Lages <[EMAIL PROTECTED]> wrote: Thanks for the hint, it seems to be my fault. I opened the OpenThreads/Config file to see the method used, and everything was commented... I hade to remove my CMakeCache.txt to have the file generated again and use the atomic pointers. Now it works like a charm ! Good to hear things are working again. I wonder if the Config file generated initially was incorrect, then CMake just used this, even when later updates to the CMake build where checked in that fixed problems here the old erroneous Config was not replaced. It might be that others will come up against the same issue during this transition between pre Config/Atomic days and what we have now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese
There is a current issue with VS 7.1 against any version of cmake see "Re: [osg-users][osg-submissions] API configurations in a separateConfig include file" thread James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Friday, June 27, 2008 3:22 AM Subject: Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese Hi J-S, On Thu, Jun 26, 2008 at 8:17 PM, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote: OSG SVN on Windows Vista, VS8, CMake 2.4.8 and 2.6, builds and runs fine. VPB SVN on Windows Vista, VS8, CMake 2.6 (didn't take time to test on 2.4.8), builds and runs fine. I'll test on my Ubuntu Virtualbox, but I suspect that's a bit unnecessary... Just being thorough. :-) Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
I tried 2.4.8 and 2.6 for both VS 7.1 and VS 9: Unfortunately for VS 7.1 (does not matter if its 2.4.8 or 2.6) I get this error: -- Build started: Project: OpenThreads, Configuration: Debug Win32 -- Compiling... Atomic.cpp \Games\GremlinGames\Source\Utilities\OSG_SVN\OpenSceneGraph\src\OpenThreads\common\Atomic.cpp(66) : error C3861: 'MemoryBarrier': identifier not found, even with argument-dependent lookup \Games\GremlinGames\Source\Utilities\OSG_SVN\OpenSceneGraph\src\OpenThreads\common\Atomic.cpp(92) : error C3861: 'MemoryBarrier': identifier not found, even with argument-dependent lookup VS 9 appears to build fine as MemoryBarrier resides in winnt.h my guess.. there is a compiler version check that is greater that 7.1 to use. What DOES work, is the config file detecting interlocked (as you verified), I wonder why the use float bounding box and use float bounding sphere are float by default... perhaps this is a general default for all platforms. I've been using double instead, and things run fine. Oh yes, and the projects which are dependent on Open Threads and OSG now include the build directory, so while I do not quite understand the install workflow that you were saying it appears that we can build the solution without needing to do anything with install. To me the install is a folder which is ran last where, once the build has built successfully I click the install to put the stuff together, and then our client code includes and links to this folder... that way when the code breaks the install folder is still fine from the previous successful session. James Killian - Original Message - From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, June 26, 2008 7:53 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hi James, Thanks for explaining things: No problem, that's what we're there for. :-) Well I'll give Cmake 2.6 another shot. I tried it too early before and it had some strange behavior. Hopefully now since a lot of people are using it I'll feel a bit more confident that it will work. I may get back with you on the Install workflow, but I'll need to see how 2.6 looks first. For sure give it a shot. It should work as intended out of the box for OSG out of SVN. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Thanks for pointing that out... I keep forgetting to fix my reply in plain text... Now this would explain why Robert did not respond... and all this time I thought it was because I made him upset. ;) On a side note... I really really really... hope that the client code will not have to break up the rendering into subsections like suggested in the threaded building blocks document from intel. - Original Message - From: Cedric Pinson To: OpenSceneGraph Users Sent: Thursday, June 26, 2008 4:33 PM Subject: Re: [osg-users] multi threaded with slave camera and fbo Your mails are black so i need to select the test to read it. Anyway i am interested by all result you have. If you can post them Cedric James Killian wrote: > > I too find some interesting issues with this thread. :) > > Robert, > This proposal you mention for 2.6 will it help balance the cpu > workload against the gpu I/O bottleneck? > > I've been doing some osg performance benchmark research on thread > synchronization using the Intel Threaded compiler, and so far the > results are looking really good except for a 26% over-utilization due > to sleeping. I do want to say awesome job to those responsible for > threading, the amount of critical section use looked very good! All > the worker threads also had good profiling results. > > The ultimate test I want to try today deals with an intentional GPU > bottleneck... where I have a quadcore that pipes graphics out a PCI > graphics card. If anyone is interested I'll post these test results. > I know now that using a quad core there is lack of parallelization > (e.g. 25% 85% 15% 15%), but that is a different battle for a different > time. > > I do want to get to the bottom of the profiling and determine how well > the workload is balanced against the gpu i/o, and see if there is some > opportunity for optimization here. > > > > - Original Message - > *From:* Robert Osfield <mailto:[EMAIL PROTECTED]> > *To:* OpenSceneGraph Users > <mailto:osg-users@lists.openscenegraph.org> > *Sent:* Thursday, June 26, 2008 7:06 AM > *Subject:* Re: [osg-users] multi threaded with slave camera and fbo > > Hi Guys, > > I've just skimmed through this thread. Interesting issues :-) > > Wojtek explanations of the double buffered SceneView is spot on, in > this case leading to two FBO's, Creation of two FBO's for RTT is > something I've been aware of since the inception of the > DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext, but as > yet haven't had the opportunity to refactor the code to avoid it. > > The problem actually stems from the reuse of SceneView to do something > that it was never intended to handle, and in terms of osgViewer > implementation SceneView was used simply because it was the line of > least resistance i.e. it worked and code be adapted to help speed up > the implementation of osgViewer, and mostly it's actually worked out > ok, the stop gap has worked out pretty well. > > However, it has always been my plan to rewrite the osgViewer::Renderer > so that it doesn't use SceneView at all, let alone double buffering > them, instead it's my plan to use a single CullVisitor which > alternately populates double buffered RenderStage. This approach > would be far leaner and less obfusticated, and we should be able to > clean up some of the artefacts as well. The downside is by not using > SceneView we'll loose all the stereo rendering support, so instead > we'll need to refactor osgViewer so that stereo rendering is done at > the viewer level i.e. using slave cameras - this means more coding > work, but the actually end result would be far better both design wise > as well as in flexibility and performance. > > I just need to time to go off and do this work, I might be able to get > it done for 2.6, but spare time certainly isn't something that I'm > blessed with right now. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > <mailto:osg-users@lists.openscenegraph.org> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net __
Re: [osg-users] multi threaded with slave camera and fbo
I too find some interesting issues with this thread. :) Robert, This proposal you mention for 2.6 will it help balance the cpu workload against the gpu I/O bottleneck? I've been doing some osg performance benchmark research on thread synchronization using the Intel Threaded compiler, and so far the results are looking really good except for a 26% over-utilization due to sleeping. I do want to say awesome job to those responsible for threading, the amount of critical section use looked very good! All the worker threads also had good profiling results. The ultimate test I want to try today deals with an intentional GPU bottleneck... where I have a quadcore that pipes graphics out a PCI graphics card. If anyone is interested I'll post these test results. I know now that using a quad core there is lack of parallelization (e.g. 25% 85% 15% 15%), but that is a different battle for a different time. I do want to get to the bottom of the profiling and determine how well the workload is balanced against the gpu i/o, and see if there is some opportunity for optimization here. - Original Message - From: Robert Osfield To: OpenSceneGraph Users Sent: Thursday, June 26, 2008 7:06 AM Subject: Re: [osg-users] multi threaded with slave camera and fbo Hi Guys, I've just skimmed through this thread. Interesting issues :-) Wojtek explanations of the double buffered SceneView is spot on, in this case leading to two FBO's, Creation of two FBO's for RTT is something I've been aware of since the inception of the DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext, but as yet haven't had the opportunity to refactor the code to avoid it. The problem actually stems from the reuse of SceneView to do something that it was never intended to handle, and in terms of osgViewer implementation SceneView was used simply because it was the line of least resistance i.e. it worked and code be adapted to help speed up the implementation of osgViewer, and mostly it's actually worked out ok, the stop gap has worked out pretty well. However, it has always been my plan to rewrite the osgViewer::Renderer so that it doesn't use SceneView at all, let alone double buffering them, instead it's my plan to use a single CullVisitor which alternately populates double buffered RenderStage. This approach would be far leaner and less obfusticated, and we should be able to clean up some of the artefacts as well. The downside is by not using SceneView we'll loose all the stereo rendering support, so instead we'll need to refactor osgViewer so that stereo rendering is done at the viewer level i.e. using slave cameras - this means more coding work, but the actually end result would be far better both design wise as well as in flexibility and performance. I just need to time to go off and do this work, I might be able to get it done for 2.6, but spare time certainly isn't something that I'm blessed with right now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning on 64bits: cast to pointer from integerofdifferent size
I believe int used to be and then Microsoft mucked it up from 32 to 64, and thus you get the warning (for what it's worth I grew up with the Commodore/Amiga line of products, and had to join the dark side). I use Vista 64 at work, and can say in confidence that osg works great in 32 bit mode. I have not tried to compile osg in 64bit yet, but I did see there is a 64bit platform available in cmake. I code in x64 all the time at work now, and it is great to step into and see the new 64 bit assembly. I no longer feel nauseous coding on the inferior 8088 processor. James Killian - Original Message - From: Peter Wraae Marino To: OpenSceneGraph Users Sent: Thursday, June 26, 2008 2:02 AM Subject: Re: [osg-users] Warning on 64bits: cast to pointer from integerofdifferent size Hi James, I always thought that "int" and "unsigned int" would be the best fit n-bit on the system? if it was an 8bit system then it would be 8bit int, if 32bit system then 32bit int or did I mis-understand something? and now that we are on the subject of 64bit.. I would like to ask a question... I considering buying a new computer and OS -- the OS (I know Robert will hate this).. is going to be Vista 64 bit and would like to start coding using 64bit.. is OpenSceneGraph working with 64bit? regards, Peter On Thu, Jun 26, 2008 at 4:14 AM, James Killian <[EMAIL PROTECTED]> wrote: I am not sure about the osg coding protocol, but for what we do at my work place we use size_t as the generic "unsigned int"... this will be unsigned long for win32 and __int64 for the x64 platform. It is good to use as a generic container for local variables since it chooses the native size that fits best per platform. size_t is great for pointer offsets too. The part that is unclear to me is the osg protocol in regards to using things like size_t fpos_t etc... osg has to be more generic to comply to all platforms, and this is something I have not needed to worry about (yet). James Killian - Original Message - From: "Mario Valle" <[EMAIL PROTECTED]> To: Sent: Wednesday, June 25, 2008 12:02 PM Subject: [osg-users] Warning on 64bits: cast to pointer from integer ofdifferent size On x86_64 (Suse 10.3) the following warning appears at lines 431 and 600 of BufferObject.cpp : "warning: cast to pointer from integer of different size" In both places (few lines over), if I change the line: unsigned int offset = 0; to: unsigned long offset = 0; The warning goes away. Can anyone more knowledgeable than me confirm that the change is correct before I submit the change? Thanks! mario -- Ing. Mario Valle Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Thanks for explaining things: For the first point about using config files, that's cool... I am in no position to judge whether or not to do that since I do not have experience building on other platforms, but at the same time I do know the perception this has for those who build with VS and my first impression of this was the same especially before I knew how it was suppose to work. As for the second point I'll be looking forward to hearing back from you and/or Mathias when this is resolved, then I'll try to build again. The third point: Well I'll give Cmake 2.6 another shot. I tried it too early before and it had some strange behavior. Hopefully now since a lot of people are using it I'll feel a bit more confident that it will work. I may get back with you on the Install workflow, but I'll need to see how 2.6 looks first. James Killian - Original Message - From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Wednesday, June 25, 2008 10:59 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hello James, I think you're mixing things up. There are three different issues here: 1. The choice to use Config headers. 2. The fact that the Atomic header includes windows.h. 3. The fact that your version of CMake chooses the wrong configuration and does not generate the Config header. Number 1 is a design choice. The choice is basically between having a file that defines options that affect the build, and needing to specify those options as defines in *each* project that uses OSG. I can see why the choice to have a Config file was taken. Otherwise, you would have to support people configuring their OSG build one way and then linking to it in a project where the incorrect define was being used, which would happen more often than you'd think. Having a Config header ensures that both the built version of OSG and your project use the same options (as long as the same Config header is included for both). Number 2 was a mistake (by the person who made the change, but still unrelated to the choice in number 1), and is being rectified as we speak. Check the messages from yesterday. *That* is what's breaking the build on Windows right now. As for Number 3, I believe that is caused by CMake 2.4.x. This can be investigated and fixed *after* the windows.h issue is fixed, which is much more major (as it affects *everyone* building on Windows, independently of the version of CMake they use). A workaround for you would be to get CMake 2.6 from cmake.org. Then you would get the right configuration (interlocked), the Config header would be generated and used, and you would see the windows.h include problem... At least that's what I think. :-) " you don't need anything different than before, since the Config headers are installed with your other OSG headers. " Do you have an "out-of-source" configuration or in source? I use the "out-of-source" configuration and so the config headers are installed in the directory. I use an out-of-source build with CMake 2.6, and the Config header is being generated just fine. But what I was talking about in the line you quoted above is that OSG headers are including the Config headers. If you don't do an INSTALL (or make install), then the Config headers are not together with your other OSG headers. Config headers: OpenSceneGraph//include/OpenThreads/Config OpenSceneGraph//include/osg/Config Other headers: OpenSceneGraph/include/OpenThreads/* OpenSceneGraph/include/osg/* So the other headers won't find #include or #include unless you add the directories above (in ) to your include file search path. Which was not required before. But if you do an INSTALL, you don't have that problem, because the INSTALL target copies the Config headers to the same place as the other headers, and so #include will work without any change to your project files. I hope that clears things up. (FYI this is in plain text so you should be able to see it) :) Thanks :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning on 64bits: cast to pointer from integer ofdifferent size
I am not sure about the osg coding protocol, but for what we do at my work place we use size_t as the generic "unsigned int"... this will be unsigned long for win32 and __int64 for the x64 platform. It is good to use as a generic container for local variables since it chooses the native size that fits best per platform. size_t is great for pointer offsets too. The part that is unclear to me is the osg protocol in regards to using things like size_t fpos_t etc... osg has to be more generic to comply to all platforms, and this is something I have not needed to worry about (yet). James Killian - Original Message - From: "Mario Valle" <[EMAIL PROTECTED]> To: Sent: Wednesday, June 25, 2008 12:02 PM Subject: [osg-users] Warning on 64bits: cast to pointer from integer ofdifferent size On x86_64 (Suse 10.3) the following warning appears at lines 431 and 600 of BufferObject.cpp : "warning: cast to pointer from integer of different size" In both places (few lines over), if I change the line: unsigned int offset = 0; to: unsigned long offset = 0; The warning goes away. Can anyone more knowledgeable than me confirm that the change is correct before I submit the change? Thanks! mario -- Ing. Mario Valle Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ 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] [osg-submissions] API configurations in aseparateConfig include file
What was the last version you were able to successfully build? " you don't need anything different than before, since the Config headers are installed with your other OSG headers. " Do you have an "out-of-source" configuration or in source? I use the "out-of-source" configuration and so the config headers are installed in the directory. If anyone has had a successful time in building on the VS platform, I am interested in how they are doing it. Right now I'm doing the wrong thing which is to copy the config files into the source tree and then manually turning on the correct configuration (i.e. interlocked and enforce threading). This is as of build 8483. (FYI this is in plain text so you should be able to see it) :) - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Wednesday, June 25, 2008 10:08 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hi Bob, > what fun would this list be if someone (lucky me) didn't get to stick their > foot in their mouth from time to time. :) I assume you got some personal replies to your message, as I haven't seen anything on osg-users that reacted to it in any way, so your own reaction is a bit surprising to me. For the record, I agree with your sentiment, even if I can see reasons why OSG evolves as it does (open source software often imposes its own pace and demands that developers be more fluid and open to change...) So I personally didn't find your comment offensive. > and so, as an act of contrition (yes, i was raised a catholic child), > i submit my updated 'FindOSG.cmake' which i use to create builds of apps > with osg on windows, linux, and the mac. this cmake FIND_PACKAGE tool will > setup the variable OSG_INCLUDE_DIRS to point to both the generated and > installed source of osg, as well as the OSG_LIBRARY_DIR for the discovered > osg libraries. I agree that a "template" for a standalone project using OSG is a good addition. In the past, I have cannibalized the VPB CMake/project files for my own projects, and that worked for me (though of course, with the recent changes, even those will have to be reworked slightly). And it should be made clear that if you do 'make install' or build the INSTALL target in Visual Studio, you don't need anything different than before, since the Config headers are installed with your other OSG headers. It's only if you build and then use the files straight from your build tree (or copy them manually from there to somewhere else, omitting the Config headers) that you need to add the /include/OpenThreads and /include/osg directories in your include path. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Sorry about the black on black, sometimes Outlook express likes to enter a black background when I switch into html. I try to keep plain text to avoid issue... my black contrast environment helps reduce the amount of light emitting from the monitors. James Killian - Original Message - From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, June 24, 2008 3:54 PM Subject: Re: [osg-users] Windows build is broken Hi James, I'm going to hold off on getting the latest until Mathias has a chance to checkin some fixes with windows.h Probably a good idea, then we can check if there are any other outstanding issues. BTW, did you set your e-mail message's background to black or am I seeing a bug in my client or yours? Your message was black text on black background. :-( J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file
What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the "why can't my application find the Config header?" issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: "Paul Martz" <[EMAIL PROTECTED]> To: "'OpenSceneGraph Submissions'" <[EMAIL PROTECTED]> Cc: "'OpenSceneGraph Users'" Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: "why can't my application find the Config header?". Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -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] Windows build is broken
" Yes, and I always use it, and it works (copies the Config header). So no problem there. " Given that we are building an out-of-source solution as of build 8483: It does indeed copy the config file to the build directory for me as well, but for VS 7.1 using cmake 2.4.8 it fails to identify using Interlocked, and the config files revert to a single threaded environment. This is minor, but can get annoying if something wants to rebuild. Aside from this only OpenThreads and OSG include the build path... all projects dependant on these do not, and will give error that they cannot find the config file. Ideally the cmake scripts of these projects should also include the build path. I'm going to hold off on getting the latest until Mathias has a chance to checkin some fixes with windows.h - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Tuesday, June 24, 2008 7:25 AM Subject: Re: [osg-users] Windows build is broken Hello Mathias, > Alternatively, cmake povides an 'install' target on unix builds. I do not know > if this is also available in win32. Yes, and I always use it, and it works (copies the Config header). So no problem there. > I see that problem. > Appologies for not testing that stuff on windows. I was just too naive to > believe that this will just work. And given that I do cross platform > development here at work I must have known that better. Sorry! Hehe, classic mistake! :-) > I believe that I will provide something that will use inline versions of that > atomic functions if possible but will make some cpp file implementation if > this does not make sense like in the win32 case ... I think if you declare both the declaration and implementation of a method inline, the compiler will take that as a hint that it should be inlined if possible... But yes, windows.h should only be included in a .cpp file in the case of a header like Atomic that is included everywhere... > Robert, ok? Robert is not checking his mails until Thursday. Since this currently prevents building on Windows, I would say go ahead. > I guess that this will be ready about tomorrow. I hope that you can live with > that until then ... OK, I was having a go at doing it, but if you want to go ahead, you're more familiar with it than I am. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improvements for OSX application bundles
If 2.6 can solve the need to having the config files in the source (for out-of-source environment) then I'll be looking forward to the change. :) Ideally cmake scripts should be able to work out good defaults given a platform, and find a way to setup the environment. Now that I am thinking about it they should have been able to add them into the preprocessor definition list /D [macro], and then atomic (and others) could have some ifdef check to bypass the need to include a config file. James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Sunday, June 22, 2008 2:16 PM Subject: Re: [osg-users] Improvements for OSX application bundles Hi James, On Sun, Jun 22, 2008 at 7:49 PM, James Killian <[EMAIL PROTECTED]> wrote: Does your suggestion mean 2.6x for just OSX or for all platforms? Just for OSX. Although for other later platforms combinations we might need to require this as well. I initially tried 2.6 for VS 9, and it had some strange issues like creating 2 folders for each project. Both CMake 2.6 and VS 9 are pretty new so it make take a little time for 2.6 to fully support VS 9. This is an issue that needs to be brought up with the Cmake team, but first we need to characterise it a bit more - i.e. see others reproduce it, work out what bits causes things to go unstuck. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improvements for OSX application bundles
Does your suggestion mean 2.6x for just OSX or for all platforms? I initially tried 2.6 for VS 9, and it had some strange issues like creating 2 folders for each project. James Killian - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Sunday, June 22, 2008 12:47 PM Subject: Re: [osg-users] Improvements for OSX application bundles Hi Eric, On Sun, Jun 22, 2008 at 11:33 AM, Stephan Huber <[EMAIL PROTECTED]> wrote: the new files broke cMake 2.4, I got weird errormessages (looked like a memory dump :), after upgrading to 2.6 the compile went fine on OS X. Could you post the error messages? Exactly which version of CMake didn't work? Given the Cmake 2.6 has lots of improvements in support of OSX, what about just dropping support for CMAke 2.4.x for OSX, and require Cmake 2.6.x for now onwards (i.e. for OSG-2.5.3+) Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
