From guest Tue Mar 1 02:31:16 1994 From: "Ran Yakir" Message-Id: <9403010230.ZM6073@rea1.bvr.co.il> Date: Tue, 1 Mar 1994 02:30:01 -0800 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer and OpenGL Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi Are there any plans to have an OpenGL version of Performer ? When ? Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Tue Mar 1 06:36:30 1994 From: Bernd Froehlich Message-Id: <9403011337.AA07820@viswiz.gmd.de> Subject: point in bounding volume test To: info-performer@sgi.sgi.com Date: Tue, 1 Mar 94 15:37:19 MET Status: O two questions: 1. what is the best way to do a point in bounding box/bounding sphere test with Performer? I have a hierarchical scene graph with DCSs attached to each inner and leaf node. I thought about using pfSegsIsectNode with a zero length segment but I think this won't help because it actually computes the intersection of the line segment with the bounding spheres or triangles. And if the line segment is a point it will never return an intersection. 2. We are working on a stereo-application using quad buffers. There are two channels attached to a pipe which are linked together as a channel group. The draw callback switches left- and rightbuffers. The left and right eye view are set using pfChanViewMat(chanLeft, LeftEyeView); pfChanViewMat(chanRight, RightEyeView); and the frustum by pfMakePerspFrust( chanLeft, xminl, xmaxl, yminl, ymaxl ); pfFrustAspect(chanLeft, PFFRUST_CALC_VERT, TableAspect); pfFrustNearFar( chanLeft, Z_Near, Z_Far ); pfMakePerspFrust( chanRight, xminr, xmaxr, yminr, ymaxr ); pfFrustAspect(chanRight, PFFRUST_CALC_VERT, TableAspect); pfFrustNearFar( chanRight, Z_Near, Z_Far ); The view matrices and frustra are updated for every frame and this seems to be a problem. Everything works fine if pfMultiprocess(PFMP_APPCULLDRAW) or pfMultiprocess(PFMP_APP_CULLDRAW) is set, but using pfMultiprocess(PFMP_DEFAULT) causes a flickering view. The objects are moving correctly only the view is flickering. We kept the view matrices constant which doesn't help. Then we kept the frustra constant, only changing the view matrices which also doesn't help. Only if you keep the viewing matrices and the frustra constant then it works. Seems that the viewing information is not mp safe? It would be possible to keep the viewing matrices constant and to transform the objects into a fixed viewing coordinate system, but the viewing frustra have to be changed for each frame in our application. I had already a short discussion with Michael Jones and he wrote: >This is a multiprocessing problem. Use "passthrough" data and you >will be ok. Look and the pfPassChanData() man page for details on >this. Your data is changing before you use it. Shouldn't be the viewing information automatically copied into passthrough-buffers if I call pfFrame? So is it a bug or not? What should I put into passthrough data? I can't put the pfChannel itself into passthrough data. It is possible to do the stuff with GL-calls and pass-through data inside the draw callback but this is not the way it should be. Bernd bernd@viswiz.gmd.de ------------------------------------------------------------------------- Bernd Froehlich Scientific Visualization Dept. GMD Schloss Birlinghoven D-53757 St. Augustin Germany ------------------------------------------------------------------------- From guest Tue Mar 1 06:56:16 1994 Message-Id: <9403011455.ZM25234@unknown.zmail.host> Date: Tue, 1 Mar 1994 14:55:33 +0000 In-Reply-To: Bernd Froehlich "point in bounding volume test" (Mar 1, 3:37pm) References: <9403011337.AA07820@viswiz.gmd.de> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Hangup during pfswitch Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi I have a problem using Performer, which I hope someone will be able to explain. I have a pfswitch, which has two nodes, 0,1. When I switch on node 1 (node 0 being the default) the display hangs for up to 3 seconds, then it starts going again with the correct node switched in. Interestingly, the application process keeps going during the hangup. Indeed, printing the results of pfFrame, which appears to return the number of the rendered frame, then it returns as if the frames have been rendered. When I switch back to node 0 then there are no problems. Other aspects of this is that CPU usage seems to become very high during the hangup. I have a 4 150 MHZ cpu Onyx with VTX graphics. Does anyone have any explanations or advice? Thanks Richard Gallery From guest Tue Mar 1 09:20:59 1994 Date: Tue, 1 Mar 94 09:20:51 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9403011720.AA22801@tubes.asd.sgi.com> To: info-performer@sgi.sgi.com, Richard Gallery Subject: Re: Hangup during pfswitch References: <9403011337.AA07820@viswiz.gmd.de> Status: O >I have a problem using Performer, which I >hope someone will be able to explain. I >have a pfswitch, which has two nodes, 0,1. >When I switch on node 1 (node 0 being the >default) the display hangs for up to 3 seconds, then >it starts going again with the correct node switched in. >Interestingly, the application process keeps >going during the hangup. Indeed, printing the results of pfFrame, >which appears to return the number of the rendered >frame, then it returns as if the frames have been >rendered. When I switch back to node 0 then there >are no problems. Other aspects of this is that CPU >usage seems to become very high during the hangup. >I have a 4 150 MHZ cpu Onyx with VTX graphics. Does >anyone have any explanations or advice? You might have switched in geometry which contains textures. The first time a texture is rendered it must be formatted by the GL which takes a long time. When multiprocessing (which is the default for your system) the application process is independent of the draw and will continue even if the draw completely stops. pfFrame's return value is the application processes' frame count, not the number of frames rendered. From guest Tue Mar 1 10:26:48 1994 From: "Michael Jones" Message-Id: <9403010952.ZM583@babar.asd.sgi.com> Date: Tue, 1 Mar 1994 09:52:43 -0800 In-Reply-To: jrohlf@tubes (John Rohlf) "Re: Hangup during pfswitch" (Mar 1, 9:20am) References: <9403011337.AA07820@viswiz.gmd.de> <9403011720.AA22801@tubes.asd.sgi.com> X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com, Richard Gallery Subject: Re: Hangup during pfswitch Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mar 1, 9:20am, John Rohlf wrote: > Subject: Re: Hangup during pfswitch : :>I have a problem using Performer, which I :>hope someone will be able to explain. ... :You might have switched in geometry which contains textures. :The first time a texture is rendered it must be formatted by the GL which :takes a long time. When multiprocessing (which is the default for :your system) the application process is independent of the draw and :will continue even if the draw completely stops. pfFrame's return :value is the application processes' frame count, not the number of :frames rendered. If so, the way to resolve it is to download all the textures *before* you start your program. If you use the LoadFlight() function to read in your databases, then use GetSharedFltTexList() to get the textures. Otherwise you can write a simple traverser to do this yourself. Let me know if you want the code to do this. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Mar 1 10:35:06 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403011834.AA24698@tubes.asd.sgi.com> Subject: Re: Performer questions To: guest (Robert Webb) Date: Tue, 1 Mar 94 10:34:43 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199402180748.AA14301@godzilla.cgl.citri.edu.au>; from "Robert Webb" at Feb 18, 94 6:48 pm X-Mailer: ELM [version 2.3 PL8] Status: O > - The Performer documentation we have describes a function pfGlobalGState(), > but this function does not seem to actually exist (and there is no prototype > for it in the header file). How do I set up global pfGeoState defaults > without it? This is a mistake in the documentation. The routine does not exist. You set up global default by calling normal libpr routines such as pfApplyMtl(), pfEnable() etc. > - In one of our applications at least, the culling does not work properly. > Objects suddenly vanish before they leave the viewing frustrum. Any ideas > why this could be? We are not changing any of the GeoSets or other data in > the hierarchy after it has been initially set up. Print out the scene with pfDebugPrint and make sure your bounding boxes are reasonable. > - I've read the pfLight man page and I'm still not sure how to position lights > properly. It says that for lights like the sun, which have a fixed position > in the world, pfLightOn() should be called every frame with only the viewing > transformation on the matrix stack. I understand the concept, but how do I > actually do it? Performer does all the drawing and transformations for you > so do I need some sort of call-back to call pfLightOn() at the right moment? Call pfLightOn in your draw callback set by pfChanDrawFunc(). > If I set up lights in a pfGeoState with: > pfGStateAttr(gstate, PFSTATE_LIGHTS, lights); > and associate this with a pfGeoSet, then is that the same as using > pfLightOn() with the modelling transformations for that GeoSet on the stack? > That is, will the lights then move with the object like lights on a car? Or > does this simply use the lights but not affect their position? Do you still > need to call pfLightOn()? Yes, Yes, No, No. > Again I would like to use pfGlobalGState() to define global non-moving > lights, but this is unavailable. You do not need this. Just call pfLightOn and you have defined a global non-moving light. > - Ultimately it would be nice if pfGeoStates could be attached to any node, > and inherited by children. A pfGroup which holds all the various geometry > nodes for an object could then define materials etc. for all its children, > without each pfGeoSet having to do this itself to override the global state. > Does every little pfGeoSet really need its own pfGeoState? If so, is this > efficient provided consecutive children use the same pfGeoState? On the surface this seems like a nice concept but it is contrary to Performer doctrine and will never happen. Inheritance in a scene graph causes more problems than it is worth because you have to potentially examine large portions of the scene graph to decide how to draw something. It's like a deep C++ hierarchy where you have to chase a chain of 15 constructors to see what's going on. With the pfGeoSet/pfGeoState combination we know immediately how to draw a chunk of geometry (except for transforms) and we can use this information to efficiently sort geometry by mode and add other optimizations. pfGeoSets can share pfGeoStates at little or no cost. Believe me, the pfGeoSet/pfGeoState combination is pretty damn efficient. From jrohlf@tubes Tue Mar 1 11:25:59 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403011925.AA25209@tubes.asd.sgi.com> Subject: Re: pfDelete.... To: aschaffe (Nils Thune) Date: Tue, 1 Mar 94 11:25:57 PST Cc: info-performer-dist In-Reply-To: <199402121410.PAA05836@sgi_nils.cmr.no>; from "Nils Thune" at Feb 12, 94 3:10 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Part of my scene consist of a pfGeode with a gset. The vertices, colors and > normals in the gset has been allocated with pfMalloc(..., NULL); and added to > the gset with pfGSetAttr(...); > > When I call pfDelete(myGeode); will it deallocate the gset itself and all the > memory used by the user supplied vertices, colors and normals (allocated by > pfMalloc(...), and hence should have a ref count)? Yes. You do not normally need to bother with reference counts. pfMalloc'ed arrays are automatically reference-counted by the pfGeoSet. If an array is referenced by multiple geosets, it will not be deleted until the last geoset which references it is deleted. > > Or, do I have to add a pfDeleteFunc to gset which then should delete verices, > etc.? pfDeleteFunc is only for deleting user data specified by pfUserData. From guest Tue Mar 1 13:41:49 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403012141.AA25676@tubes.asd.sgi.com> Subject: Re: Questions about Perf1.2 To: guest (Marc SIMON Presales support) Date: Tue, 1 Mar 94 13:41:36 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9402021857.ZM814@girl.paris.sgi.com>; from "Marc SIMON Presales support" at Feb 2, 94 6:57 pm X-Mailer: ELM [version 2.3 PL8] Status: O > I have some questions about features of GL vs PERFORMER. > > - Is there a way in Performer to manage pagination of texture like > in GL . 1.2 Performer supports the following GL concepts: 1. Texture idle through pfIdleTex() 2. Query whether a texture is loaded or not through pfIsTexLoaded() Other GL features such as subtexload will be supported in the release following 1.2 which will be OpenGL based. Expect sophisticated texture management in 1.3 or 2.0 or whatever we call it. > - For managing the pfLayer i read that Perf1.2 uses > DisplacePolygon, but if i well remember displace polygon modify the Z > value of a polygon by a factor calculated by the use of the polygon > orientation, and this factor is 0.0 if the polygon as its normal oriented > direct to the viewer.So for coplanar polygon in front of the viewer it > will no works fine > Is'it right ??? Is there a way to avoid this ??? This is a correct evaluation of a fundamental flaw in displacepolygon(). The OpenGL version will solve this problem by adding an offset in addition to the scale. Remember that you can use stencil-based decaling in Performer by calling pfLayerMode(layer, PFDECAL_BASE_STENCIL). We may even change the default back to stencil since many people have had problems with displacepolygon-type decaling. > - Is there a way to store informations on every nodes of the > hierarchy ?? In 1.2, all libpr and libpf objects including nodes have a data pointer accessed through pfUserData. Thus you can attach the structure of your choice to any object. > - I heard that Performer sorts the polygons before the drawing to > optimise the graphics (Especially mode transitions).But what kind of > sorting Performer uses .. Is it only to group polygons with the same > textures to avoid Texbind ??? We have a sorting hierarchy that includes sorting by texture but we also sort by matrix, by material, and by transparency. The sorting hierarchy may differ between machines and releases. > - My last question is not especially for Performer guys, in fact > it seems that the GL call "msmask()" is very slow . Is it right ??? I don't know. We use msmask for fade LOD and it doesn't seem to be very slow. Of course the term "slow" is relative to the number of times you call it per frame. From aschaffe Tue Mar 8 09:24:24 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080924.ZM24355@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:24:24 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Wed, 2 Mar 94 10:51:18 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9403021551.AA15802@cae.ca> To: info-performer@sgi.sgi.com Subject: Perf. on PIs Status: O A quick question: will Performer run on a 4D/35? (I guess it depends at least in part on whether IRIX 4.x can be installed on a PI). ------------------------------------------------------------------ J.F. Richard jfr@cae.ca CAE Electronics Ltd Montreal, Canada ------------------------------------------------------------------ From aschaffe Tue Mar 8 09:24:34 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080924.ZM24361@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:24:34 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <9403021903.AA07973@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Mar 1994 14:03:57 -0500 To: info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: WTK, Performer, and dVS/dVISE Status: O We are working on some virtual environment apps and are considering using a commercial package to avoid rewriting things that have already been done elsewhere. Some tools we are currently looking at include WorldToolKit from Sense8 Corp and dVS/dVISE from Division. I would be interested in hearing experiences of others using these systems. I assume that people on this mailing list are for the most part writing their own, but if anyone has any experience with either of the two packages listed, please let me know what you think. We are most concerned about: - Overhead (overall speed, graphics speed, code size, etc.) - Tech Support - Flexibility Any testimonials or flames? Thanks, John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From aschaffe Tue Mar 8 09:24:48 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080924.ZM24367@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:24:48 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: aschaffe (Allan Schaffer) Message-Id: <9403022147.ZM6489@holodeck.asd.sgi.com> Date: Wed, 2 Mar 1994 21:47:57 -0800 In-Reply-To: jfr@cae.ca (Jean-Francois Richard) "Perf. on PIs" (Mar 2, 10:51am) References: <9403021551.AA15802@cae.ca> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: jfr@cae.ca (Jean-Francois Richard) Subject: Re: Perf. on PIs Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mar 2, 10:51am, Jean-Francois Richard wrote: > > A quick question: will Performer run on a 4D/35? (I guess it > depends at least in part on whether IRIX 4.x can be installed > on a PI). Yes to both. Currently released software for that configuration is IRIX 4.0.5 and Performer 1.0; IRIX 5.2 and Performer 1.2 coming soon. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From aschaffe Tue Mar 8 09:25:31 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080925.ZM24384@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:25:31 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: jrohlf@tubes (John Rohlf) Message-Id: <9403072011.AA06905@tubes.asd.sgi.com> Subject: Re: point in bounding volume test To: guest (Bernd Froehlich) Date: Mon, 7 Mar 94 12:11:01 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403011337.AA07820@viswiz.gmd.de>; from "Bernd Froehlich" at Mar 1, 94 3:37 pm X-Mailer: ELM [version 2.3 PL8] Status: O > 2. We are working on a stereo-application using quad buffers. > There are two channels attached to a pipe which are linked together as > a channel group. The draw callback switches left- and rightbuffers. > > The left and right eye view are set using > > pfChanViewMat(chanLeft, LeftEyeView); > pfChanViewMat(chanRight, RightEyeView); > > and the frustum by > > pfMakePerspFrust( chanLeft, xminl, xmaxl, yminl, ymaxl ); > pfFrustAspect(chanLeft, PFFRUST_CALC_VERT, TableAspect); > pfFrustNearFar( chanLeft, Z_Near, Z_Far ); > > pfMakePerspFrust( chanRight, xminr, xmaxr, yminr, ymaxr ); > pfFrustAspect(chanRight, PFFRUST_CALC_VERT, TableAspect); > pfFrustNearFar( chanRight, Z_Near, Z_Far ); > > The view matrices and frustra are updated for every frame and this > seems to be a problem. > > Everything works fine if pfMultiprocess(PFMP_APPCULLDRAW) or > pfMultiprocess(PFMP_APP_CULLDRAW) is set, but using > pfMultiprocess(PFMP_DEFAULT) causes a flickering view. > The objects are moving correctly only the view is flickering. > We kept the view matrices constant which doesn't help. > Then we kept the frustra constant, only changing the view matrices > which also doesn't help. > Only if you keep the viewing matrices and the frustra constant > then it works. Seems that the viewing information is not mp safe? > > It would be possible to keep the viewing matrices constant and to > transform the objects into a fixed viewing coordinate system, but the > viewing frustra have to be changed for each frame in our application. > > I had already a short discussion with Michael Jones and he wrote: > > >This is a multiprocessing problem. Use "passthrough" data and you > >will be ok. Look and the pfPassChanData() man page for details on > >this. Your data is changing before you use it. > > Shouldn't be the viewing information automatically copied > into passthrough-buffers if I call pfFrame? So is it a bug or not? > What should I put into passthrough data? I can't put the > pfChannel itself into passthrough data. It is possible to do > the stuff with GL-calls and pass-through data inside the > draw callback but this is not the way it should be. I had a flickering problem with my own stereo application. It turned out to be an MP-related bug with caused only the left buffer to be updated. Barring an unlikely bug, Performer's viewing parameters are MP-safe so I would concentrate on your application. First characterize the flickering: - close each eye and see if only 1 of the left/right buffers is being updated. - close each eye and see if both buffers are being updated but 1 of the buffers has a bogus viewing transform. - put printf's in your draw callback and print out the viewing and projection matrices and the current left/right buffer to make sure you are toggling them. You can also send me your code and I will check it out. From aschaffe Tue Mar 8 09:22:58 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080922.ZM24348@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:22:57 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: Kevin Russo Message-Id: <199403012345.XAA16581@midway> To: info-performer@sgi.sgi.com Subject: Re: Performer questions Status: O >> - In one of our applications at least, the culling does not work properly. >> Objects suddenly vanish before they leave the viewing frustrum. Any ideas >> why this could be? We are not changing any of the GeoSets or other data in >> the hierarchy after it has been initially set up. > > Print out the scene with pfDebugPrint and make sure your bounding > boxes are reasonable. I found that for linestrips, anyway, Performer only checks if the first point or so of the lineseg is in the viewing frustum, regardless of the bounding box. Perhaps this little speed enhancing trick is at work in other types of GeoSets? I overcame it by installing a node pre-cull callback like this: node_cull_pre_cb() { pfCullResult(PFIS_ALL_IN); return PFTRAV_CONT; } It was most frustrating to watch my trajectory line segments disappear any time the origin wasn't in view. Kevin From aschaffe Tue Mar 8 09:25:04 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080925.ZM24377@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:25:03 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <199403032216.OAA00484@archimedes.chinalake.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: Gauges in Performer... Status: O Hello all! I'l like to use some simple gauges within Performer to do things like the airspeed indicator in dogfight. I know that GL windows can be open in Performer, but how does one go about defining a gauge that can be manipulated by outside data? jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Dude Internet: jan@archimedes.nwc.navy.mil Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA Naval Air Warfare Center kc6uth@kc6uth.ampr.org -Weapons Division [44.17.2.6] From aschaffe Tue Mar 8 09:08:05 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080908.ZM24254@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:08:04 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Tue, 8 Mar 94 10:26:14 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403081626.AA12825@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Display lists Status: O I have a quick question (hopefully); would there be any problem using display lists in the draw process of Performer? I'm planning to use genobj() makeobj() closeobj() and callobj(). Is genobj() necessary (IE is Performer using the GL maintained display lists?) Thanks in Advance, _ Aaron Hightower - aaron@dseg.ti.com | | . Visualization & Simulation __| |___ Technology Development, TI \ =/=/ Voice: (214)575-6759 \X / / FAX: (214)575-6779 \ ( \/ From aschaffe Tue Mar 8 09:22:08 1994 Date: Tue, 8 Mar 94 09:22:02 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9403081722.AA24340@holodeck.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: info-performer messages backed up Status: O Due to operator error (ahem) after an OS upgrade a number of messages didn't get forwarded along to the mailing list. In fact, anything sent between late March 1 and today has been patiently sitting in-queue. Looks like about 9 or 10 messages. I'll send them in a big, but brief, chunk. Sorry folks! Allan ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Tue Mar 8 09:48:20 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403081748.AA09121@tubes.asd.sgi.com> Subject: Re: Display lists To: aschaffe (Aaron M. Hightower) Date: Tue, 8 Mar 94 9:48:10 PST Cc: iris-performer@sgi.sgi.com In-Reply-To: <9403081626.AA12825@skips.dseg.ti.com>; from "Aaron M. Hightower" at Mar 8, 94 10:26 am X-Mailer: ELM [version 2.3 PL8] Status: O > > I have a quick question (hopefully); would there be any problem using > display lists in the draw process of Performer? I'm planning to use genobj() > makeobj() closeobj() and callobj(). Is genobj() necessary (IE is Performer > using the GL maintained display lists?) There only restriction is that you must make all obj calls in the draw process - don't try to create an object in the APP etc. The only GL display lists that Performer deals with are those created for pfGeoSets when you specify the COMPILE_GL mode to pfGSetDrawMode. For this reason genobj() is recommended so you don't collide with these objects. From guest Tue Mar 8 10:05:25 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403081805.AA09155@tubes.asd.sgi.com> Subject: Re: Performer questions To: aschaffe (Kevin Russo) Date: Tue, 8 Mar 94 10:05:14 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199403012345.XAA16581@midway>; from "Kevin Russo" at Mar 1, 94 11:45 pm X-Mailer: ELM [version 2.3 PL8] Status: O > >> - In one of our applications at least, the culling does not work properly. > >> Objects suddenly vanish before they leave the viewing frustrum. Any ideas > >> why this could be? We are not changing any of the GeoSets or other data in > >> the hierarchy after it has been initially set up. > > > > Print out the scene with pfDebugPrint and make sure your bounding > > boxes are reasonable. > > I found that for linestrips, anyway, Performer only checks if the first > point or so of the lineseg is in the viewing frustum, regardless of > the bounding box. Perhaps this little speed enhancing trick is at work > in other types of GeoSets? > > I overcame it by installing a node pre-cull callback like this: > node_cull_pre_cb() { pfCullResult(PFIS_ALL_IN); return PFTRAV_CONT; } > > It was most frustrating to watch my trajectory line segments disappear > any time the origin wasn't in view. I'd like to get to the bottom of this. We don't do anything special for linestrips or any other pfGeoSet type. If you are able, send me an application and/or database which illustrates the problem and I'll find out what's going on. Also, send me the following information: 1. Which Performer release are you running? 2. What application: perfly or custom? 3. What multiprocessing model? 4. What culling mode (pfChanTravMode)? N.B.: There is an easier way than using pfCullResult(PFIS_ALL_IN); described above. Call pfNodeTravMask(node, PFTRAV_CULL, 0, PFTRAV_SELF, PF_SET); With a cull mask of 0, the node will be not be cull-tested and will be automatically accepted. From guest Tue Mar 8 11:26:05 1994 Date: Tue, 8 Mar 94 14:28:26 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9403081928.AA12292@cae.ca> To: info-performer@sgi.sgi.com Subject: .flt version on Perf. 1.0 Status: O According to the Performer 1.0 documentation, the supplied Multigen loader supports Version 10 .flt files, while some of the previous mail on this list claims that V11 is supported. I am currently trying to load a V11 Multigen database. It loads properly into perfly under Performer 1.2a94 (a beta release) but causes a segmentation fault in the Performer 1.0 perfly, which leads me to believe that my .flt loader only supports V10. How can I tell? None of the files in /usr/src/Performer/src/pfflt seem to specifiy a .flt version number (while under Performer 1.2, comments in hier.c clearly state that it is for a V11 .flt database). If there is a V11 loader for Performer 1.0, and I don't have it, how can I get it? ---------------------------------------------- J.F. Richard jfr@cae.ca CAE Electronics Ltd ---------------------------------------------- From guest Tue Mar 8 13:11:49 1994 Message-Id: <9403082111.AA14608@nova.sarnoff.com> Date: 8 Mar 1994 14:26:33 U From: "Shalini Govil" Subject: Unsubscribe To: "Performer" Status: O Subject: Time:2:30 PM OFFICE MEMO Unsubscribe Date:3/8/94 Unsubscribe me from the list Thanks Shalini From guest Wed Mar 9 07:08:19 1994 From: "Marc SIMON Presales support" Message-Id: <9403091623.ZM14799@girl.paris.sgi.com> Date: Wed, 9 Mar 1994 16:23:08 +0100 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: "Dynamic LOD" Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Is anybody in the performer worlds heard about a soft from the M.I.T. named BRUSH , that could manage automatically Level Of Detail with a unique description of the model (No multiple instance of the 3D model ), and the soft reduce the number of polygons according to the distance between eyes and the object. Any informations will be very helpfull. smarc@paris.sgi.com From guest Wed Mar 9 08:28:49 1994 From: Mark Coyle Subject: GL and Performer To: info-performer@sgi.sgi.com Message-Id: <9403091423.AA25661@dexter.psych.umn.edu> X-Mailer: ELM [version 2.4 PL6] Content-Type: text Content-Transfer-Encoding: 7BIT Content-Length: 435 Status: O Hi, I know this is in the FAQ but I can't seem to get GL to draw into a Performer Window (i.e. a HUD). I'm sure it is just a wrong/missing/ function call. If anyone has a simple sample program that does this, i would appreciate getting a copy of the code. I have just signed onto this group, so I apologize if this questioned has been answered before. Mark Coyle Human Factors Lab Computer Science Department U of Minnesota From guest Wed Mar 9 09:50:24 1994 Date: Wed, 9 Mar 94 11:27:55 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403091727.AA17205@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Drawing HUD's Status: O From the FAQ: (Sharon Fischler) ------------ Subject: -12- How do I overlay graphics on top of my Performer scene? Date: 06 Oct 93 00:00:01 EST Typically this is done to implement a heads-up display (HUD). In the draw function callback, the basic algorithm is: save state with pfPushState() disable textures, fog, & lighting with pfBasicState() save & clear projection matrix ortho2() save & clear modelling matrix draw() restore modelling matrix restore projection matrix restore state with pfPopState() Or, you can draw your static info in the overlay planes and only redraw it when the window receives a REDRAW event (moved, resized, etc.). Changing between drawing to the overlays and drawing to regular bitplanes takes a big hit. For things that need to be updated real-time, draw() would consist of: zfunction(ZF_ALWAYS); zwritemask(0x0); draw HUD stuff zfunction(ZF_LEQUAL); zwritemask(0xffffffff); ----------------------------------------------------------------------------- Example: (modification of PostDraw from Perfly) void drawHUD(pfChannel *chan) /* example function */ { pfPushState(); pfBasicState(); pfPushIdentMatrix(); zfunction(ZF_ALWAYS); zwritemask(0); /* Example of how to put into pixel coordinates. * Not necessary depending on requirements of GL calls * IE: You may want to use different coordintes instead */ pfGetChanSize(chan,&chanSizeX,&chanSizeY); ortho2(-.5f,chanSizeX-.5f,-.5f,chanSizeY-.5f); **** DRAW GL JUNK HERE **** zfunction(ZF_LEQUAL); zwritemask(0xffffffff); pfPopMatrix(); pfPopState(); } void PostDraw(pfChannel *chan, void *data) { drawHUD(chan); /*** Insert this line into PostDraw in perfly ***/ if (ViewState->stats) pfDrawChanStats(chan); if(chan == ViewState->masterChan) pfuCollectInput(); } From guest Wed Mar 9 10:10:37 1994 Date: Wed, 9 Mar 94 13:11:27 EST From: rsilvers@nynexst.com (Rob Silvers) Message-Id: <9403091811.AA07491@texas.nynexst.com> To: info-performer@sgi.sgi.com Subject: Performance of RE2 doing perfly on town. Status: O I just used perfly with the town database on an RE2 with the following config: 128MB RAM 2 RMs - 4MB texture memory each 2 R4400 CPUs Most of the time, it ran at 30 fps, but sometimes was quite jumpy and went to 15 fps. (mostly when I looked at the area where all the buildings were). The stats display indicated that it was the draw processes that was overrunning. My question is: what configuration can run this at 30fps all the time? Were the textures being swapped on an 8MB texture system? (meaning would more texture memory make it run at 30fps) Would 4 R4400 make it run at 30 fps all the time? Would 4 RMs be needed to make it run at 30fps all the time? Can any SGI machine run it at 30fps? My guess is that it is the RMs - does anyone know for sure? Thanks, --Rob. From guest Wed Mar 9 11:35:50 1994 Message-Id: <9403091935.AA12152@surreal.asd.sgi.com> To: rsilvers@nynexst.com (Rob Silvers) Cc: info-performer@sgi.sgi.com Subject: Re: Performance of RE2 doing perfly on town. In-Reply-To: Your message of "Wed, 09 Mar 94 13:11:27 EST." <9403091811.AA07491@texas.nynexst.com> Date: Wed, 09 Mar 94 11:35:30 -0800 From: Jim Helman Status: O The simpler village version of the database runs at 30Hz, the town does not. Also, some versions of the town demo shipped with PFPHASE_LOCK as the default, which is bad for a database like the town which was not modeled to run at a high, fixed frame rate. It all fits in 4MB, so it's not swapping textures. You can tell if more RMs will help an application by making the window smaller. If it runs faster, you're pixel fill limited and RMs will help. If not, you are probably geometry or CPU limited. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Mar 9 14:14:59 1994 Message-Id: <199403092214.RAA08435@favorite.cis.ohio-state.edu> To: iris-performer@sgi.sgi.com Subject: pfMakePerspFrust Status: O I'm running 1.2beta on an Onyx RE^2. I need off-axis perspective views so I am using pfMakePerspFrust(). I'm was not getting the desired results so I called pfGetFrustFOV and pfGetFrustNearFar to verify the values. While near and far matched, the horizontal and vertical field of view differed from the values I passed. I am not using pfFrustAutoAspect() and checked to make sure the default was PFFRUST_CALC_NONE. Am I going about this the wrong way ? Thanks, Mark Visconti LTSI, WPAFB, Dayton, OH From guest Wed Mar 9 15:04:54 1994 From: fraser@BanffCentre.AB.CA (Glen Fraser) Message-Id: <9403092254.AA15169@moose.BanffCentre.AB.CA> Subject: pfFrustums and pfChannels To: iris-performer@sgi.sgi.com Date: Wed, 9 Mar 1994 15:54:28 -0700 (MST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 892 Status: O I am using Performer 1.1 on an Onyx RE2. I am trying to do off-axis perspective. How can I do this with 1.1? Is there a call like pfSetChanFrust(pfChannel *chan, pfFrustum *frust) which would --- facilitate this? A previous message seemed to indicate that one could use pfMakePerspFrust(), which sets up a pfFrustum. Are pfFrustums and pfChannels compatible enough to be used in this way? Is this a valid way of assigning an asymmetric viewing frustum to a channel? Thanks, Glen. ------------------------------------------------------------------ | Glen D. Fraser | fraser@banffcentre.ab.ca | | Work: (403)762-6669 | | | Virtual Reality Developer | "Let it well be known, | | The Banff Centre for the Arts | These opinions are my own." | ------------------------------------------------------------------ From guest Wed Mar 9 15:18:48 1994 Return-Path: Date: Wed, 9 Mar 94 18:17:40 EST From: flip@cgrg.ohio-state.edu (Flip Phillips) Message-Id: <9403092317.AA03725@sap.cgrg.ohio-state.edu> To: fraser@BanffCentre.AB.CA Cc: iris-performer@sgi.sgi.com In-Reply-To: <9403092254.AA15169@moose.BanffCentre.AB.CA> (fraser@BanffCentre.AB.CA) Subject: Re: pfFrustums and pfChannels Status: O From: fraser@BanffCentre.AB.CA (Glen Fraser) Date: Wed, 9 Mar 1994 15:54:28 -0700 (MST) I am using Performer 1.1 on an Onyx RE2. I am trying to do off-axis perspective. How can I do this with 1.1? Is there a call like pfSetChanFrust(pfChannel *chan, pfFrustum *frust) which would --- not available 'til v1.2 I believe. -- flip From guest Wed Mar 9 19:24:19 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403100324.AA22011@tubes.asd.sgi.com> Subject: Re: pfFrustums and pfChannels To: guest (Flip Phillips) Date: Wed, 9 Mar 94 19:24:07 PST Cc: fraser@BanffCentre.AB.CA, iris-performer@sgi.sgi.com In-Reply-To: <9403092317.AA03725@sap.cgrg.ohio-state.edu>; from "Flip Phillips" at Mar 9, 94 6:17 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > From: fraser@BanffCentre.AB.CA (Glen Fraser) > Date: Wed, 9 Mar 1994 15:54:28 -0700 (MST) > > I am using Performer 1.1 on an Onyx RE2. I am trying to do off-axis > perspective. How can I do this with 1.1? Is there a call like > pfSetChanFrust(pfChannel *chan, pfFrustum *frust) which would > --- > > not available 'til v1.2 I believe. > > > -- flip > This is correct. In 1.2, pfChannel is "derived" from pfFrustum so you can call pfMakePerspFrust on a pfChannel. From guest Thu Mar 10 00:36:58 1994 Message-Id: <9403100836.AA19690@surreal.asd.sgi.com> To: fraser@banffcentre.ab.ca (Glen Fraser) Cc: info-performer@sgi.sgi.com Subject: Re: pfFrustums and pfChannels In-Reply-To: Your message of "Wed, 09 Mar 94 15:54:28 MST." <9403092254.AA15169@moose.BanffCentre.AB.CA> Date: Thu, 10 Mar 94 00:36:43 -0800 From: Jim Helman Status: O > I am using Performer 1.1 on an Onyx RE2. I am trying to do off-axis > perspective. How can I do this with 1.1? Is there a call like > pfSetChanFrust(pfChannel *chan, pfFrustum *frust) which would Doing off-axis work in 1.1 requires that you set the channel viewpoint and FOV so that the on-axis frustum used for culling, encompasses the off-axis frustum you really want. Then in the channel draw callback, set the GL matrix perspective and viewing matrices appropriately. Here's how 1.1 initializes them by default: window(winLeft, winRight, winBottom, winTop, near, far); mmode(MVIEWING); loadmatrix(ident); rot(-90, 'x'); /* convert from GL to Performer coords */ { pfMatrix invViewMat; pfOrthoNInvertMat(invViewMat, ViewMat); multmatrix(invViewMat); } rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Mar 10 03:38:21 1994 From: "Ran Yakir" Message-Id: <9403101337.ZM10354@rea1.bvr.co.il> Date: Thu, 10 Mar 1994 13:37:02 +0000 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Fog Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi All I'm using spline fog on Performer 1.2, and have 2 questions 1. The spline fog doesn't work on every RealityEngine machine. Furthermore, on our dual-headed ONYX, it works on the zeroth head but not on the other one. By 'doesn't work' I mean that you set the fog, but see no fog whatsoever. 2. Is it expensive to set the fog ranges and ramp each frame ? Is it better to create several fogs and just switch between them when necesary ? Here is the code fragement that generates the fog : /* * init_fog() is called once at the beginning of time */ void init_fog (nrt_fog *fog) { fog->is_fog = 0; fog->fog = pfNewFog (pfGetSharedArena()); fog->fog_type = PFFOG_PIX_SPLINE; pfFogType (fog->fog, fog->fog_type); pfFogColor (fog->fog, 1.0, 1.0, 1.0); fog->onset_range = 20000.0; fog->opaque_range = 50000.0; pfFogRange (fog->fog, fog->onset_range, fog->opaque_range); pfGetFogRamp (fog->fog, &fog->nof_points, fog->ramp_range, fog->ramp_density, &fog->ramp_bias); } /* * update_env() is called each frame and updates the fog among other things */ void update_env (pfChannel *chan, nrt_environment *env) { /* * do other things */ .... /* * do fog */ pfFogType (env->fog.fog, env->fog.fog_type); pfFogRange (env->fog.fog, env->fog.onset_range, env->fog.opaque_range); pfFogRamp (env->fog.fog, env->fog.nof_points, env->fog.ramp_range, env->fog.ramp_density, env->fog.ramp_bias); if (env->fog.is_fog) pfESkyFog (esky, PFES_GENERAL, env->fog.fog); else pfESkyFog (esky, PFES_GENERAL, NULL); pfChanESky (chan, esky); /* * do more other things */ .... } Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Fri Mar 11 08:29:47 1994 Date: Fri, 11 Mar 94 11:28:21 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9403111628.AA06926@ldsa.com> To: info-performer@sgi.sgi.com Status: O The pfBillboard seems to be fairly simple, but I cannot get even a simple one to display. Does someone have a snipit of code where they create a billboard. A billboard with a single white polygon would be sufficient. What I am trying is like a series of telephone poles. I create a geoset for the pole, and try to create multiple billboards of the pole. I don't see the problem. I am running Performer 1.0 on an Indigo2 with IRIX 4.0. Mike Williams mwilliam@ldsa.com (216)796-8644 From guest Fri Mar 11 11:25:12 1994 Message-Id: <9403111924.AA05623@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Fri, 11 Mar 94 11:28:21 EST." <9403111628.AA06926@ldsa.com> Date: Fri, 11 Mar 94 11:24:29 -0800 From: Jim Helman Status: O Try turning off backface culling, perhaps they are backwards? I think the 1.0 man page may have been incorrect about the orientation. Here's a code fragment. Note that the code is inefficient in that it only has one billboard polygon per pfBillboard node. Several pfGeoSets would per pfBillboard be better. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 pfVec2 STexCoords[] ={{0.0f, 0.0f}, {1.0f, 0.0f}, {0.0f, 1.0f}, {1.0f, 1.0f}}; pfVec3 SVertCoords[] ={{-0.5f, 0.0f, 0.0f}, { 0.5f, 0.0f, 0.0f}, {-0.5f, 0.0f, 1.0f}, { 0.5f, 0.0f, 1.0f}}; long PrimLens[] = { 4 }; long seed = 0xe58a3e61; pfGroup *MakeBills(pfGroup *where, char **texNames, long nBills, float *sizes) { void *arena = pfGetSharedArena(); pfTexture *tex[MAX_BILL_TEX]; pfTexEnv *tenv; pfGroup *group; long i,j; pfBox bbox; float xorigin, yorigin; float xrange, yrange; pfCoord c; pfGeode *geode; char filepath[256]; long nVerts = 4; long nTex = 0; srand48(seed); pfGetNodeBBox(where, &bbox, NULL); xorigin = bbox.min[0]; yorigin = bbox.min[1]; xrange = bbox.max[0] - bbox.min[0]; yrange = bbox.max[1] - bbox.min[1]; tenv = pfNewTEnv(arena); /* pfTEnvMode(tenv, PFTE_DECAL); */ for (i = 0 ; texNames[i] != NULL ; i++) { tex[i] = pfNewTex(arena); if (!pfFindFile(texNames[i], filepath, R_OK)) { fprintf(stderr, "WARNING: unable to find texture file \"%s\"\n", texNames[i]); return NULL; } if (!pfLoadTexFile(tex[i], filepath)) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "couldn't find %s\n", texNames[i]); pfTexRepeat(tex[i], PFTEX_WRAP, PFTEX_CLAMP); nTex++; } if (nTex == 0) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "no textures for billboards\n"); group = pfNewGroup(); for(i = 0, j = 0 ; i < nBills && j < 10 * nBills ; j++) { float p, r; pfCoord pos; pfVec4 *colors; pos.xyz[0] = drand48() * xrange + xorigin; pos.xyz[1] = drand48() * yrange + yorigin; pfSetVec3(pos.hpr, 0.0f, 0.0f, 0.0f); if (GetZPR((pfNode *)where, &pos, &pos.xyz[2], &p, &r)) { long k; pfVec3 *verts; pfGeoSet *gset; pfGeoState *gst; pfBillboard *bill; float size; pfVec3 *posarr; size = (drand48() * 0.5f + 0.5f) * sizes[i%nTex]; verts = (pfVec3 *)pfMalloc(sizeof(pfVec3)*nVerts, arena); for (k = 0 ; k < nVerts ; k++) pfScaleVec3(verts[k], size, SVertCoords[k]); colors = (pfVec4 *)pfMalloc(sizeof(pfVec4), arena); pfSetVec4(colors[0], 0.6f * drand48(), 0.4 + 0.4 * drand48(), 0.0f, 1.0f); gset = pfNewGSet(arena); pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, NULL); pfGSetAttr(gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, STexCoords, NULL); pfGSetAttr(gset, PFGS_COLOR4, PFGS_PER_PRIM, colors, NULL); pfGSetPrimLengths(gset, PrimLens); pfGSetPrimType(gset, PFGS_TRISTRIPS); pfGSetNumPrims(gset, 1); gst = pfNewGState(arena); pfGStateAttr(gst, PFSTATE_TEXTURE, tex[i%nTex]); pfGStateAttr(gst, PFSTATE_TEXENV, tenv); pfGStateMode(gst, PFSTATE_ALPHAFUNC, PFAF_NOTEQUAL); pfGStateMode(gst, PFSTATE_ALPHAREF, 0); pfGStateMode(gst, PFSTATE_ENLIGHTING, 0); /* pfGStateMode(gst, PFSTATE_TRANSPARENCY,PFTR_ON); */ pfGSetGState(gset, gst); bill = pfNewBboard(); pfAddGSet(bill, gset); pfBboardPos(bill, 0, pos.xyz); pfAddChild(group, bill); i++; } } if (i < nBills) fprintf(stderr, "Only planted %d billboards\n", i); return group; } From guest Sat Mar 12 18:53:19 1994 Message-Id: <9403130253.AA04421@wavefront.wti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 12 Mar 1994 22:51:34 -0500 To: info-performer@sgi.sgi.com From: marc@wti.com (Marc Roth) Subject: Information on Use of Performer with Wavefront's Advanced Visualizer Status: O I have several clients who are interested in any information from people who are currently using Performer with The Advanced Visualizer. ANY information on translators, performance, etc. would be greatly appreciated. Thanks in advance. Marc Roth (703)241-8878 marc@wavefront.wti.com From aschaffe Wed Mar 16 02:17:18 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403160217.ZM20193@holodeck.asd.sgi.com> Resent-Date: Wed, 16 Mar 1994 02:17:17 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <9403141401.AA06478@sgi.sgi.com> Date: Mon, 14 Mar 1994 08:03:48 -0600 From: lechnerr@adadv1.mdc.com To: guest Subject: G Dimming X-Vms-To: SMTP%"guest@holodeck.asd.sgi.com" Status: O I'm looking for the most efficient way to simulate G Dimming (slowly blacking out the display given a percentage intensity) for a fixed wing aircraft simulation with Performer. Any suggestions? MDTS Rob Lechner From guest Mon Mar 14 05:20:24 1994 To: info-performer@sgi.sgi.com Subject: Audio Systems Date: Mon, 14 Mar 94 14:20:09 CET From: "Infobyte S.R.L." Message-Id: <9403141420.aa11998@ax433.mclink.it> Status: O Hi all, we are looking for a 3D sound system that can work on ONYX machines in VR applications. We already have Paradigm Simulation AudioWorks, but we are looking for an alternative source. We have some information from Crystal River Egineering (Convolvotron, Acoustetron, ecc.), but it seems that their systems work only for headphones, instead we need ambient output (4 or more loudspeakers). Has anyone heard of or, better than all, experienced such a system? Thank you in advance for any information. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Mon Mar 14 06:46:57 1994 Date: Mon, 14 Mar 94 15:45:32 +0100 From: binni@avocado.mpib-tuebingen.mpg.de (Sabine Dartsch) Message-Id: <9403141445.AA25491@avocado> To: info-performer@sgi.sgi.com Subject: forms - library Status: O Does anybody have experience in binding the Performer (1.2) with the forms - library ??? Whenever I try to do it I get the error message, that all forms - functions I used are "unresolved". Thanks in advance. =============================================================================== Sabine Dartsch --- binni@cabbage.mpib-tuebingen.mpg.de ------------------------------------------------------------------------------- Max - Planck Institut fuer | Spemannstr. 38 biologische Kybernetik | 72076 Tuebingen, Germany ------------------------------------------------------------------------------- Phone: +49-7071-601.xxx FAX: -49 7071 601575 Office: xxx=602 Secretary: xxx=601 =============================================================================== From guest Mon Mar 14 05:57:04 1994 From: "Ran Yakir" Message-Id: <9403141555.ZM412@rea1.bvr.co.il> Date: Mon, 14 Mar 1994 15:55:51 +0000 Return-Receipt-To: "Ran Yakir" X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfLight vs. pfLightSource Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi All Does anybody know what's the difference of pfLight from pfLightSource ? It seems that pfLightSource got in there with the 1.2 release, since it has no mention in the old documentation. Why should I use one instead of the other, or other instead of the one ? Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Mon Mar 14 08:03:02 1994 Date: Mon, 14 Mar 94 08:02:53 -0800 From: ib@ivan (Ivan Bach) Message-Id: <9403141602.AA25501@ivan.asd.sgi.com> To: binni@avocado.mpib-tuebingen.mpg.de (Sabine Dartsch), info-performer@sgi.sgi.com Subject: Re: forms - library Status: O The forms library comes with some sample programs, such as a scientific calculator. Can you build and run those sample programs on your system? Specify the option -v on the cc command line. That will give you detailed information about how your program is compiled and linked. Then specify the option -v on the cc command line you use to compile and link your Peformer program. Are -L options and the forms library specified the same way in both cases? If not, please make necessary changes. Enter: printenv to check the setting of environment variables. Is the environment you use to build sample forms programs the same as the environment you use to build Peformer programs? The account you are using may be customized. That customization may be causing the problem you reported. Try to use an uncustomized account, an account that uses default settings. Ivan Bach, ib@sgi.com From guest Mon Mar 14 11:11:30 1994 Message-Id: <9403141911.AA04281@surreal.asd.sgi.com> To: "Ran Yakir" Cc: info-performer@sgi.sgi.com Subject: Re: pfLight vs. pfLightSource In-Reply-To: Your message of "Mon, 14 Mar 94 15:55:51 GMT." <9403141555.ZM412@rea1.bvr.co.il> Date: Mon, 14 Mar 94 11:11:21 -0800 From: Jim Helman Status: O pfLight is a libpr immediate mode/pfDispList creature. In 1.0/1.1, the only way to get a light in the scene was to call pfLightOn with the proper xform on the stack, typically in a callback. pfLightSource is a new 1.2 inhabitant of a libpf scene graph. It lets you just say 'I want a light there (XYZ in world coordinates)'. Much easier. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Mon Mar 14 14:05:49 1994 Date: Mon, 14 Mar 94 14:05:45 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9403142205.AA07463@holodeck.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Coming soon to a Pipeline near you Status: O Those of you with SGI support contracts will soon receive the latest edition of Pipeline (Mar/Apr 1994). It contains an article called, "IRIS Performer: An overview." The sample code in that article is now on-line and available via anonymous FTP to sgi.com; two files in the directory ~ftp/support/Pipeline: intersect.c - intersection sample for Performer 1.2 + intersect1-0.c - intersection sample for Performer 1.0/1.1 Enjoy.. Allan ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Mar 16 08:26:17 1994 Message-Id: <9403161626.AA06531@mithras.boston.sgi.com> To: info-performer@sgi.sgi.com Subject: please subscribe me Reply-To: dpy@sgibos.boston.sgi.com Date: Wed, 16 Mar 1994 11:26:12 -0500 From: David Youatt Status: O Thanks. -- David Youatt, dpy@sgi.com, 508/562-4800 x353 From guest Wed Mar 16 09:48:00 1994 From: "perfor" Message-Id: <9403161748.ZM8282@cathy.rennes.sgi.com> Date: Wed, 16 Mar 1994 17:48:27 +0100 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Could you subscribe me Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Thanks perfor@rennes.sgi.com From guest Wed Mar 16 09:11:57 1994 Message-Id: <9403161654.AA16034@sparky.bvu-lads.loral.com> X-Sender: mheinen@sparky.bvu-lads.loral.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Mar 1994 09:16:03 -0800 To: info-performer@sgi.sgi.com From: mheinen@bvu-lads.loral.com (Mark N. Heinen) Subject: Request to add Status: O subscribe info-performer@sgi.com ------------------------------------------------------------------------------- Mark N. Heinen Loral Advanced Distributed Simulation 13810 SE Eastgate Way Suite 500 Bellevue, WA 98005 EMail : mheinen@bvu-lads.loral.com Phone : (206) 957-3236 Fax : (206) 746-1335 From guest Wed Mar 16 13:00:37 1994 Message-Id: <199403162059.VAA10749@godemine.cmr.no> X-Authentication-Warning: godemine.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: godemine.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: Triangel problems... Date: Wed, 16 Mar 1994 21:59:50 +0100 From: Nils Thune Status: O Hi! My config: HW - Indigo2 Extreme SW - Performer 1.2 Problem: I'm creating a geometry node with one geoemtry set, which is a set with independent triangles (a geoemetry state ++ is also attached). This geometry is a set with coplanar triangles, representing an oil spill, where z = 1.0. I'm using an Earth Sky model were the ground height is set to 0.0. Now, if the z value for the oil spill is set to 0.0, the zbuffer gets messed up as expected. With z = 1.0, things get better, but the problem is that when these triangles are drawn, they now flicker randomly on and off like they are not double buffered or their Z value still is messed up (whole triangles dissapears and the ground/water shines through the oil spill at random spots). If my view point is close to z = 1.0 things are not that bad (only a few triangles, 10 out of 1000, flicker on and off), but moving up to z = [50 - 500] almost 50% percent turn on and off every frame. I have tried a lot of things like setting the lsetdepth, near and far plane is 1 and 5000, etc. but notting seems to help. I should add that models loaded with the FLT loader and added to the same scene (a boat floating around in the oil spill) behaves fine, so there must be something that I'm doing wrong here. Any help are highly appreciated! - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Wed Mar 16 17:34:10 1994 Date: Wed, 16 Mar 94 17:33:52 PST From: penafiel@guild.rdd.lmsc.lockheed.com (Hugo Penafiel) Message-Id: <9403170133.AA05579@guild.rdd.lmsc.lockheed.com> To: thune@cmr.no Subject: Re: Triangle problems... Cc: info-performer@sgi.sgi.com Status: O thune@cmr.no wrote: ============== > If my view point is close to z = 1.0 things are not that bad (only a few > triangles, 10 out of 1000, flicker on and off), but moving up to z = [50 - > 500] almost 50% percent turn on and off every frame. > I have tried a lot of things like setting the lsetdepth, near and far plane is > 1 and 5000, etc. but notting seems to help. ============== This problem sounds a lot like one we were puzzling over. The problem is due to the fact that the Z-buffering is suffering from numerical round off problems. The way to "fix" it is by setting your near clipping plane to something larger than what you are using now (try 5, 10 or 15 and see what happens). There is no magic number that will make it go away forever. "The solution is left as an exercise for the reader." So definitely experiment with many values to see what works for you. Hugo Penafiel email: penafiel@guild.rdd.lmsc.lockheed.com Lockheed Missiles & Space Co. Research & Development Division Palo Alto, CA From guest Wed Mar 16 19:23:37 1994 Date: Wed, 16 Mar 94 19:22:38 PST From: lee@igate1.hac.com (Craig A. Lee) Message-Id: <9403170322.AA06378@igate1.hac.com> To: info-performer@sgi.sgi.com Status: O SUBSCRIBE From guest Thu Mar 17 08:23:53 1994 From: "Angus Henderson" Message-Id: <9403171623.ZM3850@death.reading.sgi.com> Date: Thu, 17 Mar 1994 16:23:20 +0000 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@giraffe, nafo_gurus@giraffe, intl_gurus@giraffe, eurose@neu.sgi.com Subject: Cheap Modeller Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Medit Productions S.A. in Valencia have written a neat little 3D modelling tool ( it does heirarchy, LODs, textures etc..), which I have a version of on my own machine. We used it to design the new RealityCentre in Silicon Graphics UK as you can drop the files into both Performer & Inventor. If you would like to try it, ( and see our model of the RealityCentre to boot! ) take a copy of... guest@death.reading.sgi.com:/anarchy/RC_Export/Medit ( 27 Mb ) ...there are no restrictions on copying it because you need a licence to save anything but I think they will give a demo licence to each Silicon Graphics office as a cheap marketing ploy. ANgus Henderson The Reality Centre From guest Fri Mar 18 03:09:51 1994 From: "Angus Henderson" Message-Id: <9403181109.ZM5079@death.reading.sgi.com> Date: Fri, 18 Mar 1994 11:09:38 +0000 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@giraffe Subject: Cheap Modeller Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I have put Medit on sgi.com as ~ftp/pub/Medit.tar.Z if anyone external wants it. Angus Henderson The Reality Centre From guest Fri Mar 18 09:41:24 1994 Message-Id: <199403181740.SAA19706@godemine.cmr.no> X-Authentication-Warning: godemine.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: godemine.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Subject: Calling pfDraw twice.... Date: Fri, 18 Mar 1994 18:40:50 +0100 From: Nils Thune Status: O How can one render objects in the pfScene to the same frame number when the objects are located in different parts of the view frustrum, separated by a delta view voulme in which objects should not be rendered? | NearPlane=1.0 FarPlane=100.0 NearPlane=500.0 FarPlane=10000.0 | | | | | | | | | | ----> |-------------------------------------------------------------------- | | | | | | | | | | | Draw objects No drawing Draw objects View direction and viewplane Basically I want to do the following: 0. Clear channel. 1. Cull scene against the view volume defined by near=1.0, far=100.0. 2. Draw the objects which were not culled, i.e. the display list. 3. Cull scene against the view volume defined by near=500.0, far=10000.0 4. Draw the new objects which were not culled, i.e a new display list. 5. Swap buffers, and start over at 0. How can this be done? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Fri Mar 18 16:03:48 1994 Date: Fri, 18 Mar 94 14:55:37 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403182055.AA15472@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Using shared arenas Status: O Is there any problem with using shared memory arenas under Performer? IE: usinit() in addition to pfDataPool(). I am experiencing problems with pfDataPools when using shared memory also. Just curious if there is any conflict that I should be aware of. More generally: What is the best way to share memory between non-related processes in Performer without having to link with Performer on both processes. In other words, one process is a performer process, and another is just doing messages and things of that nature.. Thanks for any help, _ Aaron Hightower - aaron@dseg.ti.com | | Visualization & Simulation __| |___ Technology Development, TI \ * / <--- Plano, TX! Voice: (214)575-6759 \_ / FAX: (214)575-6779 \ ( \/ From guest Mon Mar 21 07:13:53 1994 From: susi@avocado.mpib-tuebingen.mpg.de (Susanne Huber) Message-Id: <9403211513.AA04860@avocado> Subject: Real-Time Simulation To: info-performer@sgi.sgi.com Date: Mon, 21 Mar 94 16:13:17 MEZ X-Mailer: ELM [version 2.3 PL8] Status: O I'm working on an autonomous navigation system based on the optical flow. (Onyx RE^2, Performer 1.2) Until now the algorithm, which is computing the next heading direction isn't a real-time algorithm. I have the feeling that Performer gets in trouble with the synchronisation, if the application lasts a lot longer (here ca. 2 seconds) than the framerate. Does anybody have experience whether Performer can handle those applications which last longer than the FrameRate? Or is it perhaps better to use Inventor for this problem? Or the other way round: synchronisation starts with the call to pfSync(). Does the synchronisation sleep after the call to pfFrame until pfSync is called again? If that is true, I could call the appliation before calling pfSync or after calling pfFrame, and there wouldn't be any synchronisation problems? Thanks in advance Susanne H. -- ---------------------------------------------------------------- Susanne Huber Max-Planck-Institut f"ur Biologische Kybernetik Spemannstr. 38 72076 Tuebingen e-mail: susi@spinach.mpib-tuebingen.mpg.de ---------------------------------------------------------------- From guest Mon Mar 21 09:49:55 1994 From: "pierre VERCRUYSSE" Message-Id: <9403211749.ZM4960@cathy.rennes.sgi.com> Date: Mon, 21 Mar 1994 17:49:45 +0100 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: performer 1.2preMR Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi I try to install the performer 1.2preMR (alpha 150) on an Indigo 2 with Irix 5.2MR and Performer 1.2 a94. The inst tools say me that this versions is an older one than the alpha 94 ? Have you an idea ? pierre@rennes.sgi.com From guest Mon Mar 21 09:33:33 1994 Date: 21 Mar 94 12:30:25 EST From: Colin Dooley <100346.1122@CompuServe.COM> To: Subject: Medit modeller Message-Id: <940321173024_100346.1122_BHJ58-1@CompuServe.COM> Status: O Re: Medit modeller. We seem to have caused a bit of a fuss with our modelling software. If anybody is interested in getting a demo tape, or would like more details, please fax your company details to us at ++346 372 6063, and tell us what sort of tape you would like (we can supply DAT or QIC-150). Thanks, Colin Dooley, Medit productions. 100346.1122@compuserve.com From guest Mon Mar 21 10:24:37 1994 Date: Mon, 21 Mar 94 13:02:01 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9403211802.AA11421@ldsa.com> To: info-performer@sgi.sgi.com Status: O I am using Performer 1.0 with an Indigo Extreme running Irix 4.0 . This fog is implemented over a very simple data base with some pfLightPoints, and some simple polygon geosets. My problem is that the fog only seems to be applied to the polygons. The lightpoints continue to shine through the fog at any distance. I am applying the fog in the EarthSky model similar to the way it is done in perfly. I am using black as the fog color to simulate night-time conditions. Is there a setting I missed which makes fog apply to lights? I have considered replacing my LightPoints with small polygons to avoid the 1 pixel maximum for lightpoints on this system. If I have emissive polygons will they also shine through the fog? Any help on this is appreciated. Mike Williams mwilliam@ldsa.com (216) 796-8644 From guest Mon Mar 21 10:31:17 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403211830.AA05004@tubes.asd.sgi.com> Subject: Re: performer 1.2preMR To: guest (pierre VERCRUYSSE) Date: Mon, 21 Mar 94 10:30:58 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403211749.ZM4960@cathy.rennes.sgi.com>; from "pierre VERCRUYSSE" at Mar 21, 94 5:49 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > Hi > > I try to install the performer 1.2preMR (alpha 150) on an Indigo 2 with Irix > 5.2MR and Performer 1.2 a94. The inst tools say me that this versions is an > older one than the alpha 94 ? > > Have you an idea ? > > pierre@rennes.sgi.com > This is as result of changing internal version numbers between releases. We used to have silly numbers but now use human-recognizable numbers. Alpha 94 used 1008404916 while 151 uses 1008000151 and inst sees that 151 is < 404916 so it complains. The solutions are to "set neweroverride on" while installing or to "versions -remove performer_dev; versions -remove performer_eoe;" before installing a151. From guest Mon Mar 21 11:10:12 1994 Date: 21 Mar 94 14:05:59 EST From: Colin Dooley <100346.1122@CompuServe.COM> To: Subject: Medit pricing Message-Id: <940321190558_100346.1122_BHJ72-4@CompuServe.COM> Status: O Re: Medit pricing. Medit costs approx 1600 US dollars. Stop sending the e-mail! Colin Dooley From guest Mon Mar 21 11:55:31 1994 From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403211950.AA01461@skips.dseg.ti.com> Subject: Re: Real-Time Simulation To: iris-performer@sgi.sgi.com Date: Mon, 21 Mar 94 13:50:06 CST X-Mailer: ELM [version 2.3 PL0] Status: O > From: susi@avocado.mpib-tuebingen.mpg.de (Susanne Huber) > > Until now the algorithm, which is computing the next heading > direction isn't a real-time algorithm. > I have the feeling that Performer gets in trouble with the > synchronisation, if the application lasts a lot longer (here ca. 2 seconds) > than the framerate. > -- from the pfConfig man page: Each pfPipe has a cull and draw stage which may be configured as either one or two processes. The intersection stage is independent of any pfPipe and may run in the same process as the application process or as a process by itself. In the latter case, the user may further multiprocess intersection traversals through any IRIX multiprocessing mechanism such as fork, sproc, or m_fork. -- It seems that what you may be able to do is create a user-defined intersection process that handles the high compute-intensive heading determination, and places the result in shared memory (EG ViewState->myHeading)... -- from the pfIsectFunc man page: Within the intersection callback, the user may further multiprocess intersection queries through any IRIX multiprocessing mechanism such as fork, sproc, or m_fork. All of these processes may call pfSegsIsectNode in parallel. When the intersection function is in a separate process, it will run asynchronously with the rest of the rendering pipeline. Specifically, if the intersection function takes more than a frame time, the rendering pipeline will not be affected. -- > > Does anybody have experience whether Performer can handle those applications > which last longer than the FrameRate? > Or is it perhaps better to use Inventor for this problem? There is more information in pfIsectFunc man page that you definitely want to check out. > Or the other way round: synchronisation starts with the call to > pfSync(). Does the synchronisation sleep after the call to pfFrame > until pfSync is called again? > If that is true, I could call the appliation before calling pfSync or > after calling pfFrame, and there wouldn't be any synchronisation > problems? Hope this helps! _ Aaron Hightower - aaron@dseg.ti.com | | . Visualization & Simulation __| |___ Technology Development, TI \ =/=/ Voice: (214)575-6759 \X / / FAX: (214)575-6779 \ ( \/ From guest Tue Mar 22 08:42:03 1994 Date: Tue, 22 Mar 94 08:41:07 -0800 From: mars@clubted.csd.sgi.com (David Marsland) Message-Id: <9403221641.AA08273@clubted.csd.sgi.com> To: shj@swlvx2.msd.ray.com Subject: Stereo code examples for Onyx/RE? Cc: info-performer@sgi.sgi.com Status: O I'm passing on this request for Steve Joyce. Please respond to him at shj@swlvx2.msd.ray.com if you have any Onyx/RE stereo examples you'd like to share. Sorry if this is an FAQ. Steve, if you would like to join this mailing group you can send mail to info-performer-request@sgi.com. Steve Joyce wrote: (stuff deleted) > an Onyx example of stereo viewing that you knew of when I raised the > question at the end of class. I'm in general looking for some examples of > stereo viewing programs if you happen to know of any (besides a couple > in 4Dgifts). > > Thanks for any help - > > Steve Joyce > /* David Marsland "On Spaceship Earth * * MTS, Worldwide Education R&D there are no passengers, * * Silicon Graphics Computer Systems only crew." * * Internet: mars@csd.sgi.com Buckminster Fuller */ From guest Tue Mar 22 08:53:15 1994 Date: Tue, 22 Mar 94 17:57:59 +0100 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9403221657.AA27416@scl> To: info-performer@sgi.sgi.com Subject: From GL world to PF world ... how to translate viewing ?????? Status: O HI ... Trying to recover camera trajectory from a GL defined world to to Performer world, I have several problems to get the right result ... My original information is XYZ position, XYZ target and roll of the camera in a GL environment ... how to translate it in a Performer based world ? ... Any information will be welcome to improve my beginer's knowledge about it ... Thank's to everybody ... Cedric PS: Is there another solution if I can get the Eulers angles from GL world ? Email: gce@syseca.fr ==================== From guest Tue Mar 22 09:09:34 1994 Date: Tue, 22 Mar 94 09:08:47 -0800 From: ib@ivan (Ivan Bach) Message-Id: <9403221708.AA17990@ivan.asd.sgi.com> To: mars@clubted.csd.sgi.com (David Marsland), shj@swlvx2.msd.ray.com Subject: Re: Stereo code examples for Onyx/RE? Cc: mars@csd.sgi.com, info-performer@sgi.sgi.com Status: O Article: 274 of comp.sys.sgi.hardware Subject: General info about SGI stereo (was: How does one use stereo goggles?) Message-ID: Date: 3 Feb 93 17:24:59 GMT Organization: University of Illinois at Urbana In article <1kn5jqINNqs0@darkstar.UCSC.EDU> gross@maxwell.ucsc.edu (Mike Gross) writes: > One of the researchers in our department recently bought a pair of stereo > goggles for our SGI Crimson, but I haven't been able to find anyone in this > university who knows how to use them. I'm interested primarily in using > the goggles with Explorer (assuming this is possible), but I'm also interested > in finding out how to adapt existing GL programs to use the goggles. Does > anyone out there have any idea how to get this working? The goggles came > without an ounce of documentation, and SGI hasn't been very helpful, either. > Any help is appreciated. > > If you followup to this post, please e-mail me a copy, too. > > Mike Gross > Physics Board and Lick Observatory > Univ of California GO SLUGS!!!!! > Santa Cruz, CA 95064 > gross@lick.ucsc.edu Here is a quick general description of how the SGI stereo goggles work, for those who do not know much about them, and what must be done to have your programs use them: First of all, in order to see stereo images on your SGI monitor, you need to have both the glasses AND special stereo hardware installed in your machine. Just buying some glasses will not allow you to see in stereo. So if your computer did not come already equipped for stereo display, the glasses won't help any. Second, here is the general method used by the stereo system: connected to the SGI is an infrared emitter, which you place generally on top of or right next to your monitor. The glasses have a detector on them that senses the signal being put out by this emitter. In your program (or from the Unix command prompt) you issue a command to switch the monitor into stereo mode; this changes the frequency of screen updates from 60 times/sec to 120 times/sec. Thus, the monitor updates the screen twice as fast as it does in non-stereo mode. The purpose for this is that to see stereo, you must have two images, a left-eye image and a right-eye image, and so the monitor with display the two images each 60 times/sec, for a total of 120 images updates/sec. In fact, each second it draws the left eye image, then the right eye image, and alternates drawing left-right. The infrared emitter puts out a signal which tells the glasses which eye's image is currently being drawn, and the glasses, which contain LCD lenses, darken the lens of the eye for which the image is not being drawn. So, when the monitor displays the left eye image, the glasses make the right lens black, and vice versa. Each eye sees 60 images/second still, and sees only the image for that eye. The special stereo hardware is required to keep everything in sync, and to allow the monitor to display 120 images/sec. Third, here is what must be done to display stereo images from your program: step one is to switch the monitor into stereo mode; there are some demo programs in ~demos/Stereo, including a utility to check and see if your system has the stereo option installed. In these demo programs is some code they provide to switch between stereo/non-stereo. On our system, however, there were already installed the programs 'onstereo' and 'offstereo' which could be used from the command prompt (or a system() call in a program) to switch stereo modes. ~demos/Stereo also provides examples on how to draw images in your program to display in stereo. Basically, there is no way to take just any program executable lying around and make it display in stereo; you need to rewrite the drawing routines so that they properly display the image such that it will look 3-D to a person wearing the stereo glasses. Also, the stereo option works best only when your graphics window is the size of the entire screen. Normally, of course, the SGI display is 1280 x 1024 pixels; when in stereo mode, the display 'wraps around' 1/2 of this and displays it on top of the other 1/2. Actually, here is how the original display is mapped to the stereo display: +----------------------+ (1279, 1023) | | | | | | | left eye image | | | | | | | +----------------------+ (1279, 532 = YOFFSET) | space not used | | by either eye | +----------------------+ (1279, 491 = YMAXSTEREO) | | | | | | | right eye image | | | | | | | 0,0+----------------------+ (1279,0) So, in your program, you must draw the same image twice, using a slightly different perspective for each eye. Here is a quick list of steps you coud use: a) for the right eye: 1) set the viewport to the right eye region: viewport(0,XMAXSCREEN,0,YMAXSTEREO); 2) set the perspective so that you are looking at the object from the right eye's position, i.e. if you use a 'lookat' perspective call (there are no doubt much more sophisticated methods to do this; this is just a quick example): perspective(450, 0.5*(float)XMAXSCREEN/(float)YMAXSTEREO, nearClip, farClip); lookat(SGIeyeSep, 0.0, eyePosition[2], 0.0, 0.0, 0.0, 0); 3) draw the image b) for the left eye: 1) set the viewport to the left eye region: viewport(0,XMAXSCREEN,YOFFSET,YOFFSET + YMAXSTEREO); 2) set the perspective for the left eye: perspective(450, 0.5*(float)XMAXSCREEN/(float)YMAXSTEREO, nearClip, farClip); lookat(-SGIeyeSep, 0.0, eyePosition[2], 0.0, 0.0, 0.0, 0); 3) draw the image If this is done, then the monitor will display the two images right on top of each other, and the glasses will only see the left eye image in the left eye, etc. Note that each image will only have about 1/2 the vertical resolution possible in non-stereo mode; this is the price that must be paid for the 3-D effect (besides the fact that drawing each frame will take twice as long, since each frame requires two redraws). -- Bill Humphrey (billh@lisboa.ks.uiuc.edu) (Beckman Institute - University of Illinois) (405 North Matthews) (Urbana, IL 61801) ---------------------------- Article: 283 of comp.sys.sgi.hardware From: spencer@hailwood.asd.sgi.com (Paul Spencer) Subject: Re: General info about SGI stereo (was: How does one use stereo goggles?) Date: 5 Feb 1993 02:39:29 GMT Organization: Silicon Graphics, Inc., Mountain View, CA billh@lisboa.ks.uiuc.edu (William F. Humphrey) says: > [ excellent description of stereo mode and goggles deleted ] What Bill described is what we call `old-style' stereo on RealityEngine. (It's the only kind of stereo available on VGX'es and older). On RE, we have available `new-style' stereo, which differs in the following ways (otherwise, it's remarkably similar): - Instead of using two different pieces of the screen for left and right eyes, your software uses the SAME window in the SAME place. Just as each window has a front and a back buffer, a window in new-style stereo mode has a left buffer and a right buffer. Well, in fact, it has FOUR: left-front, left-back, right-front, right-back. - a new-style stereo program looks something like this: winopen(""); doublebuffer(); stereobuffer(); gconfig(); while (1) { leftbuffer(TRUE); rightbuffer(FALSE); /* draw scene as seen from the left eye here */ leftbuffer(FALSE); rightbuffer(TRUE); /* draw scene as seen from the right eye here */ swapbuffers(); } - new-style stereo has one huge advantage over old-style stereo: non-stereo programs on your screen look normal! That's right, all of your xwsh/xterm/xclock/etc. all look just like they do today; no mad flickering, no seeing them in just one eye. Everything works just like normal (even if you aren't wearing the glasses!) - The screen in new-style stereo is less strangely shaped (1280 x 492 is kind of an odd aspect ratio!) Formats available are: 1025 x 768 at 96 Hz 640 x 512 at 120 Hz 815 x 611 at 120 Hz 960 x 680 at 108 Hz ....paul -- Paul Spencer Silicon Graphics Advanced Graphics Division spencer@sgi.com Mountain View, California ---------------- Article: 28247 of comp.sys.sgi From: martinm@sgi.com (Martin McDonald) Subject: Re: Stereo in a window on a RealityEngine Message-ID: <1992Nov12.155346.13219@news.csd.sgi.com> Sender: news@news.csd.sgi.com (Net News CSD) Organization: Silicon Graphics, Inc., Mountain View, CA References: <17403@borg.cs.unc.edu> Date: Thu, 12 Nov 1992 15:53:46 GMT In article <17403@borg.cs.unc.edu> cullip@pooh.cs.unc.edu (Timothy Cullip) writes: >We have a loaner Crimson/RealityEngine that we are evaluating for >our needs. One of our needs is stereo in a window (which I've heard >it is capable of doing. Does anyone out there have a simple example >program that demonstrates this capability? If so, could I get my >nands on the source code? try this one out. note from the header you need to change the video output format to do stereo per window. to do this you need to be root. run /usr/gfx/setmon 960x680_108s . then run /usr/gfx/stopgfx followed up with /usr/gfx/startgfx . you will lose some screen real estate, but you will be able to do single window stereo. this program will be found in 4Dgifts soon. /*********************************************************************** * * * Stereo In Window Sample Program * * * * WARNING: YOU MUST RUN 960x680_108s VOF TO USE STEREO IN WINDOW * * WILL ONLY WORK ON REALITY ENGINE * ***********************************************************************/ #include #include #define XSIZE 640.0 #define YSIZE 512.0 static Matrix idmat = { 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0, }; static float mat[] = { AMBIENT, 0.35, 0.25, 0.1, DIFFUSE, 0.65, 0.5, 0.35, SPECULAR, 0.0, 0.0, 0.0, SHININESS, 0.0, LMNULL }; static float lig[] = { AMBIENT, 0.0, 0.0, 0.0, LCOLOR, 1.0, 1.0, 1.0, POSITION, 0.0, 0.0, -1.0, 0.0, LMNULL }; static float mod[] = { AMBIENT, 0.3, 0.3, 0.3, LOCALVIEWER, 0.0, LMNULL }; static float ang = 0.0; static float v[8][3] = { -1.0,-1.0,-1.0, 1.0,-1.0,-1.0, 1.0, 1.0,-1.0, -1.0, 1.0,-1.0, -1.0,-1.0, 1.0, 1.0,-1.0, 1.0, 1.0, 1.0, 1.0, -1.0, 1.0, 1.0, }; static float n[6][3] = { 0.0, 0.0, 1.0, 0.0, 0.0,-1.0, 0.0, 1.0, 0.0, -1.0, 0.0, 0.0, 0.0,-1.0, 0.0, 1.0, 0.0, 0.0, }; static void draw_scene(long); static void draw_polyg(float *,float *,float *,float *,float *); main() { foreground(); prefposition(0,XSIZE-1,0,YSIZE-1); winopen("Stereo In Window"); RGBmode(); doublebuffer(); stereobuffer(); gconfig(); if (!getgconfig(GC_DOUBLE) || !getgconfig(GC_STEREO)) { fprintf(stderr,"ERROR: Could not configure doublebuffer stereo!\n"); exit(0); } subpixel(TRUE); zbuffer(TRUE); lsetdepth(getgdesc(GD_ZMIN),getgdesc(GD_ZMAX)); lmdef(DEFMATERIAL, 1, 0, mat); lmdef(DEFLIGHT, 1, 0, lig); lmdef(DEFLMODEL, 1, 0, mod); lmbind(MATERIAL, 1); lmbind(LMODEL, 1); mmode(MPROJECTION); perspective(450,XSIZE/YSIZE,0.1,100.0); mmode(MVIEWING); loadmatrix(idmat); lmbind(LIGHT1,1); while (1) { leftbuffer(TRUE); rightbuffer(FALSE); draw_scene(0); leftbuffer(FALSE); rightbuffer(TRUE); draw_scene(1); swapbuffers(); } } static void draw_scene(long flag) { czclear(0,getgdesc(GD_ZMAX)); pushmatrix(); /* left/right eye */ if (flag == 0) lookat(5.0,-1.0,0.0,0.0,0.0,0.0,0); else lookat(5.0, 1.0,0.0,0.0,0.0,0.0,0); ang+=2.0; rotate(ang,'y'); rotate(ang/2.7,'z'); cpack(0xffffffff); draw_polyg(v[0],v[1],v[2],v[3],n[0]); draw_polyg(v[4],v[5],v[6],v[7],n[1]); draw_polyg(v[0],v[1],v[5],v[4],n[2]); draw_polyg(v[1],v[2],v[6],v[5],n[3]); draw_polyg(v[2],v[3],v[7],v[6],n[4]); draw_polyg(v[3],v[0],v[4],v[7],n[5]); popmatrix(); } static void draw_polyg(float *v0,float *v1,float *v2,float *v3,float *n) { bgnpolygon(); n3f(n); v3f(v0); v3f(v1); v3f(v2); v3f(v3); endpolygon(); } -- Martin McDonald Up there they got a lot of sand, but down here we got a hot crustacean band. each little snail he know how to wail. that's why it's hotter under the water under the sea. -sebastian --------------------------------- Article: 227 of comp.sys.sgi.graphics From: airey@woof.asd.sgi.com (John Airey) Subject: Source for stereo demo... Date: 27 Jan 1993 22:25:09 GMT Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 435 Message-ID: <1k7245INNhc7@fido.asd.sgi.com> NNTP-Posting-Host: woof.asd.sgi.com Here is some source for a demo that uses stereo in a window. For RealityEngine. No promises or guarantees okay? It works for me. #include #include #include #include #include #define X 0 #define Y 1 #define Z 2 static int Colors[] = { 0xff7f1f9f, 0xff5f0f9f, 0xff9f0f3f, 0xff0f9fff, 0xffff1fff, 0xff3f5f4f, 0xff9f3f0f, 0xff1f2f1f, }; #define CFACES 6 #define VERTS_PER_CFACE 4 static float cdata[8][3] = {{-1., -1., -1.,}, { 1., -1., -1.,}, { 1., 1., -1.,}, {-1., 1., -1.,}, {-1., -1., 1.,}, { 1., -1., 1.,}, { 1., 1., 1.,}, {-1., 1., 1.,},}; static int cndex[CFACES][VERTS_PER_CFACE] = {{3, 2, 1, 0}, {4, 5, 6, 7}, {0, 1, 5, 4}, {1, 2, 6, 5}, {2, 3, 7, 6}, {3, 0, 4, 7},}; static float tex[4][2] = {{ 0., 0., }, { 1., 0., }, { 1., 1., }, { 0., 1., },}; static int NumFaces = 6; static int NumVertsPerFace = 3; static int LeftBuffer = 1; static float IOD = 2.3; maketexture(unsigned long t[], char *name, int x, int y) { int j,i,n=0; int r,g,b,a; IMAGE *iimage; unsigned short *st = (unsigned short *) t; short rbuf[1024],gbuf[1024],bbuf[1024],abuf[1024]; if ( (iimage = iopen(name,"r")) == NULL){ fprintf(stderr,"\nCANT OPEN %s\n\n",name); exit(1); } for (j= 0; j< x; j++){ getrow(iimage,rbuf,j,0); for (i= 0; i < y; i++){ st[n++]= (rbuf[i]) | (rbuf[i]<<8); } } iclose(iimage); } #define TEXSIZE 64 unsigned long tt1[TEXSIZE*TEXSIZE]; unsigned long tt2[TEXSIZE*TEXSIZE]; unsigned long tt3[TEXSIZE*TEXSIZE]; unsigned long tt4[TEXSIZE*TEXSIZE]; unsigned long tt5[TEXSIZE*TEXSIZE]; unsigned long tt6[TEXSIZE*TEXSIZE]; float Ztranslation = 0.; #define CONVERGENCETRACK 0 #define PARALLELVIEWS 1 #define SCREENCONVERGE 2 int StereoModel = CONVERGENCETRACK; float texps[] = { TX_MAGFILTER, TX_SHARPEN, TX_MINFILTER, TX_MIPMAP_TRILINEAR, TX_INTERNAL_FORMAT, TX_IA_8, TX_NULL }; float tevps[] = { TV_MODULATE, TV_NULL }; float ConvergenceFudge = 0.0; extern void draw_frame(float , float , float ); main() { short val, mval[2], lastval[2]; long org[2], size[2]; Device dev, mdev[2]; Boolean run; int leftmouse_down = 0; int middlemouse_down = 0; float rx,ry; float from[3]; float at[3]; char buf[80]; lastval[X] = -1; maketexture(tt1,"t1.rgba",TEXSIZE,TEXSIZE); maketexture(tt2,"t2.rgba",TEXSIZE,TEXSIZE); maketexture(tt3,"t3.rgba",TEXSIZE,TEXSIZE); maketexture(tt4,"t4.rgba",TEXSIZE,TEXSIZE); maketexture(tt5,"t5.rgba",TEXSIZE,TEXSIZE); maketexture(tt6,"t6.rgba",TEXSIZE,TEXSIZE); foreground(); noborder(); prefposition(0,959,0,679); winopen("StereoSpin"); RGBmode(); doublebuffer(); subpixel(1); zbuffer(1); stereobuffer(); gconfig(); if (!getgconfig(GC_STEREO)){ fprintf(stderr,"stereo not available\n"); exit(1); } tevdef(1,0,tevps); tevbind(0,1); texdef2d(1,2,TEXSIZE,TEXSIZE,tt1,0,texps); texdef2d(2,2,TEXSIZE,TEXSIZE,tt2,0,texps); texdef2d(3,2,TEXSIZE,TEXSIZE,tt3,0,texps); texdef2d(4,2,TEXSIZE,TEXSIZE,tt4,0,texps); texdef2d(5,2,TEXSIZE,TEXSIZE,tt5,0,texps); texdef2d(6,2,TEXSIZE,TEXSIZE,tt6,0,texps); mmode(MVIEWING); getorigin(&org[X], &org[Y]); getsize(&size[X], &size[Y]); mdev[X] = MOUSEX; mdev[Y] = MOUSEY; getdev(2, mdev, lastval); /* initialize lastval[] */ lastval[X] -= org[X]; lastval[Y] -= org[Y]; qdevice(LEFTMOUSE); qdevice(MIDDLEMOUSE); qdevice(ESCKEY); qdevice(MOUSEX); qdevice(MOUSEY); qdevice(SPACEKEY); qdevice(RETKEY); qdevice(UPARROWKEY); qdevice(DOWNARROWKEY); qdevice(LEFTARROWKEY); qdevice(RIGHTARROWKEY); while (1){ while (qtest()) { switch (dev = qread(&val)) { case LEFTMOUSE: leftmouse_down = val; break; case MIDDLEMOUSE: middlemouse_down = val; break; case MOUSEX: mval[X] = val - org[X]; break; case MOUSEY: mval[Y] = val - org[Y]; if (leftmouse_down) { rx += (mval[Y] - lastval[Y]); ry += (mval[X] - lastval[X]); } if (middlemouse_down){ Ztranslation += (mval[X] - lastval[X])*(1./8.); } lastval[X] = mval[X]; lastval[Y] = mval[Y]; break; case SPACEKEY: if (val){ StereoModel = (StereoModel+1)%3; } break; case RETKEY: if (val){ IOD = 2.3; StereoModel = CONVERGENCETRACK; ConvergenceFudge = 0.0; } break; case UPARROWKEY: if (val) ConvergenceFudge += 0.5; break; case DOWNARROWKEY: if (val) ConvergenceFudge -= 0.5; break; case LEFTARROWKEY: if (val) IOD -= .1; break; case RIGHTARROWKEY: if (val) IOD += .1; break; case ESCKEY: exit(0); } } /* * try to define everything in inches * */ #define SCREEN_WIDTH 15. /* width of screen in inches*/ #define SCREEN_HEIGHT 10.625 /* height of screen in inches*/ #define DISTANCE_TO_SCREEN 19. /* distance from eye to screen (nearclip)*/ #define CLIP_FACTOR (1./8.00) /* to move near clip in */ #define NEAR_CLIP_DISTANCE (DISTANCE_TO_SCREEN*CLIP_FACTOR) #define FAR_CLIP_DISTANCE (DISTANCE_TO_SCREEN*30.) #define DESIRED_SIZE_ON_SCREEN 2. #define WORLD_SPACE_SIZE 2. if (LeftBuffer = !LeftBuffer){ leftbuffer(1); rightbuffer(0); from[X] = -IOD/2.; from[Y] = 0.0; from[Z] = DISTANCE_TO_SCREEN; at[X] = 0.0; at[Y] = 0.0; at[Z] = 0.0; } else{ leftbuffer(0); rightbuffer(1); from[X] = IOD/2.; from[Y] = 0.0; from[Z] = DISTANCE_TO_SCREEN; at[X] = 0.0; at[Y] = 0.0; at[Z] = 0.0; } if (StereoModel == CONVERGENCETRACK) { float dir[3],new_dir[3],mag, new_mag; /* compute old magnitude of lookat vector */ dir[X] = at[X]-from[X]; dir[Y] = at[Y]-from[Y]; dir[Z] = at[Z]-from[Z]; mag = dir[X]*dir[X] + dir[Y]*dir[Y] + dir[Z]*dir[Z]; mag = fsqrt(mag); /* compute new lookat direction */ new_dir[X] = dir[X]; new_dir[Y] = dir[Y]; new_dir[Z] = dir[Z]+Ztranslation+ConvergenceFudge; new_mag = new_dir[X]*new_dir[X] + new_dir[Y]*new_dir[Y] + new_dir[Z]*new_dir[Z]; new_mag = fsqrt(new_mag); new_dir[X] /= new_mag; new_dir[Y] /= new_mag; new_dir[Z] /= new_mag; /* make sure new lookat direction has same mag as old lookat vector */ at[X] = new_dir[X]*mag + from[X]; at[Y] = new_dir[Y]*mag + from[Y]; at[Z] = new_dir[Z]*mag + from[Z]; } else if (StereoModel == PARALLELVIEWS){ if (LeftBuffer) at[X] = -IOD/2.; else at[X] = IOD/2.; } else if (StereoModel == SCREENCONVERGE){ } cpack(0x2f2f2f2f); zclear(); clear(); ortho2(0.,1.,0.,1.); cpack(0xffffffff); switch (StereoModel){ case CONVERGENCETRACK: sprintf(buf,"StereModel: CONVERGENCETRACK"); break; case PARALLELVIEWS: sprintf(buf,"StereModel: PARALLELVIEWS"); break; case SCREENCONVERGE: sprintf(buf,"StereModel: SCREENCONVERGE"); break; } cmov2(0.1,0.96); charstr(buf); sprintf(buf,"IOD: %2.1f",IOD); cmov2(0.4,0.96); charstr(buf); sprintf(buf,"centroid at: %3.1f inches", DISTANCE_TO_SCREEN-Ztranslation); cmov2(0.5,0.96); charstr(buf); /* sprintf(buf,"centroid at: %3.1f inches", DISTANCE_TO_SCREEN-Ztranslation); cmov2(0.5,0.96); charstr(buf); */ pushmatrix(); window(-CLIP_FACTOR*SCREEN_WIDTH/2., CLIP_FACTOR*SCREEN_WIDTH/2., -CLIP_FACTOR*SCREEN_HEIGHT/2., CLIP_FACTOR*SCREEN_HEIGHT/2., NEAR_CLIP_DISTANCE, FAR_CLIP_DISTANCE); lookat(from[X], from[Y], from[Z], at[X], at[Y], at[Z], 0); draw_frame(ry,-rx, DESIRED_SIZE_ON_SCREEN/WORLD_SPACE_SIZE); popmatrix(); if (LeftBuffer) swapbuffers(); } } void draw_frame(float ry, float rx, float s) { register int i,j; #if 0 cpack(0xafafafaf); for (i = 0; i < 20; i++){ float v1[3]; float v2[3]; v1[2] = 0.; v1[1] = SCREEN_HEIGHT/2.; v1[0] = SCREEN_WIDTH*((float)i/20.) - SCREEN_WIDTH/2; v2[2] = 0.; v2[1] = -SCREEN_HEIGHT/2.; v2[0] = SCREEN_WIDTH*((float)i/20.) - SCREEN_WIDTH/2; bgnline(); v3f(v1); v3f(v2); endline(); } #endif translate(0.,0.,Ztranslation); rot(ry,'y'); rot(-rx,'x'); scale(s,s,s); for (i = 0; i < NumFaces; i++){ cpack(Colors[i]); texbind(0,(i%6)+1); bgnpolygon(); for (j = 0; j < NumVertsPerFace; j++){ t2f(tex[j]); v3f(cdata[cndex[i][j]]); } endpolygon(); } texbind(0,0); } john m. airey airey@asd.sgi.com (415) 390-5248 M/S 7U-553 Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039 ------ Ivan Bach, ib@sgi.com From guest Tue Mar 22 09:25:48 1994 Date: Tue, 22 Mar 94 17:25:30 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9403221725.AA10007@death.reading.sgi.com> To: info-performer Subject: Detail Texture Status: O I can't work out how to get a nice detail texture into my scene. I would much rather do it through the libpfflt loader but I have a feeling that it does not allow me to control my "pfTexSpline" Does anyone know if I have fine control of detail texture directly through MultiGen and Loadflt ? I can set all the TX_CONTROL point values in the .attr files but it seems to have no effect on the scene. ANgus "Imagine your witty quote here" From guest Tue Mar 22 10:13:55 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403221813.AA12562@tubes.asd.sgi.com> Subject: Re: Performer questions To: aschaffe (Kevin Russo) Date: Tue, 22 Mar 94 10:13:46 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199403012345.XAA16581@midway>; from "Kevin Russo" at Mar 1, 94 11:45 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > >> - In one of our applications at least, the culling does not work properly. > >> Objects suddenly vanish before they leave the viewing frustrum. Any ideas > >> why this could be? We are not changing any of the GeoSets or other data in > >> the hierarchy after it has been initially set up. > > > > Print out the scene with pfDebugPrint and make sure your bounding > > boxes are reasonable. > > I found that for linestrips, anyway, Performer only checks if the first > point or so of the lineseg is in the viewing frustum, regardless of > the bounding box. Perhaps this little speed enhancing trick is at work > in other types of GeoSets? > > I overcame it by installing a node pre-cull callback like this: > node_cull_pre_cb() { pfCullResult(PFIS_ALL_IN); return PFTRAV_CONT; } > > It was most frustrating to watch my trajectory line segments disappear > any time the origin wasn't in view. Are you using pfDCSs? Your release has a bug where bounding volumes for pfDCSes are not properly updated as the pfDCS changes. Do you have a test database? From guest Tue Mar 22 10:41:48 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403221827.AA12595@tubes.asd.sgi.com> Subject: Re: Performance of RE2 doing perfly on town. To: guest (Rob Silvers) Date: Tue, 22 Mar 94 10:27:10 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403091811.AA07491@texas.nynexst.com>; from "Rob Silvers" at Mar 9, 94 1:11 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > > I just used perfly with the town database on an RE2 with the > following config: > > 128MB RAM > 2 RMs - 4MB texture memory each > 2 R4400 CPUs > > Most of the time, it ran at 30 fps, but sometimes was quite jumpy and > went to 15 fps. (mostly when I looked at the area where all the buildings > were). The stats display indicated that it was the draw processes that > was overrunning. My question is: what configuration can run this at 30fps > all the time? A 4RM/4CPU system can come very close to a steady 30Hz but there are certain views where you will drop to a lower frame rate. This database was not designed for a fixed frame rate. Also, try to change the phase to FREE_RUN (use the 'p' key to toggle through phase selections). This should dramatically reduce stuttering if you are currently using LOCK phase. > Were the textures being swapped on an 8MB texture system? > (meaning would more texture memory make it run at 30fps) Additional RM's do not increase texture memory. 4MB is the limit for RM4's while 16MB is the limit for RM5's. The town database fits entirely in texture memory so there is no texture paging. > My guess is that it is the RMs - does anyone know for sure? This is correct. Additional RMs would be most beneficial. A reasonable and cheaper alternative is to use a smaller VOF. In my experience, 960x680 (/usr/gfx/setmon 960x680_60) looks great and fill requirements are 1/2 of full res. In fact most vis sim customers think we're crazy when we run 1280x1024 non-interlaced since they're used to a much smaller, interlaced format. This should get you very close to a steady 30Hz. From guest Tue Mar 22 10:41:53 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403221841.AA13019@tubes.asd.sgi.com> Subject: Re: pfMakePerspFrust To: guest (Mark Visconti) Date: Tue, 22 Mar 94 10:41:43 PST Cc: iris-performer@sgi.sgi.com In-Reply-To: <199403092214.RAA08435@favorite.cis.ohio-state.edu>; from "Mark Visconti" at Mar 9, 94 5:14 pm X-Mailer: ELM [version 2.3 PL8] Status: O > I'm running 1.2beta on an Onyx RE^2. I need off-axis perspective views > so I am using pfMakePerspFrust(). I'm was not getting the desired results > so I called pfGetFrustFOV and pfGetFrustNearFar to verify the values. > While near and far matched, the horizontal and vertical field of view > differed from the values I passed. I am not using pfFrustAutoAspect() and > checked to make sure the default was PFFRUST_CALC_NONE. > Am I going about this the wrong way ? No, I think I screwed up the API in this particular area. By default, a pfChannel has PFFRUST_CALC_VERT auto aspect so when you call pfMakePerspFrust the vertical FOV will be tweaked. Contrary to what you might think, calling pfFrustAspect does not change the auto aspect value of the pfChannel. Also, pfFrustAspect is improperly implemented now since it implies that it is set and forget but it has lasting effect, ie.- it really does to the work of a "pfFrustAutoAspect". The following should work: pfChanAutoAspect(chan, PFFRUST_CALC_NONE); pfFrustNearFar(chan, n, f); pfMakePerspFrust(chan, l, r, b, t); Sorry for any confusion. From guest Tue Mar 22 14:16:18 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222216.AA14422@tubes.asd.sgi.com> Subject: Re: Using shared arenas To: guest (Aaron M. Hightower) Date: Tue, 22 Mar 94 14:16:11 PST Cc: iris-performer@sgi.sgi.com In-Reply-To: <9403182055.AA15472@skips.dseg.ti.com>; from "Aaron M. Hightower" at Mar 18, 94 2:55 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Is there any problem with using shared memory arenas under Performer? > IE: usinit() in addition to pfDataPool(). An interaction is possible since pfNewDPool sets up some usconfig parameters that will be inherited by your usinit but these default are almost always reasonable: usconfig(CONF_INITUSERS, MAXDPUSERS); /* up to MAXDPUSERS users */ usconfig(CONF_ARENATYPE, US_GENERAL); /* allow unrelated processes */ usconfig(CONF_LOCKTYPE, US_NODEBUG); /* fastest locks */ Also, you may have trouble mapping datapools to the same virtual address if you have your own usinit arenas that aren't shared by everyone. Perhaps jimh could comment on this? > More generally: What is the best way to share memory between non-related > processes in Performer without having to link with Performer on both > processes. usinit and usgetinfo/usputinfo are what datapools use so this method should be OK. From guest Tue Mar 22 15:02:38 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222233.AA14442@tubes.asd.sgi.com> Subject: Re: Real-Time Simulation To: guest (Susanne Huber) Date: Tue, 22 Mar 94 14:33:04 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403211513.AA04860@avocado>; from "Susanne Huber" at Mar 21, 94 4:13 pm X-Mailer: ELM [version 2.3 PL8] Status: O > I'm working on an autonomous navigation system based on the optical > flow. (Onyx RE^2, Performer 1.2) > > Until now the algorithm, which is computing the next heading > direction isn't a real-time algorithm. > I have the feeling that Performer gets in trouble with the > synchronisation, if the application lasts a lot longer (here ca. 2 seconds) > than the framerate. > > Does anybody have experience whether Performer can handle those applications > which last longer than the FrameRate? > Or is it perhaps better to use Inventor for this problem? > The application process must call pfFrame to trigger the rendering for a new frame. If your processing takes 2 secs then you are limited to a rendering rate of .5Hz since you are only providing a new eyepoint every 2 seconds. It sounds like what you want is eyepoint extrapolation or "dead reckoning" which is used for systems like DIS which receive positional updates at long intervals. "Dead reckoning" is non-trivial and I don't have any references for you. Extrapolation is trivial but will require that you spawn another process which will handle your processing. As soon as you remove your processing from Performer's APP process, the APP can easily keep up with the frame rate and extrapolate the eyepoint. > Or the other way round: synchronisation starts with the call to > pfSync(). Does the synchronisation sleep after the call to pfFrame > until pfSync is called again? > If that is true, I could call the appliation before calling pfSync or > after calling pfFrame, and there wouldn't be any synchronisatione > problems? When you run in LOCK or FLOAT mode, pfSync will sleep the APP process until the next frame boundary. pfFrame triggers the culling and drawing of a new frame and does not sleep although it may not return immediately. From guest Tue Mar 22 15:02:22 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222236.AA14451@tubes.asd.sgi.com> Subject: Re: your mail To: guest (Micheal J. Williams) Date: Tue, 22 Mar 94 14:36:32 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403211802.AA11421@ldsa.com>; from "Micheal J. Williams" at Mar 21, 94 1:02 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > I am using Performer 1.0 with an Indigo Extreme running Irix 4.0 . > This fog is implemented over a very simple data base with some > pfLightPoints, and some simple polygon geosets. > > My problem is that the fog only seems to be applied to the polygons. > The lightpoints continue to shine through the fog at any distance. > I am applying the fog in the EarthSky model similar to the way it is > done in perfly. In 1.0 pfLightPoints are not fogged. In 1.2 they are fogged but the fog onset and opaque ranges are modified by the values passed to pfLPointFogScale. This allows lightpoints to shine through fog more than non-emissive surfaces. > If I have emissive polygons will they also shine through the fog? > Any help on this is appreciated. Unfortunately not. I think this is really a GL issue but if it doesn't get resolved in the GL then we will handle it in Performer in a future release. From guest Tue Mar 22 15:01:57 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222252.AA14567@tubes.asd.sgi.com> Subject: Re: Stereo code examples for Onyx/RE? To: guest (David Marsland) Date: Tue, 22 Mar 94 14:52:13 PST Cc: shj@swlvx2.msd.ray.com, info-performer@sgi.sgi.com In-Reply-To: <9403221641.AA08273@clubted.csd.sgi.com>; from "David Marsland" at Mar 22, 94 8:41 am X-Mailer: ELM [version 2.3 PL8] Status: O > > > I'm passing on this request for Steve Joyce. Please respond to him at > shj@swlvx2.msd.ray.com if you have any Onyx/RE stereo examples you'd > like to share. Sorry if this is an FAQ. > > Steve, if you would like to join this mailing group you can send mail > to info-performer-request@sgi.com. > > Steve Joyce wrote: > (stuff deleted) > > an Onyx example of stereo viewing that you knew of when I raised the > > question at the end of class. I'm in general looking for some examples of > > stereo viewing programs if you happen to know of any (besides a couple > > in 4Dgifts). > > > > Thanks for any help - > > > > Steve Joyce > > > /* David Marsland "On Spaceship Earth * > * MTS, Worldwide Education R&D there are no passengers, * > * Silicon Graphics Computer Systems only crew." * > * Internet: mars@csd.sgi.com Buckminster Fuller */ > I have modified perfly to run stereo-in-a-window. You can find a tar file with source code in tubes.asd:/usr/tmp/sfly.tar. Note that this is not a trivial stereo example. From guest Tue Mar 22 16:40:06 1994 Date: Tue, 22 Mar 94 18:36:31 CST From: reedwhit@skips.dseg.ti.com (Reed Whittington) Message-Id: <9403230036.AA15998@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Extrapolation Status: O This is an easy way to extrapolate for non uniform position updates. It works if you know the velocity, accel, and frame rate. /* * vehicle.h - public interface to vehicle.c */ #ifndef _VEHICLE_H_ #define _VEHICLE_H_ #include "xformer.h" #include "ex_comm.h" #define DEFAULT_MODEL_ID 30 /* vehicle entity object */ typedef struct Vehicle_s { Base_vehicle_t dis; /* information in from data pool (DIS) */ pfDCS *dcs; /* parent dcs */ pfNode *model_root; /* root to cloned visual model */ pfCoord coord; /* current position and direction */ double dt; /* delta time since last frame */ pfuSmoke *smoke; /* each vehicle will have a smoke model */ pfuSmoke *fire; /* each vehicle will have a fire model */ } Vehicle_t; /* vehicle.c */ extern pfGroup* vehLoadLibrary(char *vehicle_dat); extern void vehCheckIsect(void); extern void vehProcess(void); #endif /* * extrapolate a new coord based on the last coord and the * current dis entity state. */ static void vehExtrapolate( Vehicle_t* veh ) { /* extrap xyh hpr */ veh->coord.xyz[PF_X] = (veh->dis.lin_vel_xyz[PF_X] * veh->dt) + veh->coord.xyz[PF_X]; veh->coord.xyz[PF_Y] = (veh->dis.lin_vel_xyz[PF_Y] * veh->dt) + veh->coord.xyz[PF_Y]; veh->coord.hpr[PF_H] = (veh->dis.ang_vel_xyz[PF_Z] * veh->dt) + veh->coord.hpr[PF_H]; veh->coord.xyz[PF_Z] = (veh->dis.lin_vel_xyz[PF_Z] * veh->dt) + veh->coord.xyz[PF_Z]; veh->coord.hpr[PF_P] = (veh->dis.ang_vel_xyz[PF_X] * veh->dt) + veh->coord.hpr[PF_P]; veh->coord.hpr[PF_R] = (veh->dis.ang_vel_xyz[PF_Y] * veh->dt) + veh->coord.hpr[PF_R]; } ******************************** Reed Whittington Texas Instruments Visual Simulation Technology Development MS 8518 6620 Chase Oaks Blvd. Plano, Texas 75086 (214) 575-6761 off (214) 575-6771 fax reedwhit@dseg.ti.com ******************************** From guest Tue Mar 22 17:22:38 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403230122.AA14744@tubes.asd.sgi.com> Subject: Re: Calling pfDraw twice.... To: guest (Nils Thune) Date: Tue, 22 Mar 94 17:22:29 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199403181740.SAA19706@godemine.cmr.no>; from "Nils Thune" at Mar 18, 94 6:40 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > How can one render objects in the pfScene to the same frame number when the > objects are located in different parts of the view frustrum, separated by a > delta view voulme in which objects should not be rendered? > > > | NearPlane=1.0 FarPlane=100.0 NearPlane=500.0 FarPlane=10000.0 > | | | | | > | | | | | > ----> |-------------------------------------------------------------------- > | | | | | > | | | | | > | Draw objects No drawing Draw objects > View direction > and viewplane > > Basically I want to do the following: > > 0. Clear channel. > 1. Cull scene against the view volume defined by near=1.0, far=100.0. > 2. Draw the objects which were not culled, i.e. the display list. > 3. Cull scene against the view volume defined by near=500.0, far=10000.0 > 4. Draw the new objects which were not culled, i.e a new display list. > 5. Swap buffers, and start over at 0. > > How can this be done? > Use 2 pfChannels. Give each channel a different frustum as you've illustrated above and combine them into a channel group with pfAttachChan so they can share attributes like view point and view direction, viewport, etc. Just make sure that the second channel doesn't clear the frame buffer and wipe out the results of the first. This should be easy to do in the draw callback. From guest Tue Mar 22 18:07:17 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403230207.AA15174@tubes.asd.sgi.com> Subject: stereo perfly To: info-performer@sgi.sgi.com Date: Tue, 22 Mar 94 18:07:10 PST X-Mailer: ELM [version 2.3 PL8] Status: O I have put a stereo version of perfly on sgi.com:~ftp/pub/sfly.tar.Z. This tar file contains: a cmdline.c 19 blocks a cmdline.h 3 blocks a custom.h 3 blocks a env.c 11 blocks a env.h 3 blocks a generic.c 38 blocks a generic.h 5 blocks a gui.c 46 blocks a gui.h 4 blocks a keybd.c 15 blocks a keybd.h 3 blocks a main.c 11 blocks a main.h 3 blocks a sfly.c 38 blocks a sfly.h 12 blocks a Makefile 11 blocks a sfly 5064 blocks 1. uncompress sfly.tar 2. tar -xvf sfly.tar 3. smake opt 4. as root: /usr/gfx/setmon -n 960x680_108s or your favorite stereo format. 5. sfly file The GUI contains a slider for intraocular distance. -s option disables stereo. From guest Tue Mar 22 19:47:31 1994 Message-Id: <9403230347.AA05724@surreal.asd.sgi.com> To: "Infobyte S.R.L." Cc: info-performer@sgi.sgi.com Subject: Re: Loadflt Callback And Pfnodes In-Reply-To: Your message of "Fri, 18 Feb 94 15:37:56 +0700." <9402181537.aa19654@ax433.mclink.it> Date: Tue, 22 Mar 94 19:47:16 -0800 From: Jim Helman Status: O As a performance optimization the loader "flattens" (removes static xform by applying them to geoemtry) and "cleans" (removes unnecessary nodes) the scene graph. Since flattening has to duplicate instanced subgraphs, you may find some new nodes in your scene graph. Since clean removes nodes, some may be missing as well. See LoadFltMode to change this behavior, or use callbacks or pfFind to reconstruct the information you need on the optimized scene graph. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 To: info-performer@sgi.sgi.com Subject: Loadflt Callback And Pfnodes Date: Fri, 18 Feb 94 15:37:56 CET From: "Infobyte S.R.L." Message-Id: <9402181537.aa19654@ax433.mclink.it> Hi all, I am "playing" with Performer1.2a81.irix5 beta and I have experienced a strange behavior: I am using the callback functions with LoadFlt routine. At loading time (in the callback function), I print the addresses of the Performer nodes and their names that are (by default) the same of MultiGen ones. When, after in the application, I print the same addresses (from the pfHit structure after a collision I can obtain the Geodes), they are different for the objects. I am sure that the nodes are the right ones because I know the polygons of the objects and because if I print the adresses and names of the Parents of the nodes, they are the right ones. Further when I try to find the addresses of the objects by name with pfFind, it doesn't work for them (NULL return values), but it works fine for the parent groups or lods. It seems that the objects' addresses are in some way changed and their names deleted, while groups' and lods' are not. Is it possible or is there anything else I have to do (or not to do!). Thank you in advance for any help. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Tue Mar 22 21:02:02 1994 From: "Ignazio Ranno" Message-Id: <9403222101.ZM2124@zorro.melbourne.sgi.com> Date: Tue, 22 Mar 1994 21:01:32 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer 1.1 on Indy Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hello All Does Performer 1.1 run on an Indy running 5.1.1X. When I load it on the system it seems to fail to load libpr.a. From guest Wed Mar 23 04:01:14 1994 Date: Wed, 23 Mar 94 13:04:13 +0100 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9403231204.AA02905@scl> To: info-performer@sgi.sgi.com Subject: From GL to PF ... may be a solution ... Status: O Hi everybody ... Finaly it seams I found a way to go from GL view to PF view as follow but may be it is not really the good one ! ... anyway it seams to work currently ... pfMatrix stvViewMatrix; static pfMatrix stvConvertMatrix= { { 1.0f, 0.0f, 0.0f, 0.0f }, { 0.0f, 0.0f, 1.0f, 0.0f }, { 0.0f, -1.0f, 0.0f, 0.0f }, { 0.0f, 0.0f, 0.0f, 1.0f } }; pfCoord stvCamera; stvCamera.xyz[0]= glTransX; stvCamera.xyz[1]= glTransY; stvCamera.xyz[2]= glTransZ; stvCamera.hpr[0]= glRotZ; stvCamera.hpr[1]= glRotX; stvCamera.hpr[2]= glRotY; pfMakeCoordMat(stvViewMatrix, &stvCamera); pfPreMultMat(stvViewMatrix, stvConvertMatrix); pfChanViewMat(stvChannel, stvViewMatrix); Thank's to Renee Strong for her help ! (I think its "her" as Renee in french !) Merci et bienvenue ... Cedric Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Wed Mar 23 10:14:38 1994 Message-Id: <9403231814.AA18096@surreal.asd.sgi.com> To: "Ignazio Ranno" Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.1 on Indy In-Reply-To: Your message of "Tue, 22 Mar 94 21:01:32 PST." <9403222101.ZM2124@zorro.melbourne.sgi.com> Date: Wed, 23 Mar 94 10:14:28 -0800 From: Jim Helman Status: O I think this is in the current FAQ. The Indy did not exist when 1.1 came out, so you need to tell inst it's something else, inst -m "GFXBOARD=LIGHT" rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Mar 23 11:30:48 1994 Date: Wed, 23 Mar 1994 11:26:39 -0800 (PST) From: "Matthew S. Reeves" Subject: increasing performer heap To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, I'm getting errors on heap size and wonder if there is any way to increase the size ? Appreciate any help ! Matt layer geometry generation time: 0.049999 seconds expanding layer "R_CLG2" (40 of 41) ... creating geometry data structures ... [12851] XvsDXF.c: 651: allocating 33408 bytes for 2784 vertices [12851] XvsDXF.c: 667: filling in vertices [12851] XvsDXF.c: 686: constructing 928 polygons [12851] XvsDXF.c: 753: constructing composite object [12851] XvsDXF.c: 767: cleaning up after composite object layer geometry generation time: 0.179999 seconds expanding layer "R_LITES" (41 of 41) ... creating geometry data structures ... [12851] XvsDXF.c: 651: allocating 66816 bytes for 5568 vertices [12851] XvsDXF.c: 667: filling in vertices [12851] XvsDXF.c: 686: constructing 1856 polygons [12851] XvsDXF.c: 753: constructing composite object [12851] XvsDXF.c: 767: cleaning up after composite object layer geometry generation time: 0.290000 seconds total geometry generation time: 51.790000 seconds -- DXF complete delete time: 1.299998 seconds Performer Fatal (12):pfMalloc() Unable to allocate 15720448 bytes from the heap. -IRI: From aschaffe Wed Mar 23 17:23:37 1994 Date: Wed, 23 Mar 94 17:23:29 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9403240123.AA06427@holodeck.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: IRIS Performer 1.2 released! Cc: vogt@mars.esd.sgi.com, jed@mars.esd.sgi.com Status: O == ANNOUNCEMENT ================== IRIS Performer 1.2 is complete. It is based on IrisGL and supports all SGI graphics systems at maximum speed with the same API using either IRIX 4.0.5 or IRIX 5.2. The total release size is just slightly more than 350MB. (The days of 1/4" tape cartridge distributions are over.) IRIS Performer 1.2 is Silicon Graphics' premier graphics software development environment for high-performance graphics applications such as visual simulation, virtual reality, entertainment systems, and advanced visualization. Congratulations are in order to the Engineering, Customer Support, and Technical Publications groups for producing an excellent product with many new technical features and capabilities, nearly doubling the content of the Programming Guide and other documentation, creativity in working around two serious bugs, one in GL and one in IRIX 5.2's libc, and for surviving sustained 25-hour work days. Special thanks go to Michael Jones, Sharon Fischler, Allan Schaffer, Chris Tanner, John Rohlf, Jim Helman, Jed Hartman, and Derrald Vogt. We also wish to thank our many IRIS Performer 1.2 BETA sites for their sustained testing and patience during the release cycle. We now set our sights on IRIS Performer 2.0 as well as continuing our partnerships with major simulation and entertainment customers. == WHAT'S NEW ==================== Almost too much to mention: o Import DWB, FLT, IRIS Inventor, Wavefront, and many other data formats o Expanded and enhanced documentation, especially the Programming Guide o New pfLightSource and pfPartition node types o Utility library with many important tools (here are a few): - elaborate triangle mesher - easy to use database loader development tools - unified x and gl input management system o Detailed statistics gathering o Rewritten sample code o Friends of Performer: over 300Mb of data, games, movies, code, and database tools developed by the IRIS Performer team, our customers, and our partners. o Much, much more. == ORDERING INFORMATION ========== Silicon Graphics sales offices worldwide will be recieving IRIS Performer 1.2 information packets shortly and will be able to begin taking orders in April. ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Mar 24 09:56:14 1994 Message-Id: <9403241041.AA24208@surreal.asd.sgi.com> To: "Matthew S. Reeves" Cc: info-performer@sgi.sgi.com Subject: Re: increasing performer heap In-Reply-To: Your message of "Wed, 23 Mar 94 11:26:39 PST." Date: Thu, 24 Mar 94 02:41:24 -0800 From: Jim Helman Status: O You should only be allocating from the heap if you are running in a single-process environment and never plan to use libpf's multiprocessing capabilities. If you plan to use MP, the argument to libpr's pfNew should be pfGetSharedArena(). Performer has no control over your heap size. Check your shell limits. Did you really intend a single allocation of 16MB? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Mar 24 13:22:42 1994 Date: 24 Mar 94 16:20:02 EST From: Colin Dooley <100346.1122@CompuServe.COM> To: performer Subject: Billboards Message-Id: <940324212002_100346.1122_BHJ43-1@CompuServe.COM> Status: O I have a problem with billboards using Performer 1.0. The problem is that they don't seem to work. We have written a library to load Medit modeller files into performer, but when we try to add a billboard, we get nothing We can get everything to render correctly just by changing the pfNewBboard for pfNewGeode. When we do this everything is fine (except the objects don't rotate to face us). When we change it back to pfNewBboard, we get nothing again. Does anybody know what is going on? Colin Dooley From guest Thu Mar 24 15:01:12 1994 Message-Id: <9403242301.AA01347@surreal.asd.sgi.com> To: Colin Dooley <100346.1122@compuserve.com> Cc: performer Subject: Re: Billboards In-Reply-To: Your message of "24 Mar 94 16:20:02 EST." <940324212002_100346.1122_BHJ43-1@CompuServe.COM> Date: Thu, 24 Mar 94 15:01:10 -0800 From: Jim Helman Status: O The man page was wrong about the orientation. Try reversing the vertex ordering or looking at the source code to the Flight loader to get the correct orientation. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Mar 24 16:28:04 1994 Date: Thu, 24 Mar 94 16:30:18 -0800 From: lroy@jetson (Linda Roy) Message-Id: <9403250030.AA04440@jetson.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Is performer worthwhile, if I'm re-calculating tex-coords? Status: O Would it be worthwhile to use Performer for a viewer where I was re-calculating texture coordinates for each vertex, each frame? My guess is I'ld want to replace the low-level drawing routines of performer for these objects. Is this easy to do or is this such a pain that I am better off sticking with GL for this?. Any suggestions and opinions are welcome. Speed is second to these texture calculations, here. Thanks, ~~~~~~~~~ Linda Roy lroy@sgi.com (415)390-3684 From aschaffe Tue Mar 29 13:52:13 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403291352.ZM18773@holodeck.asd.sgi.com> Resent-Date: Tue, 29 Mar 1994 13:52:13 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Fri, 25 Mar 94 17:00:03+080 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9403250900.AA06403@bochap.iss.nus.sg> To: info-performer@sgi.sgi.com Subject: Loading Dgn files Content-Length: 2503 Status: O Hi, We have recently started using Performer 1.1 and are porting over code from our existing internally developed toolkit. Much of the existing tools were developed for dealing with "Intergraph" format "dgn" files. (Translation from dgn to performer is a two-step process, first we translate from a very complicated binary format from dgn to an ascii version and then we load the ascii to performer). We have constructed a "loadDgn" using the examples, which seems to work reasonable well. We have several questions however. 1) Dgn files typically have lots of "shapes". The easiest thing to do is to create a new geometry and node for each of these. We get a bunch of geometries with pfGSetNumPrims set to 1. It seems that this approach creates lots and lots of nodes; in our first tests it seemed we have poor performance on such datasets. One solution would be to collect the shapes of the different types (quads, or triangles) and then create a single geometry; however this is quite messy (and a LOT more work). Also culling won't work as nice if the orginally shapes were far apart. So what is the best approach? 2) What happens if you don't set a pfGeoState for a pfGeoSet? Does it inherit the global state? 3) This is the embarrassing one. We have lots of polygons that have greater that 4 vertices. Before we easily used gl to draw them. Now given drawing primitives that have < 5 vertices, do we have to decompose them into smaller polygons or are we missing something? If we have to decompose them, how do we do it? thanks much, Kim. PS By the way, we have a lovely translator for taking dgn design files and turning them into polygons (at selectable resolutions). Is any one else doing the same? Here is a data file fragment of the output of the translator. We will convert it to binary in the future (always nice to debug in ascii :->). format: bgf shape { material { ambient: 1.000000 1.000000 1.000000 diffuse: 0.000000 0.777778 0.744444 emission: 0.000000 0.000000 0.000000 specular: 0.000000 0.000000 0.000000 shininess: 0.000000 transparency: 0.000000 } no of polygons: 4 polygon { layer: 255 type: 4 no of points: 3 vertex { 0.041743 0.049698 -0.048695 -0.005608 0.049698 -0.048695 0.018067 0.026023 -0.022703 } normal { 0.000000 0.739274 0.673405 0.000000 0.739274 0.673405 0.000000 0.739274 0.673405 } } polygon { layer: 255 From aschaffe Tue Mar 29 13:54:45 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403291354.ZM18805@holodeck.asd.sgi.com> Resent-Date: Tue, 29 Mar 1994 13:54:45 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Fri, 25 Mar 94 16:09:38 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9403252109.AA15088@ldsa.com> To: info-performer@sgi.sgi.com Status: O On an Indigo2 Extreme (IRIX 4.0 and Performer 1.0) I need to be able to direct the Performer image output to an NTSC video type display (specifically RS-170 video format). We will probably be using a Galaleo video board. How does one cause the graphic output to be routed to the video board (assuming that it is possible)? I do know that there is a broadcast video option (BVO) available which will scan convert the console image to NTSC, but we would rather use the video board if possible. Also, does anyone know anything about the internals of the pfDraw? Does the draw go directly to the video memory, such that the image is updated immediately, or is the video buffered such that the image will not appear until the next video frame? We have a latency requirement of 150 milisec that we must meet and are trying to account for each step of the process. Email responses can be sent to: mwilliam@ldsa.com Tnx Ken Slezak 216/796-5907 7:30am-4:30pm EST From aschaffe Tue Mar 29 13:55:01 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403291355.ZM18811@holodeck.asd.sgi.com> Resent-Date: Tue, 29 Mar 1994 13:55:00 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <9403260124.AA01546@surreal.asd.sgi.com> To: lroy@jetson (Linda Roy) Cc: info-performer@sgi.sgi.com Subject: Re: Is performer worthwhile, if I'm re-calculating tex-coords? In-Reply-To: Your message of "Thu, 24 Mar 94 16:30:18 PST." <9403250030.AA04440@jetson.asd.sgi.com> Date: Fri, 25 Mar 94 17:24:07 -0800 From: Jim Helman Status: O pfGeoSet coordinate arrays are exposed, so you can do whatever you want to them. The only issue is when to do it so you don't collide with the draw process using them (might cause tearing or anomalies). For a single pipe application, you can diddle the coordinates in a draw callback on the parent geode or if you multibuffer the geoset so you don't collide with the one the draw is using you can do it in the application process. For complete safety in a multipipe application, each pipe needs its own copy of the pfGeoSet to avoid collision or problems during frame extension. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Mar 29 17:02:44 1994 Return-Path: Message-Id: <9403300100.AA07659@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Cc: hasimoto@iml.mkhar.sharp.co.jp Subject: scaling image using rectcopy Date: Wed, 30 Mar 1994 10:00:51 +0900 From: Takeshi Hashimoto Status: O Hi, I wrote a program in Performer whose window size is 320x240 pixel. I want to display it's 320x240 window to NTSC full screen by Galileo Video. How can I do it? I tried to scale image after pfDraw ,using rectzoom and rectcopy but it didn't work as I want. in draw process DrawFunc( pfChannel *chan, void *data) .... pfDraw(); afunction(0,AF_ALWAYS); viewport(0,639,0,479); rectzoom(2.0f,2.0f); rectcopy(0,0,319,239,0,0); } Is it wrong? --- //\\ The sky above Chiba-City was the color of television (O O) tuned to a 'video' channel..... \o/ WOW hasimoto@iml.mkhar.sharp.co.jp From guest Tue Mar 29 15:08:53 1994 From: peterk@foetus.sydney.sgi.com (Peter Kerney) Message-Id: <9403300857.ZM1371@foetus.sydney.sgi.com> Date: Wed, 30 Mar 1994 08:57:53 -0500 In-Reply-To: mwilliam@ldsa.com (Micheal J. Williams) "" (Mar 25, 16:09) References: <9403252109.AA15088@ldsa.com> X-Face: $5b3RM{:c7HBWke?Q2ED_pDjVz%hll)C'(@AA0J5eHMZ5Icz/Uf'EXR)HME!M?R*7KasG3ks/\2=1\e_1`Z(0GV<;Kj#hQ>HYn_lC/rW3x6YboDE\9+u;'[CnK(ueOqBFqLL=WAkY.SZvMaQT*'%R^!=x;HU4a7pw,HbY5OB=HSHq$Y)wzTW#v# X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com Subject: Galileo Video with Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I have done some stuff with this here in our office. When you get the Galileo, you will be forced to upgrade to 5.x (probably 2) to make the thing work. I would also imagine that you will have to upgrade your version of Performer as well as all you other products. The Galileo board simply take an NTSC/PAL movable region of your frame buffer and outputs that to video in several formats. It will also output the entire framebuffer using scan conversion if you want. The BVO that you speak of was only available on VGX systems and as such will not enter into the discussion. In order to get the output happenning, you simply invoke the 'videoout' program and move the output window to where you want it. Depending upon you application you could also purchase the Digital Media Developers option which will allow you to call the video library directly and make the application startup a bit simpler. You don't *have* to do anything to your application at all (neat eh!). I am not sure of the answer to your question about the delays associated with the Galileo but I know that the board communicates with the Extreme graphics across the video bus and probably just looks at the frontbuffer and you will get whatever is there are the time. I would say that there is some sort of syncronisation that would stop a swapbuffer occurring on the middle of a video retrace. Hope that answers some of your questions. On Mar 25, 16:09, Micheal J. Williams wrote: > Subject: > On an Indigo2 Extreme (IRIX 4.0 and Performer 1.0) I need to be able to direct > the Performer image output to an NTSC video type display (specifically RS-170 > video format). We will probably be using a Galaleo video board. How does one > cause the graphic output to be routed to the video board (assuming that it is > possible)? I do know that there is a broadcast video option (BVO) available > which will scan convert the console image to NTSC, but we would rather use the > video board if possible. > > Also, does anyone know anything about the internals of the pfDraw? Does the > draw go directly to the video memory, such that the image is updated > immediately, or is the video buffered such that the image will not appear > until the next video frame? We have a latency requirement of 150 milisec that > we must meet and are trying to account for each step of the process. > > Email responses can be sent to: mwilliam@ldsa.com > > Tnx > Ken Slezak > 216/796-5907 > 7:30am-4:30pm EST > >-- End of excerpt from Micheal J. Williams -- -------------------------------------------------------------------------- Peter Kerney. Silicon Graphics, Sydney, Australia. (peterk@sydney.sgi.com) 'Everybody wants a rock to wind a piece of string around.' They Might Be Giants -------------------------------------------------------------------------- From guest Wed Mar 30 08:05:38 1994 From: "pierre VERCRUYSSE" Message-Id: <9403301606.ZM9943@cathy.rennes.sgi.com> Date: Wed, 30 Mar 1994 16:06:22 +0100 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: fog problem on RE2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I, can some body can help? I'm in Performer 1.2a151preMR IRIX 5.2 MR on an Onyx RE2. And when i initialize a fog with EarthSky = pfNewESky(); /* creation du modele horizon/meteo */ pfChanESky(Channel,EarthSky); /* attachement au modele horizon/meteo */ Fog = pfNewFog(NULL); /* creation du modele brume */ pfFogType(Fog,PFFOG_VTX_EXP2);/* attenuation de type expo**2 sur sommets */ /* attachement du modele brouillard au modele horizon/meteo */ pfESkyFog(EarthSky,PFES_GENERAL,Fog); Soleil = pfNewLight(NULL); /* on cree, positionne une nouvelle source */ pfApplyLModel(SoleilModel = pfNewLModel(NULL)); My fog are very cloud, i don't see the scene. In advance thanks for your help, pierre@rennes.sgi.com From guest Wed Mar 30 08:43:31 1994 From: "Michael Jones" Message-Id: <9403300843.ZM6250@babar.asd.sgi.com> Date: Wed, 30 Mar 1994 08:43:20 -0800 In-Reply-To: fair@iss.nus.sg (Kim Michael Fairchild) "Loading Dgn files" (Mar 25, 5:00pm) References: <9403250900.AA06403@bochap.iss.nus.sg> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: fair@iss.nus.sg (Kim Michael Fairchild), info-performer@sgi.sgi.com Subject: Re: Loading Dgn files Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mar 25, 5:00pm, Kim Michael Fairchild wrote: > Subject: Loading Dgn files :We have recently started using Performer 1.1 and are porting over code :from our existing internally developed toolkit. Any chance of upgrading to the lastest 1.2 version of IRIS Performer? It has numerous facilities for building optimized database loaders, such as functions to tesselate concave or complex polygons, form triangle meshes, and make spatial-subdivision hierarchies from the resulting pfGeoSets. (It has a few hundred other new features too...) :We have constructed a "loadDgn" using the examples, which seems to :work reasonable well. We have several questions however. : :1) Dgn files typically have lots of "shapes". The easiest thing to do :is to create a new geometry and node for each of these. We get a bunch :of geometries with pfGSetNumPrims set to 1. It seems that this :approach creates lots and lots of nodes; in our first tests it seemed :we have poor performance on such datasets. Not unexpected. Triangle strips are desired, and geosets with tens of primitives are best. :One solution would be to collect the shapes of the different types :(quads, or triangles) and then create a single geometry; however this :is quite messy (and a LOT more work). Also culling won't work as nice :if the orginally shapes were far apart. So what is the best approach? Actually this is the EASY method with IRIS Performer 1.2 and the new pfuBuilder() functions. You just allocate a pfuBuilder, add polygons one at a time (each of which may have many sides, be concave, etc.) and then call pfuMakeGSets() when you're done -- you'll be give a minimal set of triangle strips of maximal length, as well as quads for the few fragments you have left over. It's that easy and explained in detail in the new Programming Guide. If the resulting pfGeoSets are too big spatially, then use pfuBreakup to reduce them to an efficient hierarchy. :2) What happens if you don't set a pfGeoState for a pfGeoSet? Does it :inherit the global state? No. Having no pfGeoState is a kind of "don't care" mode. It's like Bungee jumping without a cord. Since pfGeoStates inherit all modes and attributes by default, the "use global state" solution is to make one plain pfGeoState that's referenced by all the pfGeoSets you want to have inherit the global state. :3) This is the embarrassing one. We have lots of polygons that have :greater that 4 vertices. Before we easily used gl to draw them. Now :given drawing primitives that have < 5 vertices, do we have to :decompose them into smaller polygons or are we missing something? If :we have to decompose them, how do we do it? You make a triangle strip that zig-zags the n-gon. For example, if you had a 12-sided polygon, with vertices numbered as a clock face, you could specify the triangle strip: 1, 2, 12, 3, 11, 4, 10, 5, 9, 6, 8, 7 which makes for ten triangles, the same number which would have been drawn by IrisGL when sent the 12-sided polygon. Alternately, just give the 12 vertices to the pfuBuilder() and it will do all the work for you. (Hint: use the pfuBuilder(), it's your friend) :PS By the way, we have a lovely translator for taking dgn design files :and turning them into polygons (at selectable resolutions). Is any one :else doing the same? Here is a data file fragment of the output of the :translator. We will convert it to binary in the future (always nice to :debug in ascii :->). -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Mar 30 08:49:10 1994 From: "Michael Jones" Message-Id: <9403300848.ZM6265@babar.asd.sgi.com> Date: Wed, 30 Mar 1994 08:48:57 -0800 In-Reply-To: peterk@foetus.sydney.sgi.com (Peter Kerney) "Galileo Video with Performer" (Mar 30, 8:57am) References: <9403252109.AA15088@ldsa.com> <9403300857.ZM1371@foetus.sydney.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: peterk@foetus.sydney.sgi.com (Peter Kerney), mwilliam@ldsa.com (Micheal J. Williams) Subject: Re: Galileo Video with Performer Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mar 30, 8:57am, Peter Kerney wrote: > Subject: Galileo Video with Performer :I have done some stuff with this here in our office. : :When you get the Galileo, you will be forced to upgrade to 5.x (probably 2) :to make the thing work. I would also imagine that you will have to upgrade :your version of Performer as well as all you other products. You can use any version of IRIS Performer on IRIX 5.2 systems, although the new IRIS Performer 1.2 is the recommended choice. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Mar 30 09:04:26 1994 From: "Michael Jones" Message-Id: <9403300904.ZM6352@babar.asd.sgi.com> Date: Wed, 30 Mar 1994 09:04:12 -0800 In-Reply-To: Takeshi Hashimoto "scaling image using rectcopy" (Mar 30, 10:00am) References: <9403300100.AA07659@bach.iml.mkhar.sharp.co.jp> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Takeshi Hashimoto , info-performer@sgi.sgi.com Subject: Re: scaling image using rectcopy Cc: hasimoto@iml.mkhar.sharp.co.jp Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mar 30, 10:00am, Takeshi Hashimoto wrote: > Subject: scaling image using rectcopy :Hi, : I wrote a program in Performer whose window size is 320x240 :pixel. I want to display it's 320x240 window to NTSC full :screen by Galileo Video. :How can I do it? : :I tried to scale image after pfDraw ,using rectzoom and rectcopy :but it didn't work as I want. : :in draw process :DrawFunc( pfChannel *chan, void *data) : .... : : pfDraw(); : afunction(0,AF_ALWAYS); : viewport(0,639,0,479); : rectzoom(2.0f,2.0f); : rectcopy(0,0,319,239,0,0); :} : :Is it wrong? They way to do this is to simply make the pfPipe's origin and size match the Galileo Video's expectations. Take the code above out of the Channel Draw Callback, and simply make the Pipeline Initialization Callback specify the desired window size and origin. That's all there should be to it. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311