RE: 2D/3D flight instrument displays

New Message Reply Date view Thread view Subject view Author view

Kevin Kronmiller (Kronmiller++at++metricsys.com)
Wed, 27 Oct 1999 07:14:05 -0500


Be sure to get the latest loader from MultiGen if you intend to use
clipbeads in your instrumentation. If you do not, you will get duplicated
instrumentation in your HUD. I believe this new loader came out within the
last month.

Kevin Kronmiller

-----Original Message-----
From: Simon Mills [SMTP:simon++at++wgs.estec.esa.nl]
Sent: Wednesday, October 27, 1999 2:50 AM
To: a.t.bavuso++at++larc.nasa.gov
Cc: info-performer++at++sgi.com
Subject: Re: 2D/3D flight instrument displays

Anthony Bavuso wrote:
>
> I have a question on how best to implement flight instrument displays
using
> Performer for a real-time flight simulator.
>
> The end system will have several display panels driven from an Onyx2.
 For
> example, one display for the artificial horizon, one display for the mode
> control panel, throttle display, and several displays for the pilots out
of
> the cockpit views. This will be a very graphics intensive system where
> every polygon counts.
>
> So it seems to me that I have two options for creating flight
instruments.
>
> Option 1)
> I have Multigen II and it has an instrumentation package where you can
> generate open flight models of flight instruments easily. I can create
the
> instruments in Multigen and then in Performer put them into the scene
graph
> for rendering. The only problem is that the instruments are treated as
3D
> objects and through the scene graph must go through all the culling and
> transformations that other 3D objects require. But the flight
instruments
> do not require all the transformations and culling calculations, and it
> seems a waste to do all the extra calculation when they not required.
>
> Option 2)
> I could use openGL directly from inside the draw process and therefore
> directly control what calculations are performed on my instruments. This
> seems performance wise to be the better choice. But if I go this route I
> lose all the nice functionality of the Multigen and the scene graph. And
as
> a consequence my code becomes more complex and more difficult to write.
>
> So the question is, is it worth the extra programming complexity to save
on
> the polygon count and to save on the unnecessary calculations on the
> instruments by using openGL as opposed to using open flight and the scene
> graph? How much will putting the open flight instruments in the scene
graph
> negatively affect performance?
>
> I am sure that someone out there has written a flight simulation
application
> using Performer. How did you implement your flight instruments?
>
> Do you'all have any suggestions, comments?

I would suggest you still use the Multigen Instrumentation option to
create your instruments. From what you say these would be just 2D
panels, not HUD's. In Performer you can set up a 2D orthogonal
projection, attach your models to the scene graph and off you go. The
extra calculations of culling etc. would normally be done in another
process and *should* be much quicker than drawing your geometry and so
will not slow you down. If the extra CPU cycles really matter then you
could set up culling callbacks that trivially return always in view. If
you want a HUD then I think (I haven't tried this) you could still use
MG geometry. Load them but don't attach to the scene graph. In the post
draw callback set up an othogonal projection using OpenGL and then use
immediate mode to draw the geosets (pfGeoSet::draw) in your loaded MG
geometry.

IMHO the flexibility and ease of using the MG Instrumentation option and
Performer outweighs any minimal performance gain from hand-coded OpenGL
(I have used both methods in the past). I may be a little biased since
I'm mostly making research simulators where flexibility is more
important than absolute performance. On the other hand I wish the MG
Instrumentation option could also output OpenGL code for embedding in
applications like some other packages can (e.g. VAPS).

> Thanks for you help.
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

--
Regards, Simon
________________________________________________________________________

Simon C. Mills Modelling & Simulation Section (TOS-EMM) Tel: +31 (0)71 565 3725 European Space Agency (ESA/ESTEC) Fax: +31 (0)71 565 5419 Postbus 299, 2200AG Noordwijk e-mail: simon++at++wgs.estec.esa.nl The Netherlands http://www.estec.esa.nl/wmwww/EMM ________________________________________________________________________ ----------------------------------------------------------------------- List Archives, FAQ, FTP: http://www.sgi.com/software/performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Oct 27 1999 - 05:15:37 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.