[osg-users] How to count polygons in view
Hello all,I'm a new around here. So far I've managed to get around but I'm stuck on a simple task. How many polygon do I have on screen right now. I saw the post http://groups.google.com/group/osg-users/browse_thread/thread/6e2894a28daa2f68/435314f8a1ffafc3?hl=enlnk=gstq=number+polygon#435314f8a1ffafc3 But I just can't make it work. I did some thing like that: osg::viewer viewer; . . . . . RenderStage *rs = new RenderStage; rs-setCamera(viewer.getCamera()); but nothing updates any 1??? thank YoU. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to count polygons in view
Hi, Maybe you can have a look on osg sources, on osgViewer and statistics... If you make a new viewer, press 's' and see the statistics... it can gives you an idea of what you can obtain. An other way can be to do it manually : with a nodecallback or a cullcallback, you can check if a node is in the frutum or not. After that, just count the visible node polygons... Vincent. 2008/12/3 oren david [EMAIL PROTECTED] Hello all,I'm a new around here. So far I've managed to get around but I'm stuck on a simple task. How many polygon do I have on screen right now. I saw the post http://groups.google.com/group/osg-users/browse_thread/thread/6e2894a28daa2f68/435314f8a1ffafc3?hl=enlnk=gstq=number+polygon#435314f8a1ffafc3 But I just can't make it work. I did some thing like that: osg::viewer viewer; . . . . . RenderStage *rs = new RenderStage; rs-setCamera(viewer.getCamera()); but nothing updates any 1??? thank YoU. ___ 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 of dynamic_cast vs. virtual call
Hi Ulrich,
Well of course a dynamic_cast is not always repleacable by a className() call.
This happens only sometimes. My bench' only says if you can, then use
className() and also says use dynamic_cast wisely: it costs a lot.
And about the static_cast in the bench', you're right, but I'm not sure this
has any performance impact since the type is only an information for the
compiler. Only the affectation would cost something I think. Well... I'm going
to test.
(...)
Result: that's right, I can't see any difference. So you're code is cleaner
than mine, but there is no noticeable effect on performance.
Thank you!
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Quoting Sukender [EMAIL PROTECTED]:
Has anyone *benchmarked* the difference between a dynamic_cast and a virtual
call to identify the type of a class? Before my benchmark, I guessed the
virtual call was cheaper, but how much? I just knew it depends a lot on how
types are related for the dynamic_cast.
interesting results, I wouldn't have thought it'd be that different.
However when doing a dynamic_cast you probably don't want to check for exact
type (which is what the name compare is doing) but rather find out if an
object
supports a certain interface i.e. is derived from a specific base class. You
simply can't do that by checking the class name.
Also for consistency you should add (and time) a static_cast after your
strcmp
to get a pointer to the actual data type:
if (pointer-className() == Target) {
Target* t = static_castTarget*(pointer);
}
Cheers,
/ulrich
___
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] problems with CompositeViewer
Hi all, regarding the question yesterday about the problem with the compositeviewer, I attach the fragment of code that i am using. Has somebody any idea about where is the problem? Thank you very much. osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; // Init the Windata Variable that holds the handle for the Window to display OSG in. osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(GetSafeHwnd()); // Setup the traits parameters traits-x = 0; traits-y = 0; traits-width = RectDLG.right - RectDLG.left; traits-height = RectDLG.bottom - RectDLG.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; // Create the Graphics Context osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); // view 1: for 3D model /* Create the scene data */ // osgViewer::View* view1 = new osgViewer::View(); view1-getCamera()-setViewport(new osg::Viewport(traits-width/2,traits-y,traits-width/2,traits-height)); view1-getCamera()-setProjectionMatrixAsPerspective(30.0f, static_castdouble(traits-width/2)/static_castdouble(traits-height), 1.0f, 1.0f); view1-getCamera()-setGraphicsContext(gc); view1-setSceneData(BackgroundRoot); // view 2: for Background image /* Create the background image graph */ // osgViewer::View* view2 = new osgViewer::View(); view2-setSceneData(hudRoot); view2-getCamera()-setViewport(new osg::Viewport(0,0,traits-width,traits-height)); view2-getCamera()-setProjectionMatrixAsPerspective(30.0f, static_castdouble(traits-width)/static_castdouble(traits-height), 1.0f, 1.0f); view2-getCamera()-setGraphicsContext(gc); view2-setSceneData(ModelRoot); // Attach views to CompositeViewer sceneView-addView(view2); // Draw first? sceneView-addView(view1); - Original Message - From: David Oyarzun To: osg-users@lists.openscenegraph.org Sent: Tuesday, December 02, 2008 6:09 PM Subject: problems with CompositeViewer Hi all, I think I have a problem with the render order of the CompositeViewer. I am trying to program a osg-based windowed application that shows a 3D animated object centered in the right middle of the window. Moreover, it has a background image that fills all the window, including the right middle (behind the 3D model). I want that the application is modular, in the sense that depending the initial width and height fo the window, the 3D object appears always centered in the right middle. For doing that, I have created a CompositeViewer with 2 views, one of them setting the viewport to all the window and putting the background as SceneData, and the other one with the right middle size for putting the 3D object, but I only see the backgorund image. It seems like the backgorund image is always in the front, because if I delete its view, the 3D object is well positioned. Could be something related with the render order? If it is, how could I tell CompositeViewer to draw the background before the 3D model? Else, is it a good idea using the CompositeViewer for this kind of issue? Thank you in advance, David. __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3658 (20081202) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KDTree Picking (at an angle)
Hi Sean,
This sounds like a bug, but without a dataset and example that
reproduces the problem it's next to impossible to home in on a fix.
Would it be possible for you to provide a problem dataset that
illustrates the problem? If it can be reproduced with one of the
existing examples like osgpick then this will make it easier to track
down.
Robert.
On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED] wrote:
Hi Gang,
I'm working on improving picking performance via KDTree, but I'm hitting an
issue that is driving me nuts: If I pick a node from directly above (e.g. +
Z axis) everything works great, and picking is *very* fast. If I pick at an
angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate - nodes
to the left, right, top, or bottom get picked instead of what I'm after.
Here is my KDTree Build function:
#ifdef USE_KDTREE
// Update the KDTree
osg::KdTree::BuildOptions kdTreeBuildOptions;
osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
if(kdTree-build(kdTreeBuildOptions, geometry))
{
geometry-setShape(kdTree.get());
}
else
{
LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.;
}
#endif
Any suggestions?
cheers,
sean
___
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] VPB: Partial terrain with vpbmaster, why?
On Wed, Dec 3, 2008 at 2:11 AM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: I tried but no clue yet. How is going the VPB documentation project? Been too swamped by other work to get on to it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAudio/OpenAL/osgAL
Hi Sukender,
Thanks for confirmed message about Platform SDK. It really help me because I
haven't tried express edition yet.
I have an question about Effects. After installation OpenAL Sdk 1.1 there is
some samples and all of them using Framework library. Can we use effects
using plain alut functions? Do we really need this framework? I have tried
to implement alut functions but there is a definition problem about external
functions ( alEffects, alFilters and etc ) in Framework.h
Any though?
Regards.
2008/12/2 Sukender [EMAIL PROTECTED]
Just a quick note: if you use VC8, you'll need the Platform SDK (free). I'm
not sure but I guess VC9 does not need it since it's included (to be
confirmed).
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 16:55:00 +0100, Ümit Uzun [EMAIL PROTECTED] a
écrit:
Hi Sukender,
Thanks for your researching. As you say, I will install express edition
visual studio 2005.
Regards,
2008/12/2 Sukender [EMAIL PROTECTED]
Hi Ümit,
This is a variadic macro. This is not in the C++ standard, as far as I
know. I use VC8 (2005) Express and have no problem with it. This macro
seems
tu be used only for debugging (?), so maybe this could be removed on
compilers that don't support it? Anyway, you should use VC8 since there
are
some useful improvements. Tell me about your progress on that topic.
See http://en.wikipedia.org/wiki/Variadic_macro
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 16:07:49 +0100, Ümit Uzun [EMAIL PROTECTED] a
écrit:
Hi Sukender,
I have tried to compile openal-soft but there is strange error about
#define
AL_PRINT(...) do { pattern. Do you think it's right declaration? It
is
seen
me odd.
Errors are :
error C2010: '.' : unexpected in macro formal parameter list
error C2065: '__VA_ARGS__' : undeclared identifier
Should I declare something? I am using VS-2003 and Cmake-2.6.
Regards.
2008/12/2 Sukender [EMAIL PROTECTED]
Hi Stephan,
Thanks a lot for testing.
I'll ask the OpenAL-soft author about what you say and give you
feedback.
However, if you can say where (= line code) the problem arises, that
would
be very useful I think.
Yes, OpenAL is part of the system, but the main goal here (about
using
OpenAL-Soft instead of OpenAL) is just to ensure we have an unique
library
that:
- works correctly across platforms (= the same ones as OSG does)
- is maintained
- evolves
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 15:26:06 +0100, Stephan Maximilian Huber
[EMAIL PROTECTED] a écrit:
Sukender schrieb:
Hi all,
This is only partially related to OSG, so I'll make it short:
In order to make an osgAudio layer and a corresponding plugin
based
on
OpenAL-Soft and osgAL, there is some need for testing and/or
development.
1. Anyone that can help testing OpenAL-Soft on following platforms
may
mail me or openal-devel mailing list (
http://opensource.creative.com/mailman/listinfo/openal-devel ):
- Mac OSX (most wanted of all tests)
i downloaded OpenAL-Soft, compiled it and ran the sample-app. It
couldn't create a context. I did not have time to dig deeper but it
seems, OpenAl couldn't create an output device.
OpenAL is part of the system-libs, though.
cheers,
Stephan
___
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
--
Ümit Uzun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance of dynamic_cast vs. virtual call
On Wed, Dec 3, 2008 at 9:18 AM, Sukender [EMAIL PROTECTED] wrote: Well of course a dynamic_cast is not always repleacable by a className() call. This happens only sometimes. My bench' only says if you can, then use className() and also says use dynamic_cast wisely: it costs a lot. dynamic_cast is documented in C++ texts as being relatively slow, it's best to go do some background reading on how its implemented to understand why it's so much slower than virtual function call. The OSG uses dynamic_cast sparingly, and not in any inner loops of on operations that are called often in a frame, I'd recommend doing the same. The OSG has several robust alternatives to dynamic_cast, first up is the NodeVisitor which uses double dispatch (two virtual function calls, see Visitor design pattern) to determine object type, and virtual Class* asClass() style methods that exhist for the most common types of base class to subclass operations. For instance Transform* node-asTransform() or Geometry* drawable-asGeometry(). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with CompositeViewer
HI David, I'll stop being subtle about it then as you seem to have ignored my previous email which told you exactly what to do. Using two views to do what you want to do is *completely* the wrong way to tackle the problem. You task requires a single view, but with either a slave Camera or a in scene graph Camera. Please just abandon your currently code as a lost cause, and review the osghud example and learn about the different ways of using cameras. Robert. On Wed, Dec 3, 2008 at 9:25 AM, David Oyarzun [EMAIL PROTECTED] wrote: Hi all, regarding the question yesterday about the problem with the compositeviewer, I attach the fragment of code that i am using. Has somebody any idea about where is the problem? Thank you very much. osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; // Init the Windata Variable that holds the handle for the Window to display OSG in. osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(GetSafeHwnd()); // Setup the traits parameters traits-x = 0; traits-y = 0; traits-width = RectDLG.right - RectDLG.left; traits-height = RectDLG.bottom - RectDLG.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; // Create the Graphics Context osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); // view 1: for 3D model /* Create the scene data */ // osgViewer::View* view1 = new osgViewer::View(); view1-getCamera()-setViewport(new osg::Viewport(traits-width/2,traits-y,traits-width/2,traits-height)); view1-getCamera()-setProjectionMatrixAsPerspective(30.0f, static_castdouble(traits-width/2)/static_castdouble(traits-height), 1.0f, 1.0f); view1-getCamera()-setGraphicsContext(gc); view1-setSceneData(BackgroundRoot); // view 2: for Background image /* Create the background image graph */ // osgViewer::View* view2 = new osgViewer::View(); view2-setSceneData(hudRoot); view2-getCamera()-setViewport(new osg::Viewport(0,0,traits-width,traits-height)); view2-getCamera()-setProjectionMatrixAsPerspective(30.0f, static_castdouble(traits-width)/static_castdouble(traits-height), 1.0f, 1.0f); view2-getCamera()-setGraphicsContext(gc); view2-setSceneData(ModelRoot); // Attach views to CompositeViewer sceneView-addView(view2); // Draw first? sceneView-addView(view1); - Original Message - From: David Oyarzun To: osg-users@lists.openscenegraph.org Sent: Tuesday, December 02, 2008 6:09 PM Subject: problems with CompositeViewer Hi all, I think I have a problem with the render order of the CompositeViewer. I am trying to program a osg-based windowed application that shows a 3D animated object centered in the right middle of the window. Moreover, it has a background image that fills all the window, including the right middle (behind the 3D model). I want that the application is modular, in the sense that depending the initial width and height fo the window, the 3D object appears always centered in the right middle. For doing that, I have created a CompositeViewer with 2 views, one of them setting the viewport to all the window and putting the background as SceneData, and the other one with the right middle size for putting the 3D object, but I only see the backgorund image. It seems like the backgorund image is always in the front, because if I delete its view, the 3D object is well positioned. Could be something related with the render order? If it is, how could I tell CompositeViewer to draw the background before the 3D model? Else, is it a good idea using the CompositeViewer for this kind of issue? Thank you in advance, David. __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3658 (20081202) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.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 of dynamic_cast vs. virtual call
Hi Robert, Thanks for being so precise. Well I knew most of it, but that's always good to remember all of this. :) And to also be precise: I just wanted to benchmark my system, and I had values than outcame my expectations. So I told others about this. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 03 Dec 2008 10:35:54 +0100, Robert Osfield [EMAIL PROTECTED] a écrit: On Wed, Dec 3, 2008 at 9:18 AM, Sukender [EMAIL PROTECTED] wrote: Well of course a dynamic_cast is not always repleacable by a className() call. This happens only sometimes. My bench' only says if you can, then use className() and also says use dynamic_cast wisely: it costs a lot. dynamic_cast is documented in C++ texts as being relatively slow, it's best to go do some background reading on how its implemented to understand why it's so much slower than virtual function call. The OSG uses dynamic_cast sparingly, and not in any inner loops of on operations that are called often in a frame, I'd recommend doing the same. The OSG has several robust alternatives to dynamic_cast, first up is the NodeVisitor which uses double dispatch (two virtual function calls, see Visitor design pattern) to determine object type, and virtual Class* asClass() style methods that exhist for the most common types of base class to subclass operations. For instance Transform* node-asTransform() or Geometry* drawable-asGeometry(). 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
[osg-users] How to count polygons in view
Well, I need the polygons counts not the node counts. maybe I can count drawables or something like that. According the post I mentioned OSG has something built-in for it ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to count polygons in view
Hi Oren, Could you *please* use the same threads that you've already started. Starting up new threads to ask practically the same question over and over is really bad use of the osg mailing list. This is the second time I've had to suggest this to you. Also could please read the replies to your others posts - answers to your questions have been supplied. You will need also need to show a little initiative, you have all source code to the OSG. Robert. On Wed, Dec 3, 2008 at 11:12 AM, oren david [EMAIL PROTECTED] wrote: Well, I need the polygons counts not the node counts. maybe I can count drawables or something like that. According the post I mentioned OSG has something built-in for it ___ 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] Packaging granularity + platform specific scripts
Hi Robert, all, I have used the CPack program and module from the CMake suite with a small (but production) project at my company. It didn't use CPack to it's full extent nor did it ship for other platforms than win32. I believe that it might be a good and fairly unobtrusive way of defining packages in our current CMake scripts. Mathieu Marache have commented on the state of the DEB generator in previous post and that is certainly a drawback in the short term. An experienced debian package maintainer (which I am not but willing to try if noone steps up) could probably get a good start from the current DEB package generator in CPack though. Is CPack an option at all? if so - should I whiip together an example of how this might be implemented based on the current osg source tree for you and developers to review? cheers Mattias On Thu, Nov 27, 2008 at 3:42 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Cedric, On Thu, Nov 27, 2008 at 2:29 PM, Cedric Pinson [EMAIL PROTECTED] wrote: I think it's better if you read an example of an ebuild. Because source are compiled when installing package it's easy to setup the cmakelist option when installing the package. In the ebuild example we could add option like gdal, osgal, and what you want. Thanks for the ebuild example, this is exactly what I need to get on an idea of the different needs of packing on different platforms. But i think it's not a good idea to create a new package format that could be common with all system. In my opinion the best way to setup package should be to have some vserver that automatically make package. Like a compiling farm. It sound big but could be made step by step. I'm not thinking about replacing existing packaging system, just better supporting the ones that are already there. In the case of windows there is rather a vacuum. How to solve this one I can't answer. But in fact we just need more maintainer, having those build system limit the amount of work by a human. Just need to check when new version. If we got more maintainers on differents distribution the package problem would not really exist. Maybe we need to find a comunity manager :) More maintainers isn't just what we require. We need coordinated maintenaners, something that is rather lacking right now. It's a case of who has the itch goes scratch it for as long as them have time and interest. The maintainers also need to be working off the same general script, and to getting required changes back up stream, engaging directly with the OSG community. I am not sure to understand the big picture you have about packaging so maybe i am wrong I don't have any strong idea of the ideal system for the OSG and it's community, which is why I raised this thread. My plan is just - Set out a rough goal of wanting to improving the packaging situation, gather information, and then tryto resolve some workable plan going going. We're at the information gathering point 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] osgAudio/OpenAL/osgAL
Hi Ümit,
Well, for integration of audio in OSG I:
- Compiled OpenAL-Soft (even if you can use OpenAL)
- used freeALUT binaries
- Compiled ligOGG and libVorbis
- Compiled osgAL (uses FreeALUT and OpenAL/OpenAL-Soft and OGG/Vorbis)
I did't use the OpenAL SDK, so I guess this is not required (or maybe for some
special functions???). I can't tell you anything about OpenAL SDK and its
samples, nor about effects, sorry.
If you need my binaries (VC8 SP1), just ask me (maybe directly and not on the
mailing list until it's related to OSG).
PS: Remember to install SP1 for VC8 (or VC9) because .lib aren't compatible
between SP1 and non-SP1 versions.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Wed, 03 Dec 2008 10:32:09 +0100, Ümit Uzun [EMAIL PROTECTED] a écrit:
Hi Sukender,
Thanks for confirmed message about Platform SDK. It really help me because I
haven't tried express edition yet.
I have an question about Effects. After installation OpenAL Sdk 1.1 there is
some samples and all of them using Framework library. Can we use effects
using plain alut functions? Do we really need this framework? I have tried
to implement alut functions but there is a definition problem about external
functions ( alEffects, alFilters and etc ) in Framework.h
Any though?
Regards.
2008/12/2 Sukender [EMAIL PROTECTED]
Just a quick note: if you use VC8, you'll need the Platform SDK (free). I'm
not sure but I guess VC9 does not need it since it's included (to be
confirmed).
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 16:55:00 +0100, Ümit Uzun [EMAIL PROTECTED] a
écrit:
Hi Sukender,
Thanks for your researching. As you say, I will install express edition
visual studio 2005.
Regards,
2008/12/2 Sukender [EMAIL PROTECTED]
Hi Ümit,
This is a variadic macro. This is not in the C++ standard, as far as I
know. I use VC8 (2005) Express and have no problem with it. This macro
seems
tu be used only for debugging (?), so maybe this could be removed on
compilers that don't support it? Anyway, you should use VC8 since there
are
some useful improvements. Tell me about your progress on that topic.
See http://en.wikipedia.org/wiki/Variadic_macro
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 16:07:49 +0100, Ümit Uzun [EMAIL PROTECTED] a
écrit:
Hi Sukender,
I have tried to compile openal-soft but there is strange error about
#define
AL_PRINT(...) do { pattern. Do you think it's right declaration? It
is
seen
me odd.
Errors are :
error C2010: '.' : unexpected in macro formal parameter list
error C2065: '__VA_ARGS__' : undeclared identifier
Should I declare something? I am using VS-2003 and Cmake-2.6.
Regards.
2008/12/2 Sukender [EMAIL PROTECTED]
Hi Stephan,
Thanks a lot for testing.
I'll ask the OpenAL-soft author about what you say and give you
feedback.
However, if you can say where (= line code) the problem arises, that
would
be very useful I think.
Yes, OpenAL is part of the system, but the main goal here (about
using
OpenAL-Soft instead of OpenAL) is just to ensure we have an unique
library
that:
- works correctly across platforms (= the same ones as OSG does)
- is maintained
- evolves
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 15:26:06 +0100, Stephan Maximilian Huber
[EMAIL PROTECTED] a écrit:
Sukender schrieb:
Hi all,
This is only partially related to OSG, so I'll make it short:
In order to make an osgAudio layer and a corresponding plugin
based
on
OpenAL-Soft and osgAL, there is some need for testing and/or
development.
1. Anyone that can help testing OpenAL-Soft on following platforms
may
mail me or openal-devel mailing list (
http://opensource.creative.com/mailman/listinfo/openal-devel ):
- Mac OSX (most wanted of all tests)
i downloaded OpenAL-Soft, compiled it and ran the sample-app. It
couldn't create a context. I did not have time to dig deeper but it
seems, OpenAl couldn't create an output device.
OpenAL is part of the system-libs, though.
cheers,
Stephan
___
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
[osg-users] Problem installing and running Open scene graph
Hello iam a new user to OSG i tried to install it under win XP SP3 with MS visual studio 2008 : i used the steps in the site : http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio follower or combined with the steps in the text OsgInstallationOnWindows.rar: except for the step : - C/C++ - Language - Enable Run-Time Type Info - Yes (/GR) i replace it with the step : - C/C++ - Language - Enable Run-Time Type Info - Yes now i tried to run the file OSGviewer application . it is compiling and linking with no problem but when i run it it throw an exception at the following line : arguments.getApplicationUsage()-setApplicationName(arguments.getApplicationName()); i tried other examples but they all give me exceptions can any one please help me . thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] unresolved external(s) in svn: boundingsphere
I'm getting many unresolved external errors for the current svn version (rev. 9311) error LNK2001: unresolved external symbol public: void __thiscall osg::BoundingSphere::expandBy(class osg::BoundingBox const ) ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) TransferFunction.objosg I think it propagates to other functions later, e.g. error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphereImplclass osg::Vec3f __thiscall osg::Group::computeBound(void)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@osg@@@[EMAIL PROTECTED]) Effect.objosgFX -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Packaging granularity + platform specific scripts
Hi Matthias, I was unware of CPack. It certainly sounds like something that might take us further along the road to standardising/automating more of this work. It would be great if you produce an example. Robert. On Wed, Dec 3, 2008 at 12:04 PM, Mattias Helsing [EMAIL PROTECTED] wrote: Hi Robert, all, I have used the CPack program and module from the CMake suite with a small (but production) project at my company. It didn't use CPack to it's full extent nor did it ship for other platforms than win32. I believe that it might be a good and fairly unobtrusive way of defining packages in our current CMake scripts. Mathieu Marache have commented on the state of the DEB generator in previous post and that is certainly a drawback in the short term. An experienced debian package maintainer (which I am not but willing to try if noone steps up) could probably get a good start from the current DEB package generator in CPack though. Is CPack an option at all? if so - should I whiip together an example of how this might be implemented based on the current osg source tree for you and developers to review? cheers Mattias On Thu, Nov 27, 2008 at 3:42 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Cedric, On Thu, Nov 27, 2008 at 2:29 PM, Cedric Pinson [EMAIL PROTECTED] wrote: I think it's better if you read an example of an ebuild. Because source are compiled when installing package it's easy to setup the cmakelist option when installing the package. In the ebuild example we could add option like gdal, osgal, and what you want. Thanks for the ebuild example, this is exactly what I need to get on an idea of the different needs of packing on different platforms. But i think it's not a good idea to create a new package format that could be common with all system. In my opinion the best way to setup package should be to have some vserver that automatically make package. Like a compiling farm. It sound big but could be made step by step. I'm not thinking about replacing existing packaging system, just better supporting the ones that are already there. In the case of windows there is rather a vacuum. How to solve this one I can't answer. But in fact we just need more maintainer, having those build system limit the amount of work by a human. Just need to check when new version. If we got more maintainers on differents distribution the package problem would not really exist. Maybe we need to find a comunity manager :) More maintainers isn't just what we require. We need coordinated maintenaners, something that is rather lacking right now. It's a case of who has the itch goes scratch it for as long as them have time and interest. The maintainers also need to be working off the same general script, and to getting required changes back up stream, engaging directly with the OSG community. I am not sure to understand the big picture you have about packaging so maybe i am wrong I don't have any strong idea of the ideal system for the OSG and it's community, which is why I raised this thread. My plan is just - Set out a rough goal of wanting to improving the packaging situation, gather information, and then tryto resolve some workable plan going going. We're at the information gathering point 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem installing and running Open scene graph
Are you using the 3rd party pre-compiled dependency binaries package as there ones currently available off the site are for VS2005 and you cannot mix OSG and its dependencies between VS2005/2008 build ( see mail archives for all the details ) ( see http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHels ing for vs2008 binaries), __ Capture the magic of Christmas this year see http://www.capturethemagic.com __ Gordon Tomlinson [EMAIL PROTECTED] IM: [EMAIL PROTECTED] www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of olfat ibrahim Sent: Wednesday, December 03, 2008 7:08 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Problem installing and running Open scene graph Hello iam a new user to OSG i tried to install it under win XP SP3 with MS visual studio 2008 : i used the steps in the site : http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Vi sualStudio follower or combined with the steps in the text OsgInstallationOnWindows.rar: except for the step : - C/C++ - Language - Enable Run-Time Type Info - Yes (/GR) i replace it with the step : - C/C++ - Language - Enable Run-Time Type Info - Yes now i tried to run the file OSGviewer application . it is compiling and linking with no problem but when i run it it throw an exception at the following line : arguments.getApplicationUsage()-setApplicationName(arguments.getApplication Name()); i tried other examples but they all give me exceptions can any one please help me . thanks ___ 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] unresolved external(s) in svn: boundingsphere
Hi Ferdi, Could you do a clean regeneration of the build system using Cmake then a clean build of the OSG. Robert. On Wed, Dec 3, 2008 at 12:07 PM, Ferdi Smit [EMAIL PROTECTED] wrote: I'm getting many unresolved external errors for the current svn version (rev. 9311) error LNK2001: unresolved external symbol public: void __thiscall osg::BoundingSphere::expandBy(class osg::BoundingBox const ) ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) TransferFunction.objosg I think it propagates to other functions later, e.g. error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphereImplclass osg::Vec3f __thiscall osg::Group::computeBound(void)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@osg@@@[EMAIL PROTECTED]) Effect.objosgFX -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ 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] flt-exporter: Index out of rangeinVertexPaletteManager
Hi Andreas, I don't know if it fits what you require, but the osg::DrawElements*() primitive set types provide index support that is fully supported by OpenGL so works with the fast paths. The index support works for all per vertex attributes at the same time, so it's quite as flexible as vertex index arrays, so you may have to duplicate some vertex data that you previously didn't have to. Robert. On Wed, Dec 3, 2008 at 12:17 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi Paul Robert, thanks for your explanations. I started with osg 0.96 and use 1.2 for my software at the moment. At least in those versions I could not find any deprecated-warnings. Also I did not chose osg for performance-reasons primarily, but for it´s clean object orientated interface. Performance is mostly uncritical for me, as I do not use very large scenes. Those index arrays were useful for me, as my program allows to change the geometries dynamically, and it is not guaranteed that all vertices exist at all times (depending on what the user does). So it was very easy to keep the vertex- and normal arrays the same size all time and just add or remove the indices depending on if a certain vertex exists or not. I will do the following: - revert my changes to my own geometry not to use vertex and normal indices anymore - code geometries for shapes like sphere, cylinder, box, cone and maybe some others. I don´t feel fit to replace the ShapeDrawables with a geometry-based design, but I will be happy to post an example where those shapes are rendered as geometries. I think this would be a useful example, as some people tend to have problems with the math involved. One more question regarding the flt-exporter: I use the RT 3d Model viewer plugin for firefox to display flt-files in a browser. The background is black here. I don´t know if this is an error of that plugin, or if the GL_CLEAR_COLOR is not yet exported by the exporter. Regards, Andreas Robert Osfield schrieb: Hi Paul, On Tue, Dec 2, 2008 at 8:57 PM, Paul Martz [EMAIL PROTECTED] wrote: You are correct that code can access ShapeDrawable primitive/vertex data using the PrimitiveFunctor. Let me explain my thinking in more detail... ... Thanks for the explanation. ... (I think there's a notify message when a Geometry takes the slow path; perhaps we should bump up its verbosity to WARN.) Perhaps this is something the Optimizer could do - have a warning pass, or just a conversion pass that generates all the osg::Geometry without indices - there is a method in osg::Geometry that does this already: bool suitableForOptimization() const; void copyToAndOptimize(Geometry target); However, it seems to me that coding time would be better spent optimizing one's data to not use sub-optimal rendering features. It's curious how often I have strongly made the point about not using vertex indices for performance reasons, the comment in osg::Geometry next to all the vertex indices code is pretty clear too: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ Yet users still want to use it. With the coming of OpenGL 3.0 and OpenGL ES and the lack of display lists and slow path support this is becoming even more of an issue. Something I've been planning on doing for a while is to move all vertex index support out of osg::Geometry to prevent this type of misuse of deprecated feature. Perhaps it's time for me to do it - support for reading old data files will be the awkward part. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unresolved external(s) in svn: boundingsphere
Robert, Ok that seems to work now; configuring/building everything from scratch (still busy, but the osg link went ok). Simply cleaning the project(s) didn't help. Anyway it works again, sorry for posting too quickly... Robert Osfield wrote: Hi Ferdi, Could you do a clean regeneration of the build system using Cmake then a clean build of the OSG. Robert. On Wed, Dec 3, 2008 at 12:07 PM, Ferdi Smit [EMAIL PROTECTED] wrote: I'm getting many unresolved external errors for the current svn version (rev. 9311) error LNK2001: unresolved external symbol public: void __thiscall osg::BoundingSphere::expandBy(class osg::BoundingBox const ) ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) TransferFunction.objosg I think it propagates to other functions later, e.g. error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphereImplclass osg::Vec3f __thiscall osg::Group::computeBound(void)const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@osg@@@[EMAIL PROTECTED]) Effect.objosgFX -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ 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 -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about FluidFrictionOperator
Hello,
I think that I found a problem on
osgParticle::FluidFrictionOperator::operate(Particle* P, double dt),
I suppose that the current modular program is in relative reference frame.
The method compute a force (Fr) from velocity of the particle which is
in local space
The force is then converted in world space
if (_current_program-getReferenceFrame() ==
ModularProgram::RELATIVE_RF) {
Fr = _current_program-rotateLocalToWorld(Fr);
}
Then delta velocity computed in world space is added to the particle
velocity which is on local space
// correct unwanted velocity increments
osg::Vec3 dv = Fr * P-getMassInv() * dt;
float dvl = dv.length();
if (dvl vm) {
dv *= vm / dvl;
}
P-addVelocity(dv);
I think that there is a problem.
Can someone tell me if I wrong or not?
Thank you.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index out of rangeinVertexPaletteManager
Robert Osfield schrieb: Hi Andreas, I don't know if it fits what you require, but the osg::DrawElements*() primitive set types provide index support that is fully supported by OpenGL so works with the fast paths. The index support works for all per vertex attributes at the same time, so it's quite as flexible as vertex index arrays, so you may have to duplicate some vertex data that you previously didn't have to. Robert. Hi Robert, thank you very much, this might be exactly what I need. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] osgdb_curl.dll does notcompile without wldap32.lib
Hi Paul, I'm using VS 2008 and I've confirmed that wldap32.lib is indeed installed in the directory C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib. Regardless, the osgdb_curl build fails with the message: LINK : fatal error LNK1181: cannot open input file 'wldap32.lib' May I ask: How are others' compilers configured to find this file? I imagine I just need to add the path to the compiler-wide list of library paths in the Options dialog, but wanted to check first. In general, the Platform SDK (renamed to Windows SDK for VS9 (2008) ) library, include and bin paths should be set in your compiler's VC++ Directories configuration dialog. So setting these should resolve your problem. Tools - Options, then on the left, expand Projects and Solutions and select VC++ Directories. 1. Select Executable files on the top right, then add the Bin directory of your Windows SDK (probably C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin) 2. Select Include files and add the Include directory (C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include) 3. Select Library files and add the Lib directory (C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib) I would think that when installing VC++2008 (either the commercial version or the express version which now comes with the Platform/Windows SDK bundled, which wasn't the case for VC++2005 Express...) these paths would be set already... I don't know why they aren't. 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
Re: [osg-users] Depth/Cull question
Hi Vincent, My goal is to set this state in a callback, to allow changes when camera is near the plane : the culling is good without cheating... when camera is far from it, the culling/zbuffer makes stranges things, so I would make the necessary things to set the plane always visible... Setting the node to always render without the z-buffer is not a fix, it's a workaround. It will introduce other problems when something else (a cloud perhaps) is on top of the airplane. The result you're seeing is z-fighting, and is a result of poor z-buffer precision (you have too much distance between your near and far planes to have enough precision to represent the distance between two objects, so the z-buffer thinks object A is in front of object B when it's the opposite). The fix is to fix your z-buffer precision problem. Do you disable automatic near/far calculation? You probably should not, since this would make sure that your near plane is at the top of your airplane, and your far plane is below your ground. Or perhaps your ground is a very very large sphere where no part of the sphere can be culled away, so the far plane is actually behind the Earth (which is very far away relatively to the distance between the airplane and the ground)... Look into these problems, and you'll be able to fix the real problem. 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
Re: [osg-users] flt-exporter: Index out ofrangeinVertexPaletteManager
Hi Robert I know in our case we use vertex index arrays out of need, we have so much vertex data and have to share that many times that in our use cases we simply cannot have duplicate data , we simply cannot afford the memory bloat this would cause While understand for many using osg::DrawElements*() is the best approach, that should not preclude others that need The older functionality. I certainly for one would not want this removed from osg::Geometry this is simply a critical need for us Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 7:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index out ofrangeinVertexPaletteManager Hi Andreas, I don't know if it fits what you require, but the osg::DrawElements*() primitive set types provide index support that is fully supported by OpenGL so works with the fast paths. The index support works for all per vertex attributes at the same time, so it's quite as flexible as vertex index arrays, so you may have to duplicate some vertex data that you previously didn't have to. Robert. On Wed, Dec 3, 2008 at 12:17 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi Paul Robert, thanks for your explanations. I started with osg 0.96 and use 1.2 for my software at the moment. At least in those versions I could not find any deprecated-warnings. Also I did not chose osg for performance-reasons primarily, but for it´s clean object orientated interface. Performance is mostly uncritical for me, as I do not use very large scenes. Those index arrays were useful for me, as my program allows to change the geometries dynamically, and it is not guaranteed that all vertices exist at all times (depending on what the user does). So it was very easy to keep the vertex- and normal arrays the same size all time and just add or remove the indices depending on if a certain vertex exists or not. I will do the following: - revert my changes to my own geometry not to use vertex and normal indices anymore - code geometries for shapes like sphere, cylinder, box, cone and maybe some others. I don´t feel fit to replace the ShapeDrawables with a geometry-based design, but I will be happy to post an example where those shapes are rendered as geometries. I think this would be a useful example, as some people tend to have problems with the math involved. One more question regarding the flt-exporter: I use the RT 3d Model viewer plugin for firefox to display flt-files in a browser. The background is black here. I don´t know if this is an error of that plugin, or if the GL_CLEAR_COLOR is not yet exported by the exporter. Regards, Andreas Robert Osfield schrieb: Hi Paul, On Tue, Dec 2, 2008 at 8:57 PM, Paul Martz [EMAIL PROTECTED] wrote: You are correct that code can access ShapeDrawable primitive/vertex data using the PrimitiveFunctor. Let me explain my thinking in more detail... ... Thanks for the explanation. ... (I think there's a notify message when a Geometry takes the slow path; perhaps we should bump up its verbosity to WARN.) Perhaps this is something the Optimizer could do - have a warning pass, or just a conversion pass that generates all the osg::Geometry without indices - there is a method in osg::Geometry that does this already: bool suitableForOptimization() const; void copyToAndOptimize(Geometry target); However, it seems to me that coding time would be better spent optimizing one's data to not use sub-optimal rendering features. It's curious how often I have strongly made the point about not using vertex indices for performance reasons, the comment in osg::Geometry next to all the vertex indices code is pretty clear too: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ Yet users still want to use it. With the coming of OpenGL 3.0 and OpenGL ES and the lack of display lists and slow path support this is becoming even more of an issue. Something I've been planning on doing for a while is to move all vertex index support out of osg::Geometry to prevent this type of misuse of deprecated feature. Perhaps it's time for me to do it - support for reading old data files will be the awkward part. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org
Re: [osg-users] How to count polygons in view
Hello David, I will repeat what Robert already said, please use the Reply button in your mail client instead of starting a new message each time. This helps people keep track of what has been said before, and also allows you to keep the relevant parts of the previous message to give context to your replies, like this: Well, I need the polygons counts not the node counts. maybe I can count drawables or something like that. According the post I mentioned OSG has something built-in for it If you use a cull callback to know if a node was culled or not, you will know how many polygons are not culled, since if a Geode is not culled, then all its Drawables are not culled, and thus you can count the number of polygons in each Drawable. Also Vincent gave you an excellent suggestion, you can check out the code for the osgViewer::StatsHandler, it does exactly this and more. For an example, press 's' 4 times in osgviewer, and you will see what I mean. Move the camera around (to see part of the model or none of it in the view) and you will see the polygon counts change. 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
Re: [osg-users] msvc90 dependencies
Hi Sukender, Well, this can easily happen with mails, since we often write quite quickly (or well, at least *I* do answer often quickly, and I suppose that's the same for many!)... That and we're missing some vital information to be able to ascertain someone's tone (facial expressions, voice level, etc.) :-) 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
Re: [osg-users] Depth/Cull question
To NOT render a node and all its children simply set is Node mask to 0x0
to stop it being drawn, and set it 0xFFF and any value that results
in true when locial AND'ed cameras mask
As to alsway being drawn
1) Turn OSG culling of on the node
2) Place the node and its children in a render bin with a high number
like 100 or higher than any other you may be using.
This will make sure it is rendered last
node-setRenderBinDetails( 100,LastRenderBin);
3) If you want all of the geometry to be drawn then turn OFF the depth
test of for node and its children as shown below
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulrich
Hertlein
Sent: Wednesday, December 03, 2008 12:53 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Depth/Cull question
Hi Vincent,
Quoting Vincent Bourdier [EMAIL PROTECTED]:
I just need to set a node to be always rendered (or not).
It needs to not depend on the Zbuffer/culling.
...
*osg::ref_ptrosg::StateSet state = node-getOrCreateStateSet();*
*state-setMode(GL_CULL_FACE, osg::StateAttribute::ON);*
*osg::ref_ptrosg::Depth depth;*
*if(set){*
*depth = new osg::Depth(osg::Depth::ALWAYS, 0.0, 1.0);*
*state-setMode(GL_CULL_FACE,
osg::StateAttribute::OFF);*
*node-setCullingActive(false);*
*}else{*
*depth = new osg::Depth(osg::Depth::LEQUAL, 0.0, 1.0);*
*state-setMode(GL_CULL_FACE, osg::StateAttribute::ON);*
*node-setCullingActive(true);*
*}*
**
*state-setAttributeAndModes(depth.get(),
osg::StateAttribute::ON);*
Seems to me you're actually throwing different concepts into one bag:
- Zbuffer/depth test
- GL face culling
- OSG node culling
If I understand you correctly then you want to make sure a node is
always drawn irrespective of any objects that might be in front of it.
Simply turn of the depth test:
state-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF)
That might expose issues with the order in which objects are drawn - the
solution to that is RenderBins.
When you say always rendered *(or not)* (my emphasis) do you want to
turn it off completely?
Hope this helps,
Cheers,
/ulrich
___
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] msvc90 dependencies
Well, this can easily happen with mails, since we often write quite quickly (or well, at least *I* do answer often quickly, and I suppose that's the same for many!)... That and we're missing some vital information to be able to ascertain someone's tone (facial expressions, voice level, etc.) :-) You're right! From now, I'll fill my mails with plenty of stupid smileys and typos, as if I was a 14 years old analphabet chatting on intant messaging while listening to Crazy Frog: kikoo lol put1 tro mdr le keum lol lol lol ll :) :) :) :) :) =) XD :) !! allé @+ x15. (Note: I you don't understand french... well you miss nothing) A last one: :D Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth/Cull question
Hi, I know that I want to render some nodes without Z-buffer. It is a choice, implemented as a solution enabled ans disabled in real-time execution, when necessary. Sure there will be no nodes (clouds) over it. I know exactly what can be the associated problems. Near/Far calculation is already disabled , but the scene is big, so this is not a surprised that the culling have difficulties. So, to make a real No Z-buffer on some node, do you have any idea ? Thanks, Regards, Vincent. 2008/12/3 Jean-Sébastien Guay [EMAIL PROTECTED] Hi Vincent, My goal is to set this state in a callback, to allow changes when camera is near the plane : the culling is good without cheating... when camera is far from it, the culling/zbuffer makes stranges things, so I would make the necessary things to set the plane always visible... Setting the node to always render without the z-buffer is not a fix, it's a workaround. It will introduce other problems when something else (a cloud perhaps) is on top of the airplane. The result you're seeing is z-fighting, and is a result of poor z-buffer precision (you have too much distance between your near and far planes to have enough precision to represent the distance between two objects, so the z-buffer thinks object A is in front of object B when it's the opposite). The fix is to fix your z-buffer precision problem. Do you disable automatic near/far calculation? You probably should not, since this would make sure that your near plane is at the top of your airplane, and your far plane is below your ground. Or perhaps your ground is a very very large sphere where no part of the sphere can be culled away, so the far plane is actually behind the Earth (which is very far away relatively to the distance between the airplane and the ground)... Look into these problems, and you'll be able to fix the real problem. 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] msvc90 dependencies
The supreme shame is that I made a typo in my normal text... (I you don't understand = If...) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 4m 36 seconds!
Hi Guys, I've been done a few basic benchmarks today and was stunned to find far lower performance than on my older and slower quad core system, the cull and draw traversals being far longer. I've traced the problem back to cmake's release build options being blank on this machine - so release build was build without the usual -O3 option in place. I'm currently doing a rebuild to see what happens with manually putting -O3 in the CMAKE_CXX_FLAGS_RELEASE entry. The cmake version which I grabbed from the Kubuntu 8.10 repositories is cmake 2.6-patch 0, which on my older system I had compiled and and installed 2.6 path 1. I don't know yet whether this makes the difference. I'll go investigate on my other 8.10 systems. My quick look at benchmarking also hinted that hyper threading may be hurting performance, or at least the current CPU affinity strategy employed by osgViewer may be hurting performance on a hyper threading CPU. Until I get an optimitized build running I can't go investigate further. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAudio/OpenAL/osgAL
Hi Sukender,
I have got back to the VS-2003. And compile osgal by plain openal not soft.
But When I try to execute samples ( example osgal and etc) program can't
read wav data by using createSound function and catching error and exit
program.
I created dlls and libraries all of related stuff. But there is much
warnings about conversion one format to another ( float to double and etc )
while compiling vorbis source. Is this make sense my problem?
If you have any time, could you create an instruction step by step what did
you do and how can you execute osgAL because there much more omission in the
source code?
I will try to make work again. I don't know but I think I am a bit
impractical about this topic ;0
Best regards.
2008/12/3 Sukender [EMAIL PROTECTED]
Hi Ümit,
Well, for integration of audio in OSG I:
- Compiled OpenAL-Soft (even if you can use OpenAL)
- used freeALUT binaries
- Compiled ligOGG and libVorbis
- Compiled osgAL (uses FreeALUT and OpenAL/OpenAL-Soft and OGG/Vorbis)
I did't use the OpenAL SDK, so I guess this is not required (or maybe for
some special functions???). I can't tell you anything about OpenAL SDK and
its samples, nor about effects, sorry.
If you need my binaries (VC8 SP1), just ask me (maybe directly and not on
the mailing list until it's related to OSG).
PS: Remember to install SP1 for VC8 (or VC9) because .lib aren't
compatible between SP1 and non-SP1 versions.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Wed, 03 Dec 2008 10:32:09 +0100, Ümit Uzun [EMAIL PROTECTED] a
écrit:
Hi Sukender,
Thanks for confirmed message about Platform SDK. It really help me
because I
haven't tried express edition yet.
I have an question about Effects. After installation OpenAL Sdk 1.1 there
is
some samples and all of them using Framework library. Can we use effects
using plain alut functions? Do we really need this framework? I have
tried
to implement alut functions but there is a definition problem about
external
functions ( alEffects, alFilters and etc ) in Framework.h
Any though?
Regards.
2008/12/2 Sukender [EMAIL PROTECTED]
Just a quick note: if you use VC8, you'll need the Platform SDK (free).
I'm
not sure but I guess VC9 does not need it since it's included (to be
confirmed).
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 16:55:00 +0100, Ümit Uzun [EMAIL PROTECTED] a
écrit:
Hi Sukender,
Thanks for your researching. As you say, I will install express
edition
visual studio 2005.
Regards,
2008/12/2 Sukender [EMAIL PROTECTED]
Hi Ümit,
This is a variadic macro. This is not in the C++ standard, as far as
I
know. I use VC8 (2005) Express and have no problem with it. This
macro
seems
tu be used only for debugging (?), so maybe this could be removed on
compilers that don't support it? Anyway, you should use VC8 since
there
are
some useful improvements. Tell me about your progress on that topic.
See http://en.wikipedia.org/wiki/Variadic_macro
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 16:07:49 +0100, Ümit Uzun [EMAIL PROTECTED]
a
écrit:
Hi Sukender,
I have tried to compile openal-soft but there is strange error
about
#define
AL_PRINT(...) do { pattern. Do you think it's right declaration?
It
is
seen
me odd.
Errors are :
error C2010: '.' : unexpected in macro formal parameter list
error C2065: '__VA_ARGS__' : undeclared identifier
Should I declare something? I am using VS-2003 and Cmake-2.6.
Regards.
2008/12/2 Sukender [EMAIL PROTECTED]
Hi Stephan,
Thanks a lot for testing.
I'll ask the OpenAL-soft author about what you say and give you
feedback.
However, if you can say where (= line code) the problem arises,
that
would
be very useful I think.
Yes, OpenAL is part of the system, but the main goal here (about
using
OpenAL-Soft instead of OpenAL) is just to ensure we have an unique
library
that:
- works correctly across platforms (= the same ones as OSG does)
- is maintained
- evolves
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
Le Tue, 02 Dec 2008 15:26:06 +0100, Stephan Maximilian Huber
[EMAIL PROTECTED] a écrit:
Sukender schrieb:
Hi all,
This is only partially related to OSG, so I'll make it short:
In order to make an osgAudio layer and a corresponding plugin
based
on
OpenAL-Soft and osgAL, there is some need for testing and/or
development.
1. Anyone that can help testing OpenAL-Soft on following
platforms
may
mail me or openal-devel mailing list (
Re: [osg-users] flt-exporter: Index out ofrangeinVertexPaletteManager
Hi Gordon, On Wed, Dec 3, 2008 at 2:18 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: I know in our case we use vertex index arrays out of need, we have so much vertex data and have to share that many times that in our use cases we simply cannot have duplicate data , we simply cannot afford the memory bloat this would cause It may be a false economy though... as display listing will be duplicating the vertex data to be able to put in a form that the hardware can digest, so you may be just moving the memory problems elsewhere. While understand for many using osg::DrawElements*() is the best approach, that should not preclude others that need The older functionality. I certainly for one would not want this removed from osg::Geometry this is simply a critical need for us My thought is to move the vertex indexing support to a subclass of osg::Geometry, perhaps place it out in osgSim as another hint that it's not core functionality. I don't plan on dropping the support completely for platforms that support it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] msvc90 dependencies
Hi Guys, On Wed, Dec 3, 2008 at 2:28 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Sukender, Well, this can easily happen with mails, since we often write quite quickly (or well, at least *I* do answer often quickly, and I suppose that's the same for many!)... That and we're missing some vital information to be able to ascertain someone's tone (facial expressions, voice level, etc.) :-) Can we stop all the kiss and make up nonsense, next we'll be wearing flowers in our hair and listening to girly pop. I think what we really need is an osgflamefest example that we can put sparring partners in for a few rounds, and let the rest of cheer the blood letting for the sidelines on! Robert @ (my best attempt at a flower in the hair smiley ;-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] msvc90 dependencies
Hi Robert, Can we stop all the kiss and make up nonsense Hey, come on, we're just trying to be friendly... 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
Re: [osg-users] CompositeViewer views rendering order
Hi Sebastien, The Camera::setRenderOrder(RenderOrder,int) method controls the rendering order that cameras are rendering in. If you have just one camera active per view then you'd use something like: v1-getCamera()-setRenderOrder(osg::Camera::PRE_RENDER); v2-getCamera()-setRenderOrder(osg::Camera::POST_RENDER); // or... v1-getCamera()-setRenderOrder(osg::Camera::NESTED_RENDER,0); v2-getCamera()-setRenderOrder(osg::Camera::NEDTED_RENDER,1); The rendering ordered PRE_RENDER negative to positive, NESTED_RENDER negative to positive, POST_RENDER negative to positive. Robert. On Wed, Dec 3, 2008 at 2:45 PM, Sebastien Roy [EMAIL PROTECTED] wrote: Hi everyone, Does anyone know what exactly determines the rendering order of the views in a CompositeViewer? This is important in my case because I intend to have the various viewports overlap. Clearly, the original rendering order follows the order of the addView(). But if you later change the list order, say by using removeView() and then addView() again, the order is changed in the list of views but not in the rendering order. This is unexpected. Then, how can I dynamically change the rendering order of the views? This might relate to the following observation: Say I have two views v1,v2 added to a Compositeviewer cv: osg::ref_ptrosgViewer::View v1 = new osgViewer::View; osg::ref_ptrosgViewer::View v2 = new osgViewer::View; ... cv-addView(v1.get()); cv-addView(v2.get()); ... When I remove a view later, say cv-removeView(v1.get()), any ongoing animation freezes in place but the view still gets rendered, until I explicitely destroy it (v1=NULL), or until there is any input event in the CompositeViewer window (immediately crashing osg). Thank in advance for comments or suggestions, Regards, Sébastien ___ 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] msvc90 dependencies
On Wed, Dec 3, 2008 at 3:11 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Robert, Can we stop all the kiss and make up nonsense Hey, come on, we're just trying to be friendly... And I was only joking... or at least trying to... But now you are picking on ME, WHAT IS YOUR PROBLEM!!! ;-) Trying hard not to take oneself too seriously xxx Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Not using display list our data is too dynamic Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 10:04 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, On Wed, Dec 3, 2008 at 2:18 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: I know in our case we use vertex index arrays out of need, we have so much vertex data and have to share that many times that in our use cases we simply cannot have duplicate data , we simply cannot afford the memory bloat this would cause It may be a false economy though... as display listing will be duplicating the vertex data to be able to put in a form that the hardware can digest, so you may be just moving the memory problems elsewhere. While understand for many using osg::DrawElements*() is the best approach, that should not preclude others that need The older functionality. I certainly for one would not want this removed from osg::Geometry this is simply a critical need for us My thought is to move the vertex indexing support to a subclass of osg::Geometry, perhaps place it out in osgSim as another hint that it's not core functionality. I don't plan on dropping the support completely for platforms that support it. Robert. ___ 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] KDTree Picking (at an angle)
Robert,
I will see if I can repro the problem with osgpick and send you the osg
file. It may take me a week or two though as I've got a lot on my plate ;-)
cheers,
sean
On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]wrote:
Hi Sean,
This sounds like a bug, but without a dataset and example that
reproduces the problem it's next to impossible to home in on a fix.
Would it be possible for you to provide a problem dataset that
illustrates the problem? If it can be reproduced with one of the
existing examples like osgpick then this will make it easier to track
down.
Robert.
On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
wrote:
Hi Gang,
I'm working on improving picking performance via KDTree, but I'm hitting
an
issue that is driving me nuts: If I pick a node from directly above (e.g.
+
Z axis) everything works great, and picking is *very* fast. If I pick at
an
angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate -
nodes
to the left, right, top, or bottom get picked instead of what I'm after.
Here is my KDTree Build function:
#ifdef USE_KDTREE
// Update the KDTree
osg::KdTree::BuildOptions kdTreeBuildOptions;
osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
if(kdTree-build(kdTreeBuildOptions, geometry))
{
geometry-setShape(kdTree.get());
}
else
{
LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.;
}
#endif
Any suggestions?
cheers,
sean
___
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] Cmake-2.6-patch 0 optimisation problems
HI All, I've been testing my newly built Intel Core i7/X58/Kubuntu 8.10 system and found that OSG performance was around 1/3rd of what I expected, and have traced the cause of this down to the cmake-2.6.0 (2.6 patch 0) that I installed from the Ubuntu repositories. The specific problem is that Cmake is defaulting to a blank entry for CMAKE_CXX_FLAGS_RELEASE, something that normally reads -O3 -DNDEBUG, to see the value run ccmake . and then press 't' to get the advanced options. Manually setting CMAKE_CXX_FLAGS_RELEASE to -O3 -DNDEBUG fixed the performance problem with the Release build. I have also pulled down cmake 2.6.2 from the cmake website, built and installed it and this version of Cmake sets up the expect value for CMAKE_CXX_FLAGS_RELEASE so they have fixed this bug. I don't know whether this bug is just specific to my process architecture, or whether its just an issue with the Ubuntu repositories version of CMake 2.6.0, but there is a good chance that the problem affects more platforms and Cmake versions. Could users check their CMAKE_CXX_FLAGS_RELEASE value and report this value along with cmake version, source of your cmake version and platform details. Once we have a pattern of what is cmake versions/platforms this problem we can post an advisory on the wiki, and perhaps see if we can get the repositories updated. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Attaching Nodes (Characters Objects)
Rusty, Here's my take on what you intend to do. You are using one of the latest developer versions of OSG or even the SVN version. Skinned mesh support is part of the osgAnimation nodekit which was recently integrated with OSG. OK, so you load an .osg or .ive model that contains skinned mesh information with animations. Just out of interest what tool/exporter did you use to generate the model? You need to find the node of interest probably by name (e.g. right hand). This is best done with a nodevisitor. See the FindNamedNodeVisitor in example osgplanets. This visitor will find the osgAnimation::Bone that you prepared for attachment. If the node is found you can simply attach your object (e.g. a weapon) by adding the model to attach as a child of that node. If this bone is the correct attachment point all is well, but possibly you need to apply an extra offset transform to correctly position the model w.r.t. the hand. -- Roland From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Morris Sent: woensdag 3 december 2008 0:01 To: OpenSceneGraph Users Subject: Re: [osg-users] Attaching Nodes (Characters Objects) It's a skinned mesh with bones. This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Hi Robert Short answer is yes we get acceptable rates (through hard work :)) using geometries with indexed array's, Basically we have a terrain handling system that is capable of handling the world and doing this on the fly from elevation sources such as DTED 1/2/3 sub meter Lidar data etc and a system that matches this to very hi-resolution satellite imagery again up to world coverage, our system handles the reading, conversion, paging, LODing etc. this is all on the fly from the raw data ( or saved of cached from our paging system ) so basically the amount of data we can be handling is in the hundreds of millions and more of points and tri's and terra bytes of imagery, Of course this is not all on the card or in memory we HAVE to manage that :), but the nature of what we do having to be live ( for many) on data that's maybe minutes old for many users means we have to be very dynamic in our data handling, The faster paths would be great but in our case not a reality at this time for us We get acceptable rates we don't need 60hz we can live with 15-20 and thus we have built in checks to ensure we meet those by using our dynamic on the fly loading system complexity handling ( also depends on how much data the uses is throwing at us at any one time) So we build out geometry on the fly using arrays that are stored in our fast large paging system as they are read and then feed to geometries with LODS that have do all the normal stitch to lower levels LODS etc now we don't change every ting every frame ( we used have a total CLOD solution but that has other limitations) but have no guarantee on the life of an thing in the scene :) Currently the only data that goes thru the normal OSG read node mode is some of feature data that has models, and next year we hope to add feature data to our paging and memory handling systems so the we will be able to handle much more feature data to match out elevation and imagery capabilities etc for us right now we havie something that works and down the road I'm know we will look to improve things adopt newer higher performance ways were possible Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 10:37 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, On Wed, Dec 3, 2008 at 3:25 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Not using display list our data is too dynamic So you have a large amount of data being sent to the graphics card each frame with glBegin/glVertex/glEnd? Does it performance acceptably? How much data are we talking about here? Robert. ___ 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] Depth/Cull question
2008/12/3 Tomlinson, Gordon [EMAIL PROTECTED]
To NOT render a node and all its children simply set is Node mask to 0x0
to stop it being drawn, and set it 0xFFF and any value that results
in true when locial AND'ed cameras mask
As to alsway being drawn
1) Turn OSG culling of on the node
2) Place the node and its children in a render bin with a high number
like 100 or higher than any other you may be using.
This will make sure it is rendered last
node-setRenderBinDetails( 100,LastRenderBin);
3) If you want all of the geometry to be drawn then turn OFF the depth
test of for node and its children as shown below
Hmm, I use this code :
*osg::ref_ptrosg::StateSet state = node-getOrCreateStateSet();
node-setCullingActive(false);
state-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
state-setRenderBinDetails(1000, RenderBin);*
and nothing happen...
It is not my lucky day today...
Thanks.
Regards,
Vincent.
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulrich
Hertlein
Sent: Wednesday, December 03, 2008 12:53 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Depth/Cull question
Hi Vincent,
Quoting Vincent Bourdier [EMAIL PROTECTED]:
I just need to set a node to be always rendered (or not).
It needs to not depend on the Zbuffer/culling.
...
*osg::ref_ptrosg::StateSet state = node-getOrCreateStateSet();*
*state-setMode(GL_CULL_FACE, osg::StateAttribute::ON);*
*osg::ref_ptrosg::Depth depth;*
*if(set){*
*depth = new osg::Depth(osg::Depth::ALWAYS, 0.0, 1.0);*
*state-setMode(GL_CULL_FACE,
osg::StateAttribute::OFF);*
*node-setCullingActive(false);*
*}else{*
*depth = new osg::Depth(osg::Depth::LEQUAL, 0.0, 1.0);*
*state-setMode(GL_CULL_FACE, osg::StateAttribute::ON);*
*node-setCullingActive(true);*
*}*
**
*state-setAttributeAndModes(depth.get(),
osg::StateAttribute::ON);*
Seems to me you're actually throwing different concepts into one bag:
- Zbuffer/depth test
- GL face culling
- OSG node culling
If I understand you correctly then you want to make sure a node is
always drawn irrespective of any objects that might be in front of it.
Simply turn of the depth test:
state-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF)
That might expose issues with the order in which objects are drawn - the
solution to that is RenderBins.
When you say always rendered *(or not)* (my emphasis) do you want to
turn it off completely?
Hope this helps,
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
ghttp://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] Bad Link on SkewMatrix age
On page http://www.skew-matrix.com/OSGQSG/ the contact link is http://www.skew-matrix.com/OSGQSG/..%5Ccontact.html it should be http://www.skew-matrix.com/contact.html In addition the contact.html page's submit produces a page containing: Sorry You entered an incorrect security code. So, I guess that is broken also. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Hi Gordon, If you data is regular grids then you may well be able to use osgTerrain and have it build the geometry at the resolution you required. osgTerrain::TerrainTile uses vertex arrays, draw elements indexing and VBO's. The algorithm used for generating the geometry is still in it's infancy so doesn't do any fancy downsampling - just straight decimation, but it's produces pretty reasonable results as is so is usable for most purposes. VirtualPlanetBuilder when used with the --terrain spits out database that are stored with osgTerrain::TerrainTile's instead of traditional polygonal data. It's already generated multi-terrabyte databases that can be browsed online at a solid 60Hz with the standard osgviewer. The nice thing about using osgTerrain::TerrainTile's is that as we update the implementation in osgTerrain over time the rendering quality and speed will only improve without the need for rebuilding the database. Given the above example that already works I would have though a system could be built that pulls in other types of data and have custom reader build osgTerrain::TerrainTile based tiles from this data, and let osgTerrain build the geometry for you. This might not be possible in your case, but it's certainly doable. Robert. On Wed, Dec 3, 2008 at 4:19 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Hi Robert Short answer is yes we get acceptable rates (through hard work :)) using geometries with indexed array's, Basically we have a terrain handling system that is capable of handling the world and doing this on the fly from elevation sources such as DTED 1/2/3 sub meter Lidar data etc and a system that matches this to very hi-resolution satellite imagery again up to world coverage, our system handles the reading, conversion, paging, LODing etc. this is all on the fly from the raw data ( or saved of cached from our paging system ) so basically the amount of data we can be handling is in the hundreds of millions and more of points and tri's and terra bytes of imagery, Of course this is not all on the card or in memory we HAVE to manage that :), but the nature of what we do having to be live ( for many) on data that's maybe minutes old for many users means we have to be very dynamic in our data handling, The faster paths would be great but in our case not a reality at this time for us We get acceptable rates we don't need 60hz we can live with 15-20 and thus we have built in checks to ensure we meet those by using our dynamic on the fly loading system complexity handling ( also depends on how much data the uses is throwing at us at any one time) So we build out geometry on the fly using arrays that are stored in our fast large paging system as they are read and then feed to geometries with LODS that have do all the normal stitch to lower levels LODS etc now we don't change every ting every frame ( we used have a total CLOD solution but that has other limitations) but have no guarantee on the life of an thing in the scene :) Currently the only data that goes thru the normal OSG read node mode is some of feature data that has models, and next year we hope to add feature data to our paging and memory handling systems so the we will be able to handle much more feature data to match out elevation and imagery capabilities etc for us right now we havie something that works and down the road I'm know we will look to improve things adopt newer higher performance ways were possible Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 10:37 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, On Wed, Dec 3, 2008 at 3:25 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Not using display list our data is too dynamic So you have a large amount of data being sent to the graphics card each frame with glBegin/glVertex/glEnd? Does it performance acceptably? How much data are we talking about here? Robert. ___ 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 ___ osg-users mailing list
[osg-users] OSGQSG: Error
http://www.skew-matrix.com/OSGQSG/
p37, Memeory Management Examples.
Misspelled Memory in the errata.
-
p37, Memory Management Examples.
There are multiple solutions to the dilemma of how to return a Referenced object
address. The method employed in this book's example code is to return
a ref_ptr
storing the address, as the code below illustrates.
osg::ref_ptrosg::Group createGroup()
{
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address. This stores the Group
// address in a ref_ptr and places the ref_ptr on the
// call stack as the return value.
return grp.get();
}
Why is it
return grp.get();
rather than
return grp;
Isn't grp.get() a pointer to an osg::Group?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Unfortunately for our use cases VirtualPlanetBuilder is not a usable solution The key is for us is ours is done on the FLY ( for most users) and with live data is not at that time gridded (we do that on the fly as art of our process) Most of our users simply cannot use pre-built data they live in different world to traditional vis-sim where their source data changes daily, hourly and in many cases has live feeds Many of our users also have no write permissions apart from the temp dir And because of certain operations and calculations that are done on our data we have to have very precise control of what happens and what we return. ( cannot say much on this sadly due to the nature of the tools) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 11:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, If you data is regular grids then you may well be able to use osgTerrain and have it build the geometry at the resolution you required. osgTerrain::TerrainTile uses vertex arrays, draw elements indexing and VBO's. The algorithm used for generating the geometry is still in it's infancy so doesn't do any fancy downsampling - just straight decimation, but it's produces pretty reasonable results as is so is usable for most purposes. VirtualPlanetBuilder when used with the --terrain spits out database that are stored with osgTerrain::TerrainTile's instead of traditional polygonal data. It's already generated multi-terrabyte databases that can be browsed online at a solid 60Hz with the standard osgviewer. The nice thing about using osgTerrain::TerrainTile's is that as we update the implementation in osgTerrain over time the rendering quality and speed will only improve without the need for rebuilding the database. Given the above example that already works I would have though a system could be built that pulls in other types of data and have custom reader build osgTerrain::TerrainTile based tiles from this data, and let osgTerrain build the geometry for you. This might not be possible in your case, but it's certainly doable. Robert. On Wed, Dec 3, 2008 at 4:19 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Hi Robert Short answer is yes we get acceptable rates (through hard work :)) using geometries with indexed array's, Basically we have a terrain handling system that is capable of handling the world and doing this on the fly from elevation sources such as DTED 1/2/3 sub meter Lidar data etc and a system that matches this to very hi-resolution satellite imagery again up to world coverage, our system handles the reading, conversion, paging, LODing etc. this is all on the fly from the raw data ( or saved of cached from our paging system ) so basically the amount of data we can be handling is in the hundreds of millions and more of points and tri's and terra bytes of imagery, Of course this is not all on the card or in memory we HAVE to manage that :), but the nature of what we do having to be live ( for many) on data that's maybe minutes old for many users means we have to be very dynamic in our data handling, The faster paths would be great but in our case not a reality at this time for us We get acceptable rates we don't need 60hz we can live with 15-20 and thus we have built in checks to ensure we meet those by using our dynamic on the fly loading system complexity handling ( also depends on how much data the uses is throwing at us at any one time) So we build out geometry on the fly using arrays that are stored in our fast large paging system as they are read and then feed to geometries with LODS that have do all the normal stitch to lower levels LODS etc now we don't change every ting every frame ( we used have a total CLOD solution but that has other limitations) but have no guarantee on the life of an thing in the scene :) Currently the only data that goes thru the normal OSG read node mode is some of feature data that has models, and next year we hope to add feature data to our paging and memory handling systems so the we will be able to handle much more feature data to match out elevation and imagery capabilities etc for us right now we havie something that works and down the road I'm know we will look to improve things adopt newer higher performance ways were possible Gordon __ Gordon
Re: [osg-users] OSGQSG: Error
Misspelled Memory in the errata. Fixed, thanks. Why is it return grp.get(); rather than return grp; Isn't grp.get() a pointer to an osg::Group? osg::ref_ptr has a constructor that takes an address. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer views rendering order
Thanks Robert,
Using -setRenderOrder() does fix the problem, but only partially.
Now the rendering of overlapping viewports is displayed correctly, but
the mouse input events still go to the first added view.
Actually, the composite viewer process events in the order of cameras of
the GraphicsWindow, not to its own list of views. If you change the
order of the cameras there, then you can make any camera the top one
for input:
osg::Camera* mycam = ... (this is the camera I want on top for input
purposes)
// get the graphics window (in my case, a simple single shared context)
osgViewer::ViewerBase::Contexts contexts;
osg-viewer-getContexts(contexts);
osgViewer::GraphicsWindow* gw =
dynamic_castosgViewer::GraphicsWindow*(contexts[0]);
// remove the camera and then add it at the back of the list
osg::GraphicsContext::Cameras cameras = gw-getCameras();
for(osg::GraphicsContext::Cameras::iterator itr = cameras.begin(); itr !
= cameras.end(); ++itr) {
if( *itr == mycam ) {
cameras.erase(itr);cameras.push_back(mycam);break;
}
}
So I guess changing the order of the views, both for input and
rendering, is just a matter of changing the order of the cameras of a
GraphicsWindow. There is a renderOrder mechanism for rendering, but no
similar inputOrder mechanism... shoud there be one?
In any case, is my solution reasonable?
Sebastien
Le mercredi 03 décembre 2008 à 15:17 +, Robert Osfield a écrit :
Hi Sebastien,
The Camera::setRenderOrder(RenderOrder,int) method controls the
rendering order that cameras are rendering in. If you have just one
camera active per view then you'd use something like:
v1-getCamera()-setRenderOrder(osg::Camera::PRE_RENDER);
v2-getCamera()-setRenderOrder(osg::Camera::POST_RENDER);
// or...
v1-getCamera()-setRenderOrder(osg::Camera::NESTED_RENDER,0);
v2-getCamera()-setRenderOrder(osg::Camera::NEDTED_RENDER,1);
The rendering ordered PRE_RENDER negative to positive, NESTED_RENDER
negative to positive, POST_RENDER negative to positive.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Not using display list our data is too dynamic Be advised that both glBegin/glEnd _and_ display lists are deprecated in OpenGL 3.0, and I can tell you from my exposure to the ARB that they will be removed in the OpenGL 3.1 spec.(*). Moving forward, the preferred method for dynamic data will be buffer objects with glMapBuffer or the new map sub-region functionality. The ARB defines deprecated as: * Not the optimal performing path -- use something else * Might not work properly with new functionality * (Obviously) could be removed in a future OpenGL release For all of these reasons, I'd prefer to see any new OSG development avoid the use of any deprecated OpenGL functionality. (*) Even after they are removed, you'll still be able to access the glBegin/glEnd and display lists features by restricting yourself to creating a 2.1-compatible context, or using extensions with a 3.1 (and beyond) context, but it's uncertain how long vendors will continue to provide this functionality. Presumably, not forever. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fancy window managers and their effect on performance and window behaviour
Hi All, Prior to building my new machine I've been a KDE 3.x user, and it's been a solid base for graphics work, the X11 window manager that comes with it works robustly and does what it's told and generally keeps out of the way - for a full screen visual simulation is just what you want. With building this new machine I've opted to try KDE 4.1 and experiment with the effect of the new fancy desktop effects. KDE 4.1 is still a bit buggy and lacking in a minor features, but not problematic enough for me to run back to KDE 3.x, and the more I use it the more I like it, both from a aesthetic as well as productivity standpoint. I'm not normal user though... I'm a 3D performance addict, it's my life... fancy desktop effects mean nothing to me if I don't get my solid 60Hz hertz on my biggest databases. My interest in trying out the new desktop effects isn't just a personal thing, all the latest major platforms are now employing desktop compositors, if I don't start exposing myself directly to this world then I won't be able to grok all the problems that end users have. So in I dive... but I'm not alone so I'd like feedback from others on how things are working out for you. My own observations so far is that there is significant performance hit - on a town model that I test against the peformance of my standard test path goes down from 360Hz to 256Hz with vysnc disabled. osgviewer cow.osg performance goes from Hz to 888Hz. This would suggest the extra frame time hit is between 1.1ms and 0.7ms which is pretty small in the grand scheme of things, but might be enough for you to miss frame. How are others fairing in the performance stakes with enable/disabling the desktop effects/compositors? The behavioural differences I've seen with moving to KDE 4.1 is that when I run osgviewer and toggle between fullscreen to windowed mode I don't see any window decoration on the window. This artefact occurs whether I enable desktop effects or not. This points to a basic difference in the way that the window manager is handling osgViewer's X11 calls/settings. We've seen others reporting problems under Gnome as well, so it's not just KDE 4.x that we've not performing perfectly on. I'm not an X11 expert, let alone up to speed on the specific requirements of the new window managers, so I need others more knowledgeable on the new X11 mechanisms we should be leverage to get things working sweetly both on older window managers as well as the new cutting edge ones. I've also read on osg-users suggestions about specific full screen modes, rather than the current windowless fullscreen that we currently leverage, so this is another facet that we could explore. For OSG-2.8 it'd be good to solve this windowing behaviour issues, but if we can scoop out some other features at the same time with much extra coding I'm open to suggestions. So please, feedback, how is your platform performing and behaving? Also do you know of any good online resouces that discuss details on how best to manage windowing in the presence of these new window managers? Thanks in advance for your feedback, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bad Link on SkewMatrix age
Interesting. The Skew Matrix web page is undergoing redesign, so stuff breaks periodically. Thanks for pointing these issues out. I'll have my webmaster take a look, because the HTML appears correct to me. If you start from the root page (www.skew-matrix.com), then click Contact Us, these problems do not appear. It's only an issue from the OSGQSG page. -Paul On page http://www.skew-matrix.com/OSGQSG/ the contact link is http://www.skew-matrix.com/OSGQSG/..%5Ccontact.html it should be http://www.skew-matrix.com/contact.html In addition the contact.html page's submit produces a page containing: Sorry You entered an incorrect security code. So, I guess that is broken also. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer views rendering order
Hi Sebastien,
You can disable whether a camera allows event focus using
Camera::setAllowEventFocus
In general if you have an app that has overlapping viewports then I
would tend to think perhaps separate views is not the most appropriate
usage of the viewer, perhaps using slave cameras (that has events
disabled) for the background would be the best route.
The other route if you really must use multiple views and each view
must really have some custom event focus scheme just go an implement
it yourself by subclassing form the view and overriding
eventTraversal().
Robert.
On Wed, Dec 3, 2008 at 4:56 PM, Sebastien Roy [EMAIL PROTECTED] wrote:
Thanks Robert,
Using -setRenderOrder() does fix the problem, but only partially.
Now the rendering of overlapping viewports is displayed correctly, but
the mouse input events still go to the first added view.
Actually, the composite viewer process events in the order of cameras of
the GraphicsWindow, not to its own list of views. If you change the
order of the cameras there, then you can make any camera the top one
for input:
osg::Camera* mycam = ... (this is the camera I want on top for input
purposes)
// get the graphics window (in my case, a simple single shared context)
osgViewer::ViewerBase::Contexts contexts;
osg-viewer-getContexts(contexts);
osgViewer::GraphicsWindow* gw =
dynamic_castosgViewer::GraphicsWindow*(contexts[0]);
// remove the camera and then add it at the back of the list
osg::GraphicsContext::Cameras cameras = gw-getCameras();
for(osg::GraphicsContext::Cameras::iterator itr = cameras.begin(); itr !
= cameras.end(); ++itr) {
if( *itr == mycam ) {
cameras.erase(itr);cameras.push_back(mycam);break;
}
}
So I guess changing the order of the views, both for input and
rendering, is just a matter of changing the order of the cameras of a
GraphicsWindow. There is a renderOrder mechanism for rendering, but no
similar inputOrder mechanism... shoud there be one?
In any case, is my solution reasonable?
Sebastien
Le mercredi 03 décembre 2008 à 15:17 +, Robert Osfield a écrit :
Hi Sebastien,
The Camera::setRenderOrder(RenderOrder,int) method controls the
rendering order that cameras are rendering in. If you have just one
camera active per view then you'd use something like:
v1-getCamera()-setRenderOrder(osg::Camera::PRE_RENDER);
v2-getCamera()-setRenderOrder(osg::Camera::POST_RENDER);
// or...
v1-getCamera()-setRenderOrder(osg::Camera::NESTED_RENDER,0);
v2-getCamera()-setRenderOrder(osg::Camera::NEDTED_RENDER,1);
The rendering ordered PRE_RENDER negative to positive, NESTED_RENDER
negative to positive, POST_RENDER negative to positive.
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] OSGQSG: Error
So when I see things like the following in the OSG code base is it wrong?
ApplicationUsage* ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
To me this looks like your first example.
// DON'T do this. It stores the address as the return value on
// the call stack, but when the grp ref_ptr goes out of
// scope, the reference count goes to zero and the memory is
// deleted. The calling function is left with a dangling
// pointer.
osg::Group* createGroup()
{
// Allocate a new Group node.
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address.
return grp.get();
}
Should it be as in the second example?
osg::ref_ptrosg::Group createGroup()
{
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address. This stores the Group
// address in a ref_ptr and places the ref_ptr on the
// call stack as the return value.
return grp.get();
}
In other words...
osg::ref_ptrosg::ApplicationUsage ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Hi Gordon, I intended to use VirtualPlanetBuilder as an example that building terrain on the fly and at extremely high resolution can be done on the fly using osgTerrain::TerrainTile. You needn't use VirtualPlanetBuidler at all, its the osgTerrain::TerrainTile that is all you need to leverage. As an example of how things scale, I've been able to work with VPB built database with a million vertices on screen running at a solid 60hz, with no frame drops, all with the database being read and geometry built on the fly. This example does illustrate that you can get good performance with dynamically generated database whilst using vertex buffer objects and OpenGL fast paths. Robert. On Wed, Dec 3, 2008 at 4:58 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Unfortunately for our use cases VirtualPlanetBuilder is not a usable solution The key is for us is ours is done on the FLY ( for most users) and with live data is not at that time gridded (we do that on the fly as art of our process) Most of our users simply cannot use pre-built data they live in different world to traditional vis-sim where their source data changes daily, hourly and in many cases has live feeds Many of our users also have no write permissions apart from the temp dir And because of certain operations and calculations that are done on our data we have to have very precise control of what happens and what we return. ( cannot say much on this sadly due to the nature of the tools) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 11:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, If you data is regular grids then you may well be able to use osgTerrain and have it build the geometry at the resolution you required. osgTerrain::TerrainTile uses vertex arrays, draw elements indexing and VBO's. The algorithm used for generating the geometry is still in it's infancy so doesn't do any fancy downsampling - just straight decimation, but it's produces pretty reasonable results as is so is usable for most purposes. VirtualPlanetBuilder when used with the --terrain spits out database that are stored with osgTerrain::TerrainTile's instead of traditional polygonal data. It's already generated multi-terrabyte databases that can be browsed online at a solid 60Hz with the standard osgviewer. The nice thing about using osgTerrain::TerrainTile's is that as we update the implementation in osgTerrain over time the rendering quality and speed will only improve without the need for rebuilding the database. Given the above example that already works I would have though a system could be built that pulls in other types of data and have custom reader build osgTerrain::TerrainTile based tiles from this data, and let osgTerrain build the geometry for you. This might not be possible in your case, but it's certainly doable. Robert. On Wed, Dec 3, 2008 at 4:19 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Hi Robert Short answer is yes we get acceptable rates (through hard work :)) using geometries with indexed array's, Basically we have a terrain handling system that is capable of handling the world and doing this on the fly from elevation sources such as DTED 1/2/3 sub meter Lidar data etc and a system that matches this to very hi-resolution satellite imagery again up to world coverage, our system handles the reading, conversion, paging, LODing etc. this is all on the fly from the raw data ( or saved of cached from our paging system ) so basically the amount of data we can be handling is in the hundreds of millions and more of points and tri's and terra bytes of imagery, Of course this is not all on the card or in memory we HAVE to manage that :), but the nature of what we do having to be live ( for many) on data that's maybe minutes old for many users means we have to be very dynamic in our data handling, The faster paths would be great but in our case not a reality at this time for us We get acceptable rates we don't need 60hz we can live with 15-20 and thus we have built in checks to ensure we meet those by using our dynamic on the fly loading system complexity handling ( also depends on how much data the uses is throwing at us at any one time) So we build out geometry on the fly using arrays that are stored in our fast large paging system as they are read and then feed to geometries
Re: [osg-users] OSGQSG: Error
Hi Fred,
Returning a C pointer is more flexible, and as long as ref counting is
managed cleanly everything works fine, so the
ApplicationUsage::instance() code you suggest is perfectly fine, and
avoids thrashing the reference count something that is helps on the
performance front.
One little change I'm slowly rolling out in the various singletons
that the OSG users is that I'm moving across to using the convention:
osg::ref_ptrApplicationUsage ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
The subtle thing here is that the code is passing back a reference to
the static ref_ptr rather than a ref_ptr like in your suggestion.
A subtle difference but really important in a couple of ways - first
up it avoid the thrashing of the ref count as no temporary ref_ptr
are passed around, second it allows uses to reassign the singleton's
static ref_ptr so you can manually delete the singleton or set an
custom objects in its place.
This trick is only appropriate for static ref_ptr object though, I
wouldn't advice this a general solution.
Robert.
On Wed, Dec 3, 2008 at 5:22 PM, Fred [EMAIL PROTECTED] wrote:
So when I see things like the following in the OSG code base is it wrong?
ApplicationUsage* ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
To me this looks like your first example.
// DON'T do this. It stores the address as the return value on
// the call stack, but when the grp ref_ptr goes out of
// scope, the reference count goes to zero and the memory is
// deleted. The calling function is left with a dangling
// pointer.
osg::Group* createGroup()
{
// Allocate a new Group node.
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address.
return grp.get();
}
Should it be as in the second example?
osg::ref_ptrosg::Group createGroup()
{
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address. This stores the Group
// address in a ref_ptr and places the ref_ptr on the
// call stack as the return value.
return grp.get();
}
In other words...
osg::ref_ptrosg::ApplicationUsage ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
___
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] OSGQSG: Error
So when I see things like the following in the OSG code base
is it wrong?
ApplicationUsage* ApplicationUsage::instance() {
static osg::ref_ptrApplicationUsage s_applicationUsage
= new ApplicationUsage;
return s_applicationUsage.get();
}
In the code above, s_applicationUsage is a static variable, not a local
variable allocated on the stack, so it does not go out of scope when
instance() returns. This is the classic singleton design pattern.
Contrast this with the code below, in which the grp variable is local,
allocated on the stack. It goes out of scope when createGroup() returns,
thus decrementing the ref count to zero, deallocating the memory, and
returning a dangling pointer.
To me this looks like your first example.
// DON'T do this. It stores the address as the return value
on // the call stack, but when the grp ref_ptr goes out of
// scope, the reference count goes to zero and the memory is
// deleted. The calling function is left with a dangling // pointer.
osg::Group* createGroup()
{
// Allocate a new Group node.
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address.
return grp.get();
}
Should it be as in the second example?
I hope that helps?
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outof rangeinVertexPaletteManager
One more question regarding the flt-exporter: I use the RT 3d Model viewer plugin for firefox to display flt-files in a browser. The background is black here. I don´t know if this is an error of that plugin, or if the GL_CLEAR_COLOR is not yet exported by the exporter. The primary third-party software used to test OSG's FLT exporter was MPI's Creator 3.0. I did have a subcontractor with access to some other FLT-reading software; don't recall the name of the package, but all software used was able to correctly display all test models we exported during development. If you'd like to email me your exported FLT file, I'd be happy to load it in Creator and send you a screen shot of what is displayed. This would tell us whether the problem is with the exporter or your software. (Note that another osg-users poster discovered that the OSG FLT exporter doesn't attempt to create unique record names, and this was causing problems with the third party FLT software that he was using. As the FLT exporter creates record names directly from Node names, the quick fix for this would be to write a NodeVisitor to unique-ify all the Node names just before you attempt to export the scene graph. It might be useful to add similar capability directly to the FLT exporter, but I'd like to see this as an option, as I don't feel the FLT exporter should take responsibility to make up record names that the calling application didn't specify. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] using picking
Hello ! So I'm new in OSG and I don't make a code about picking, for example:I'm load a object 3DS and would like use in this case , if anybody know ! please! Thanks , Claudio Rogerio ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using picking
Hi Claudio, Take a look at the example osgpick. Regards. On Wed, Dec 3, 2008 at 8:47 PM, Claudio Rogerio [EMAIL PROTECTED]wrote: Hello ! So I'm new in OSG and I don't make a code about picking, for example:I'm load a object 3DS and would like use in this case , if anybody know ! please! Thanks , Claudio Rogerio ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Christophe Loustaunau. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
To be honest OGL 3.0 is not on my horizon right now ( I know its there ) A lot of our customers are on base line machines with 7 year old cards such as NVIDIA Quadro4 700 XGL OpenGl 2.1 and 256mb is a luxury :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, December 03, 2008 12:11 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Not using display list our data is too dynamic Be advised that both glBegin/glEnd _and_ display lists are deprecated in OpenGL 3.0, and I can tell you from my exposure to the ARB that they will be removed in the OpenGL 3.1 spec.(*). Moving forward, the preferred method for dynamic data will be buffer objects with glMapBuffer or the new map sub-region functionality. The ARB defines deprecated as: * Not the optimal performing path -- use something else * Might not work properly with new functionality * (Obviously) could be removed in a future OpenGL release For all of these reasons, I'd prefer to see any new OSG development avoid the use of any deprecated OpenGL functionality. (*) Even after they are removed, you'll still be able to access the glBegin/glEnd and display lists features by restricting yourself to creating a 2.1-compatible context, or using extensions with a 3.1 (and beyond) context, but it's uncertain how long vendors will continue to provide this functionality. Presumably, not forever. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
E or . . . . . :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Bosse' Sent: Wednesday, December 03, 2008 2:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] aa On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ 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] aa
0xff (=16777215 = b = ...) PS: Morse code is not used anymore! PS2: When we'll reach zzz...zzz, then we'll know we're at least 26 fools :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 03 Dec 2008 21:02:57 +0100, Tomlinson, Gordon [EMAIL PROTECTED] a écrit: E or . . . . . :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Bosse' Sent: Wednesday, December 03, 2008 2:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] aa On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ 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] Request: bool Polytope.contains(another_polytope)
Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] aa
On Wed, 2008-12-03 at 21:09 +0100, Sukender wrote: 0xff (=16777215 = b = ...) PS: Morse code is not used anymore! PS2: When we'll reach zzz...zzz, then we'll know we're at least 26 fools :) Whatver, I'm not a fool. Shsh... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 03 Dec 2008 21:02:57 +0100, Tomlinson, Gordon [EMAIL PROTECTED] a écrit: E or . . . . . :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Bosse' Sent: Wednesday, December 03, 2008 2:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] aa On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ 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] Request: bool Polytope.contains(another_polytope)
Rather than asking Robert to implement this function you could implent it your self as you have the source and contribute it back to the OSG source and community for which we would all be grateful Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jefferson Pinheiro Sent: Wednesday, December 03, 2008 3:11 PM To: OpenSceneGraph Users Subject: [osg-users] Request: bool Polytope.contains(another_polytope) Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request: bool Polytope.contains(another_polytope)
Alas, I lack the knowledge to do that. On Wed, Dec 3, 2008 at 6:25 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Rather than asking Robert to implement this function you could implent it your self as you have the source and contribute it back to the OSG source and community for which we would all be grateful *Gordon* __ *Gordon Tomlinson* *Product Manager 3D **Email * : gtomlinson @ overwatch.textron.com __ *(C): (+1) 571-265-2612 (W)**: (+1) 703-437-7651* Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - *Master Tambo Tetsura* -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jefferson Pinheiro *Sent:* Wednesday, December 03, 2008 3:11 PM *To:* OpenSceneGraph Users *Subject:* [osg-users] Request: bool Polytope.contains(another_polytope) Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jefferson Pinheiro (51) 9192 3535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cmake-2.6-patch 0 optimisation problems
Hi Robert, Once we have a pattern of what is cmake versions/platforms this problem we can post an advisory on the wiki, and perhaps see if we can get the repositories updated. We could also show a warning on Configure if we detect that the CMake version is one of those that cause the problem. 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
Re: [osg-users] aa
On Wed, 2008-12-03 at 15:15 -0500, Jeremy Moles wrote: On Wed, 2008-12-03 at 21:09 +0100, Sukender wrote: 0xff (=16777215 = b = ...) PS: Morse code is not used anymore! PS2: When we'll reach zzz...zzz, then we'll know we're at least 26 fools :) Whatver, I'm not a fool. Shsh... Oh no, wait, wait. I just went backwards from F. That's no ood... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 03 Dec 2008 21:02:57 +0100, Tomlinson, Gordon [EMAIL PROTECTED] a écrit: E or . . . . . :) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Bosse' Sent: Wednesday, December 03, 2008 2:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] aa On Wed, Dec 3, 2008 at 4:37 AM, Ümit Uzun [EMAIL PROTECTED] wrote: I have though to send bbb before Robert but then think it might be seen foolish :) But Robert seems braver :) Congratulations! And it's my turn :) ccc 2008/12/3 Robert Osfield [EMAIL PROTECTED] On Wed, Dec 3, 2008 at 8:05 AM, Malcom Poiter [EMAIL PROTECTED] wrote: aaa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph .org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- It is only necessary to make war with five things: with the maladies of the body, with the ignorances of the mind, with the passions of the body, with the seditions of the city, with the discords of families. - Tacitus The desire for safety stands against every great and noble enterprise. - Tacitus Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Numquam ponenda est pluralitas sine necessitate. - William of Ockham ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
To be honest OGL 3.0 is not on my horizon right now ( I know its there ) A lot of our customers are on base line machines with 7 year old cards such as NVIDIA Quadro4 700 XGL OpenGl 2.1 and 256mb is a luxury :) A very decent card in its day. I think I have one in my collection! :-) Your dilemma sounds familiar. My previous employer also had customers with old hardware. As an engineer, my opinion of this was that it was OK, as long as they also never upgraded the software. But if they had maintenance contracts and expected to install and use new versions of our software product, eventually they would be forced into a hardware upgrade. We could not hold back new development because some maintenance customer with a Pentium Pro and TNT graphics card refused to purchase a new system. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerWX vs. osgPython 2.2.0
Hi Randolph,
seems that was missed out from wrapping ... I guess we have a 2.6.x
release next week out - please be patient :)
Hartmut
--
Dr. Hartmut Seichter
PhD (HKU), Dipl.-Ing. (BUW)
Post-Doctoral Fellow, HIT Lab NZ
+64 3 364 2987 Ext. 3078
http://www.hitlabnz.org/people/hse25
Randolph Fritz wrote:
When I try to run this (new) example with this (old) library under IDLE,
I get the following error in line 67:
AttributeError: 'PySwigObject' object has no attribute 'windowResize'
Followed by a crash
Line 67 is:
self.graphicswindow.getEventQueue().windowResize(0, 0, w, h)
Far as I can tell, this is correct. Did windowResize have a different
name in OSG 2.2.0?
Randolph
Platform Windows-XP-5.1.2600
Architecture ('32bit', 'WindowsPE')
Machine --
Python build ('r252:60911', 'Feb 21 2008 13:11:45')
Python compiler MSC v.1310 32 bit (Intel)
--
osg.osgGetLibraryName OpenSceneGraph Library
osg.osgGetVersion 2.2.0
osg.osgGetSOVersion 25
osg Python library location :
C:\Python25\lib\site-packages\osg-2.2.0-msw\osg.pyc
osg Dynamic linked library location : module '_osg' from
'C:\Python25\lib\site-packages\osg-2.2.0-msw\_osg.pyd'
--
osgDB.osgGetLibraryName OpenSceneGraph DB (Data Base)
Library
osgDB.osgGetVersion 2.2.0
osgDB Python library location:
C:\Python25\lib\site-packages\osg-2.2.0-msw\osgDB.pyc
osgDB Dynamic linked library location: module '_osgDB' from
'C:\Python25\lib\site-packages\osg-2.2.0-msw\_osgDB.pyd'
___
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] Cmake-2.6-patch 0 optimisation problems
Hi Robert, I have cmake-2.6.0. I had it before Intrepid; downloaded from cmake.org and it has the proper CMAKE_CXX_FLAGS_RELEASE (-O3 -NDEBUG). This suggests that the ubuntu archives might be the source of your problem. I - like you - also have cmake-2.6.2 installed with proper CMAKE_CXX_FLAGS_RELEASE. This too downloaded manually from cmake.org cheers Mattias On Wed, Dec 3, 2008 at 5:09 PM, Robert Osfield [EMAIL PROTECTED] wrote: HI All, I've been testing my newly built Intel Core i7/X58/Kubuntu 8.10 system and found that OSG performance was around 1/3rd of what I expected, and have traced the cause of this down to the cmake-2.6.0 (2.6 patch 0) that I installed from the Ubuntu repositories. The specific problem is that Cmake is defaulting to a blank entry for CMAKE_CXX_FLAGS_RELEASE, something that normally reads -O3 -DNDEBUG, to see the value run ccmake . and then press 't' to get the advanced options. Manually setting CMAKE_CXX_FLAGS_RELEASE to -O3 -DNDEBUG fixed the performance problem with the Release build. I have also pulled down cmake 2.6.2 from the cmake website, built and installed it and this version of Cmake sets up the expect value for CMAKE_CXX_FLAGS_RELEASE so they have fixed this bug. I don't know whether this bug is just specific to my process architecture, or whether its just an issue with the Ubuntu repositories version of CMake 2.6.0, but there is a good chance that the problem affects more platforms and Cmake versions. Could users check their CMAKE_CXX_FLAGS_RELEASE value and report this value along with cmake version, source of your cmake version and platform details. Once we have a pattern of what is cmake versions/platforms this problem we can post an advisory on the wiki, and perhaps see if we can get the repositories updated. 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
[osg-users] Node Kits for Charts Graphs
Can anyone tell me whether there are any node kits for OSG in existence that provide chart or graph capabilities? In particular I am mainly interested in 3D bar charts and if there was support for intersection (i.e mouse hovering) with displayed data Cheers _ Get Windows Live Messenger on your Mobile http://clk.atdmt.com/UKM/go/msnnkmgl001001ukm/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
Ah yes, static makes a world of difference. page 47 osg::ref_ptrosg::Geode geode0 = new osg::Geode; group-addChild( Geode0.get() ); osg::ref_ptrosg::Geode geode1 = new osg::Geode; group-addChild( Geode1.get() ); Upper case problem with Geode0 and Geode1. They should be geode0 and geode1. There were two cases of Memeory in the errata. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
Thanks! All memeory instances should be fixed. One of these days I'll have to find a free tool that spell checks HTML because I'm too cheap to buy one. Thanks for catching the capitalization issue on p47, this is added to the errata and changes in the master book source for a possible future reprinting. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Sent: Wednesday, December 03, 2008 2:17 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] OSGQSG: Error Ah yes, static makes a world of difference. page 47 osg::ref_ptrosg::Geode geode0 = new osg::Geode; group-addChild( Geode0.get() ); osg::ref_ptrosg::Geode geode1 = new osg::Geode; group-addChild( Geode1.get() ); Upper case problem with Geode0 and Geode1. They should be geode0 and geode1. There were two cases of Memeory in the errata. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node Kits for Charts Graph
Hi Simon, As far as I know, there isn't any special nodekit about chart or graph as you want. But you can create these processes easly using canned osg geometry ( coni, sphere, box and etc ) and using callback and update visitors to check if mouse cursor is on the desired chart or not and you can assign some operation when cursor hover the chart and etc. Hope this helps. Regards. 2008/12/3 Simon Sanderson [EMAIL PROTECTED] Can anyone tell me whether there are any node kits for OSG in existence that provide chart or graph capabilities? In particular I am mainly interested in 3D bar charts and if there was support for intersection (i.e mouse hovering) with displayed data Cheers -- Read amazing stories to your kids on Messenger. Try it Now!http://clk.atdmt.com/UKM/go/117588488/direct/01/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setUpdateOperations?
What are the UpdateOperations used for in the osgViewer::Viewer class? -B --- Brad Colbert Renaissance Sciences Corporation W: 480 374-5073 x:5073 F: 425 675-8044 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Calendar time in FrameStamp
Hi Robert -- There doesn't appear to be any code in the OSG distribution that sets or gets the calendar time in FrameStamp. Is this purely for application convenience? Applications can store any values they want in the tm struct? (The header comment says, Note the calendar time can be an artificial simulation time or capture the real time of day etc. The comment doesn't go into detail about how those options are set, but to me the comment seems to imply that FrameStamp (or something else in OSG) manages calendar time and can be configured for either of those options. But this is not the case from the code I've seen, so perhaps I'm misinterpreting it.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerWX vs. osgPython 2.2.0
Great! Will be waiting...
Randolph
On Dec 3, 2008, at 12:55 PM, Hartmut Seichter wrote:
Hi Randolph,
seems that was missed out from wrapping ... I guess we have a 2.6.x
release next week out - please be patient :)
Hartmut
--
Dr. Hartmut Seichter
PhD (HKU), Dipl.-Ing. (BUW)
Post-Doctoral Fellow, HIT Lab NZ
+64 3 364 2987 Ext. 3078
http://www.hitlabnz.org/people/hse25
Randolph Fritz wrote:
When I try to run this (new) example with this (old) library under
IDLE, I get the following error in line 67:
AttributeError: 'PySwigObject' object has no attribute
'windowResize'
Followed by a crash
Line 67 is:
self.graphicswindow.getEventQueue().windowResize(0, 0,
w, h)
Far as I can tell, this is correct. Did windowResize have a
different name in OSG 2.2.0?
Randolph
Platform
Windows-XP-5.1.2600
Architecture ('32bit', 'WindowsPE')
Machine --
Python build ('r252:60911', 'Feb 21 2008 13:11:45')
Python compiler MSC v.1310 32 bit (Intel)
--
osg.osgGetLibraryName OpenSceneGraph Library
osg.osgGetVersion 2.2.0
osg.osgGetSOVersion 25
osg Python library location : C:\Python25\lib\site-
packages\osg-2.2.0-msw\osg.pyc
osg Dynamic linked library location : module '_osg' from 'C:
\Python25\lib\site-packages\osg-2.2.0-msw\_osg.pyd'
--
osgDB.osgGetLibraryName OpenSceneGraph DB (Data
Base) Library
osgDB.osgGetVersion 2.2.0
osgDB Python library location: C:\Python25\lib\site-
packages\osg-2.2.0-msw\osgDB.pyc
osgDB Dynamic linked library location: module '_osgDB' from 'C:
\Python25\lib\site-packages\osg-2.2.0-msw\_osgDB.pyd'
___
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] 4m 36 seconds!
Hi Robert, Quoting Robert Osfield [EMAIL PROTECTED]: My quick look at benchmarking also hinted that hyper threading may be hurting performance, or at least the current CPU affinity strategy employed by osgViewer may be hurting performance on a hyper threading CPU. Until I get an optimitized build running I can't go investigate My take on hyper-threading was always to disable it, if enough (say = 4) cores are available. It's not a separate core after all and there is a certain amount of work involved to make one core look like two. Additionally: what is the communities' experience with manually assigning processes to cores? Does it work? It sounds like a good idea but in my experience it's best to leave the scheduling up to the operating system to handle core affinity (except when you're running Windows which has a completely fscked-up round-robin scheduler). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node Kits for Charts Graph
Simon, I just started lurking here, in the hopes of doing something similar. If something doesn't exist yet, perhaps we could discuss how to make this work? -Brent ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node Kits for Charts Graph
I've been toying with the idea of osgDiagram. I have created my own Edge node which links two geodes to create dynamic graphs. I definitely see scope for graphing capabilities in OSG and would be happy to contribute. Cheers, Paul -- Paul McIntosh www.internetscooter.com ---Original Message--- From: Brent Fulgham [EMAIL PROTECTED] Subject: Re: [osg-users] Node Kits for Charts Graph Sent: 04 Dec '08 11:43 Simon, I just started lurking here, in the hopes of doing something similar. If something doesn't exist yet, perhaps we could discuss how to make this work? -Brent ___ 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] Cmake-2.6-patch 0 optimisation problems
Hi, I have -O3 -DNDEBUG on Debian Sid 32-bit for CMAKE_CXX_FLAGS_RELEASE. cmake --help claims it is: cmake version 2.6-patch 0 The Debian package is 2.6.0-6 jp Robert Osfield wrote: HI All, I've been testing my newly built Intel Core i7/X58/Kubuntu 8.10 system and found that OSG performance was around 1/3rd of what I expected, and have traced the cause of this down to the cmake-2.6.0 (2.6 patch 0) that I installed from the Ubuntu repositories. The specific problem is that Cmake is defaulting to a blank entry for CMAKE_CXX_FLAGS_RELEASE, something that normally reads -O3 -DNDEBUG, to see the value run ccmake . and then press 't' to get the advanced options. Manually setting CMAKE_CXX_FLAGS_RELEASE to -O3 -DNDEBUG fixed the performance problem with the Release build. I have also pulled down cmake 2.6.2 from the cmake website, built and installed it and this version of Cmake sets up the expect value for CMAKE_CXX_FLAGS_RELEASE so they have fixed this bug. I don't know whether this bug is just specific to my process architecture, or whether its just an issue with the Ubuntu repositories version of CMake 2.6.0, but there is a good chance that the problem affects more platforms and Cmake versions. Could users check their CMAKE_CXX_FLAGS_RELEASE value and report this value along with cmake version, source of your cmake version and platform details. Once we have a pattern of what is cmake versions/platforms this problem we can post an advisory on the wiki, and perhaps see if we can get the repositories updated. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
