From guest Thu Oct 28 01:42:17 1993 From: rmann@remarque.berkeley.edu (Roderick L. Mann) Message-Id: <9310280842.AA16992@remarque.berkeley.edu> Subject: pfSync() and faster dynamics To: info-performer@sgi.sgi.com (Performer Discussion) Date: Thu, 28 Oct 1993 01:42:05 -0700 (PDT) Content-Type: text Content-Length: 566 Status: OR I am somewhat new to Performer, so forgive this (probably) bonehead question. I want to run my vehicle dynamics loop at an integral multiple of the cull/draw calls. That is, if the frame rate is 30 Hz, I'd like to cruise through my dynamics simulation at 60 or 120 Hz. The reason for this is to provide faster feedback to other systems, including a motion platform and cockpit displays (not the monitors). What would be the best way to do this? I am fairly sure that the model is simple enough to allow such a high rate. Rick -------- rmann@remarque.berkeley.edu From guest Thu Oct 28 09:23:29 1993 Date: Thu, 28 Oct 93 09:23:21 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310281623.AA28491@tubes.asd.sgi.com> To: rmann@remarque.berkeley.edu (Roderick L. Mann), info-performer@sgi.sgi.com (Performer Discussion) Subject: Re: pfSync() and faster dynamics Status: OR >I want to run my vehicle dynamics loop at an integral multiple >of the cull/draw calls. That is, if the frame rate is 30 Hz, I'd >like to cruise through my dynamics simulation at 60 or 120 Hz. >The reason for this is to provide faster feedback to other >systems, including a motion platform and cockpit displays (not >the monitors). > >What would be the best way to do this? I am fairly sure that the >model is simple enough to allow such a high rate. Probably the best method is to fork a processs which runs the dynamics simulation and communicates the results to Performer's APP process through shared memory. Remember that this dynamics process should not modify any Performer data structures. You can use the video clock through pfVClockSync to synchronize this process. pfVClockSync() uses the video retrace clock for synchronization so it won't work for rates > the video rate which is usually 60Hz. Therefore, running at 120Hz is problematic and requires a different synchronization mechanism. You could spin on pfGetTime() if you had a CPU to burn. From guest Fri Oct 29 18:41:34 1993 Date: Fri, 29 Oct 93 18:42:32 -0700 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9310300142.AA09705@bessie.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: RE: pfSync() and faster dynamics Status: OR Back in the early days before performer we used gl on 4D/60Gs. We were happy to get 6Hz on a Unmanned Aircraft Simulator. At that speed they system was very unstable. So what we did was devide the time from the last frame to this frame by 5 or 10 and use those as time steps. In Performer, how about running a fixed rate of 30Hz and the sim at 60hz. Draw, pfSync()/pfFrame(), every other cycle. Dave\ Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Fri Oct 29 19:07:47 1993 Message-Id: <9310300207.AA07315@surreal.asd.sgi.com> To: pratt@bessie.cs.nps.navy.mil (david pratt) Cc: info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics In-Reply-To: Your message of "Fri, 29 Oct 93 18:42:32 PDT." <9310300142.AA09705@bessie.cs.nps.navy.mil> Date: Fri, 29 Oct 93 19:07:39 -0700 From: Jim Helman Status: OR Probably the best way to do this is to fork off a process which uses pfVClockSync() to wake up on every video retrace (60Hz) while running Performer at a frame rate of 30Hz. The dynamics process can communicate back to the application process through shared memory. Or if you're sure the appliation process runs safely under 16ms, you could run your current simulation loop but only call pfSync/pfDraw every other time. On the other iterations you could use pfVClockSync() to go to sleep until the next video retrace. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Oct 30 07:28:36 1993 Date: Sat, 30 Oct 93 07:29:14 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310301429.AA28593@netcom4.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics Status: OR At the recent IEEE VR Symposium in San Jose this past week it appeared to me that the consensus in the VR research community was that synchronizing object action simulations to the rendering simulation rate was considered pretty much out of date. Even a fixed integer ratio between object simulation rate and rendering frame rate was not considered a great solution (though, certainly an improvement over 1-1 ratio). In Andy Van Dam's keynote talk, "VR As A Forcing Function: Software Implications of New Paradigns", he spoke in favor of every object in a VR simulation having its own independent simulation, what he referred to as fine grained concurrency. How to actually implement such concurrency is difficult to determine, and probably should be done differently for different applications. But, the point was that synchronizing application updates with rendering updates is a loser. Jim Helman's suggestion (and I believe also John Rohlfe in some earlier msgs.) of separate forked processes is one solution, though it adds a bit of run-time overhead and a lot of app. programmer overhead and debugging complexity (esp. if you're a klutz with programming multiple processes and shared memory like I am). Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Sat Oct 30 08:10:28 1993 Date: Sat, 30 Oct 93 08:10:56 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310301510.AA01322@netcom4.netcom.com> To: hitchner@netcom.com, info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics Status: OR P.S. A point I forgot in my earlier msg. In most traditional visual scene simulations (e.g., flight and vehicle simulation or frame-at-a-time 3D graphics animation for film or video production) a difference between application sim. rate and rendering rate usually implies that the app sim runs faster than the rendering. In VR simulations, however, the ratio could go either way. Although flight simulator folks would turn their noses up at vehicle dynamics that run at a slower rate than the visual update rate, that's not necessarily the case in VR (examples: the UNC Nanomanipulator project with scanning tunneling microscope and projects at NASA Ames and Univ. of Alberta to visualize CFD super-computer simulations). In scientific visualization it's possible that the application simulation update rate might be relatively slow compared to the head tracked motion driving the viewing transformation and rendering frame update rate. And, of course the other way around (app sim rate > rendering rate) is certainly important in VR also, e.g., for collision detection. So, for VR the ratio between rendering update rate and application object simulation update rates can be: 1) not the same ratio for all objects, 2) not an integer ratio, and 3) >= 1 as well as < 1. From guest Sat Oct 30 16:42:36 1993 Message-Id: <9310302342.AA16696@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics In-Reply-To: Your message of "Sat, 30 Oct 93 08:10:56 PDT." <9310301510.AA01322@netcom4.netcom.com> Date: Sat, 30 Oct 93 16:42:11 -0700 From: Jim Helman Status: OR Decoupling tasks to run at different rates is essential, but going from 1:1 to 1:N and N:1 (synchronous) gets you a lot more than going the next step to 1:X.X and X.X:1 (asynchronous). Given most common languages, fully asynchronous systems are much harder to debug (and harder to have confidence in) because of all the possible run-time timing variations. They are also more prone to problems of temporal aliasing as the frame udpate frequency beats with the asynchronous thread's frequency. All this can be dealt with, but why? I'm curious where Andy saw a big advantage for complete asynchronicity. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Oct 30 20:01:14 1993 From: rmann@remarque.berkeley.edu (Roderick L. Mann) Message-Id: <9310310301.AA10424@remarque.berkeley.edu> Subject: Re: pfSync() and faster dynamics To: hitchner@netcom.com (Lew Hitchner) Date: Sat, 30 Oct 1993 20:01:06 -0700 (PDT) Cc: info-performer@sgi.sgi.com (Performer Discussion) In-Reply-To: <9310301429.AA28593@netcom4.netcom.com> from "Lew Hitchner" at Oct 30, 93 07:29:14 am Content-Type: text Content-Length: 394 Status: OR Hitchner writes that it is favorable to NOT sync the simulation to the rendering cycle. However, someone else mentioned that if the loop frequencies aren't integral multiples of each other, then there is a jerkiness caused by the beat frequency between the two loops. There are some solutions for this, such as extrapolating based on velocities, etc., but does anyone have any comments? Rick From guest Mon Nov 1 08:04:04 1993 Date: Mon, 1 Nov 93 10:17:37 -0600 From: steve@mred.hti.com (Steve Baker) Message-Id: <9311011617.AA18010@mred > To: info-performer@sgi.sgi.com Subject: Re: pfSync()... Status: OR In flight simulation, the dynamics calculations are usually done at high rate (eg 120Hz), but communicated to the graphics sub-systems at a much lower (but synchronous) rate (say 20 or 30Hz) in order to keep inter-process or network traffic to a minimum. The graphics frame rate is asynchronous to this rate (say 50 or 60Hz) and works by extrapolation. When the dynamics task creates a data packet, it time-stamps it, when the graphics task is nearly ready to start a new frame, it extrapolates the data forwards to the point when the video retrace is likely to occour for this data. The extrapolation would be necessary in order to remove the latency through the system - even if the dynamics code were utterly synchronised to the frame rate. One of the nastiest features of VR systems that I have seen is the total ignorance of the effects of failing to remove latency. This is the single biggest cause of so-called simulator sickness - especially in head and eye-tracked systems. Given that you need the extrapolation anyway, the cost of using a variable or asynchronous frame rate is minimal. The other aspect of all of this is the effect of graphics overloads. These are very hard to avoid when the system is being driven near to its limits (ie Always :-) ) and when a frame take too long to render, you generally don't want the dynamics stuff to slow down as well. (eg A car driving down a complicated-looking street should travel at the same speed as on driving through a featureless plain given that all other simulation parameters are equal!! Steve Baker Hughes Training Inc. Arlington, Texas. From guest Thu Nov 4 09:09:05 1993 Return-Path: Posted-Date: Thu, 04 Nov 93 12:08:41 -0500 Message-Id: <9311041708.AA20982@graphics.cis.upenn.edu> To: info-performer Cc: granieri@graphics.cis.upenn.edu Subject: Performer Asynch i/o on socket? Date: Thu, 04 Nov 93 12:08:41 -0500 From: John Granieri Status: OR Hello: Is it possible to use the pfReadFile and pfWriteFile on a socket that I create (i.e. are there any hooks into the pf*File() routines to give them a file id other than one created by pfOpenFile ?). Or must I sproc my own process to handle the socket i/o asynchronously? Thanks -John Granieri Computer Graphics Research Lab University of Pennsylvania From guest Thu Nov 4 12:54:16 1993 Message-Id: <9311042054.AA27374@surreal.asd.sgi.com> To: John Granieri Cc: info-performer Subject: Re: Performer Asynch i/o on socket? In-Reply-To: Your message of "Thu, 04 Nov 93 12:08:41 EST." <9311041708.AA20982@graphics.cis.upenn.edu> Date: Thu, 04 Nov 93 12:54:13 -0800 From: Jim Helman Status: OR The rt file stuff is only designed with files in mind, and there is currently no way to set or get the file descriptor. You mention sockets. Are there other cases in which this would be useful? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Jun 6 03:51:28 1994 Message-Id: From: crux@artcom.de (Dirk Luesebrink) Subject: multi threading with libpf objects To: info-performer@sgi.sgi.com Date: Mon, 6 Jun 1994 12:50:29 +0100 (MDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1822 Status: OR hi there, i'm searching for a way to make it safe to create libpf objects from a thread. im now running in APP_CULL_DRAW mode. the application process make an sproc for a communication thread which takes cmds from the outside world. one such command is "load world". then in this thread a loader is started which shuold create the performer tree which belongs to that world. if this is finished the thread terminates. the new tree is then added to the rest by adding it to group node. This happens in the application process. for most of my testmodels this mechanism works fine most of the time. when i make APPCULLDRAW it work in general. the problem is, that with more complicated scenes to load, i get Performer Warning (13): Attempt to modify deleted object but still most of the time it works, but sometimes it dumpes core. now i tried the following. // main simulation loop while (!Shared->exitFlag) { pfSync(); viewer->update(); plexControl.stopAll(); pfFrame(); plexControl.contAll(); updateScene(); } there stopAll and contAll will stop (cont) all threads which are started from somewhere in the application. the idea is, to have the extra threads in perfect sync with the application process. when i do that, Performer Warning (13) disapears. so far so good. But, then after while of loading, the whole applicatio wil hang. pfFrame does not return any more. it looks like one of the threads aquires some resources, then gets blocked, pfFrame starts and waits for that resource, but will never get it because the holding thread is stopped. off course i could stop the application for running completly through the thread and continue afterwards, but thats not what i want. any help or hint is greatly appriciated. dirk Luesebrink