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

Robert Osfield robert.osfield at gmail.com
Tue Sep 18 01:23:33 PDT 2007


Hi Joe,

W.r.t XML, I have used libxml2 in Present3D, http://present3d.osgforge.osg.

Thanks to the new CMake build its now easy to make parts of the build
optional and only built when the dependencies are available so its no
longer so much of hassle for end users to add another external
dependency.

As a general note I always try and keep file loading out in plugins,
and keep NodeKits clean of any serializing support.  This way you can
change how you implement the loading.  For instance if you have a
NodeKit then you'll ideally be able to read and write to a standard
.osg file.

Robert.

On 9/17/07, Sullivan, Joseph (CDR) <jasullivan at nps.edu> wrote:
> 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 indicatorand 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 currentlyhangs 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.
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>



More information about the osg-users mailing list