From: Dan Johnston (dan.johnston++at++nrc.ca)
Date: 10/16/2001 05:56:40
Hello to everyone in the Performer group!
I would like your help. Performer is great, and we all earn
our salaries by developing with it, but we also all are asked
why the development takes so long!
I may have a solution to long development times!
I have attached two files (both in plain text). The first
README describes a library I created for in-house use.
I think you will find it interesting. And, it does work! I
use the code to create full-featured applications. The second
attachment is a copy of the source file fore one of these
applications. Simple source, full of features, but all of
my applications must be considered 'demo'or 'alpha'
code - because the library is still 'alpha'.
It needs to be tested for more applications and display
configureations than I have the time or hardware to support.
This is where you can help. Please look over the attachments
and if you feel you can contribute to this development then
contact me at the e-mail address listed below. I can make
copies of the documentation, sample programs and even
binary copies of the library available to those parties who
can help, and who can show they can keep the work
confidential.
I cannot release source code. My company insists that we
try to persue a commercial agreement to sell/license this
code. By helping with the development, you would
move this code to the market faster, and give yourself a
'head start' on the training and documentation for this
new development tool. Why wait for Performer 2.5?
Thank you for all replies!
--
___|__ |
/ | \ ||\ 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!
(This file name ... was last revised on date ... by ...) // $Id: README,v 1.5 2001/05/11 16:14:17 johnston Exp $
What is pfAPC?
pfAPC is a 'C' library - built on top of Performer. The code does not rely on any other libraries or licenses.
pfAPC will allow a single application to show models on any display configuration. 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 it will (soon!) support the very low cost red-blue stereo display.
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 provides 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.).
What is 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.
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 - cycle through all viewing modes (mono, active stereo, passive left, passive right) - toggle between passive left and passive right viewing modes
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'".
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. Remore 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.
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 description 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 curved walls and multi-wall CAVE(tm) display configurations. If no configuration 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.
The current version of the software has been developed and tested using OpenGL Performer(tm) version 2.4.
How fast are the pfAPC displays?
pfAPC has been tested with large models and a CAVE(tm) display. 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, 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 software library. Note: TrackD software and license must be purchased separately.
- Interaction window (in progress). A separate window can be created, via pfAPC function calls, at an application specified position, rotation, and size. This window will not be used to view the model, but instead used to display and interact with a user interface (GUI). It does not support stereo display. The window visibility can be toggled. The GUI can be created with either Performer utility library function (pfGUI) or via Motif/Xwindows.
- reb/blue stereo. All pfAPC application will support this very low cost stereo display mode in addition to the existing active/passive stereo and mono modes. The configuration file will set the initial mode to use, and allow the user to bypass a mode, i.e. if you don't have active stereo glasses or do not want to see the red/blue rendering. With this new mode active, the stereo viewing mode control will then switch the order as mono/stereo/passiveLeft/passiveRight/redBlue/mono...
- 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.
- documentation (in progress). Documentation of all functions and controls. Also documentation on configuration, options and use of the library.
- Bug fixing (in progress)
Daniel F. Johnston National Research council of Canada 2001-May-11
/* * * 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( "./configs/basic-1-win" );
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 : Tue Oct 16 2001 - 06:03:36 PDT