Re: [osg-users] changing thread priority
Hi Nick, On Fri, Mar 12, 2010 at 7:05 AM, Trajce (Nick) Nikolov nikolov.tra...@gmail.com wrote: is there a way to force the threading in osg (cull, update, draw) to use different priority (let say RealTime)? My IG works fine but I thought I might force it to even do better :) You can get all the threads of the viewer via : osgViewer::Viewer::Threads threads; viewer.getAllThreads(threads); Then set their priority as you wish. via : thread-setSchedulePriority(prirotiy); See include/OpenThreads/Thread + include/osgViewer/ViewerBase for details. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Problems building osgdotnet wrappers
Hi Vedran, It's good to here the compile is now fixed. Beyond this I can't help you though, I don't know osgdotnet and I dont' have a windows box. Robert. On Thu, Mar 11, 2010 at 10:42 PM, Vedran Pavlic vedran.pav...@fer.hr wrote: i just tried with the latest update, and osg builds fine now, after that i build osgdotnet generator for the svn osgdotnet version and went to start without debugging. And it gives me this output: Instantiating augmented libraries and types... osgFX Caught exception: failed to load OSG wrapper library for osgFX Press any key to continue . . . now i'm fresh out of ideas Vedran -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25533#25533 ___ 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] changing thread priority
Thanks Robert. That is exactly what I was looking for ! -Nick On Fri, Mar 12, 2010 at 10:51 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Nick, On Fri, Mar 12, 2010 at 7:05 AM, Trajce (Nick) Nikolov nikolov.tra...@gmail.com wrote: is there a way to force the threading in osg (cull, update, draw) to use different priority (let say RealTime)? My IG works fine but I thought I might force it to even do better :) You can get all the threads of the viewer via : osgViewer::Viewer::Threads threads; viewer.getAllThreads(threads); Then set their priority as you wish. via : thread-setSchedulePriority(prirotiy); See include/OpenThreads/Thread + include/osgViewer/ViewerBase for details. 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] need help with cmake / osg / os x / frameworks
Hi Stephan, Robert, I have compiled the frameworks with Unix makefiles,and with generated XCode project. Despite compiling succesful, I have seen a problem (a part of the headers installation in osgViewer). In the file ModuleInstall.cmake line 37: IF(!OSG_COMPILE_FRAMEWORKS) it doesn't work, so the frameworks are always installed. The correct way to write this in CMake is : IF (NOT OSG_COMPILE_FRAMEWORKS). I am compiling now with this modification, I will write to you again in a while. Cheers. 2010/3/10 Stephan Maximilian Huber ratzf...@digitalmind.de Hi all, I am trying to add framework-support to the cmake-files, and I am hitting a wall. I am not a cmake-expert so I'll ask the community for help. Attached you'll find my modified cmake-files (based on current trunk), which adds compiling osg as frameworks, which can be embedded into application bundles (this is the main reason for the existance of the deprecated xcode-project) To compile frameworks with cmake you'll have to: set OSG_COMPILE_FRAMEWORKS to TRUE modify OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR if needed set the CMAKE_INSTALL_PREFIX to something reasonable, I use a folder on my desktop as destination. Click Configure, click generate, open the xcode project, click build, select the install-target, click build again. So you'll find in CMAKE_INSTALL_PREFIX a bunch of folders, in lib you'll find the frameworks, ready to be embedded into your app. You'll get valid frameworks ONLY if you run the install-target. Without that, the install_name_dirs are bound to the local storage of the frameworks, and will not work on other computers, or other destinations. And here's the big BUT: I have problems to move the api-headers of osgViewer into their right places (osgViewer.framework/headers/api/(Carbon|Cocoa)/*) They end all in osgViewer.framework/headers/ There is a special property for this called MACOSX_PACKAGE_LOCATION, which should move the corresponding files to the special place in the framework-bundle, but it doesn't work for the api-headerfiles. Perhaps someone can look at the source in src/osgViewer/CMakeLists.txt and check my approach. cmake copies two cpp-files into that place instead of the header-files. So please, please test the packaged cmake-files and perhaps there is someone out there who can help with the issues with the osgviewer-header-files! thanks in advance, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres Fabra gvSIG 3D blog http://gvsig3d.blogspot.com Instituto de Automática e Informática Industrial http://www.ai2.upv.es ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Need help to understand this code snippet with accept and operator
Hi
I was wondering if someone could help explain this piece of code or at
least point me in the right direction. It was posted by Yuen Helbig in
2008
osg::TriangleIndexFunctorTriangleIndexVisitor tif;
tempGeode.geode-getDrawable(j)-accept(tif);
With TriangleIndexVisitor defined as:
class TriangleIndexVisitor
{
public:
CArrayint,int indices;
void operator()(const int v1, const int v2, const int v3)
{
// toss the computed indices into the indices array
indices.Add( v1 );
indices.Add( v2 );
indices.Add( v3 );
}
};
I think I am struggling with the concept of how accept and operator
work.
All the best
Fred
--
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] OSG Virtual Planets, the core of gvSIG3D.
Hi Allen, You are wellcome. Don't hesitate to ask if you have doubts. We hope this tutorial helps. Good Look! 2010/3/11 Allen Saucier allen.sauc...@itt.com Hi Jordi, thanks for the updated. Sorry for being a pest. I do really appreciate your help and I definitely understand your pressure. I have been totally swamped myself. I'll let you know how the latest info you've given me works. Talk to you soon! :D Best regards, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25542#25542 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres Fabra gvSIG 3D blog http://gvsig3d.blogspot.com Instituto de Automática e Informática Industrial http://www.ai2.upv.es ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] need help with cmake / osg / os x / frameworks
Hi Jordi, Am 12.03.10 10:59, schrieb Jordi Torres: I have seen a problem (a part of the headers installation in osgViewer). Yes, the copying of the osgviewer-headers is currently broken for frameworks, this the last missing piece to get cmake-support complete (see my first mail) In the file ModuleInstall.cmake line 37: IF(!OSG_COMPILE_FRAMEWORKS) it doesn't work, so the frameworks are always installed. The correct way to write this in CMake is : IF (NOT OSG_COMPILE_FRAMEWORKS). Ah, thanks for the fix! Thanks again, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] need help with cmake / osg / os x / frameworks
Hi Stephan, Yes, the copying of the osgviewer-headers is currently broken for frameworks, this the last missing piece to get cmake-support complete (see my first mail) I understood tour first mail when I readed it. :). In the file ModuleInstall.cmake line 37: IF(!OSG_COMPILE_FRAMEWORKS) it doesn't work, so the frameworks are always installed. The correct way to write this in CMake is : IF (NOT OSG_COMPILE_FRAMEWORKS). Ah, thanks for the fix! Thanks again, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres Fabra gvSIG 3D blog http://gvsig3d.blogspot.com Instituto de Automática e Informática Industrial http://www.ai2.upv.es ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Need help to understand this code snippet with accept and operator
Hi Fred,
The TriangleIndexFunctor is a template helper class for making it
easier to access the triangles held in osg::Drawable. The actual
geometry primitives held within different osg::Drawable subclasses
could be of any type and any arrangement, so casting osg::Drawable to
osg::Geometry etc. and then accessing the primitives directly and then
working out how to interpret the triangles from this is rather
complex, tedious and prone to poor performance unless you are very
careful.
To address the tight coupling of accessors to implementations, the
osg::Drawable has an accept(osg::Drawable::PrimitiveFunctor) method
exists to allow a subclass from osg::Drawable to pass details on the
geometry primitives that it has to the functor in a generic way - thus
hiding the local implementation details of that Drawable and enabling
your own custom PrimitiveFunctor to work with a wide range of Drawable
without needing to know the implementation details. While this
achieves good decoupling the PrimitiveFunctor still has to handle all
the different types of primitives - polygons, tri strips, quads, qaud
strips, lines etc, which is still pretty complicated to implement.
To address the complexity of handling all the different types of
primitives the TriangleIndexFunctor template class exists to decompose
all the descriptions of generic primitives into the simple triangles
marked by their corner indices. For you the app developer all you
then need to do is create you little functor that implements the void
operator()(const int v1, const int v2, const int v3) method as per the
example, and then pass the resulting templated class to the drawable
to get all the triangle information. The use of templates also
ensures good performance.
If it wasn't for PrimtiiveFunctor and
TriangleFunctor/TriangleIndexFunctor accessing geometry would be very
tedious and error prone task - lots of casts, switch statements and
book keeping. These helper classes might seem a bit convoluted at
first look, they really make life much easier. Go have a search
through the OSG code base, there are plenty of examples of
TriangleFunctor/TriangleIndexFunctor in action - especially in
src/osgUtil.
Cheers,
Robert.
ps. I spotted your signature and it brings back memories - I ran in
the Scottish Cross Country Nationals at Herriot-Watt when I was kid
;-)
On Fri, Mar 12, 2010 at 10:01 AM, Fletcher, Craig A c...@hw.ac.uk wrote:
Hi
I was wondering if someone could help explain this piece of code or at least
point me in the right direction. It was posted by Yuen Helbig in 2008
osg::TriangleIndexFunctorTriangleIndexVisitor tif;
tempGeode.geode-getDrawable(j)-accept(tif);
With TriangleIndexVisitor defined as:
class TriangleIndexVisitor
{
public:
CArrayint,int indices;
void operator()(const int v1, const int v2, const int v3)
{
// toss the computed indices into the indices array
indices.Add( v1 );
indices.Add( v2 );
indices.Add( v3 );
}
};
I think I am struggling with the concept of how accept and operator work.
All the best
Fred
Heriot-Watt University is a Scottish charity registered under charity number
SC000278.
___
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] texture2Darray problem
Hi All, I have tried a sample application to make use of texture2Darray and associated sampler2DArray Uniform. I wrote my code based on some previous discussions on the mailing list archives. Unfortunately I keep on having GL errors during execution, in particular and invalid enumerator after applying the extension: GL_TEXTURE_2D_ARRAY_EXT 0x8C1A Attached you find the sample program producing the error. Can someone provide any hints? I'm on Win7 + nVidia gtx295, using osg-2.8.2 Thank you, Ricky Texture2DArray.cpp Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] texture2Darray problem
Hi, I had the same issue. Its a warnig while applying texture mode. Do not use setTextureAttributeAndModes(). Use setTextureAttribute() instead. There is not such mode like GL_TEXTURE_2D_ARRAY. Texture2DArrays do not work with fixed pipeline. They are accessible only with shaders. Wojtek Lewandowski - Original Message - From: Riccardo Corsi To: OpenSceneGraph Users Sent: Friday, March 12, 2010 1:03 PM Subject: [osg-users] texture2Darray problem Hi All, I have tried a sample application to make use of texture2Darray and associated sampler2DArray Uniform. I wrote my code based on some previous discussions on the mailing list archives. Unfortunately I keep on having GL errors during execution, in particular and invalid enumerator after applying the extension: GL_TEXTURE_2D_ARRAY_EXT 0x8C1A Attached you find the sample program producing the error. Can someone provide any hints? I'm on Win7 + nVidia gtx295, using osg-2.8.2 Thank you, Ricky -- ___ 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] texture2Darray problem
Hi Wojtek, it works like a charm now! Thank you! Ricky On Fri, Mar 12, 2010 at 1:20 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Hi, I had the same issue. Its a warnig while applying texture mode. Do not use setTextureAttributeAndModes(). Use setTextureAttribute() instead. There is not such mode like GL_TEXTURE_2D_ARRAY. Texture2DArrays do not work with fixed pipeline. They are accessible only with shaders. Wojtek Lewandowski - Original Message - *From:* Riccardo Corsi riccardo.co...@kairos3d.it *To:* OpenSceneGraph Users osg-users@lists.openscenegraph.org *Sent:* Friday, March 12, 2010 1:03 PM *Subject:* [osg-users] texture2Darray problem Hi All, I have tried a sample application to make use of texture2Darray and associated sampler2DArray Uniform. I wrote my code based on some previous discussions on the mailing list archives. Unfortunately I keep on having GL errors during execution, in particular and invalid enumerator after applying the extension: GL_TEXTURE_2D_ARRAY_EXT 0x8C1A Attached you find the sample program producing the error. Can someone provide any hints? I'm on Win7 + nVidia gtx295, using osg-2.8.2 Thank you, Ricky -- ___ 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] Need help to understand this code snippet withaccept and operator
Thanks alot for your help Robert I had become pretty confused but I think I
understand it now. The proof will be when I implement something :)
You must have been a pretty strong runner when you were a kid (or maybe still
are) HW is good for stuff like that even though we are pretty much in Edinburgh
you can be in the countryside if you go out of the other side of the campus.
All the best
Fred
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: 12 March 2010 10:57
To: OpenSceneGraph Users
Subject: Re: [osg-users] Need help to understand this code snippet withaccept
and operator
Hi Fred,
The TriangleIndexFunctor is a template helper class for making it
easier to access the triangles held in osg::Drawable. The actual
geometry primitives held within different osg::Drawable subclasses
could be of any type and any arrangement, so casting osg::Drawable to
osg::Geometry etc. and then accessing the primitives directly and then
working out how to interpret the triangles from this is rather
complex, tedious and prone to poor performance unless you are very
careful.
To address the tight coupling of accessors to implementations, the
osg::Drawable has an accept(osg::Drawable::PrimitiveFunctor) method
exists to allow a subclass from osg::Drawable to pass details on the
geometry primitives that it has to the functor in a generic way - thus
hiding the local implementation details of that Drawable and enabling
your own custom PrimitiveFunctor to work with a wide range of Drawable
without needing to know the implementation details. While this
achieves good decoupling the PrimitiveFunctor still has to handle all
the different types of primitives - polygons, tri strips, quads, qaud
strips, lines etc, which is still pretty complicated to implement.
To address the complexity of handling all the different types of
primitives the TriangleIndexFunctor template class exists to decompose
all the descriptions of generic primitives into the simple triangles
marked by their corner indices. For you the app developer all you
then need to do is create you little functor that implements the void
operator()(const int v1, const int v2, const int v3) method as per the
example, and then pass the resulting templated class to the drawable
to get all the triangle information. The use of templates also
ensures good performance.
If it wasn't for PrimtiiveFunctor and
TriangleFunctor/TriangleIndexFunctor accessing geometry would be very
tedious and error prone task - lots of casts, switch statements and
book keeping. These helper classes might seem a bit convoluted at
first look, they really make life much easier. Go have a search
through the OSG code base, there are plenty of examples of
TriangleFunctor/TriangleIndexFunctor in action - especially in
src/osgUtil.
Cheers,
Robert.
ps. I spotted your signature and it brings back memories - I ran in
the Scottish Cross Country Nationals at Herriot-Watt when I was kid
;-)
On Fri, Mar 12, 2010 at 10:01 AM, Fletcher, Craig A c...@hw.ac.uk wrote:
Hi
I was wondering if someone could help explain this piece of code or at least
point me in the right direction. It was posted by Yuen Helbig in 2008
osg::TriangleIndexFunctorTriangleIndexVisitor tif;
tempGeode.geode-getDrawable(j)-accept(tif);
With TriangleIndexVisitor defined as:
class TriangleIndexVisitor
{
public:
CArrayint,int indices;
void operator()(const int v1, const int v2, const int v3)
{
// toss the computed indices into the indices array
indices.Add( v1 );
indices.Add( v2 );
indices.Add( v3 );
}
};
I think I am struggling with the concept of how accept and operator work.
All the best
Fred
Heriot-Watt University is a Scottish charity registered under charity number
SC000278.
___
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
--
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Future of osgIntrospection + genwrapper
Hi All, Today I was working on cleaning up some extension setup code in Texture::Extensions and then attempted to update the wrappers, then build them. Unfortunately genwrappers has got really confused with the typedef's for the function pointer, and I've tried to fix things with tweaks to src/osgWrappers/introspection/genwrapper.conf but can't get it to ignore the typedef's. I've even resorted to diving into the genwrapper source code itself but I can't really make sense of where it's going wrong - the code is just too unfamiliar and complicated for me be able to just dive in a fix stuff. This isn't the first time this has happened, it happens a couple of times a month where I loose half a day or even more just fighting to keep the osgIntrospection wrappers building. I have really begun to detest this work. Now if I had to time to fully digest osgIntrospection and genwrapper then I might have a chance of being able to maintain them - but I don't have this time - I have backlog of submissions and fixes to the OSG that are far more pressing. I also just can't spread my own skills so thinly, more time and intellect I spend maintaining osgIntrospection/genwrapper the less time/interlect have available for the rest of the project. osgIntrospection/genwrapper was written by Marco Jez and while he was around the community he was very active and quick to fix things up, but since he's no longer active the burnden for orphaned code falls on my shoulders. In this particular case the code is amongst the most complicated in the whole OSG - actually probably the most complicated by quite a long way, so the burden isn't a lightweight one I can easily just pop into the bag. Alas no one in the community has so far stepped into Marco's shows to champion osgIntrospection, might there be such a person? Given the repeated problems I face, and the lack of active usage of osgIntrospection out in the community I am ready to move osgIntrospection out of the core. It has long been a real maintenance problem for me and I really know my own productivity will improve with moving osgIntrospection out of the core. So... osgIntrospection users come forward, raise your hands and tell me that you still need it and are prepared to pitch in to maintain it, as I can't continue to maintain it on your behalf, it just consuming too much time of my time and productivity that needs to be spent elsewhere. Cheers, Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Plugin Error
Hi,
My name is Paul and I am Brazilian. I'm still a beginner in programming with
OSG.
I can not go through the Tutorial 3 (texturedGeometry) because I can not read
no files. Plugin error occurs. It appears that a plugin reading was not found
and the following condition is always true and the program ends.
//lines 123-129//
if (!klnFace)
{
cout couldn't find texture, quitting. endl;
return -1;
}
Commenting this part, the program runs normally, but without success, no
textures. I have tried various textures as jpg, but it did not work. I use
Windows XP Service Pack 3 with Visual Studio 2008 Professional Edition.
Thank you!
Cheers,
Paulo
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25569#25569
Attachments:
http://forum.openscenegraph.org//files/texturedgeometry_191.cpp
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Future of osgIntrospection + genwrapper
Hi Robert, Given the repeated problems I face, and the lack of active usage of osgIntrospection out in the community I am ready to move osgIntrospection out of the core. It has long been a real maintenance problem for me and I really know my own productivity will improve with moving osgIntrospection out of the core. I totally agree with this. If the wrappers were moved out of the core, it would bring two benefits: 1) changes to OSG will not cause a part of OSG that is not maintained and complicated to stop building. 2) it will be easier to give over the reins of maintaining the wrappers to someone else. Potentially they could say svn rev X of the wrappers build against svn rev Y of OSG, and then update them at their leisure as they need the wrappers to support more recent revisions of OSG. So I think it would be a good idea, and would also go toward the goal of lightening the load on your shoulders. Go for it :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Future of osgIntrospection + genwrapper
one question. I am not familiar with this piece of code at all, but , does the osgdotnet wrapper depends on it? If so, I am very interested in keeping it alive -Nick On Fri, Mar 12, 2010 at 4:53 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, Given the repeated problems I face, and the lack of active usage of osgIntrospection out in the community I am ready to move osgIntrospection out of the core. It has long been a real maintenance problem for me and I really know my own productivity will improve with moving osgIntrospection out of the core. I totally agree with this. If the wrappers were moved out of the core, it would bring two benefits: 1) changes to OSG will not cause a part of OSG that is not maintained and complicated to stop building. 2) it will be easier to give over the reins of maintaining the wrappers to someone else. Potentially they could say svn rev X of the wrappers build against svn rev Y of OSG, and then update them at their leisure as they need the wrappers to support more recent revisions of OSG. So I think it would be a good idea, and would also go toward the goal of lightening the load on your shoulders. Go for it :-) 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] Future of osgIntrospection + genwrapper
Hi Robert, If I Remember right, Wang wrote in the context of the serializer introduction, that a wrapper/introspection could be build up on that technique. I'm not sure if I remember right, but could this be a solution to maintain a kind of introspection/wrapper functionality and to move the current osgIntropsection out of the core? Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25576#25576 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multi-view Performance Issue with Statesets
Hi everyone, I've seen a lot of threads on performance issues in the mailing list but none of them seemed to address my particular problem precisely, either because the problem description was vague or the replies were covering a matter far too vast to include everything in a single message. So I've decided to expose my problem and share my observations and potential solution. My goal here is to understand why it does what it does and maybe help some other users with similar problems. Here's my system configuration: Dell XPS, Intel Core2 Quad Q9300 @ 2.5 Ghz, 4 GB RAM, NVidia GeForce GTX 280. The application uses MFC classes (extended from the OSGViewerMFC exemple) and is run under Windows Vista 32-bit. So, I have this multi-view application with textured terrains generated from osgGIS. I eliminated all LODs to eliminate this factor in my performance comparison. On those terrains, we add road segments with a stateset: mGeometrie = new osg::Geometry; mGeometrie-setVertexArray(lListe); mGeometrie-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,1)); mGeometrie-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,1)); ((osg::DrawArrays*)mGeometrie-getPrimitiveSet(0))-setCount(lListe-size()); ((osg::DrawArrays*)mGeometrie-getPrimitiveSet(1))-setCount(lListe-size()); osg::ref_ptrosg::StateSet lStateSet = mGeometrie-getOrCreateStateSet(); lStateSet-setMode(GL_LIGHTING, osg::StateAttribute::OFF); osg::ref_ptrosg::Vec4Array lCouleur = new osg::Vec4Array; lCouleur-push_back(osg::Vec4(1.0f, 1.0f, 0.0f, 1.0f)); mGeometrie-setColorArray(lCouleur); mGeometrie-setColorBinding(osg::Geometry::BIND_OVERALL); We also add a larger invisible road segment above to make things easier for the user to select a segment (the collision is detected in a visitor): osg::ref_ptrosg::Geometry lGeometrieSelection = new osg::Geometry; lGeometrieSelection-setVertexArray(lListeSelection); lGeometrieSelection-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,1)); lGeometrieSelection-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,1)); ((osg::DrawArrays*)lGeometrieSelection-getPrimitiveSet(0))-setCount(lListeSelection-size()); ((osg::DrawArrays*)lGeometrieSelection-getPrimitiveSet(1))-setCount(lListeSelection-size()); osg::ref_ptrosg::StateSet lStateset = lGeometrieSelection-getOrCreateStateSet(); osg::ref_ptrosg::Material lMateriel = dynamic_castosg::Material*(lStateset-getAttribute(osg::StateAttribute::MATERIAL)); if (!lMateriel) lMateriel = new osg::Material; lMateriel-setTransparency(osg::Material::FRONT_AND_BACK, 1.0f); lStateset-setAttributeAndModes( lMateriel, osg::StateAttribute::PROTECTED | osg::StateAttribute::ON); lStateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); osg::ref_ptrosg::Vec4Array lCouleurSelection = new osg::Vec4Array; lCouleurSelection-push_back(osg::Vec4(1.0f, 1.0f, 1.0f, 0.0f)); lGeometrieSelection-setColorArray(lCouleurSelection); lGeometrieSelection-setColorBinding(osg::Geometry::BIND_OVERALL); Now, I noticed a lot of things while doing my performance experiments: - First of all: Statesets seem to affect performance drastically and the code above generates a lot of them. I have 4 views sharing a scene containing 4 terrain with 15 segments each. Without the road segments, I reach 56 FPS with 237 statesets, 512K vertices and 970K primitives. When I add the road segments, I drop to 24 FPS with 781 statesets, 544K vertices and +1M primitives. - Primitives and vertices count also affect performance but the effect is less significant. Indeed, I can put 5 terrains without the road segments and I'm still at 55 FPS with only 257 statesets, 625K vertices and +1.2M primitives. I drop to 30 FPS with 514 statesets, 1.2M vertices and 2.4M primitives (10 terrains with no road segments). - With a single view, the stateset effect is far less significant. Maybe my multi-view is not set properly? - The FOV (set in the camera's projection matrix) also seem to affect performance negatively and worsen the stateset effect. For now, I set it to 170 degrees (to be able to cull everything for CAVE rendering) but I think I will need to optimize this value with tracker coordinates. I remember Robert saying that we should avoid independent statesets. This raises a lot of questions since I don't fully understand this functionality yet... For instance, what is the typical amount of statesets in a commercial application? How can we combine statesets for multiple objects potentially in different states from each others? Finally, do you have any idea how I could solve my particular selection problem without having to add more statesets for the invisible but larger
Re: [osg-users] Multi-view Performance Issue with Statesets
Drolet, Frederic wrote on 2010-03-12: osg::ref_ptrosg::StateSet lStateSet = mGeometrie- getOrCreateStateSet(); lStateSet-setMode(GL_LIGHTING, osg::StateAttribute::OFF); OpenGL performance is very sensitive to state changes, so it is a good idea to minimize them as much as possible. OSG groups Drawables with the same state as part of this (the exception is transparent drawables that require a certain ordering to render correctly, so they can't be grouped), but it just compares the StateSet pointers rather than a (much more expensive) comparison of what OpenGL state the StateSet pointers represent. Therefore, if you have a bunch of StateSets that are identical, like you seem to have, it is a really good idea to just use the same StateSet object everywhere you need it, rather than create a new instance every time. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Moving a line and its vertices
Hi, I have created a line in my scene based on the osggeometry example. I create the line and it displays fine, but I also need to change the end-points on the line dynamically as the simulation progresses. I started out by re-setting the vertex array data at each step in the render loop, but that did nothing. The line stayed exactly where it was when it was first initialized. I then tried creating a new vertex array and calling setVertexArray at each step, and this blew up spectacularly after a few steps. Is there any example of how I am supposed to get my line and its end points to move dynamically in the simulation? Thank you! Cheers, David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25579#25579 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-view Performance Issue with Statesets
Let's say I want to change the color of my road segment (when selected for instance). We're currently doing this modification that way: osg::Vec4Array* lCouleur = (osg::Vec4Array*)(mGeometrie-getColorArray()); *(lCouleur-begin()) = pCouleur; mGeometrie-dirtyDisplayList(); From what you're saying, I guess we should create a different stateset for every color instead of a stateset for every segment? Maybe I should ask first if the color is indeed part of the stateset anyway! If not, we could reduce the stateset count even more! Thanks! Frederic Drolet, M. Sc. Computing Solutions and Experimentations | Solutions informatiques et expérimentations Systems of Systems | Systèmes de systèmes DRDC Valcartier | RDDC Valcartier 2459, boul. Pie-XI North Quebec, Quebec G3J 1X5 CANADA Phone | Téléphone: (418) 844-4000 ext : 4820 Fax | Télécopieur: (418) 844-4538 E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca Web : www.valcartier.drdc-rddc.gc.ca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Thrall, Bryan Sent: Friday, March 12, 2010 10:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Multi-view Performance Issue with Statesets Drolet, Frederic wrote on 2010-03-12: osg::ref_ptrosg::StateSet lStateSet = mGeometrie- getOrCreateStateSet(); lStateSet-setMode(GL_LIGHTING, osg::StateAttribute::OFF); OpenGL performance is very sensitive to state changes, so it is a good idea to minimize them as much as possible. OSG groups Drawables with the same state as part of this (the exception is transparent drawables that require a certain ordering to render correctly, so they can't be grouped), but it just compares the StateSet pointers rather than a (much more expensive) comparison of what OpenGL state the StateSet pointers represent. Therefore, if you have a bunch of StateSets that are identical, like you seem to have, it is a really good idea to just use the same StateSet object everywhere you need it, rather than create a new instance every time. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Moving a line and its vertices
You need to dirty the display lists to tell OSG to send the new positions to the graphics card Code: geometry-dirtyDisplayList(); Or you can set the geometry to dynamic and it will dirty it on each pass. Can't remember the exact syntax, but search for dynamic. Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25581#25581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-view Performance Issue with Statesets
Drolet, Frederic wrote on 2010-03-12: Let's say I want to change the color of my road segment (when selected for instance). We're currently doing this modification that way: osg::Vec4Array* lCouleur = (osg::Vec4Array*)(mGeometrie- getColorArray()); *(lCouleur-begin()) = pCouleur;mGeometrie-dirtyDisplayList(); From what you're saying, I guess we should create a different stateset for every color instead of a stateset for every segment? Maybe I should ask first if the color is indeed part of the stateset anyway! If not, we could reduce the stateset count even more! The color array is independent from the StateSet. It appears you are only using the StateSet to turn lighting off; if that is true, you could just create a single StateSet that turns lighting off and put it near the top of your scene graph. The color arrays and modifying them should not affect performance as much as the OpenGL state changes that come from many StateSets. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Thrall, Bryan Sent: Friday, March 12, 2010 10:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Multi-view Performance Issue with Statesets Drolet, Frederic wrote on 2010-03-12: osg::ref_ptrosg::StateSet lStateSet = mGeometrie- getOrCreateStateSet(); lStateSet-setMode(GL_LIGHTING, osg::StateAttribute::OFF); OpenGL performance is very sensitive to state changes, so it is a good idea to minimize them as much as possible. OSG groups Drawables with the same state as part of this (the exception is transparent drawables that require a certain ordering to render correctly, so they can't be grouped), but it just compares the StateSet pointers rather than a (much more expensive) comparison of what OpenGL state the StateSet pointers represent. Therefore, if you have a bunch of StateSets that are identical, like you seem to have, it is a really good idea to just use the same StateSet object everywhere you need it, rather than create a new instance every time. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Inline shaders in .osg files have extra newline in each quoted line
Hi Robert,
This fixes a small problem in .osg files, where inline shaders would
have an extra newline per line:
Shader {
type VERTEX
code {
#version 120
#extension GL_EXT_geometry_shader4 : enable
uniform mat4 osg_ViewMatrixInverse;
...
This is because the shader is being written directly from the string
(_shaderSource) to the .osg file, and that string contains newlines.
osgDB::Output::wrapString() is called from
src/osgWrappers/deprecated-dotosg/osg/Shader.cpp :
Shader_writeLocalData(). I made the change to
osgDB::Output::wrapString() because I think in no case would we want to
keep those newlines when writing a wrapped string, because the wrapping
itself adds a newline after each closing quote of each line anyways. So
the same shader above now looks like:
Shader {
type VERTEX
code {
#version 120
#extension GL_EXT_geometry_shader4 : enable
uniform mat4 osg_ViewMatrixInverse;
...
I also made the corresponding change for the new .osgt plugin.
AsciiOutputIterator::writeWrappedString() is called from
src/osgWrappers/serializers/osg/Shader.cpp : writeShaderSource(). Again
the change will take effect for any wrapped string. I have tested this
and it fixes it too.
The reading already adds a newline to each line of code read from the
.osg/.osgt file, so the shader code we read will be what we want. The
only thing that didn't work on reading was that empty lines were
discarded in the old deprecated .osg plugin. The change to
src/osgWrappers/deprecated-dotosg/osg/Shader.cpp fixes that.
So Output.cpp goes in src/osgDB, AsciiStreamOperator.h goes in
src/osgPlugins/osg, and Shader.cpp goes in
src/osgWrappers/deprecated-dotosg/osg/
By the way, is there a way of commenting out lines in the old or new
.osg/.osgt formats?
Thanks, and sorry for being verbose.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgDB/Output
#include osgDB/Registry
#include osgDB/FileNameUtils
#include osg/Notify
#include sstream
#include stdio.h
#include string.h
using namespace std;
using namespace osgDB;
static osg::ApplicationUsageProxy
Output_e0(osg::ApplicationUsage::ENVIRONMENTAL_VARIABLE,OSG_WRITE_OUT_DEFAULT_VALUES,
ON | OFF);
Output::Output()
{
init();
}
Output::Output(const char* name) : osgDB::ofstream(name)
{
init();
_filename = name;
}
Output::~Output()
{
}
void Output::init()
{
_indent = 0;
_indentStep = 2;
_numIndicesPerLine = 10;
_pathNameHint = AS_IS;
_outputTextureFiles = false;
_textureFileNameNumber = 0;
_outputShaderFiles = false;
_shaderFileNameNumber = 0;
_writeOutDefaultValues = false;
const char* env = getenv(OSG_WRITE_OUT_DEFAULT_VALUES);
if (env)
{
_writeOutDefaultValues = strcmp(env,ON)==0;
}
}
void Output::setOptions(const Options* options)
{
_options = options;
}
void Output::open(const char *name)
{
init();
osgDB::ofstream::open(name);
_filename = name;
}
// Comment out to avoid compile errors under new compilers, the int mode
// is now a replaced by a class to wrap the mode.
// This method is not used right now to hopefully nobody will miss it...
// Jan 2002.
// void Output::open(const char *name,int mode)
// {
// init();
// ofstream::open(name,mode);
// _filename = name;
// }
Output Output::indent()
{
for(int i=0;i_indent;++i) *this' ';
return *this;
}
void Output::moveIn()
{
_indent += _indentStep;
}
void Output::moveOut()
{
_indent -= _indentStep;
if (_indent0) _indent=0;
}
std::string Output::wrapString(const char* str)
{
if (!str) return std::string(\\);
return wrapString(std::string(str));
}
std::string Output::wrapString(const std::string str)
{
std::string newstring;
newstring += '';
for(unsigned int i=0;istr.size();++i)
{
if (str[i]=='\\')
{
newstring += '\\';
newstring += '\\';
}
else if (str[i]=='')
{
newstring +=
Re: [osg-users] Moving a line and its vertices
Hi By default OSG will have display list turned on which means the drawing is cached and thus when you change something it will not be reflected, if your changing tings a lot you might want to disable display list alternatively you can tell OSG to rebuild the display list with a call like myGeometry-dirtyDisplayList(); I would recommend a searching the forum archive as well as this has been discuss many times and there are many ways in which you could edit geometry on the fly Gordon Tomlinson Product Manager 3d Technology Project Wyvern Overwatch(r) An Operating Unit of Textron Systems -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David Cofer Sent: Friday, March 12, 2010 10:46 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Moving a line and its vertices Hi, I have created a line in my scene based on the osggeometry example. I create the line and it displays fine, but I also need to change the end-points on the line dynamically as the simulation progresses. I started out by re-setting the vertex array data at each step in the render loop, but that did nothing. The line stayed exactly where it was when it was first initialized. I then tried creating a new vertex array and calling setVertexArray at each step, and this blew up spectacularly after a few steps. Is there any example of how I am supposed to get my line and its end points to move dynamically in the simulation? Thank you! Cheers, David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25579#25579 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Moving a line and its vertices
I used some different keyword google searches and ran across this post (http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg31811.html). Making these changes fixed the problem. Thanks for the help everyone. David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25585#25585 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL 4.0 released!!
Sergey Kurdakov wrote: Hi the subroutines added in GLSL 4. yes it might also affect the major feature of osg being discussed lately - the way to handle shader composition. Another big thing is the new tessellation shaders (tessellation control and tessellation evaluation). I haven't used osgTerrain myself, but I can't help but wonder if those would be useful in something like that. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vicon tracking
Thanks for your answers. I understand the theory behind this, which means that I will need to set projection matrices for the left and right eye cameras according to my distance to the display surface. The problem is, can these cameras be retrieved and have their projection matrices modified before each viewer.frame() call? As I have mentioned, at the moment I am using the ---stereo command line argument to enable stereo. I read at an older thread(around July 2009) that cameras could not be retrieved using the viewer object, but this was going to change. Now I see a getCameras method in the Viewer class. Will that work for me, or will setting the camera matrices interfere with the already implemented stereo rendering? In that case, will I need to set stereo settings to off and implement stereo manually using slave cameras, as was suggested at that thread? By the way, the stereo settings wiki: http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/StereoSettings mentions: If the user is planning to use head tracked stereo, or a cave then it is currently recommend to set it up via a VR toolkit such as VRjuggler, in this case refer to the VR toolkits handling of stereo, and keep all the OSG's stereo specific environment variables (below) set to OFF Does anyone know if this is still the case, or is that note outdated? Thanks a lot Mel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25587#25587 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vicon tracking
Mel Av wrote: Thanks for your answers. I understand the theory behind this, which means that I will need to set projection matrices for the left and right eye cameras according to my distance to the display surface. The problem is, can these cameras be retrieved and have their projection matrices modified before each viewer.frame() call? As I have mentioned, at the moment I am using the ---stereo command line argument to enable stereo. I read at an older thread(around July 2009) that cameras could not be retrieved using the viewer object, but this was going to change. Now I see a getCameras method in the Viewer class. Will that work for me, or will setting the camera matrices interfere with the already implemented stereo rendering? In that case, will I need to set stereo settings to off and implement stereo manually using slave cameras, as was suggested at that thread? By the way, the stereo settings wiki: http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/StereoSettings mentions: If the user is planning to use head tracked stereo, or a cave then it is currently recommend to set it up via a VR toolkit such as VRjuggler, in this case refer to the VR toolkits handling of stereo, and keep all the OSG's stereo specific environment variables (below) set to OFF I'm pretty sure VRJuggler is still using the old SceneView class, so I wouldn't put too much faith in that statement. You'll still need to enable quad-buffer stereo (whether you do it via environment variable or in code directly using DisplaySettings doesn't really matter). You should be able to get the cameras via the getCamera() or getCameras() call in Viewer (I think you only have one camera, though, right?), and you can definitely set the projection matrix on the Camera(s) to correspond to your head tracking and view. I don't know how the Viewer sets up the stereo projections, though (I tried to find it in the code, but it's buried pretty deep). Someone else will have to answer that question, I guess. --J Does anyone know if this is still the case, or is that note outdated? Thanks a lot Mel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25587#25587 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] iv plugin with coin4 from svn
Hi,
i cannot open any iv or vrml on MS VC 2008 and OSG 2 days ago svn- coin from
svn (= mercurial) i got a breakpoint triggered
in
Code:
SoCallbackAction::getNumTextureCoordinates(void) const
{
return SoMultiTextureCoordinateElement::getInstance(this-state)-getNum(0);
}
call stack :
Code:
msvcr90d.dll!_NMSG_WRITE(int rterrnum=10) Line 198 C
msvcr90d.dll!abort() Line 59 + 0x7 bytes C
msvcr90d.dll!_wassert(const wchar_t * expr=0x066a6b48, const wchar_t *
filename=0x066a6ad8, unsigned int lineno=435) Line 163 C
coin4d.dll!SoMultiTextureCoordinateElement::getNum(const int unit=0)
Line 435 + 0x27 bytes C++
coin4d.dll!SoCallbackAction::getNumTextureCoordinates() Line 850
C++
osgdb_ivd.dll!ConvertFromInventor::postShape(void * data=0x0013ade8,
SoCallbackAction * action=0x0013ac48, const SoNode * node=0x034bb648) Line 913
+ 0xb bytesC++
coin4d.dll!SoCallbackData::doNodeCallbacks(SoCallbackAction *
action=0x0013ac48, const SoNode * node=0x034bb648) Line 229 + 0x14 bytes C++
coin4d.dll!SoCallbackAction::invokePostCallbacks(const SoNode * const
node=0x034bb648) Line 1117 + 0x28 bytes C++
coin4d.dll!SoNode::callbackS(SoAction * action=0x0013ac48, SoNode *
node=0x034bb648) Line 990 C++
coin4d.dll!SoAction::traverse(SoNode * const node=0x034bb648) Line 963
+ 0xd bytes C++
coin4d.dll!SoChildList::traverse(SoAction * const action=0x0013ac48,
const int first=0, const int last=1) Line 337 C++
coin4d.dll!SoChildList::traverse(SoAction * const action=0x0013ac48)
Line 407 C++
auto variables
Code:
+ rterrs 0x10311048 rterrs {rterrno=2 rterrtxt=0x10201cc8 R6002
- floating point support not loaded
} rterrmsgs [23]
+ rterrs[tblindx] {rterrno=10 rterrtxt=0x10201bd8
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
} rterrmsgs
+ rterrs[tblindx].rterrtxt0x10201bd8
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
char *
tblindx 3 int
any solution?
Thank you!
Cheers,
Michele
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25589#25589
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LOD support
Hello, How much LOD support is there in OSG? I've found a couple functions that refer to LOD but I can't find any documentation on the subject. I'd like to be able to generate and configure LOD's for the scenegraph. Is that possible? Thanks, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: how to rotate view camera 90 degrees in relationship to terrain
Hi, thanks JP! :) I really appreciate your response. It appears I am fighting something I didn't expect and something I don't fully understand: the terrain manipulator. I understand what you've proposed but when I call the fucntion: setByMatrix() w/in the terrain manipulator, that function appears to be doing something to the matrix I send in that I am not expecting. What you've proposed is pretty much what I do except that I'm using quaternions and then converting those quats into matrices. So I can move the cam and I can even rotate it on the Z axis which is the position vector coming from the ECEF origin to the point on the terrain I'm working with and the cam is looking directly down that Z axis (local z-axis). It's just when I do a 90 degree rotation about the local x or y axis I get something totally screwed up and I don't know why but I think the mystery is w/in the terrain manipulator which I've not investigated more thoroughly as yet. I am hoping someone who has in depth knowledge about the terrain manipulator will see this post buzz me back on it. I have very limited understanding of the manipulator code w/in OSG as I'm still a novice w/ OSG so I get all mixed up when I delve into any of the manipulator classes: trackball, nodetracker and now terrain. thanks though! Thank you! Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25590#25590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] opengl 3 course: march 30 - april 2, 2010 - los angeles
Hi, I do believe the opengl course would be very beneficial for programming in osg but unfortunately, I don't have the money or time. But, if you can go and you use osg extensively, I would go. Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25592#25592 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Off Topic: EPX-50 Anyone know anything about these?
Folks, I'm looking for any info I can find on the Rockwell Collins EPX-50. One of our marketing guys wants to move our visual applications to these. We currently run osg on commodity hardware. Brian _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_1___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Future of osgIntrospection + genwrapper
Hi Nick, On Fri, Mar 12, 2010 at 2:57 PM, Trajce (Nick) Nikolov nikolov.tra...@gmail.com wrote: one question. I am not familiar with this piece of code at all, but , does the osgdotnet wrapper depends on it? If so, I am very interested in keeping it alive I'm not sure about the dependency in osgdotnet having never compiled or used it personally. osgdotnet itself does seem to be in rather an orphaned state, so it too could probably do with a member of the community picking up the reigns on. There is also the question whether lighter weight approaches for integrating .NET and the OSG are more suitable for most users that need to go this route. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD support
The OSG has extensive LOD support including Paged LODing Search the email archives there are many discussion on LOD's, also look through the source code its has it ALL See OpenSceneGraph\examples\osgpagedlod OpenSceneGraph\include\osg\LOD OpenSceneGraph\include\osg\PagedLOD See the OSG Quick Start guide http://www.osgbooks.com/books/osg_qs.html __ Gordon Tomlinson gor...@gordontomlinson.com www.photographybyGordon.com www.vis-sim.com www.gordontomlinson.com IM: gordon3db...@3dscenegraph.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Gotzel Sent: Friday, March 12, 2010 2:55 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] LOD support Hello, How much LOD support is there in OSG? I've found a couple functions that refer to LOD but I can't find any documentation on the subject. I'd like to be able to generate and configure LOD's for the scenegraph. Is that possible? 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
[osg-users] [build] How do I successfully deploy a OSG app?
How do we deploy an OSG app that we compiled in VC++ 2008? Because simply the .exe will not work on other computers (naturally). I've tried using VC redist. and friends, but with no avail... I have heard of static linking, but how would that work? I would greatly appreciate any helpful response! Thanks! -Masoug -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25595#25595 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How do I compile an OSG app, so that it can be run without the OSG installed?
I think when you COMPILE the application, you tell VC to statically link the libraries... I believe VC creates the DLL because of the makfile configuration, but that shouldn't change anything much... -Masoug -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25594#25594 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Future of osgIntrospection + genwrapper
Hi Torben, On Fri, Mar 12, 2010 at 3:03 PM, Torben Dannhauer z...@saguaro-fight-club.de wrote: If I Remember right, Wang wrote in the context of the serializer introduction, that a wrapper/introspection could be build up on that technique. I'm not sure if I remember right, but could this be a solution to maintain a kind of introspection/wrapper functionality and to move the current osgIntropsection out of the core? Wang Rui's new serializers do certainly overlap with osgIntrospection in terms of ability to push/pull properties from the OSG, but the serializers aren't currently built for querying individual properties or invoking methods. There is potential there. Wang Rui's serializers are much lighter weight and more efficient than osgIntrospection which is a real advantage. My experience has been that hand maintained wrappers (such as the .osg plugin) have turned out to be far easier to maintain than the automatically generated ones, so while genwrapper/osgIntrospection would appear to be very powerful and useful, their complexity and awkwardness w.r.t maintenance have held us back. I believe the complexity of osgIntrospection has also hindered it's adoption in the community - very few projects seem to use it, even the OSG itself never used it internally. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How do I successfully deploy a OSG app?
You don't need static builds to use OSG on another machine You say it does not work ...HOW does NOT work ?, how are you installing on another machine ? Yes you do need the correctly MSVC re-distributable to be installed as part of your applications installation process You need to ensure that the MSVC re-distributable's and the OSG bin\dlls are in your path and that your install all the OSG dlls including the plugin-in directory etc __ Gordon Tomlinson gor...@gordontomlinson.com www.photographybyGordon.com www.vis-sim.com www.gordontomlinson.com IM: gordon3db...@3dscenegraph.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mas Oug Sent: Friday, March 12, 2010 3:48 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] [build] How do I successfully deploy a OSG app? How do we deploy an OSG app that we compiled in VC++ 2008? Because simply the .exe will not work on other computers (naturally). I've tried using VC redist. and friends, but with no avail... I have heard of static linking, but how would that work? I would greatly appreciate any helpful response! Thanks! -Masoug -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25595#25595 ___ 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] Off Topic: EPX-50 Anyone know anything about these?
Brian, What info are you looking for in particular? I had some exposure to the EPX product a while back while working at Evans Sutherland (now bought out by Rockwell-Collins). That was about 6 years ago so I'm sure things have evolved since that time. At that time, it was an IG that used COTS graphics hardware. I believe that is still the case. It's their lower end IG product which is competitive with most other products out there that employ a similar strategy. I personally like the EPX stuff but then I'm a little biased...:) http://www.rockwellcollins.com/service/simulation/visual-products/image-gene rators/epx-50/index.html -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brian ... Sent: Friday, March 12, 2010 1:33 PM To: OpenSceneGraph Users Subject: [osg-users] Off Topic: EPX-50 Anyone know anything about these? Folks, I'm looking for any info I can find on the Rockwell Collins EPX-50. One of our marketing guys wants to move our visual applications to these. We currently run osg on commodity hardware. Brian Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. Learn More. http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON: WL:en-US:WM_HMP:032010_1 smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD support
On 3/12/2010 12:55 PM, Paul Gotzel wrote: Hello, How much LOD support is there in OSG? I've found a couple functions that refer to LOD but I can't find any documentation on the subject. I'd like to be able to generate and configure LOD's for the scenegraph. Is that possible? Tons of support. Describe your application requirements and someone might be able to give you better suggestions. -- 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] Precipitation and VBO
Hi, I am experiencing VERY bad performance (i.e 1 FPS) when I enable precipitation on my Dell laptop (XPS 1710) that uses a GeForce 7950 graphic card (dell driver version 179.xx). But here's the kicker... the performance is fine when running on any other desktop systems that has a more recent graphic card (for example a 8800 GTX). I kinda understand that it would run faster, but never expecte a drop to 1 FPS on a 7950, especially when there is ABSOLUTELY nothing in the scene. I've reduced my application to the bare minimum to isolate the problem. All I have in my scene graph is a pre- post- camera used to render my scene to a texture (using the render-target-implememtation functions of the osg::camera), and an instance of precipitation effect. I tried using different render-target-implementation technique (like FRAME_BUFFER) but that did not change anything. If I bypass the render-target-implementation (i.e I bypass the osg::camera::attach() method), keep the pre-camera, and remove the post-camera, then everything work fine (running at 60fps). Can someone shed some light on why the the render-target-implementation would affect osg::PrecipitationEffect (or vice-versa). Note: The problem is not the precipitation effect because I compared my implementation with the osg precipitation example and they are the same. When I run the example the frame rate is 60fps (which is the same as my app when I bypass the rendet to target). Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25603#25603 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Off Topic: EPX-50 Anyone know anything about these?
Hi Brian, thats an interesting move. But, I know the trends are the other way in the industry. OSG has just about everything what the commercial IGs are offering. Some of the features are even much better. Those commercial are expensive. If your company have money might be better to spend it on improving OSG then buying proprietary software ... and hardware in your case -Nick On Fri, Mar 12, 2010 at 10:33 PM, Brian ... br...@hotmail.com wrote: Folks, I'm looking for any info I can find on the Rockwell Collins EPX-50. One of our marketing guys wants to move our visual applications to these. We currently run osg on commodity hardware. Brian -- Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. Learn More.http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_1 ___ 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
