Re: [osg-users] Bounding Parallelepiped
Forgot to add: You also need the center of rotation, but I have assumed that this center point is already being stored as part of the data for the object from which the bounds are computed. If this is a standalone bounding box (for example, encapsulating a series of objects without a 'parent' object), then you would also require an additional 3D vector for the center point. -- Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuesz, Matthew Sent: Thursday, October 02, 2008 12:33 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped For the case of a non-world-aligned bounding box - but still one which is parallel-sided (i.e., a rectangular volume) - you actually do not need all eight corners. You only need the two opposite corners (as osg::BoundingBox uses) plus a rotation. Thus, you require either 5 3D vectors (2 corners + 3x3 rotation matrix) or 2 3D vectors and 1 4D vector (2 corners + rotation quaternion). For a completely arbitrary bounding volume (where no two sides are guaranteed to be the same size), however, all of the corners would be necessary. -- Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Thursday, October 02, 2008 12:26 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped How OSG uses is fine for how it is used But we were not talking about HOW OSG uses but how a someone would like a bounding box that is not necessary axially aligned and to have a box were all six sides can be of difference size thus no real correlation between corners you need the 8 corners provide by opposite sides you cannot derive these if there all different 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 Melis Sent: Thursday, October 02, 2008 12:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped Tomlinson, Gordon wrote: I disagree :) You need 8 vec3's to do that, you need the 4 corners of any 2 opposite sides of the bounding box in order to have every side a different size The osg::Bounding box only supplies 2 vec3's which effectively gives you 2 corner points and you cannot get the 8 corner points from 2, apart from a parallel rectangle ... But using 8 corner points is reduntant, as OSG uses _axis-aligned_ bounding boxes. Even in case you were using aligned bboxes you would only need 4 vec3's to represent a bounding box under any orientation (one vec3 for one of the corners + 3 * a vec3 for each sizes axis starting at the corner (and even the 3rd axis could be deduced from the other 2, except for its length)). Paul 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 Jean-Sébastien Guay Sent: Thursday, October 02, 2008 10:52 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped Hi Gordon, Unfortunately, OSG does not directly support what you want as osg'S bounding box, is as you have seen is a axially aligned min/max LL/UR That is not true. OSG's bounding box supports separate xmin/xmax, ymin/ymax, zmin/zmax values, so it can represent boxes that have different sizes on all axes. However, as Robert explained, OSG uses BoundingBox on Drawables, but BoundingSpheres on nodes. So if you just take the root node's bounding sphere and put that into a bounding box, of course you will get a bounding *cube*. ComputeBoundsVisitor is what you need. It will compute a minimal axis-aligned bounding box for all *drawables*, not using the bounding spheres. #include osg/ComputeBoundsVisitor osg::ComputeBoundsVisitor cbbv; node-accept(cbbv); osg::BoundingBox bb = cbbv-getBoundingBox(); It doesn't get much simpler than that. J-S
Re: [osg-users] Bounding Parallelepiped
For the case of a non-world-aligned bounding box - but still one which is parallel-sided (i.e., a rectangular volume) - you actually do not need all eight corners. You only need the two opposite corners (as osg::BoundingBox uses) plus a rotation. Thus, you require either 5 3D vectors (2 corners + 3x3 rotation matrix) or 2 3D vectors and 1 4D vector (2 corners + rotation quaternion). For a completely arbitrary bounding volume (where no two sides are guaranteed to be the same size), however, all of the corners would be necessary. -- Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Thursday, October 02, 2008 12:26 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped How OSG uses is fine for how it is used But we were not talking about HOW OSG uses but how a someone would like a bounding box that is not necessary axially aligned and to have a box were all six sides can be of difference size thus no real correlation between corners you need the 8 corners provide by opposite sides you cannot derive these if there all different 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 Melis Sent: Thursday, October 02, 2008 12:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped Tomlinson, Gordon wrote: I disagree :) You need 8 vec3's to do that, you need the 4 corners of any 2 opposite sides of the bounding box in order to have every side a different size The osg::Bounding box only supplies 2 vec3's which effectively gives you 2 corner points and you cannot get the 8 corner points from 2, apart from a parallel rectangle ... But using 8 corner points is reduntant, as OSG uses _axis-aligned_ bounding boxes. Even in case you were using aligned bboxes you would only need 4 vec3's to represent a bounding box under any orientation (one vec3 for one of the corners + 3 * a vec3 for each sizes axis starting at the corner (and even the 3rd axis could be deduced from the other 2, except for its length)). Paul 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 Jean-Sébastien Guay Sent: Thursday, October 02, 2008 10:52 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Bounding Parallelepiped Hi Gordon, Unfortunately, OSG does not directly support what you want as osg'S bounding box, is as you have seen is a axially aligned min/max LL/UR That is not true. OSG's bounding box supports separate xmin/xmax, ymin/ymax, zmin/zmax values, so it can represent boxes that have different sizes on all axes. However, as Robert explained, OSG uses BoundingBox on Drawables, but BoundingSpheres on nodes. So if you just take the root node's bounding sphere and put that into a bounding box, of course you will get a bounding *cube*. ComputeBoundsVisitor is what you need. It will compute a minimal axis-aligned bounding box for all *drawables*, not using the bounding spheres. #include osg/ComputeBoundsVisitor osg::ComputeBoundsVisitor cbbv; node-accept(cbbv); osg::BoundingBox bb = cbbv-getBoundingBox(); It doesn't get much simpler than that. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Smoothing camera movements from HMD's input
How fast does your HMD tracker update its orientation, and how are you retrieving these values? If you're not getting the values in realtime at least as fast as OSG is refreshing, then you would definitely have some jerky movements. And if you're not getting them this fast, then what are you interpolating between? If your HMD device is only operating at a fraction of the OSG update rate, then you need to be using predictive values, based on the last known trend deltas. You need to be careful here, as you are approaching territory where the view (OSG) lags noticeably behind the actual movement (HMD), which I would think would be rather undesirable. That is, the only way to interpolate between actual data is to wait after the fact; the only other alternative is to use predicted values to interpolate between until actual data is available - and this could also cause jerks, if the prediction period is too long, causing the actual position at the next timestep to be significantly different than the predicted one used for smoothing. I find it highly unlikely that your hardware would be returning values at less than 60 Hz (the typical target framerate for graphical applications), and that it is probably capable of much higher data rates. Thus, through a combination of efficient access to this data stream (orientations) and possibly capping the OSG framerate (think v-sync), I would expect that your HW/SW combination would be able to maintain a smooth motion without any trouble or additional smoothing. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of alessandro terenzi Sent: Tuesday, September 30, 2008 1:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Smoothing camera movements from HMD's input Yes, indeed I have a PositionAttitudeTransform node that represent my virtual camera, and whose attitude is set by HMD's data and later used to set the camera's view matrix just before calling viewer.frame(). So I thuoght to 'animate' the attitude instead of just setting values from HMD' tracker. On Tue, Sep 30, 2008 at 7:12 PM, Jim Brooks [EMAIL PROTECTED] wrote: In order to solve this problem, I was thinking about creating an animation path (on the fly) from a previously stored orientation to current head orientation. Is this the correct way to proceed? Or there is some other technique to smooth the resulting camera movements? osg::AnimationPath interpolates across rotations and positions (for smoothing). See examples/osganimate. ___ 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] shader or effect to show selected model
Color overlays are fairly simple. A one-line fragment shader: gl_FragColor = gl_Color * color_uniform; Where color_uniform is a vec4 uniform specifying RGBA color. This is the simplest of cases, of course. If you have other lighting or texturing going on, you would also need to account for that. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Morné Pistorius Sent: Tuesday, August 12, 2008 8:47 AM To: OpenSceneGraph Users Subject: Re: [osg-users] shader or effect to show selected model I did have a look at osgScribe before posting, but overlaying the wireframe is a bit heavy for models with very high polygon counts. I was looking for something a bit more subtle. Cheers, Morne On Tue, Aug 12, 2008 at 12:13 PM, Paul Melis [EMAIL PROTECTED] wrote: Morné Pistorius wrote: Hi everybody, I am looking for a bit of inspiration. I want to apply some sort of effect to a picked model in my scene to show that it has been selected. Does anyone have some ideas (or an example shader or code snippet would be excellent!) that they are willing to throw my way? Ideally I would like to have something that uses the geometry of the model itself, instead of creating new geometry. See the osgscribe example for a possible way... Paul Thanks! Regards, Morne ___ 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] Viewer/CompositeViewer
Slaves can be moved independently of the main camera by setting their reference frames to ABSOLUTE_RF. Otherwise, yes, they are offset from the main camera. Yes, slaves can either share the main graph or may have their own subgraphs. Typically, yes, though this all depends on what they're being used for. I have used a slave to provide an orthographic overlay (HUD) projection, which has its own unique subgraph. A single Viewer should be used when there is a single conceptual view, while CompositeViewer should be used when there is more than one. See the Viewer vs. Composite viewer programming guide on the OSG site for more discussion on this (including usage examples). Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 04, 2008 12:21 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Viewer/CompositeViewer I'm starting to convert several apps from OSG 1.X to the current release. I've read the posts regarding Viewer and CompositeViewer and want to make sure I'm understanding it right. If you don't mind a few beginner questions... 1) Viewer (which is a View) can have one or more Cameras, but if using multiple Cameras, they are positionally slaved to the single View Camera by offset matrices, right? 2) The slaved Cameras can share the subgraph (Scene) below the View Camera, but if desired, they could have their own subgraphs? 3) It seems that generally, since the slaves are offset from the View master camera, for most applications, they would share the same Scene, right? 4) CompositeViewer (which contains Views) can be more flexible since each View Camera can be independently positioned (i.e., different views of the same Scene, but where Camera 2 doesn't necessarily follow Camera 1). 5) The View(s) within a CompositeViewer could themselves be single-Camera or master-slave configurations. 6) It seems that a CompositeViewer with a few Views could be functionally equivalent to a Viewer with slave Cameras provided the user positions the CompositeViewer Views with respect to a designated master View in real-time? 7) I see some efficiencies, such as a master-slave View applying the Update traversal only once to the shared Scene. Are there any other significant benefits (e.g., cull, rendering, state) that make a Viewer master-slave setup more efficient than the equivalent manually-slaved Views in a CompositeViewer? Sorry for the length, but I hope this post might be useful to others just starting the 1.X to 2.X conversion. Thanks! Dan Guinther Looking for a car that's sporty, fun and fits in your budget? Read reviews on AOL Autos http://autos.aol.com/cars-BMW-128-2008/expert-review?ncid=aolaut0005000 017 . ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer/CompositeViewer
Whoops - forgot to include the numbers referencing the original email. Added them below. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuesz, Matthew Sent: Monday, August 04, 2008 12:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Viewer/CompositeViewer 1 - Slaves can be moved independently of the main camera by setting their reference frames to ABSOLUTE_RF. Otherwise, yes, they are offset from the main camera. 2 - Yes, slaves can either share the main graph or may have their own subgraphs. 3 - Typically, yes, though this all depends on what they're being used for. I have used a slave to provide an orthographic overlay (HUD) projection, which has its own unique subgraph. A single Viewer should be used when there is a single conceptual view, while CompositeViewer should be used when there is more than one. See the Viewer vs. Composite viewer programming guide on the OSG site for more discussion on this (including usage examples). Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 04, 2008 12:21 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Viewer/CompositeViewer I'm starting to convert several apps from OSG 1.X to the current release. I've read the posts regarding Viewer and CompositeViewer and want to make sure I'm understanding it right. If you don't mind a few beginner questions... 1) Viewer (which is a View) can have one or more Cameras, but if using multiple Cameras, they are positionally slaved to the single View Camera by offset matrices, right? 2) The slaved Cameras can share the subgraph (Scene) below the View Camera, but if desired, they could have their own subgraphs? 3) It seems that generally, since the slaves are offset from the View master camera, for most applications, they would share the same Scene, right? 4) CompositeViewer (which contains Views) can be more flexible since each View Camera can be independently positioned (i.e., different views of the same Scene, but where Camera 2 doesn't necessarily follow Camera 1). 5) The View(s) within a CompositeViewer could themselves be single-Camera or master-slave configurations. 6) It seems that a CompositeViewer with a few Views could be functionally equivalent to a Viewer with slave Cameras provided the user positions the CompositeViewer Views with respect to a designated master View in real-time? 7) I see some efficiencies, such as a master-slave View applying the Update traversal only once to the shared Scene. Are there any other significant benefits (e.g., cull, rendering, state) that make a Viewer master-slave setup more efficient than the equivalent manually-slaved Views in a CompositeViewer? Sorry for the length, but I hope this post might be useful to others just starting the 1.X to 2.X conversion. Thanks! Dan Guinther Looking for a car that's sporty, fun and fits in your budget? Read reviews on AOL Autos http://autos.aol.com/cars-BMW-128-2008/expert-review?ncid=aolaut0005000 017 . ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RE : Re: RE : Re: Converting a Drawable object to a Geometry object
The problem is that you are trying to cast a pointer to a base class to a pointer to a subclass. This would only work if the actual object being pointed to is an instance of that subclass (or a further subclass of that subclass). Geometry is derived from Drawable, not the other way around - which seems to be the mistake that you are making. Please refer to the inheritance diagrams for osg::Drawable and osg::Geometry. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Franclin Foping Sent: Thursday, July 31, 2008 7:17 AM To: OpenSceneGraph Users Subject: [osg-users] RE : Re: RE : Re: Converting a Drawable object to a Geometry object Hi Ulrich, I don't think you get the trick, from what you said, the only thing wrong is the ShapeDrawable. I will post a new issue in a short while which is not different from this post and you will see that even without using ShapeDrawable objects, the same issue still hang around. Just bear with me. Thanks for your help. Franclin. Ulrich Hertlein [EMAIL PROTECTED] a écrit : Hi Franclin, Downcasting from a derived class to a parent class is possible with the dynamic_cast operator. From what you have written in your mail, it looks like the snippet won't compile at all, I can bet something it will as I tried it a couple of hours ago. Try it yourself and let me know. The code is correct and will compile, it's just that the casts won't work as you expect. Okay, let's see: osg::Geode myGeode = new osg::Geode; myGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(osg::Vec3(),1,1,1))); osg::Drawable* myDrawable = myGeode-getDrawable(0); myDrawable is a Drawable* to a ShapeDrawable This is fine since Drawable is a base class of ShapeDrawable. (I assume there aren't any other Drawables in myGeode and the first one is actually the ShapeDrawable you added.) osg::Geometry* myGeom = myDrawable-asGeometry(); If you take a look at 'osg::Drawable' you'll see that this actually *always* returns 0 and ShapeDrawable doesn't override it (Geometry is the only class that overrides it). However, even doing what the comment says (and what you're doing for 'myGeom2'): osg::Geometry* geom = dynamic_cast(this) This cannot succeed since the *object* is-a ShapeDrawable (even though the pointer is Drawable*). Of course, downcasting from shapedrawable to geometry would have not worked and even worse would have not compiled at all. Agreed. But introducing a Drawable* doesn't help because it doesn't change the type of the object the pointer is pointing to. ShapeDrawable* shape = new ShapeDrawable(...) Drawable* drawable = dynamic_cast(shape); // OK, is a base class Geometry* geom = dynamic_cast(drawable); // is always 0 I'm probably not explaining this as clearly as possible but try to think of it this way: you have a base class 'Vehicle' and two derived classes 'Car' and 'Plane'. You can create a 'Plane' and have a 'Vehicle' pointer to it but you can't cast that pointer to a 'Car'. Hope this helps. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Envoyé avec Yahoo! Mail http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http:/us.rd.yahoo.com/evt=52423/*http:/fr.docs.yahoo.com/mail/overview/index.html . Une boite mail plus intelligente. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RE : Re: Getting texture coordinates of loadedmodels
A prime example of an incredibly useful non-Geometry Drawable is Text. Nodes which draw or otherwise display text are not Geometry, but are definitely still drawables. And as Gordon mentioned, there is always the opportunity for user-defined Drawables which implement their own raw OpenGL calls for custom draw capabilities. Reviewing the source and reference guides (doxygen) would easily answer all of the questions brought up in these two threads. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Thursday, July 31, 2008 10:11 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] RE : Re: Getting texture coordinates of loadedmodels A drawable does not have to be osg::Geometry ( ShapeDrawAble for instance ;) ) I can see many cases were it does not need to be Geometry in the classic sense, where my node for instance is a basically a Opengl node were I do my own Opengl calls etc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Thursday, July 31, 2008 9:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] RE : Re: Getting texture coordinates of loadedmodels Franclin Foping wrote: Hi Alberto, Indeed, that conversion is not possible. Do you know any other algorithms to retrieve texture coordinates of nodes made of a loaded model? In your previous post, you mention using indexes but assuming a Geometry node. The problem here is that here there is no Geometry node If the drawable of interest isn't a Geometry, then what class is it? Paul ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet issues with parent\child node
Judie, The default behavior is for States/StateSets to be inherited down the scene graph, from parent to child. However, in the default configuration, setting the StateSet of the child directly should cause that child (and any children that it itself has) to use the new StateSet parameters. This inheritance method is controlled by the OverrideValue flag, which can be set when attributes and modes are enabled or disabled on a StateSet. It sounds like what you're doing should work (set the state on the parent, then reset the state on the child), but I don't understand why you're creating and adding another group node in between the parent and child, as this is completely unnecessary to manipulate state changes. All you need to do is to query the StateSet from the parent (using getOrCreateStateSet() ) and make any appropriate changes. Then get the StateSet from the child, and remove/reverse any changes (e.g., disable materials, or apply 'empty' Programs in the case of shaders). Alternatively, you could set the child's OverrideValue to PROTECTED in order to prevent the parent's state values from being inherited. -- Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Judie Sent: Tuesday, July 01, 2008 1:57 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] StateSet issues with parent\child node Hi, I must be doing something wrong. I have a function that adds a sphere map and material to a node. When I apply this function to a parent, it also affects the child. How can I make it just affect the parent and not the child? Also, if I call the same function with different settings for the child, it still gets the parent's settings even if I call the function on the child last. In the algorithm I do the following: find the node by name that I want to apply the state to - currNode. make a new group node (gnode) and insert that between the currNode and it's parent. I use this gnode to get or create the state. Then I add my settings to this state. I also give it a unique name. I have also tried just applying the state to the currNode directly and I get the same behavior no matter what. Judie ___ 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] Adding a child to a node at runtime.
On a similar note, does anyone know what the performance costs of adding/removing nodes from the scene graph at runtime are compared to, say, using a Switch or manipulating NodeMasks to hide objects? That is, is the performance hit from adding/removing nodes greater or less than any loss in performance due to ignoring existing (but temporarily unwanted) nodes? For the sake of this discussion, assume that a good number of nodes are involved - not just a few here or there. I was planning on running some tests myself on this subject, but since this question came up, I thought I'd see if anyone else has already looked into this. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thrall, Bryan Sent: Thursday, June 19, 2008 1:27 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] Adding a child to a node at runtime. James Reid wrote on Thursday, June 19, 2008 12:13 PM: Howdy! When I try to add a child to a node at runtime I get an exception. Unfortunately, the exception dies quietly so I'm not sure what the actual exception is. I know I've done this before (a long time ago) and things have changed since then, so I'm not sure what I'm doing wrong. Here's the setup of our app. We're rendering on a managed window using managed c++ We have a button that enables/disable certain graphics to be drawn. To do the hiding of a graphic, I remove the geode from it's parent node. To do the showing of a graphic, I add the geode to the parent. - this causes the exception We're building a simulation and our users can toggle certain graphics on/off. For example, they can view graphic, physics, center of mass, constraints, etc... They can view any number of these at any time. My current set up is I have a Geode for each representation. I then add/remove that geode depending on the display settings. Is this the wrong setup? I've searched for similar solutions and haven't really found anything. Maybe I'm looking in the wrong places? It isn't safe to modify the scenegraph during the cull and draw passes; it's best to use a UpdateCallback, or to replace your call to frame() with your own that modifies the scenegraph before doing the cull and draw. There are other ways to show/hide geometry, such as the node mask or a CullCallback; not that what you're doing is wrong, but perhaps they might do what you want better. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ 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
