[osg-users] Instrument Panel rendering - interest? ideas?

Zach Deedler zjd at faac.com
Mon Sep 17 13:20:13 PDT 2007


Hi Joseph,

Tinyxml is an alternative to xerces which usually suffices (it always has
for me).  The code is small enough just to embed it into the library that
uses it.

Also, I was wondering how you implemented the border around the graph in
your screenshot?  I'd like to see the ability to add borders to views in the
osg libraries.  I have submitted code that decorates a CameraNode with a
border, but that was OSG 1.2.

-----Original Message-----
From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Sullivan,
Joseph (CDR)
Sent: Monday, September 17, 2007 4:03 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Instrument Panel rendering - interest? ideas?

Robert, Zach, Paul, Serge, Gerrick, and the rest of the OSG gang,
Thanks for the replies - good to know that this may be generally useful
code.
Things may have changed a bit, but the basic starting idea was to make it
easier to build reconfigurable instrument panels out of a set of gauges. 
Rather than 3D models, we use geometric primitives as the scene graph
level.  Each gauge in an instrument panel is made up of layers. Layers would
have a position and textured quad associated with them.  The indicators on
the gauge are textured quads that can be articulated: rotated, translated,
etc.  So an RPM gauge would have a layer representing the background and an
articulated layer representing the needle.  Details for how to articulate
parts are read from an XML file.  For updating the gauges we use a list of
control points and interpolate between these points.  (The control points
are real world value - offset pairs.  If RPM is linear this could just be a
list of [ [0,0] [8000,270]] zero RPM would be zero rotation, 8000 RPM would
be 270 degrees.)  The parent application updates the gauge using real-world
parameters.  Interpolation happens auto-magically.  
The attached screen shot is a somewhat generic helicopter instrument panel. 
The airspeed indicator and compass are straightforward and would work fine
for the RPM and compass.  The altimeter is a bit trickier - there is one
articulated layer for the needle and one for the thousands of feet drum. 
The drum is updated by translating the UV coords.  
We'll work on packaging this up.  The smart folks on the Delta3D team can
provide a better explanation of the current code.  Right now the code relies
on XML parsing (tiny XML or Xerces depending on version).  I doubt osg would
welcome another external dependency so we may want to look at that as well.
Thanks!
Joe


________________________________________
From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Zach
Deedler
Sent: Friday, September 14, 2007 12:57 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Instrument Panel rendering - interest? ideas?

Hello Joseph,

I have been putting off doing this myself.  I need speedometer, RPM, and
compass gauges to display onscreen.  My plan was to make them just another
3D model that sit in their own HUD.  How does the Delta3D one work?

I know it would be difficult to encapsulate this sort of thing because each
instrument panel has different properties.  So how do you define the
interface to the instrument panel node?

Thanks.

________________________________________
From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Sullivan,
Joseph (CDR)
Sent: Friday, September 14, 2007 10:42 AM
To: osg-users at lists.openscenegraph.org
Subject: [osg-users] Instrument Panel rendering - interest? ideas?

Greetings,
Over the last couple years we've worked on a few OSG/Delta3D projects that
have included a rendered instrument panel.  We have a pretty decent solution
that currently hangs out as a Delta3D utility (dtUtil).  Since it's mostly
OSG code we're wondering if it wouldn't make more sense to make this an osg
thing.
So the questions are:
Would this sort of application be useful for others?
Is there enough interest and ability to support as part of OSG?
What would be the right way to go - build as a plugin?
Thanks!
Joe S.




More information about the osg-users mailing list