From: Dan Johnston (dan.johnston++at++nrc.ca)
Date: 02/06/2003 08:39:38
It can be easier than you think to create Performer applications on
any of the supported platforms - now including MS-Windows!
Take a look at the attached 'README' file (ascii) and let me know
if you would be interested in trying a copy of the library described.
I can make a copy of the library, example source and documentation
available to anyone who seriously wants to improve how quickly
he/she creates 'feature rich' apllication - including active stereo
display on MS-Windows!
Tell me what you think! I have even attached one of the example
source files so you can see for yourself just how simple Performer
applications can be.
--
___|__ |
/ | \ ||\ Daniel (Dan) Johnston
/___|___\ || \ Dan.Johnston++at++nrc.ca
_____|____ || \ National Research Council of Canada, London, ON
| | | || \ Integrated Manufacturing Technologies Institute
\___| | | ||____\ Tel: (519) 430-7081 Fax: (519) 430-7090
\_o_\___|____|_|______\_ Inst: http://www.nrc.ca/imti
\ o / These opinions are my own! Not those of NRC.
\________________/ Virtual Reality:
http://www.nrc.ca/imti/vetc/home.html
More Tall Ships - Fewer Computers!
++++++++++++++++ README ++++++++++++++++++++++++++++
(The strange line below is used and updated by the CVS utility)
(Basicly it says that...
This file name .. version .. was last revised on date .. by ..)
// $Id: README,v 1.12 2003/01/15 13:18:28 johnston Exp $
pfAPC and the Programmer
pfAPC is a library created to support the rapid development
of 'full featured' Performer(TM) applications. It cannot
write your applications for you, but it does provide a
long list of display and viewing features so that you can
concentrate on the needs of the application and not the
details of your standard requirements.
The library was written as a layer on top of Performer. It
simplifies many of the repeated functions calls, for example
all the standard 'pfInit', 'pfExit' and 'pfConfig' calls are
done for you, but it does much more! It is not based on the
'perfly' application, but is written from scratch to provide
fast applications without the 'code bloat' of rarely used
'perfly' features. The code does not require or rely on any
other libraries or licenses.
The library, and the applications created to use it, will
work on any of the computer platforms that support the Performer
API. Applications can be written in either the 'C' or 'C++'
computer programming languages. The supplied examples are
easy to understand - at least they are easy for anyone who
can already understand the simple example code provided with
Performer.
All pfAPC features are supplied at 'no development cost' to
any application that makes use of the library. You do not
write any extra code to gain access to the features described
below. In fact, you must add library function calls to turn any
of these features off! The most basic application will have
every feature described below.
A number of example programs are included with the pfAPC
library. These demonstrate how to use most of the features.
Since the library is so powerful, these examples source files
are very simple to understand and use!
A complete user's manual is provided in HTML, Latex and
Postscript formats.
What are the pfAPC features?
pfAPC will allow any single application to show models on any display
configuration without re-compiling. This display can contain any
number of hardware pipes and any number of channels. Channels can
be off-axis and/or rotated.
All pfAPC applications support active stereo display in addition to
mono display on all channels, .. and you can toggle stereo on/off
while the application is running. It also supports stereo left view
only and right view only, suitable for passive stereo, and
the very low cost red/Blue stereo display. Any stereo mode can be
selected/changed while the application is running.
All pfAPC applications support the standard pfiXformer methods for
controlling the viewpoint. Also included is an 'orbit' view mode, a
tethered mode (viewpoint tethered to a node specified by the
application) and an application driven viewpoint (if the
application defines a function for this).
All pfAPC applications have built-in keyboard/mouse interaction to
support the pfiXformer, to select other view modes, to cycle the
stereo viewing modes, and to control model appearance (lighting,
wireframe texture display, backface polygon culling, etc.).
Users can connect a GUI for interaction with their pfAPC
applications. An additional, separate window is created via pfAPC
function calls at a specified position and size. This window
is not used to view the model, but instead used to display
the supplied user interface (GUI). It is not required that this
window support stereo display. GUI window visibility can be
toggled. It can be moved to any position on any display screen.
This GUI can be created with Performer utility library
functions (pfGUI).
What is the different between pfAPC and CAVElib from VRCO?
Both products provide control over the display configuration.
Only pfAPC will allow the on-line switching between stereo
and mono, pointer visibility, etc. With CAVElib you must
stop the application, change the configuration file, and
restart.
Only pfAPC supports the multiple viewpoint modes, model appearance
control, and other built-in event handling for applications that
will work in any display configuration without any additional
user development.
pfAPC is much lower in cost than CAVElib, and the library has
very flexible licensing arrangements.
What are the built-in keyboard/mouse controls?
- toggle texture display
- toggle between wireframe and filled display
- cycle through all model display modes (filled, hidden line, points..)
- toggle display of backface polygons
- toggle pointer visibility
- cycle through built-in lighting models
- toggle display of channel stats on master channel
- toggle display of channel stats on all channels, all pipes
- cycle through the viewpoint modes - orbit, fly, tethered, etc.
- toggle display between active stereo and mono
- toggle order of channel display in active stereo or red/Blue
stereo, i.e. "switch left and right eyes"
- cycle through all viewing modes (mono, active stereo, passive
left, passive right. red/Blue)
- toggle between passive left and passive right viewing modes
- toggle between application controlled viewpoint tracking and
no tracking (in progress)
Comments:
- The application can provide additional event handling by simply
defining the function, and providing the function name to pfAPC.
- All built-in event handling can be bypassed by setting a flag.
- All built-in event handling, except those associated with
viewpoint control, can be bypassed by setting a different flag.
- All built-in interaction can be accessed via function calls from
the application, i.e. no matter what the state of the flags.
- Keyboard and mouse events come from the first channel on the
first pipe (by default - like perfly) but can be switched by
a configuration file option to "any channel in pipe 'x'".
- Users can supply their own 'pre' and 'post' draw callbacks
to the application for maximum development capability. These
are called before and after the built-in draw callbacks.
- Applications can bypass the internal draw callbacks by
setting a flag. User supplied draw callbacks are not affected.
If the internal draw callbacks are bypassed, the application
will not be able to control drawing mode (lines, textures,
points, etc.) or turn on display of channel statistics.
What about remote keyboard/mouse controls?
All pfAPC programs can have keyboard and mouse events generated
by an application running on a remote laptop or workstation.
Source for a JAVA application is provided. Remote control
events can be bypassed or extended as described above. Remote
events can be mixed with events from the local keyboard and
mouse. More than one remote source of events is supported, as
long as two locations don't try to control the application
at the same time!
What about other remote controls?
All pfAPC programs can request access to a second built-in
network connection. The user supplies a socket port number,
and the application can then use the network data for any
requirement, i.e. to move objects in the scene, to change
the model behavior, to emulate viewpoint tracking, to support
voice control, etc.
How are different display configurations supported?
An ASCII system description is supplied to the pfAPC application.
System descriptions will provide 'hints' about the hardware in the
target display configuration (number of CPUs, number of pipes, order
of pipes, depth of z-buffer, multisampling support). Hardware
'hints' allow the system to be downgraded to a less capable
configuration, e.g. to restrict the number of CPUs assigned to
the application or to change the order of assigning hardware pipes
to software pfPipes. pfAPC will use emulation if the hardware
requested is more capable than the hardware on which the application
is run.
Display descriptions control the number of display windows, and the
number of channels assigned to each window. Windows can be full
screen or a defined size. Windows can have decorations or not.
You can specify the initial mode (stereo, mono, etc.) to be used for
display, or set which mode(s) to skip. You can define system
commands to run when you switch into or out of active stereo - so
that the visual can be changed, for example.
Each display window can contain one or more channels. These
can be simple on-axis channels displayed side-by-side, or they
have a defined viewport within the window. Background color can
be set for each channel. Off-axis channels can be defined to
configure large viewing walls - with or without overlap. Channel
rotations support "mirror" channels (i.e. reverse viewing angle),
curved walls and multi-wall CAVE(tm) display configurations.
If no display description file is specified, or if any major part of
the file is not found, then the system will create a 'default'
display configuration that will define a single, small window.
All the basic display interaction features still work on this
default one channel display.
What platforms has pfAPC been tested on?
The initial versions of pfAPC were created and tested on an SGI
O2 computer, and then on an ONYX2 IR deskside. Since then, it
has been tested on a 5 pipe ONYX IR Monster with 16 CPUs, on
Octane and Octane2, and even an old Indy. It has been compiled
on Linux, the basic functions tested OK, but there is a problem
to be solved for simulated multi-pipe configurations (current
Linux versions of Performer do not support multipipe commands).
It has been compiled and tested using the latest version of
Performer for MS-Windows. The remote control and user defined
socket features do not work (yet) on the MS-Windows version
(because I have to figure out how to use TCPIP on Windows!).
The current version of the software has been developed and tested
using OpenGL Performer(tm) version 2.5 for IRIX. The library is
source code compatible with the MS-Windows version running with
Performer Version 3.0.
The current version of pfAPC on IRIX and Linux supports the use
of the GNU 'configure' tools (and 'autoconf', 'automake', etc.).
This utility creates versions of Makefiles so that the library,
examples and documentation can be built on any of these supported
Unix operating systems. 'Automake' has not been tested on pfAPC for
MS-Windows. There are Makefiles supplied for IRIX and Visual
C++ if you don't want to use the 'automake' utility.
How fast are the pfAPC displays?
pfAPC has been tested with large models and a CAVE(tm) display.
Models size ranged from over 300,000 polygons up to 1.2 million.
CAVElib from VRCO was also tested with the same models and
display hardware. Results show that pfAPC is (at least!) as fast
as the VRCO product for all the different models and display
configurations tested.
What still need to be done?
- Viewpoint tracking (in progress). pfAPC will correctly change
all channels - and their frustums - based on the position and
orientation of the viewer within the display environment. Plans
are to support 3 modes: 1\ set viewpoint position and orientation
via the application (events, keyboard arrows, remote socket
connections etc), 2\ set position and orientation via built-in
support for Ascension Flock-of-birds, or 3\ set position and
orientation via support for the TrackD(TM) software library.
Note: TrackD software and license must be purchased separately.
- Better stereo display. (Everybody is always looking to make
the viewing of stereo images better for each display
configuration!)
- Interaction window (in progress). The GUI can also be
created via Motif/Xwindows functions. Note: Must de-bug the
pfGUI methods for switching GUI visibility in multi-pipe
configurations.
- skip view mode. Verify and fix code to allow the user to
bypass a mode, e.g. if you don't have active stereo glasses
or do not want to see the red/Blue rendering.
- visual attributes. Support in the hardware section of the
description file will define the 'visual' that pfAPC will try
to select for display. The type of options include support
for multisampling, depth of z-buffers, color depths, and
resolution. pfAPC will attempt to use the defined visual, but
will fall back to a simpler configuration if the visual is
not available.
- Complete the testing of all library features and documentation
with Performer version 3.0, on all platforms including MS-Windows.
- documentation (on-going, in progress). Documentation of all
functions, controls and changes. Also documentation on configuration,
options and use of the library. The current (evolving) reference
manual contains 360 pages. A user's manual of about 50 pages
has been completed.
- Bug fixing (on-going, in progress) The code development has
been done with 'cvs', which supports change history, branching,
multiple versions, merging, etc.
Any ideas for future work?
- It would be nice (to improve the ease of software maintenance)
to re-write the library in C++.
- Add support for tracked, head mounted displays.
- Switch the configuration file to be an XML document that
can be verified for correctness, generated by (future, graphical)
display configuration software, and parsed using the new XML
support in Performer 3.0.
- Make use of the new library (a la Performer 2.5) to simplify
development of Motif GUIs and display description.
- Add features as suggested by other pfAPC users.
Daniel F. Johnston
National Research council of Canada
2003-Feb-05
-----------------------------------------------
++++++++++++++++ simple.c ++++++++++++++++++++++++++++++
/*
*
* simple.c: simple Performer program from the standard installed
* source examples and programmer's guide
* Modified to make use of pfAPC library for pipe/window setup and
* frustrum calculations. This simple version has a fixed
* name/location for the configuration file, so the file would have
* to be edited to make changes to the pipe/channel configuration.
*
* Used for the pfAPC documentation. Copy, but do not modify!
*
* Copyright National Research Council of Canada
* All rights reserved!
* Author: Dan Johnston 2001-May-24
*
* $Revision: 1.18 $
* $Date: 2001/06/12 19:34:43 $
*
*/
#include "../include/pfapc.h"
/*
* Usage() -- print usage advice and exit. This
* procedure is executed in the application process.
*/
static void
Usage (void)
{
pfNotify(PFNFY_FATAL, PFNFY_USAGE, "Usage: simple file.ext\n");
exit(1);
}
APCsetup setup;
int
main (int argc, char *argv[])
{
pfNode *model;
if (argc < 2)
Usage();
/* now load the setup config file (if any) into the structure */
setup = apLoadSetup( ".apcsetup" );
apSetupPreMultiprocess( setup );
/* place any application code here, before Performer forks */
pfdInitConverter(argv[1]);
apSetupPostMultiprocess( setup );
/* Read a single file, of any known type. */
if ((model = pfdLoadFile(argv[1])) == NULL)
{
apSetupExit( setup );
exit(-1);
}
/* Attach loaded file to a new pfScene. */
pfAddChild( apSetupScene( setup ), model);
/* create the pipes (windows) and views (channels) as per setup */
apSetupInitPipes( setup );
/* use whole model to define the initial viewpoint, eg orbit radius */
apSetupInitViewpoint(setup, model);
/* Simulate until the user exits */
while ( apSetupQuit( setup ) == PF_OFF )
{
/* Go to sleep until next frame time. */
pfSync();
/* handle other latency critical stuff - ie setting viewpoint */
apUpdateViewpoint( setup );
/* Initiate cull/draw for this frame. */
pfFrame();
apHandleEvents( setup );
}
/* Terminate parallel processes and exit. */
apSetupExit( setup );
}
-----------------------------------------------
This archive was generated by hypermail 2b29 : Thu Feb 06 2003 - 08:42:07 PST