From aschaffe Tue Sep 6 14:23:50 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409061423.ZM10744@holodeck.asd.sgi.com> Resent-Date: Tue, 6 Sep 1994 14:23:49 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Tue, 6 Sep 94 14:23:06 -0700 From: aschaffe (Allan Schaffer) To: info-performer Subject: info-performer administrivia Hello info-performer subscribers, some news: - The latest issue of "Pipeline" (Sept/Oct) contains an article entitled "Extending IRIS Performer". It discusses Performer's traversal, callback, and user-data features. The code sample is available via anonymous ftp to sgigate.sgi.com, in /support/Pipeline/callbacks.c - SGI's technical education dept. is offering an IRIS Performer class roughly once a month. If you're interested, look at the back cover of "Pipeline" for a schedule, or call 1-800-800-4744. - mailing list traffic has backed up while our mailserver was being upgraded. There are currently 14 messages in the queue; instead of bombarding you all with them all at once I'll trickle them out 5 or 6 per day for the next few days. So expect a temporary increase in traffic which should die down around the end of the week. Allan ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From aschaffe Tue Sep 6 15:03:19 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409061503.ZM10985@holodeck.asd.sgi.com> Resent-Date: Tue, 6 Sep 1994 15:03:19 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Susanne Huber" Date: Mon, 29 Aug 1994 15:17:43 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: iris-performer@sgi.sgi.com Subject: off-screen-rendering Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Does anybody know, whether there is a way to render an image into an off-screen memory buffer like in Inventor? Thanks for any answeres, Susanne huber@mpik-tueb.mpg.de From aschaffe Tue Sep 6 15:03:19 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409061503.ZM10979@holodeck.asd.sgi.com> Resent-Date: Tue, 6 Sep 1994 15:03:19 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: aaron@qbert.rts.dseg.ti.com (Aaron Hightower) Subject: Re: Identifying channels To: iris-performer@sgi.sgi.com Date: Sun, 28 Aug 1994 20:58:58 -0500 (CDT) Reply-To: aaron@dseg.ti.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1548 > From: "Drew Hess" > Subject: Identifying channels in callbacks > > I need a way of uniquely identifying the channel passed to a post/predraw > callback in Performer 1.2. According to the man page, the return value of > pfNewChan() is a handle to the newly created channel, so it sounds like I could > use the handle for what I need. (What's actually returned is of type > (pfChannel *), so should I use the pointer itself to identify the channel or > should I dereference the pointer and use that value? The latter would work if, Trying to poke into Performer's data structures is dangerous. The main reason being that using such "undocumented features," if they exist, is no guarantee that they will continue to exist in new versions. I would not suggest dereferencing any of the Performer objects directly. > for instance, the pointer points to an integer that's used as a table index > into a libpr or libpf internal table.) There are two ways of handling this that I know of. The first way is simply to use pfUserData() on the pfChannel pointer and then make a structure that identifies the channel in whatever way you would like. The second way is to use pfAllocChanData() and pfPassChanData(). This is the way to do it if you want your data to be "frame accurate" as it keeps a copy for each of the app cull and draw. However, the data is only sent downstream. If you need to change things in the draw process and see it in the app, then pfUserData is your key. Hope this helps, Aaron Hightower From aschaffe Tue Sep 6 15:03:20 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409061503.ZM10988@holodeck.asd.sgi.com> Resent-Date: Tue, 6 Sep 1994 15:03:19 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Mark Johnson" Date: Mon, 29 Aug 1994 10:42:19 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: two-sided lighting Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 1385 Hi all, I am having some difficulty with two-sided lighting. Color only appears on one side of a scene triangle. The other side is grey. As often as not, the grey side faces the light source. If I reverse the normals, the grey side will be on the other side of the triangle. This is not a practical solution since the file cannot indicate which normals should be reversed. Why don't the backsides of the triangles have color? Also, I have broken rectangles up into triangles, and the two triangles do not have the same color, despite being in the same geoset with color applied overall. According to the man page on MtlSide, I must: 1. have a 2 sided light model 2. have face culling turned off. Both of these conditions have been met. According to pfApplyMat (later on same man page), the following conditions must be met for lighting: 1. Lighting must be enabled via pfEnable 2. a pfLightModel must be applied using pfApplyModel 3. A pfMaterial must be applied using pfApplyMtl. 4. One or more pfLights must be on. 5. the geometry must have normals. Again all of these conditions have been met. So questions: 1. Is there some dependency on the order in which the above-mentioned function calls must be made? 2. Why do the backs of triangles not have color? 3. Why do the fronts of co-planar triangles have different colors? Mark Johnson johnson@vrlab.uccb.ns.ca From aschaffe Tue Sep 6 15:03:19 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409061503.ZM10982@holodeck.asd.sgi.com> Resent-Date: Tue, 6 Sep 1994 15:03:19 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "JAVIER CASTELLAR" Date: Tue, 30 Aug 1994 05:06:03 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Stereo on HiVision Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, As far as i know this is out of the DG2 bandwidht and i don't know any video device which supports this video formats. The only way i know is: (i tried it 3 years ago and it worked ... for a few hours) 1) Use two 1271QM SONY video projectors, or the Barco equivalents. 2) Use two different polarizers on each video projector. 3) Use a dual pipe RE2 system (Onyx rack with two RE2) or two different systems sincronized via swapready (video level) and through ethernet or scramnet (aplication level). Each pipe must run in HDTV. You can do it also with an SkyWriter 440 (an old SGI dual pipe system), it had something like HDTV. 4) Use the proper polarizer glasses. 5) DO NOT USE LONG CABLES. Javier Castellar javier@madrid.sgi.com From aschaffe Tue Sep 6 15:08:44 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409061508.ZM11051@holodeck.asd.sgi.com> Resent-Date: Tue, 6 Sep 1994 15:08:44 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Wed, 31 Aug 1994 22:39:12 GMT From: Kevin Russo To: info-performer@sgi.sgi.com Subject: Bug in ilgettile.c Fellow Performers: We have run into a bug in libpfsgi/ilgettile.c (Perf 1.2) that causes a bus error. Perhaps this is a well-known problem? Whenever LoadPtu() is called over 50 times, the static buffer Images[100] in ilgettile.c overflows, corrupting other memory. There are two oversights in the code that contribute to the bug: 1) ildeffile() should check whether NImages >= MAX_IMAGES before proceeding Perhaps Images[] should be dynamically (re)alloc'd in chunks of 100? 2) ilfreetiles() should set NImages = 0 before returning. Now it only gets bigger even though the memory is really freed. from ilgettile.c: #define MAX_IMAGES 100 static char *ImageNames[MAX_IMAGES]; static ilRotZoomImg *Images[MAX_IMAGES]; static long NImages = 0; long ildeffile(char *filename, char *name, int xs, int ys) { // check NImages < MAX_IMAGES, else realloc or quit with error : Images[NImages++] = ilRotZoomImgCreate( : } void ilfreetiles(void) { int i; for(i=0;i Resent-Date: Wed, 7 Sep 1994 16:00:36 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Thu, 1 Sep 94 15:15:08 -0400 From: newcomb@enews.nrl.navy.mil (Dale Newcomb) To: info-performer@sgi.sgi.com Subject: Strange error Hi all! I tried to compile and run the sample program intersect.c in the Performer samples under .../pguide/libpf/progs and I got it to compile fine, but when I tried to run it (executable name is "Int") I got a strange error that I saw one other time...when I was trying to figure out viewpoint collision detection without using the pfuCollide functions. Here's the error: 28076:Int: rld: Error: unresolvable symbol in /usr/lib/libpf.so __pure_virtual _called 28076:Int: rld: Fatal Error: this executable has unresolvable symbols Running it through a debugger (cvd) gave me no additional help. Anyone have any ideas about why I'm getting this error and what I can do to avoid it? Secondly, if anyone has truly come to fully understand intersection testing in Performer, I'd love to talk to you - the only thing I can get to work is the pfuCollideObj function with ONE segment only (a unit segment in the view dir). Thanks for any info, Dale Newcomb, Jr. Naval Research Lab, DC From aschaffe Wed Sep 7 16:00:35 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409071600.ZM15766@holodeck.asd.sgi.com> Resent-Date: Wed, 7 Sep 1994 16:00:35 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.65c/IDA-1.4.3 for info-performer@sgi.com); Thu, 1 Sep 1994 09:27:32 +0200 From: "G.C.J.M. Luijten" Subject: DTED-suppliers To: info-performer@sgi.sgi.com, rany@bvr.co.il Date: Thu, 1 Sep 94 9:27:31 MET DST Cc: xwa04@tnofel.fel.tno.nl (W.P. Hajema) X-Mailer: ELM [version 2.3 PL11] To: info-performer@sgi.com, rany@bvr.co.il In-reply-to: rany@bvr.co.il, DTED-suppliers Sjalom Ran, A late reply to your request where to obtain DTED files. At the RNLA we make use of a service called the 'Topografische Dienst'. DTED is for-military-use-only, but they sell DTED-like files for civil use, in any format you prefer (also DTED!), based on other sources. I am not sure about the span-of-area they cover (in any case most of Europe). You can ask them to send you a catalog: Topografische Dienst POC: P.J.L. Lemmens tel: +31 5910 96911 fax: +31 5910 96296 lehitra'ot, Edgar Heertje, Royal Netherlands Army (RNLA) tel: +31 70 316 7399 fax: +31 70 316 5300 e-mail: xwa03@fel.tno.nl PS I noticed you are quite a Performer hacker! Magnetism, n: something acting upon a magnet. Magnet, n: something acted upon by magnetism. From aschaffe Wed Sep 7 16:00:35 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409071600.ZM15763@holodeck.asd.sgi.com> Resent-Date: Wed, 7 Sep 1994 16:00:35 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.65c/IDA-1.4.4 for ); Thu, 1 Sep 1994 00:45:34 -0400 Date: Thu, 1 Sep 1994 00:45:34 -0400 From: John C Vanderburgh To: info-performer@sgi.sgi.com Subject: textures... Hey all... I didn't find anything in the FAQ about this... I'm modeling the Earth's moon in a Performer application. I use a sphere constructed and textured via MultiGen. When I run my app and the moon first comes into view, my app freezes until the texture is loaded. Is there anyway to preload MultiGen-modeled texture? (It's taking about 3-4 seconds to load, which is unacceptable...) Thanks, John Vanderburgh AF Institute of Technology WPAFB, OH From aschaffe Wed Sep 7 16:00:36 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409071600.ZM15772@holodeck.asd.sgi.com> Resent-Date: Wed, 7 Sep 1994 16:00:36 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: watsen@netcom.com (Kent Watsen) Subject: Some Basic Q's To: info-performer@sgi.sgi.com (performer) Date: Sun, 4 Sep 1994 12:10:36 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2457 Hi, I've been using Performer 1.2 to write a distributed interactive simulation application and I have some basic questions which I have yet to resolve. 1) If I have a pointer to some geometry which contains one or more pfDCS's, how can I obtain pointers to the new pfDCS's after pfClone-ing the geometry? There was some recent discourse regarding a node callback mechanism for pfClone, but until that happens, what should I do? Lets say that the original pfDCS node name is 'X' and that "NewRoot" points to the geometry returned by the pfClone call. I would like to use pfFindDCS("X"), but since there may be multiple clones instanced, this call does not explicitly qualify as a search parameter in the global node-name lookup table. The man page states that a node can be qualified by using a unique relative scene graph path. Assuming the "NewRoot" is unique and that the scene graph path between "NewRoot" and "X" is unknown, is there a wildcard parameter that can be used to perform this relative search for me? Something like pfFindDCS( "NewRoot/*/X")? The only other option I have thought of is to write a little procedure to traverse the scene graph below a passed pfNode for a passed node name, returning a pointer to it when found. 2) Given a pointer to some geometry, which may contain pfDCS's, is there a way to make a duplicate of it, with out having to reload it from disk? In this case, pfClone will not suffice because I will make later modifications to the geometry which I do not wish to affect every other duplicate. What I'm looking for is something like pfNode pfDuplicate(pfNode *node); If the geometry under the passed node contains a pfDCS, I would need to obtain a pointer to it. The above discussion applies here too. 3) Given that I am developing on a Onyx RE2 with 2 RMs, what is the largest window I can open with multisampling turned off, z-buffer and color components with 8-bits, and acbuf turned on with 8-bits inside a Performer app. I have been successful with a 640-512 window. I would like to turn multisampling back onin this window, but even the smallest mssize() request causes the acbuf to emulated in software (not realtime). I have other questions regarding very low-level texture munipulations, but I will wait until I can solve these more important, basic questions. Your time and consideration is greatly appreciated. Kent Watsen DCS Corporation Simulation Branch 703.683.8430 x369 From aschaffe Wed Sep 7 16:05:01 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409071605.ZM15788@holodeck.asd.sgi.com> Resent-Date: Wed, 7 Sep 1994 16:05:00 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.67b8/IDA-1.5 for info-performer@sgi.com); Mon, 5 Sep 1994 16:39:13 +1000 (5.65c/IDA-1.5 for ); Mon, 5 Sep 1994 16:29:00 +1000 (5.65c/IDA-1.4.4 for ); Mon, 5 Sep 1994 16:27:03 +1000 Date: Mon, 5 Sep 1994 16:28:44 +1000 (EST) From: Kathryn Loynes Sender: Kathryn Loynes Reply-To: Kathryn Loynes Subject: Database Paging - when ?? To: Performer Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, I recently read the paper "Iris Performer: A High Performance Multiprocessing Toolkit for Real-Time 3D Graphics" by John Rohlf & Jim Helman. (/pub/Performer/performer-sig94.ps.Z on sgigate.sgi.com). In section 4.3 (Future Work) there is a description of an apparent intention to incorporate some type of database paging functionality into future Performer releases. Is there any information available regarding this ? In particular : What functionality will be provided ? When will it be available ? Will there be any capability to specify database locations in latitudes / longitudes ? In short, absolutely any information you are prepared to provide would be of great interest !!! Many thanx in advance. ---------------------------------------------------------------------- Kathy Loynes | Wormald Technology kathyl@wormald.com.au | Advanced Systems Engineering | Ph: +61 2 981 0611 From aschaffe Wed Sep 7 16:08:11 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409071608.ZM15815@holodeck.asd.sgi.com> Resent-Date: Wed, 7 Sep 1994 16:08:11 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist To: info-performer@sgi.sgi.com Cc: aono@trl.ibm.co.jp Subject: matching primitive ID before and after pfBuilder Date: Mon, 05 Sep 1994 15:16:34 +0900 From: Masaki Aono Is there a method of matching primitive ID before and after using pfBuilder? The following is a part of my code: ================================================= /* note: not every variable is declared here. */ pfVec3 Coord[MAXVERTEX]; ushort PrimitiveID[MAXTRIANGLES]; pfuBuilder *builder; pfuTri tri; pfList *gsetList; builder = pfuNewBuilder(); for (i=0;i Resent-Date: Thu, 8 Sep 1994 15:44:12 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Tue, 6 Sep 94 17:03:05 GMT From: "Ekkehard Klaerner" Organization: AITEC GmbH & Co KG To: info-performer@sgi.sgi.com Date: Tue, 6 Sep 1994 17:03:03 GMT+1 Subject: swapbuffer timing Cc: ek@aitec.de X-Mailer: Pegasus Mail v3.1 (R1a) Hi, I know, that in the previous beta-versions of PF1.2 there was a problem with the swapbuffer timing. If the system is semi-loaded and working in FLOAT mode with 30Hz, it tends to switch between 30 and 60 Hz. This happens just in the draw-process while the update-rate of the application-process is constant ! I understand, that in the production release of PF1.2 the problem has been fixed, but sometimes I have the impression, that it still happens. Has someone else experienced this same problem ? Ekki. AITEC GmbH & CO Informationstechnologie KG Ekkehard Klaerner Alter Hellweg 50 D-44379 Dortmund GERMANY Tel.: +49 231 9646545 Fax.: +49 231 9646598 EMail: ek@aitec.de From aschaffe Thu Sep 8 15:44:12 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409081544.ZM20770@holodeck.asd.sgi.com> Resent-Date: Thu, 8 Sep 1994 15:44:11 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist To: info-performer@sgi.sgi.com Cc: aono@trl.ibm.co.jp Subject: pfQueryHit Date: Tue, 06 Sep 1994 15:01:01 +0900 From: Masaki Aono Dear Performer users, I have a problem related to pfQueryHit. Suppose I have a (pfGeoSet *)gset made of indexed triangles. This gset is associated with a (pfGeode *)geode, which is in turn defined as a node of a "scene" root. Suppose a line segment is independently defined under the scene root. This line segment is used for intersection test with the gset. After creating the entire scene, I used "pfSegIsectNode(root,&segset,hits)" to see if the line segment intersects with the gset. When it hit the gset, I deleted the gset with "pfRemoveChild(root,geode)" and then added a new geode with a new gset by "pfAddChild(root,new_geode)". Also, I issued pfUnrefDelete(geode) to eradicate the old gset. Now I've got a problem. After checking the intersection between the line segment and the new gset, I issued pfQueryHit(*hits[0],PFQHIT_PRIM,&prim_id); and pfQueryHit(*hits[0],PFQHIT_VERTS,&triangle); . Then, I found that both of the returned values are not correct in the sense that the hit point returned by pfQueryHit(*hits[0],PFQHIT_POINT,&point); is not included in the triangle, or in the primitive pointed to by prim_id. Please note that both of the returned values are correct before removing the old gset and adding the new one. Does anyone encounter the similar problem? Any suggestions, advice, etc. are welcome. Regards, Masaki Aono Tokyo Research Laboratory Email: aono@trl.ibm.co.jp From aschaffe Thu Sep 8 15:51:07 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409081551.ZM20829@holodeck.asd.sgi.com> Resent-Date: Thu, 8 Sep 1994 15:51:07 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Drew Hess" Date: Tue, 6 Sep 1994 16:02:45 -0700 In-Reply-To: aaron@qbert.rts.dseg.ti.com (Aaron Hightower) "Re: Identifying channels" (Aug 28, 8:58pm) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: aaron@dseg.ti.com Subject: Re: Identifying channels Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Aug 28, 8:58pm, Aaron Hightower wrote: > Subject: Re: Identifying channels > > From: "Drew Hess" > > Subject: Identifying channels in callbacks > > > > I need a way of uniquely identifying the channel passed to a post/predraw > > callback in Performer 1.2. According to the man page, the return value of > > pfNewChan() is a handle to the newly created channel, so it sounds like I could > > use the handle for what I need. (What's actually returned is of type > > (pfChannel *), so should I use the pointer itself to identify the channel or > > should I dereference the pointer and use that value? The latter would work if, > > Trying to poke into Performer's data structures is dangerous. The main reason > being that using such "undocumented features," if they exist, is no guarantee > that they will continue to exist in new versions. I would not suggest > dereferencing any of the Performer objects directly. > I agree, which is why I'm using the pointer to identify the channel and not the dereferenced pointer. The only reason I can see why using the pointer value would fail is if a) Performer changes the value of the pointer at some time during the run-time life of the process, or b) the channel is in a shared memory arena that is mapped to different locations in different processes' address spaces, and the mapping of pointer->channel ID is created in one process and used for lookup in another where this aliasing exists. > > for instance, the pointer points to an integer that's used as a table index > > into a libpr or libpf internal table.) > > There are two ways of handling this that I know of. The first way is simply > to use pfUserData() on the pfChannel pointer and then make a structure > that identifies the channel in whatever way you would like. > This sounds like a less-kludgy way of accomplishing what I want. I'll look into it. Thanks -dwh- dhess@vision.arc.nasa.gov From aschaffe Thu Sep 8 15:44:11 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409081544.ZM20764@holodeck.asd.sgi.com> Resent-Date: Thu, 8 Sep 1994 15:44:11 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 5 Sep 94 09:53:26 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) To: info-performer@sgi.sgi.com Subject: Open Performer ... This is just a general question about Performer futur for SGI men ... Will the next version of Performer (may be 2.0) be a Open Performer one as the last release of Inventor for example ? ... If so, is there some kind of list of futur supported workstation under Open Performer ? Merci ... Cedric PS: What is the way to subscribe to the general SGI developer mail and/or customer support mail ? Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From aschaffe Thu Sep 8 15:44:11 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409081544.ZM20767@holodeck.asd.sgi.com> Resent-Date: Thu, 8 Sep 1994 15:44:11 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 5 Sep 94 16:57:09 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) To: info-performer@sgi.sgi.com Subject: Performer & Interpolation Hello ... This is a question for SGI mens (and/or womens !) ... I think you are surely working on data base interpolation for some futur release .... anyway you may help me in my search cause I have to include some interpolation staff in my application ... I would like to know if possible in which direction you are thinking about interpolation so that I may be able in the futur to jump from my implementation to the Performer one at the time it will be available without to many code rewritting ... Can you help me this way ? or may be more ? Merci ... Cedric Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From jimh@surreal Thu Sep 8 23:49:50 1994 To: gce@scl.syseca.fr (Cedric Gautier ) Cc: info-performer@sgi.sgi.com Subject: Re: Open Performer ... In-Reply-To: Your message of "Mon, 05 Sep 94 09:53:26 +0200." <9409050753.AA12340@scl > Date: Thu, 08 Sep 94 22:38:01 -0700 From: Jim Helman The next major release of Performer will be OpenGL based. But whether it makes sense for SGI to have Performer ported to other vendor's platforms is a separate issue. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From jimh@surreal Thu Sep 8 23:58:34 1994 To: Masaki Aono Cc: info-performer@sgi.sgi.com Subject: Re: pfQueryHit In-Reply-To: Your message of "Tue, 06 Sep 94 15:01:01 +0900." <9409060600.AA31137@ns.trl.ibm.com> Date: Thu, 08 Sep 94 22:48:11 -0700 From: Jim Helman > Now I've got a problem. After checking the intersection > between the line segment and the new gset, I issued ... > Please note that both of the returned values are correct before > removing the old gset and adding the new one. Does anyone encounter > the similar problem? Any suggestions, advice, etc. are welcome. Deleting parts of the scene graph should have no impact on intersections with subsequently created geometry. If you can reduce it to a small test case, I'll take a look at it. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From jimh@surreal Fri Sep 9 00:07:47 1994 To: John C Vanderburgh Cc: info-performer@sgi.sgi.com Subject: Re: textures... In-Reply-To: Your message of "Thu, 01 Sep 94 00:45:34 EDT." <199409010445.AA08711@stealth.afit.af.mil> Date: Thu, 08 Sep 94 22:56:12 -0700 From: Jim Helman As long as all your textures will fit in the 4 or 16MB of texture memory on your RM boards, a couple pfutil calls make this easy: >From sample/apps/common/generic.c used in perfly: ViewState->texList = pfuMakeTexList((pfNode *)scene); pfuDownloadTexList(ViewState->texList, PFUTEX_SHOW); rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Date: Thu, 1 Sep 1994 00:45:34 -0400 From: John C Vanderburgh To: info-performer@sgi.sgi.com Subject: textures... Hey all... I didn't find anything in the FAQ about this... I'm modeling the Earth's moon in a Performer application. I use a sphere constructed and textured via MultiGen. When I run my app and the moon first comes into view, my app freezes until the texture is loaded. Is there anyway to preload MultiGen-modeled texture? (It's taking about 3-4 seconds to load, which is unacceptable...) Thanks, John Vanderburgh AF Institute of Technology WPAFB, OH From jimh@surreal Fri Sep 9 00:17:46 1994 To: Kevin Russo Cc: info-performer@sgi.sgi.com Subject: Re: Bug in ilgettile.c In-Reply-To: Your message of "Wed, 31 Aug 94 22:39:12 GMT." <199408312239.WAA12841@midway.ait.nrl.navy.mil> Date: Thu, 08 Sep 94 23:14:08 -0700 From: Jim Helman > 1) ildeffile() should check whether NImages >= MAX_IMAGES before proceeding > Perhaps Images[] should be dynamically (re)alloc'd in chunks of 100? > > 2) ilfreetiles() should set NImages = 0 before returning. Now it only > gets bigger even though the memory is really freed. Thanks for the fixes. They're in our version now. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From jimh@surreal Fri Sep 9 00:26:08 1994 Essage-Id: <9409090629.AA18359@surreal.asd.sgi.com> To: newcomb@enews.nrl.navy.mil (Dale Newcomb) Cc: info-performer@sgi.sgi.com Subject: Re: Strange error In-Reply-To: Your message of "Thu, 01 Sep 94 15:15:08 EDT." <9409011915.AA19028@enews.nrl.navy.mil> Date: Thu, 08 Sep 94 23:29:18 -0700 From: Jim Helman > 28076:Int: rld: Error: unresolvable symbol in /usr/lib/libpf.so __pure_virtu\al > _called > 28076:Int: rld: Fatal Error: this executable has unresolvable symbols That symbol occurs in /usr/lib/libC.so. Does -lC appear on your link line after -lpf and all other C++-based libraries and object files? Are you trying to run on a system which does not have /usr/lib/libC.so installed? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From jimh@surreal Fri Sep 9 00:35:02 1994 Essage-Id: <9409090637.AA18399@surreal.asd.sgi.com> To: lessin@indy2.gstone.com (Dan Lessin) Cc: info-performer@sgi.sgi.com Subject: Re: Contouring In-Reply-To: Your message of "Wed, 24 Aug 94 10:33:44 PDT." <9408241733.AA04201@indy2.gstone.com> Date: Thu, 08 Sep 94 23:37:36 -0700 From: Jim Helman > The effect involves a three-dimensional texture ( or maybe just a > projection of a 2D texture ) which remains stationary as an object > moves through it. This sounds like texgen with TG_CONTOUR and a 2D texture. texgen automatically generates texture coordinates from vertex positions of the geometry. That's how Angus gave his swimming sharks in the Atlantis demo the illusion of light caustics focused by the water surface. You can use texgen in Performer by calling it in a pre-draw node callback above geometry that doesn't have any texture coordinates. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Fri Sep 9 15:47:10 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409091547.ZM25607@holodeck.asd.sgi.com> Resent-Date: Fri, 9 Sep 1994 15:47:10 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist ; Tue, 6 Sep 1994 17:42:15 -0400 Date: Tue, 06 Sep 1994 17:20:37 EDT From: "" To: info-performer@sgi.sgi.com Subject: performer 1.2 fixed frame rate problem with Indigo2 In a nutshell, I have written an application using an Indigo Elan, IRIX 4.0.5F, and Performer 1.0 where I read flight profile data and "fly" an aircraft model using this data over actual terrain. I ran this application at a real-time frame rate of 10 Hz. Everything worked fine until we bought a new Indigo2 with IRIX 5.2 and Performer 1.2. I used the script file port1.2 to upgrade my application to run on Performer 1.2 and everything works except I can't get it to run at a fixed frame rate. Since the Indigo2 is much faster than my old Elan, the application runs way too fast. Just like under Performer 1.0, I use the following commands to set up my frame rate : pfFrameRate(10.0f); pfPhase(PFPHASE_LOCK); or pfPhase(PFPHASE_FLOAT); but the application apparently ignores this setup and just runs as fast as it can. As an experiment, I tried running the SGI demo program perfly at a 10 Hz frame rate alternating between the four different pfPhase settings and they seem to have no effect either. When I relayed this information on to SGI product support they were able to duplicate this phenomenon on an Indigo2 (with perfly) but said that perfly run correctly with the different pfPhase settings on an Onyx. The problem was logged as a Performer bug (bug #228418). Has anyone else had a similar problem? I tried some pfMultiprocess settings to see if they made any difference (even though it is my understanding that since my Indigo2 has only one CPU, I'm, not supposed to have to worry about pfMultiprocess) but they either bombed the program or made no difference. I'm not having much luck getting ahold of anyone at Silicon Graphics to tell me if there is a workaround to this problem or when it might be fixed. So I was just wondering if anyone else had a problem like this and knew more about it. Thanks, Jim Beaver Smiths Industries 4141 Eastern Ave, SE Grand Rapids, MI 49518-8727 phone: 616-241-7671 email: beaver_jim@si.com From aschaffe Tue Sep 13 15:44:16 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131544.ZM2037@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 15:44:15 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: millard@hawkeye.newport.sgi.com (Ed Millard) Subject: Re: Strange error To: newcomb@enews.nrl.navy.mil (Dale Newcomb) Date: Wed, 7 Sep 1994 17:04:23 -0800 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9409011915.AA19028@enews.nrl.navy.mil> from "Dale Newcomb" at Sep 1, 94 03:15:08 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2673 > > Hi all! > > I tried to compile and run the sample program intersect.c in the Performer > samples under .../pguide/libpf/progs and I got it to compile fine, but when > I tried to run it (executable name is "Int") I got a strange error that I saw > one other time...when I was trying to figure out viewpoint collision detection > without using the pfuCollide functions. Here's the error: > > 28076:Int: rld: Error: unresolvable symbol in /usr/lib/libpf.so __pure_virtual > _called > 28076:Int: rld: Fatal Error: this executable has unresolvable symbols The performer group might be able to answer why libpf.so needs this. There must be some C++ in the code your using. This symbols is defined in /usr/lib/libC.so which is the C++ Dynamic Shared Object. Try linking with: -lC I've attached below a handy tool I keep around to find symbols like this. I keep it in: /usr/local/bin/symsall To find this symbol I did: symsall /usr/lib/*.so | grep __pure_virtual_called and it says: /usr/lib/libC.so: 0fbd6660 T __pure_virtual_called /usr/lib/libInventor.so: 00000000 U __pure_virtual_called /usr/lib/libInventorXt.so: 00000000 U __pure_virtual_called /usr/lib/libSgt.so: 00000000 U __pure_virtual_called /usr/lib/libdesktopGallery.so: 00000000 U __pure_virtual_called /usr/lib/libdesktopIcon.so: 00000000 U __pure_virtual_called /usr/lib/libdesktopIcon.so: 00000000 U __pure_virtual_called /usr/lib/libdtlxm.so: 00000000 U __pure_virtual_called /usr/lib/libil.so: 00000000 U __pure_virtual_called /usr/lib/libpf.so: 00000000 U __pure_virtual_called /usr/lib/libshowcase3d.so: 00000000 U __pure_virtual_called /usr/lib/libshowcaseext.so: 00000000 U __pure_virtual_called /usr/lib/libshowcaseui.so: 00000000 U __pure_virtual_called /usr/lib/libvk.so: 00000000 U __pure_virtual_called The entry with the 'T' is the library where this missing symbol lives. The entries with 'U' are undefined references of this symbol in DSO's which use it. ===========================symsall========================================= #!/bin/sh libdir=/usr/lib field=T cmd=`basename $0` usage() { echo "usage: $cmd file1 file2 ..." exit 1 } if [ $# = 0 ]; then usage fi if [ "$cmd" = "undef" ]; then field=U fi for i in $*; do if [ -f "$i" ]; then file=$i elif [ -f $libdir/lib$i.so ]; then file=$libdir/lib$i.so elif [ -f $libdir/lib$i.a ]; then file=$libdir/lib$i.a else echo "$i not found" file="" fi if [ -n "$file" ]; then nm -Bo $file \ | nawk -v field=$field '{ print $0 }'\ | sort fi done From aschaffe Tue Sep 13 15:44:15 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131544.ZM2028@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 15:44:15 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Wed, 7 Sep 1994 00:21:16 -0400 (EDT) From: Andrew Hildebrand Subject: SFLY and MCO on RE2 machines To: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Do you need to do anything special to the MCO on a RE2 machine to run sfly or does it run without MCO? I know that sfly is a stereo in a window, but will it work like that on a machine with MCO or do I have to split the images up? THANKS ______________________________________________________________________________ Andrew Hildebrand The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) hildebra@vsl.ist.ucf.edu _______________________________________________________________________________ From aschaffe Tue Sep 13 15:44:15 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131544.ZM2031@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 15:44:15 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: fred@vsl.ist.ucf.edu (ALFREDO) Date: Wed, 7 Sep 94 14:28:19 -0400 To: info-performer@sgi.sgi.com Subject: audiofile Hello, I know it's not really related to performer, but I got those source code files from sgigate.sgi.com where they use an "audiofile" library. This library is also used by some of the applications gathered in the "friends" directory. What is this library about? Is it an sgi product? Can I find the corresponding source code somewhere online? Thanks Frederic Meraud From aschaffe Tue Sep 13 15:54:14 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131554.ZM2129@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 15:54:14 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.65c/IDA-1.5 for ); Wed, 7 Sep 1994 20:39:19 -0700 (5.65c/IDA-1.5 for info-performer@sgi.com); Wed, 7 Sep 1994 20:39:35 -0700 Date: Wed, 7 Sep 1994 20:39:35 -0700 From: Al Jones To: info-performer@sgi.sgi.com Subject: Ada bindings for Performer? Yes, I know that you don't do graphics in Ada, and certainly not high-performance visual simulation. But ... does anyone out there have Ada bindings for the Performer library calls? Alain Jones solo@crl.com From aschaffe Tue Sep 13 15:44:15 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131544.ZM2034@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 15:44:15 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Shahram Shiri" Date: Wed, 7 Sep 1994 17:11:00 -0400 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: RE: Bug in ilgettile.c Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 >Fellow Performers: > >We have run into a bug in libpfsgi/ilgettile.c (Perf 1.2) >that causes a bus error. Perhaps this is a well-known problem? > >Whenever LoadPtu() is called over 50 times, the static buffer Images[100] >in ilgettile.c overflows, corrupting other memory. There are two oversights >in the code that contribute to the bug: > > Back in the middle of August, I posted a bug report to the net in regard to the .ptu file crashes on Onyx machines. It is similar to the problem you described on your posting. I get the core dump of running perfly only on Onyx. When I try to run the same .ptu file on an Indigo-2, it works fine. Of course, I have not tried to load multiples of the perfly on Indigo-2 and I am not surprised if it crashes. I reported the bug to sgi hotline back in August 18, too. No responses from sgi, yet. It looks to me the problem is in ImageVision Library where ilgettile() calls ilMemoryImgImg() function from IL. As you noted, the pointer to the memory location is lost. I have seen similar postings on lost memory pointers attributing to the memory allocation by IL functions. Are you able to run the program on Onyx? We tested the program on three different Onyxes with no luck. -Ron -- ------------------------------------------------------------------------- |Shahram Shiri/ ron@leaf.gsfc.nasa.gov Tel: 301-286-9985 | |NCCS/Scientific Visualization Studio Fax: 301-286-1634 | |NASA/Goddard Space Flight Center, Hughes/STX | |Greenbelt, Maryland 20771 | ------------------------------------------------------------------------- From aschaffe Tue Sep 13 16:03:30 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131603.ZM2189@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 16:03:30 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Thu, 8 Sep 94 10:17:39 GMT From: "Ekkehard Klaerner" Organization: AITEC GmbH & Co KG To: jvanderb@afit.af.mil Date: Thu, 8 Sep 1994 10:17:24 GMT+1 Subject: Re: textures... Cc: info-performer@sgi.sgi.com X-Mailer: Pegasus Mail v3.1 (R1a) Hi John, I think to solve your problem, you have to download all textures to the texture memory immediately after loading time. Use the functions pfuMakeTexList and pfuDownloadTexList (descriptions are in the man pages). Ekki. AITEC GmbH & CO Informationstechnologie KG Ekkehard Klaerner Alter Hellweg 50 D-44379 Dortmund GERMANY Tel.: +49 231 9646545 Fax.: +49 231 9646598 EMail: ek@aitec.de From aschaffe Tue Sep 13 16:13:30 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131613.ZM2307@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 16:13:29 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist To: watsen@netcom.com (Kent Watsen) Cc: info-performer@sgi.sgi.com (performer) Subject: Re: Some Basic Q's In-Reply-To: Your message of "Sun, 04 Sep 94 12:10:36 PDT." <199409041910.MAA23723@netcom.netcom.com> Date: Thu, 08 Sep 94 11:12:22 -0400 From: Len Granowetter In message <199409041910.MAA23723@netcom.netcom.com> you write: > >Hi, I've been using Performer 1.2 to write a >distributed interactive simulation application >and I have some basic questions which I have >yet to resolve. > [When you pfClone a node, how do you find the node in the cloned > graph that corresponds to a particular node in the original?] >The only other option I have thought >of is to write a little procedure to traverse the >scene graph below a passed pfNode for a passed node >name, returning a pointer to it when found. Yup. I came across this exact problem a few months ago, also while writing a DIS application (our commercial Stealth application). After asking on this mailing list, it became clear that there is no good way to do this using pfFind. So, as someone else on this list suggested, I wrote a function just like the one you describe above, which worked fine. -Len Granowetter MaK Technologies (617) 876-8085 lengrano@mak.com From aschaffe Tue Sep 13 16:23:08 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409131623.ZM2408@holodeck.asd.sgi.com> Resent-Date: Tue, 13 Sep 1994 16:23:08 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Thu, 8 Sep 94 13:40:20 EDT From: louis@speech.iar.nrc.ca (Louis Bolduc) To: info-performer@sgi.sgi.com Subject: Question about pfDelete and Geodes... The Performer programming guide is not 100 % clear on the effects of deleting a node. If I use pfDelete on a Geode, will it automatically delete the GSets and GState structures (and recursively delete the structures tied to the GState? (fog, for instance)), or do I have to clean everything up myself? Thanks ahead. - Louis | Life would be much easier to| Louis Bolduc | === __ | | understand if mother nature | (613) 998-9780 | \_______| _) | | gave us the source code. | louis@speech.iar.nrc.ca | __ /\ | __ | | - Graeme MacWilliam | Flight Research | / / \ / \ \ | | | Laboratory | | /_|_\/\/ | \ | | | #include | | \ / \/ \ / | +----- NRC/CNRC - Institute for Aerospace Research -----+- \__/ ------- \__/ -+ From jimh@surreal Tue Sep 13 17:11:24 1994 To: Al Jones Cc: info-performer@sgi.sgi.com, wes@tryada.wpd.sgi.com Subject: Re: Ada bindings for Performer? In-Reply-To: Your message of "Wed, 07 Sep 94 20:39:35 PDT." <199409080339.AA19140@crl4.crl.com> Date: Tue, 13 Sep 94 17:07:26 -0700 From: Jim Helman SGI's Ada folks have written demos in Performer, including a flyover of Yellowstone National Park and a multiplayer paintball game. Wes Embry (wes@sgi.com) can give you details. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Date: Wed, 7 Sep 1994 20:39:35 -0700 From: Al Jones To: info-performer@sgi.sgi.com Subject: Ada bindings for Performer? Yes, I know that you don't do graphics in Ada, and certainly not high-performance visual simulation. But ... does anyone out there have Ada bindings for the Performer library calls? Alain Jones solo@crl.com From aschaffe Wed Sep 14 15:35:27 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141535.ZM7104@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:35:26 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist id <27342-0@smtpgw.unizh.ch>; Fri, 9 Sep 1994 09:06:06 +0200 Fri, 9 Sep 1994 09:05:57 --100 From: suter@rsl.geogr.unizh.ch (Martin Suter) Fri, 9 Sep 94 09:05:56 +0200 Subject: Textures: Flat Shading? To: info-performer@sgi.sgi.com Date: Fri, 9 Sep 1994 07:05:56 +0000 (MET) Reply-To: suter@rsl.geogr.unizh.ch X-Organization: Remote Sensing Laboratories, University of Zurich X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 Ciao... Is it possible to apply flat shading to textures instead of gouraud shading? -- Martin Suter suter@rsl.geogr.unizh.ch Phone: +41 - 1 / 257 51 63 Remote Sensing Laboratories FAX: +41 - 1 / 362 52 27 University of Zurich Winterthurerstrasse 190 CH-8057 Zurich; Switzerland From aschaffe Wed Sep 14 15:38:10 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141538.ZM7126@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:38:10 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: David Weller X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 Subject: Re: Ada bindings for Performer? To: solo@crl.com (Al Jones) Date: Tue, 13 Sep 1994 18:31:31 -0500 (CDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <199409080339.AA19140@crl4.crl.com> from "Al Jones" at Sep 7, 94 08:39:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1167 > Yes, I know that you don't do graphics in Ada, and certainly not > high-performance visual simulation. But ... does anyone out there > have Ada bindings for the Performer library calls? > I have a version, but Wes Embry of SGI has a more complete version to my knowledge. If he doesn't chime in (I don't know if he reads this mailing list), drop me a line. Heck, I even have a version of Perfly written in Ada, if you're interested (minus GUI). As for "not doing graphics in Ada"...well, SGI's Paintball program (now written in the newer version of Ada, Ada 9X) is a good example of what you can do with the language. Frankly, this is one dude who would rather write graphics stuff in Ada 9X rather than C++, but that's not what this mailing list is about :-) -- Proud (and vocal) member of Team Ada! (and Team OS/2) ||This is not your Ada 9X -- It doesn't suck || father's Ada For all sorts of interesting Ada 9X tidbits, run the command:||________________ "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.) **Tri-Ada '94, Nov 7-11, Baltimore, MD -- Something for Everybody.** From aschaffe Wed Sep 14 15:36:27 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141536.ZM7113@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:36:26 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 12 Sep 1994 10:05:15 +0900 From: "Yuri.A.Tijerino" To: info-performer@sgi.sgi.com Subject: A beginer's question: Performer vs GL Hello, I just joined the list last week and read as much as I could from the FAQ, but couldn't find any info on how GL relates to Performer. Perhaps this info is way too obvious for all of you so it is not in the FAQ. However, I am new to SGI platforms and I am more a researcher than a programmer and I couldn't make the relation from the FAQ. What I want to know is if it is fairly simple and straight forward to port some GL program to work with Performer? Are there any porting ultilities available? We have a very large and complex GL-based application running on multiprocessor machines and are planning on buying Performer, but we would first like to know what is involved programming wise and how fast we can make the transition. Any help or pointers will be appreceiated. Sincerely yours, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Yuri A. Tijerino Ph.D. | ATR Communication Systems | Research Laboratories | Artificial Intelligence Department | _ __ _ 2-2 Hikaridai, Seikacho, | \ | ) Communication Sorakugun, Kyoto 619-02 Japan | _ \ | \ Systems Tel: +81-7749-5-1264 (Direct) | / \ | \ Research Fax: +81-7749-5-1208 | Laboratories E-mail: yuri@atr-sw.atr.co.jp | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From aschaffe Wed Sep 14 15:35:54 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141535.ZM7110@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:35:54 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Chris Tanner" Date: Fri, 9 Sep 1994 11:25:52 -0700 In-Reply-To: Jim Helman "Re: Contouring" (Sep 8, 11:37pm) References: <9409090735.AA18979@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Jim Helman , lessin@indy2.gstone.com (Dan Lessin) Subject: Re: Contouring Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Sep 8, 11:37pm, Jim Helman wrote: > Subject: Re: Contouring > > > The effect involves a three-dimensional texture ( or maybe just a > > projection of a 2D texture ) which remains stationary as an object > > moves through it. > > This sounds like texgen with TG_CONTOUR and a 2D texture. texgen > automatically generates texture coordinates from vertex positions of > the geometry. That's how Angus gave his swimming sharks in the > Atlantis demo the illusion of light caustics focused by the water > surface. > > You can use texgen in Performer by calling it in a pre-draw node > callback above geometry that doesn't have any texture coordinates. > > >-- End of excerpt from Jim Helman One quick note. Texgen in fact overrides texture coordinates sent down the pipe, so you dont have to take off texture coordinates before sending the data down (or giving the data to Performer) simply having the following (extracted from a new version of callbacks.c in the utility library) will do the trick...Note that you should do a man on texgen so that you understand how to define the texgen parameters such that your mapping from objectspace to screen-space texture coords will happen the way you want it... (For those of you not yet versed in the notion of node callbacks in the draw process, a call to pfNodeTravFuncs(Geode,PFTRAV_DRAW, pfuPreDrawContourMap, pfuPostDrawContourMap); on the relevant Geode will cause all the geometry under Geode to be Contour Mapped) static char CallBacks[PF_MAXSTRING] = "pfCallbacksDPool"; int pfuPreDrawContourMap(pfTraverser *trav, void *data) { pfDataPool *dp; float *paramsX, *paramsY; dp = pfAttachDPool(CallBacks); if (dp == NULL) pfuTexgenParams(NULL, NULL); paramsX = (float *)pfDPoolFind(dp, 1); paramsY = (float *)pfDPoolFind(dp, 2); (trav, trav); (data, data); mmode(MVIEWING); pfPushIdentMatrix(); texgen(TX_S, TG_CONTOUR, paramsX); texgen(TX_T, TG_CONTOUR, paramsY); texgen(TX_S, TG_ON, NULL); texgen(TX_T, TG_ON, NULL); pfPopMatrix(); return NULL; } int pfuPostDrawContourMap(pfTraverser *trav, void *data) { (trav, trav); (data, data); texgen(TX_S, TG_OFF, NULL); texgen(TX_T, TG_OFF, NULL); return NULL; } /* Also, to set the parameters for texgen use the following utility code */ void pfuGetTexgenParams(float *newParamsX,float *newParamsY) { pfDataPool *dp; float *paramsX, *paramsY; int i; dp = pfAttachDPool(CallBacks); if (dp == NULL) pfuTexgenParams(NULL, NULL); paramsX = (float *)pfDPoolFind(dp, 1); paramsY = (float *)pfDPoolFind(dp, 2); for (i=0;i<4;i++) newParamsX[i] = paramsX[i]; for (i=0;i<4;i++) newParamsY[i] = paramsY[i]; } void pfuTexgenParams(const float *newParamsX, const float *newParamsY) { pfDataPool *dp; float *paramsX, *paramsY; dp = pfAttachDPool(CallBacks); if (dp == NULL) { dp = pfNewDPool(sizeof(float) * 8, CallBacks); paramsX = (float *)pfDPoolAlloc(dp, sizeof(float) * 4, 1); paramsY = (float *)pfDPoolAlloc(dp, sizeof(float) * 4, 2); } else { paramsX = (float *)pfDPoolFind(dp, 1); paramsY = (float *)pfDPoolFind(dp, 2); } if (!newParamsX) { paramsX[0] = 0.0; paramsX[1] = 1.0; paramsX[2] = 0.0; paramsX[3] = 1.0; } else { paramsX[0] = newParamsX[0]; paramsX[1] = newParamsX[1]; paramsX[2] = newParamsX[2]; paramsX[3] = newParamsX[3]; } if (!newParamsY) { paramsY[0] = 0.0; paramsY[1] = 1.0; paramsY[2] = 0.0; paramsY[3] = 1.0; } else { paramsY[0] = newParamsX[0]; paramsY[1] = newParamsX[1]; paramsY[2] = newParamsX[2]; paramsY[3] = newParamsX[3]; } } -- _____________________________________________________________ Chris Tanner (cct@faith.asd.sgi.com) Silicon Graphics - Advanced Graphics Division _____________________________________________________________ From aschaffe Wed Sep 14 15:35:40 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141535.ZM7107@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:35:39 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: bleclerc@cae.ca (Bernard Leclerc) Subject: Performer On-line books To: info-performer@sgi.sgi.com Date: Fri, 9 Sep 1994 09:41:30 -0400 (EDT) Cc: rejeanc@cae.ca (Rejean Chartrand), fpeng@cae.ca (Fung Peng) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 320 Hi Performers, I'd like to know if SGI plans to offer the Performer documentation in an InSight format? I would appreciate to consult on-line books instead of searching for reference manuals. -- Bernard Leclerc Systems Engineer Dept. 74 CAE Electronics Ltd. tel.: +1 514 341 2000, local 2275 e-mail: bleclerc@cae.ca From aschaffe Wed Sep 14 15:36:59 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141536.ZM7116@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:36:59 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.67b8/IDA-1.5 for info-performer@sgi.com); Mon, 12 Sep 1994 12:21:58 +1000 (5.65c/IDA-1.5); Mon, 12 Sep 1994 12:17:00 +1000 (5.65c/IDA-1.4.4); Mon, 12 Sep 1994 12:12:55 +1000 Date: Mon, 12 Sep 1994 12:12:04 +1000 (EST) From: Kathryn Loynes Subject: Re: Some Basic Q's To: Kent Watsen Cc: performer In-Reply-To: <199409041910.MAA23723@netcom.netcom.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 4 Sep 1994, Kent Watsen wrote: > 1) If I have a pointer to some geometry which > contains one or more pfDCS's, how can I obtain > pointers to the new pfDCS's after pfClone-ing > the geometry? .... ... I have recently been involved with the same issue. I ended up doing what you describe in the last sentence : traversing down the new (cloned) geometry under "NewRoot" until the cloned node "X" was found. Then storing the pointer to new node "X" for future use. The pfuTraverse function will do this. I associated a node callback with it to distinguish the DCS nodes of interest. The callback simply tested to see if the current node was a DCS, if so then pfGetNodeName was used to establish which DCS this was (important if the geometry beneath "NewRoot" had multiple DCSs in it) and then stored the pointer to the node. I deliberately avoided using the pfFindDCS function for performance reasons. Also, as you point out it requires all node names within the scene graph to be unique which would not be the case with multiple cloning. The traversal approach only requires that all DCS nodes within a single cloned section are uniquely named. Hope this helps ! > 2) Someone else ... > > 3) Someone else ... ---------------------------------------------------------------------- Kathy Loynes | Wormald Technology kathyl@wormald.com.au | Advanced Systems Engineering | Ph: +61 2 981 0611 From aschaffe Wed Sep 14 15:37:49 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409141537.ZM7123@holodeck.asd.sgi.com> Resent-Date: Wed, 14 Sep 1994 15:37:49 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "JAVIER CASTELLAR" Date: Mon, 12 Sep 1994 12:17:31 -0600 In-Reply-To: watsen@netcom.com (Kent Watsen) "Some Basic Q's" (Sep 4, 12:10pm) References: <199409041910.MAA23723@netcom.netcom.com> X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: watsen@netcom.com (Kent Watsen), info-performer@sgi.sgi.com Subject: Re: Some Basic Q's Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, The problem is on the acsize you are using: try to use the right size on the acsize (let's say either 12 instead of 8 or 24 instead of 16). If you are using a non congruent bitplane number on the framebuffer in relation with the ac. buff you will receive a very slow software emulation. Try to use acsize(12), it should work ALWAYS (including small pixel depth = any number of RM(1-4). If you use acsize(24) you should work with medium/larger pixel depth, or if you could skip Zbuffer, you can use it also in small pixel depth. Hope to help. Javier Castellar Systems Engineer javier@madrid.sgi.com From aschaffe Fri Sep 16 18:36:40 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161836.ZM13156@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:36:40 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: jrohlf@tubes (John Rohlf) Subject: Re: Question about pfDelete and Geodes... To: aschaffe (Louis Bolduc) Date: Wed, 14 Sep 94 10:17:35 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9409081740.AA10104@speech.iar.nrc.ca>; from "Louis Bolduc" at Sep 8, 94 1:40 pm X-Mailer: ELM [version 2.3 PL8] > > The Performer programming guide is not 100 % clear on the effects of deleting a > node. > > If I use pfDelete on a Geode, will it automatically delete the GSets and GState > structures (and recursively delete the structures tied to the GState? (fog, > for instance)), or do I have to clean everything up myself? > When in doubt check man pages since they are always the final word on Performer functionality. The following states that pfDelete is recursive and "does the right thing". pfDelete frees the memory associated with obj if its reference count is <= 0. When an object is freed, it decrements the reference count of all pfObjects that it once referenced and will delete any of these pfObjects with reference counts that are <= 0. Thus, pfDelete will follow all reference chains until it encounters a pfObject which it cannot delete. pfDelete returns the following: pfDelete is implemented for all IRIS Performer objects except the following: pfPipe pfChannel pfEarthSky pfTraverser pfState pfDataPool From aschaffe Fri Sep 16 18:37:09 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161837.ZM13162@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:37:09 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: jrohlf@tubes (John Rohlf) Subject: Re: async file IO To: guest (Desmond Hii Toh Onn) Date: Wed, 14 Sep 94 10:54:50 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9408020810.AA04539@charon>; from "Desmond Hii Toh Onn" at Aug 2, 94 4:10 pm X-Mailer: ELM [version 2.3 PL8] > > Greetings, I'm having some problem with async file io. > I cannot write anything to it. There *must* be something > I did not do. Thanks for the advice in advance. > > below is the code > desmond > > /*________________________________________________________________*/ > #include > #include > #include > #include > #include > > main() > { > pfFile *oFile; > int Fstatus; > > oFile = pfOpenFile("test.open",O_WRONLY|O_CREAT|O_APPEND,0644); > > Fstatus = pfWriteFile(oFile,"first line\n",11); > printf("status of file %d\n",Fstatus); > /* returns 0 !!! */ > > Fstatus = pfGetFileStatus(oFile,PFRTF_STATUS); > printf("status of file %d\n",Fstatus); > /* return 1 */ > > Fstatus = pfCloseFile(oFile); > printf("status of file %d\n",Fstatus); > /* return 0 */ > } > There are indeed a few bugs in pfFile. However, pfFile was intended as a temporary fix for async I/O which is now supported by IRIX 5.2 I believe. Look at the aio_init() and related man pages to see if this satisfies your requirement. Otherwise we can get you pfFile fixes/workarounds. From aschaffe Fri Sep 16 18:39:30 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161839.ZM13195@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:39:30 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Thu, 15 Sep 94 11:17:26 CDT From: bmc@autobahn.mayo.EDU (Bruce Cameron) To: info-performer@sgi.sgi.com Subject: Performer Stereo Channels? I'm trying to turn stereo display on/off within a Performer application. I use the following code to create a 2nd channel and set the offsets. Problem is, I'm not seeing double in the window. I believe that I'm only seeing the left (master) channel in the window. Anyone have any clues as to what I'm not doing right or the step(s) I've missed? Many Thanks. pfChannel *right; pfVec3 stereoXYZ, stereoHPR; static void stereoOn (void) { pfVec3 xyz, hpr; long mask = pfGetChanShare (ViewState->masterChan); pfPipe *pipe = pfGetChanPipe (ViewState->masterChan); static int firsttime = 1; if (firsttime) { right = pfNewChan (pipe); /* ViewState->masterChan is left eye */ pfChanShare (ViewState->masterChan, mask|PFCHAN_VIEWPORT|PFCHAN_SWAPBUFFERS_HW); pfAttachChan (ViewState->masterChan, right); firsttime = 0; } pfGetChanViewOffsets (ViewState->masterChan, stereoXYZ, stereoHPR); /* setup viewing offsets */ pfSetVec3 (xyz, stereoXYZ[PF_X]+2.0, stereoXYZ[PF_Y], stereoXYZ[PF_Z]); pfSetVec3 (hpr, stereoHPR[PF_H]+3.0f, stereoHPR[PF_P], stereoHPR[PF_R]); pfChanViewOffsets (ViewState->masterChan, xyz, hpr); /* for right eye */ pfSetVec3 (xyz, stereoXYZ[PF_X]-2.0, stereoXYZ[PF_Y], stereoXYZ[PF_Z]); pfSetVec3 (hpr, stereoHPR[PF_H]-3.0f, stereoHPR[PF_P], stereoHPR[PF_R]); pfChanViewOffsets (right, xyz, hpr); } static void stereoOff (void) { pfChanViewOffsets (ViewState->masterChan, stereoXYZ, stereoHPR); pfChanViewOffsets (right, stereoXYZ, stereoHPR); } --- --Bruce ----------------------------------------------------- Bruce M. Cameron bmc@mayo.edu Mayo Foundation office: (507) 284-3288 200 1st St SW fax: (507) 284-1428 Rochester, MN 55905 ARS WD9CKW From aschaffe Fri Sep 16 18:36:29 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161836.ZM13153@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:36:29 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: jrohlf@tubes (John Rohlf) Subject: Re: Some Basic Q's To: aschaffe (Len Granowetter) Date: Wed, 14 Sep 94 10:12:25 PDT Cc: watsen@netcom.com, info-performer@sgi.sgi.com In-Reply-To: <9409081512.AA09539@mak.com>; from "Len Granowetter" at Sep 8, 94 11:12 am X-Mailer: ELM [version 2.3 PL8] > > In message <199409041910.MAA23723@netcom.netcom.com> you write: > > > >Hi, I've been using Performer 1.2 to write a > >distributed interactive simulation application > >and I have some basic questions which I have > >yet to resolve. > > > [When you pfClone a node, how do you find the node in the cloned > > graph that corresponds to a particular node in the original?] > > >The only other option I have thought > >of is to write a little procedure to traverse the > >scene graph below a passed pfNode for a passed node > >name, returning a pointer to it when found. > > Yup. I came across this exact problem a few months ago, also while > writing a DIS application (our commercial Stealth application). After > asking on this mailing list, it became clear that there is no good way > to do this using pfFind. So, as someone else on this list suggested, > I wrote a function just like the one you describe above, which worked > fine. Try renaming the root of the cloned subgraph to ensure that pathnames will be unique: clone = pfClone(truck, 0); pfNodeName(clone, "truck1"); wheel1 = pfFind("truck1/wheel"); This should work for now. The next release of Performer will contain more sophisticated database query routines. From aschaffe Fri Sep 16 18:40:46 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161840.ZM13201@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:40:46 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 12 Sep 94 09:19:42 CDT From: bmc@autobahn.mayo.EDU (Bruce Cameron) To: info-performer@sgi.sgi.com Subject: Intersections and Stereo I've not seen answers to these in the FAQ... 1) Does anyone have some example code the demonstrates how to detect collisions between objects with in a scene? I have an object that is driven through the scene and I would like to be able to detect what objects it runs into and report "You ran in to the ______" I thought to use pfuCollideObj() to handle the collision detection, but I've not been able to figure out how to detect which object has been run into, or how to label the objects. Any suggestions? 2) Does anyone have any example code illustrating stereo display? I've a set of crystal eyes, and I'd like to be able to turn hardware stereo display on/off via a keystroke. Any suggestions? Many Thanks. --Bruce ----------------------------------------------------- Bruce M. Cameron bmc@mayo.edu Mayo Foundation office: (507) 284-3288 200 1st St SW fax: (507) 284-1428 Rochester, MN 55905 ARS WD9CKW From aschaffe Fri Sep 16 18:43:03 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161843.ZM13214@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:43:03 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: bill@rap.ucar.EDU (Bill Myers) Subject: Ortho Projection Question To: info-performer@sgi.sgi.com Date: Tue, 13 Sep 1994 21:26:09 -0600 (MDT) In-Reply-To: X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 532 Hello all, Can someone send me an example of how to render a scene with an ortho projection matrix? I assume one uses a pfFrustrum, but I don't understand where it would get attached in the hierarchy? The code I am working with was written under Performer Rev 1.0, and I don't see anything having to do with perspective projections in there either (other than near/far clip planes). So I'm really sure where to start. As I am not a regular reader of this group, please send responses to myers@ncar.ucar.edu Thanks, Bill Myers From aschaffe Fri Sep 16 18:37:29 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161837.ZM13165@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:37:29 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: jrohlf@tubes (John Rohlf) Subject: Re: Cloning pfGSetAttr To: guest (Kent Watsen) Date: Thu, 15 Sep 94 12:25:14 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199408172308.QAA16898@netcom15.netcom.com>; from "Kent Watsen" at Aug 17, 94 4:08 pm X-Mailer: ELM [version 2.3 PL8] > > > Hello, > > Given a pointer to a pfNode which is the > root of some geometry, will a pfClone of > this node allow me to change the colors > of some polygons without affecting the > the colors of the original or any other > pfClones of the original? > > If Not, if there another way to copy all > of the geometry (LOD, DCS, pfGSetAttr, etc) > of a given node without having to reload > it from disk? > pfClone currently does not clone geosets so you'll have to reload or clone by hand. Hopefully we will fully implement pfClone for the next release. From aschaffe Fri Sep 16 18:40:14 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161840.ZM13198@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:40:14 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 12 Sep 1994 11:53:30 +0000 (GMT-1:00) From: Elke Hendon Subject: pfPushMatrix/pfPopMatrix in Traveral CB? To: Performer Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Performer, I wish to change the viewing matrix for a particular node so that the object remains "apparently" always in front of my viewpoint. Of course one could solve this by making this object a DCS. However, I wanted to try pfPushIdentMatrix in a Traversal callback (is this ok?). I does not seem to work, for the ovject is transformed as normal according to the view matrix for the channel (pfChanView). Here is sample code. Where have I gone wrong? //During APP, before simloop: setup() { pfNodeTravMask(node, PFTRAV_CULL,0L,PFTRAV_SELF|PFTRAV_DESCEND,PF_SET); pfNodeTravMask(node,PFTRAV_DRAW,0xffffffff,PFTRAV_SELF|PFTRAV_DESCEND,PF_SET); pfNodeTravFuncs(node,PFTRAV_CULL,x_precull,x_postcull); pfNodeTravFuncs(node, PFTRAV_DRAW, x_predraw, x_postdraw); } static long x_precull(pfTraverser *trav, void *data) { return(PFTRAV_CONT); } static long x_postcull(pfTraverser *trav, void *data) { return(0); } static long x_predraw(pfTraverser *trav, void *data) { pfPushIdentMatrix(); return(PFTRAV_CONT); } static long x_postdraw(pfTraverser *trav, void *data) { pfPopMatrix(); return(PFTRAV_CONT); } will subordinate nodes of "node" likewise obey this traversal rule? Thanks for hints and help!! --------------------------------------------------------------------------- K.Stuehrmann Atlas Elektronik GmbH, D-28305 Bremen, Sebaldsbruecker Heerstr. 235, Simulation Division elke@tyrann.atlas.de --------------------------------------------------------------------------- From aschaffe Fri Sep 16 18:36:49 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161836.ZM13159@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:36:49 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: jrohlf@tubes (John Rohlf) Subject: Re: Need help with indexed colors, please To: guest (Lew Hitchner) Date: Wed, 14 Sep 94 10:44:45 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199407272340.QAA25007@netcom7.netcom.com>; from "Lew Hitchner" at Jul 27, 94 4:40 pm X-Mailer: ELM [version 2.3 PL8] > > Could someone PLEASE help with how to use pfColorTable indexed colors? > 5. I enable/disable indexed color mode as follows: > > in APP process: > --------------- > material = pfGetGStateAttr(patch->geoStates[i], PFSTATE_FRONTMTL); > pfMtlColorMode(material, PFMTL_FRONT, > (enableCtab) ? PFMTL_CMODE_COLOR : PFMTL_CMODE_AD); This conditional is reversed. You need CMODE_AD when in color index mode - otherwise the PER_VERTEX colors will be overridden by the material color. From aschaffe Fri Sep 16 18:42:39 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161842.ZM13210@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:42:39 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist To: info-performer@sgi.sgi.com Cc: ohbuchi@trl.ibm.co.jp Subject: Obtaining "squished" transformation for a node Date: Wed, 14 Sep 1994 11:03:36 +0900 From: Ryutarou OHBUCHI I have been looking for an efficient way to "squish" (concatenate) transformations, both DCS and SCS, from a root to a specified node of a scene graph. I wish to know the squished transform for the node at a certain moment so that I can use it for various purposes. Following the path from the node to the root fails since a node may have multiple parents. (Is this right?) Another solution I thought of is to traverse the scene graph from the root (e.g., by pfuTraverse) until the node in question is found, while keeping track of the transform in a stack of transformation matrices. This would work fine for a small graph without too severe a performance problem if the number of queries is small. Before implementiong the traverse method, I wanted to check if there is a better method. Performer tend to have many features that I miss in my cursoly scan of the programmer's manual. ----- Ryutarou Ohbuchi IBM Japan, Ltd., SA-S76 1623-14, Shimo-tsuruma, Yamato-shi, Kanagawa-ken 242, Japan Phone: 0462-73-4882 Fax: 0462-73-7413 ip: ohbuchi@trl.ibm.co.jp From aschaffe Fri Sep 16 18:41:15 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409161841.ZM13204@holodeck.asd.sgi.com> Resent-Date: Fri, 16 Sep 1994 18:41:15 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Bruce Cameron" Date: Tue, 13 Sep 1994 09:44:40 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: retrieving intersection masks Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 In my code, I set the intersection traversal masks as follows at load time. if ((gptr = strstr (DatabaseFiles[i], "GOOD")) != NULL){ pfNodeTravMask (root, PFTRAV_ISECT, 0x01, PFTRAV_SELF|PFTRAV_DESCEND|PFTRAV_IS_CACHE, PF_SET); } else{ pfNodeTravMask (root, PFTRAV_ISECT, 0x02, PFTRAV_SELF|PFTRAV_DESCEND|PFTRAV_IS_CACHE, PF_SET); } To setup my intersection segments, I use: segset.activeMask = 1; segset.isectMask = 0x01|0x02; segset.mode = PFTRAV_IS_PRIM|PFTRAV_IS_PATH|PFTRAV_IS_CULL_BACK; segset.segs[0].length = PROBE_LEN; pfSetVec3 (segset.segs[0].pos, x, y, z); pfSetVec3 (segset.segs[0].dir, dx, dy, dz); During the simulation, I use the following to detect intersections with the data. isect = pfSegsIsectNode (ViewState->sceneGroup, &segset, hits); if (isect) { pfQueryHit (*hits[0], PFQHIT_POINT, &pnt); pfQueryHit (*hits[0], PFQHIT_NODE, &inode); mask = pfGetNodeTravMask (inode, PFTRAV_ISECT); if (mask == 0x02) { fprintf (stderr, "bad object\n"); fflush (stderr); } else if (mask == 0x01){ fprintf (stderr, "good object\n"); fflush (stderr); } } Unfortunately, the mask is 0xffffffff regardless of the object intersected with. Is there a way to retrieve the intersection traversal mask? If so, what am I doing wrong? Thanks in advance. -- --Bruce ----------------------------------------------------- Bruce M. Cameron bmc@mayo.edu Mayo Foundation office: (507) 284-3288 200 1st St SW fax: (507) 284-1428 Rochester, MN 55905 ARS WD9CKW From jimh@surreal Sun Sep 18 21:41:49 1994 Delivery-Date: Sun, 18 Sep 94 15:55:46 -0700 From: "Wes Embry" Date: Sun, 18 Sep 1994 15:54:29 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: solo@crl.com, steveh@ctaeng.com, lac@gothamcity.jsc.nasa.gov, matson@phoebus.ncsc.navy.mil Subject: Ada Performer Bindings and Demos Cc: quiggle@tryada.wpd.sgi.com, johnt@tryada.wpd.sgi.com, jimh@giraffe, mtj@giraffe, liroff@tryada.wpd.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 To everyone who has sent a request for Performer Ada Bindings, we wish to tell you that they are almost ready. We do have incomplete handwritten bindings today for the paintball and yellowstone demos, but those are being updated to run under with Ada9x and use the new Performer Bindings. These new Performer Bindings are being generated automatically from the C hdr files, in both an Ada83 form and an Ada9x form. We are currently updating our Ada binding generator tool to deal with C-macros (which are of course present in the Performer and X interfaces) but this should be ready soon. If any of you need something sooner, send mail to Tom Quiggle (quiggle@engr.sgi.com) or John Templeton (johnt@engr.sgi.com). As to the Paintball Demo, we will certainly release it in source, but we need to coordinate with the Performer Group as to how to best achieve this. Thanks for your interest, Wes From aschaffe Mon Sep 19 15:36:53 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191536.ZM17309@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 15:36:52 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: askins@hrlban1.aircrew.asu.edu Date: Wed, 14 Sep 94 16:23:42 MST To: iris-performer@sgi.sgi.com Subject: 2D distortions of resulting imagery X-Incognito-Sn: 207 X-Incognito-Format: VERSION=1.60g ENCRYPTED=NO I have a question that is not strictly Performer-related, but I thought someone out there might be able to help me (or perhaps has considered the same issue). I would like to be able to perform (in real-time of course) various 2-D transformations on the resulting rendered scene of a simulation. For example, there are certain spatial deformations (emulating optical distortions) that I would like to "view a simulation through". I won't go into the various distortions I am interested in, but suffice it to say I don't believe they could be performed with any kind of windowing/perspective set-up, but could easily be done if the simulation imagery could somwhow be rendered directly to part of texture memory, rather than the screen buffer, and then applied to a mesh of 2-D polygons laid out with the correct distortions. I've obviously thought of copying the contents of the back-buffer into texture memory each frame, but I don't think this could be done at a rate even close to real-time. (If I'm wrong please tell me!) Is there any way the graphics pipe could be made to render directly to the texture memory, rather than screen buffer (at the same speed)? Also, I've thought about the possibility of a hardware solution. I know that the Sirius video option allows video to be loaded directly into texture memory, and as I have a 2-pipe system, I was wondering if there is something similar to the Sirius that would allow me to load the screen buffer of one graphics pipe into the texture memory of the other pipe. {I think that 2 Sirius boards (one on each pipe, with the output of one hooked to the input of the other) would do this, but I think I would be limited to transferring a window of NTSC resolution. I would need to transfer at least a 1024x1024 window.} Are there any other boards on the market that would allow a transfer like this? As I said, I would need to transfer a 1024x1024 window from the screen buffer of one pipe to the texture memory of the other pipe, at 30-60 Hz. (Or possibly, transfer the screen buffer back into part of the texture memory of the same pipe.) I am working with a 2-pipe, Onyx RE2 with 16M texture memory, 8 R4400's, and 256M memory. Thanks in advance for any help. Tim Askins Univ of Dayton Research Institute @ Armstrong Laboratory From aschaffe Mon Sep 19 15:35:47 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191535.ZM17289@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 15:35:46 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Tue, 13 Sep 94 15:13:18 -0400 To: info-performer@sgi.sgi.com From: darken@enews.nrl.navy.mil (Rudy Darken) Subject: X and pf - typedef redefinitions Cc: tonnesen@enews.nrl.navy.mil In my performer application, I am creating a GL X-window with GLCreateMDraw() that performer will draw in . The problem is: how to you get this to compile? GL typedefs Boolean to a long in gl.h and X typedefs Boolean to a char in X11/Intrinsic.h The IRIX C++ Compiler (3.2.1) errors out on this redefinition. Is there a way to get around this? Thanks, Cindy Tonnesen tonnesen@enews.nrl.navy.mil _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From aschaffe Mon Sep 19 15:38:25 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191538.ZM17312@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 15:38:25 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Thu, 15 Sep 94 17:04 MDT From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: switching lights on/off Reply-To: matomira@epfl.ch Hello, I would like to have a pfLightSource and switch it on/off for different parts of the scene via draw callbacks. The man page for pfLight says the pfLightOn depends on the current transformation matrices. Is this the same for a pfLightSource ? If so, what's the efficient way to go about this? By the way, I know I can put pfLights in a pfGeoState. I do not want to do this. Thanks in advance, Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From aschaffe Mon Sep 19 15:36:33 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191536.ZM17306@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 15:36:33 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: prwhite@sgva-inhc.ucsd.edu (Payton White) Subject: Crimson RE with 1 RM To: info-performer@sgi.sgi.com Date: Tue, 13 Sep 1994 16:21:18 -0800 (PDT) Cc: sbrown@sgva-inhc.ucsd.edu (Sheldon Brown) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1158 Please help, We have just installed a Crimson RE (in our Crimson... running OS 5.2 and Performer 1.2). The RE only has one raster manager, and our local SGI rep warned us that there are some limitations as far as alpha-blending and anti-aliasing on a one RM RE. The only help he could give us is that these things are only available in a 640x512 or smaller window. This is obviously just part of the fix because this didn't change anything. Please let me know about all of the other tweaks that we must implement, and any source would be helpful. By the way, the code has run successfully on a number of other RE machines with no changes. Thanks, -- Visualization << SGI >> Simulation -- Payton R. White http://jupiter.ucsd.edu/prw/myhomepage.html prwhite@ucsd.edu __ __ __ / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From aschaffe Mon Sep 19 15:35:24 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191535.ZM17280@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 15:35:24 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.65c/IDA-1.4.4/EUnet/NO for nuug!sgi.com!info-performer); Tue, 13 Sep 1994 16:09:29 +0200 From: "Vidar Stoerkersen" Date: Tue, 13 Sep 1994 16:10:07 +0100 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Projecting textures. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 In our performer-application we want to attach headlights to our car, too be able to drive in the dark. On the "Onyx demos" CD there are some projected textures demoes. Is it possible to do texture projection in performer. If yes, how can I do it. (Can anyone provide me with an example source for texture projection.) -- Vidar Stoerkersen | Tel: +47 77 67 50 75 vidar@autosim.no | Fax: +47 77 67 67 01 From aschaffe Mon Sep 19 15:39:05 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191539.ZM17315@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 15:39:05 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: "Bob Buckley" Date: Thu, 15 Sep 1994 11:19:21 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Light Point Questions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 841 Performerides, I've been trying to increase light point sizes (pfLPointSize) with limited success. Is there currently a limit on the size of light points on REs? Regardless of the size I give to pfLPoint Also, is there any intention for Performer to do light point LOD fading? If not, can that future capability be added to the list. Thanks =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From aschaffe Mon Sep 19 18:12:41 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409191812.ZM18330@holodeck.asd.sgi.com> Resent-Date: Mon, 19 Sep 1994 18:12:41 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Fri, 16 Sep 94 11:39:32 PDT From: stiles@aic.lockheed.com (Randy Stiles) To: info-performer Subject: Perfomer Morph Node Hi, In the SIGGRAPH 94 paper that John Rolf and Jim Helman wrote, "IRIS Performer: A High Performance Multiprocessing Toolkit for Real-Time 3D Graphics" There is a description in the class hierarchy of a pfMorph node. I assume that this pfMorph node is implemented in a future release. I was interested by the description of it, but could not find it in the man pages or libraries of the MR Performer 1.2. Is there a pfMorph coming out in Performer v2.0, and could we get a more detailed description of what its capabilities are? Thanks, -Randy # Randy Stiles Lockheed AI Center # stiles@aic.lockheed.com Orgn 9620 Bldg 254F # Office: 415.354.5256 3251 Hanover Street # Fax: 415.354.5235 Palo Alto, CA 94304-1191 From jimh@surreal Mon Sep 19 18:25:29 1994 Date: Mon, 19 Sep 94 18:25:29 -0700 From: jimh@surreal (Jim Helman) To: prwhite@sgva-inhc.ucsd.edu (Payton White) Cc: sbrown@sgva-inhc.ucsd.edu (Sheldon Brown) Fcc: +inbox Subject: Re: Crimson RE with 1 RM (and AA warning under 1.2) In-Reply-To: Your message of "Tue, 13 Sep 94 16:21:18 -0800." <9409132321.AA16214@sgva-inhc> -------- It isn't the size of the window, but rather the size of the video format you are currently running. The issue at any particular screen resolution is whether the RMs have enough frame buffer storage to store multiple subsamples for each pixel. Use /usr/gfx/setmon to switch to a lower resolution VOF (hopefully, you have a multisync monitor). You can run /usr/gfx/gfxinfo to see whether you have enough frame buffer memory for multisampling as indicated by a Medium or Large pixel depth. 1RM @ 980x760 supports medium pixel depth which gives 8 subsamples with 1 bit of stencil and 24 bit Z. 1RM @ 640x480 supports large pixels which give 16 subsamples. 1RM @ 1280x1024 supports small pixels which have no subsamples and therefore no antialiasing and no multisample transparency. The lack of multisample transparency means 1) no fade LOD and 2) transparent objects must be drawn back to front to blend properly, since only blended transparency is available. You'll notice #2 in the Performer Town's trees. WARNING ON 1.2 & ANTIALIASING: by default Performer 1.2 ONLY gives 4 subsamples per pixel on medium pixel depth configs. The change was caused by Performer internally requesting 4 bits of stencil for pixel fill statistics. Programs can override the default by doing their own mssize/gconfig in the init pipe callback. When you setup the frame buffer in your application, you can tradeoff between Z (24 or 32) color bits (8 or 12), stencil bits and subsamples (0, 4, 8 or 16). You do this using mssize() gconfig() under GL windowing (always use getgconfig to check what GL decided to give you), e.g.: winopen("ms"); RGBsize(reqCol); RGBmode(); zbsize(0); /* no regular Z buf */ stensize(0); /* no regular stencil */ mssize(reqSub, reqZ, reqSten); gconfig(); printf("req: sub: %d z: %d sten: %d, col: %d\n", reqSub, reqZ, reqSten, reqCol); printf("got: sub: %d z: %d sten: %d, col: %d\n", getgconfig(GC_MS_SAMPLES), getgconfig(GC_BITS_MS_ZBUFFER), rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From jimh@surreal Mon Sep 19 21:04:44 1994 Date: Mon, 19 Sep 94 21:04:44 -0700 From: jimh@surreal (Jim Helman) To: stiles@aic.lockheed.com (Randy Stiles) Cc: info-performer Subject: Re: Perfomer Morph Node In-Reply-To: Your message of "Fri, 16 Sep 94 11:39:32 PDT." <9409161839.AA00391@aic.lockheed.com> -------- The SIGGRAPH paper describes what we've done, which is (usually) more than what we've released. pfMorph won't go out until the next major release. At this point, specifics aren't that useful, since we'll be chewing on it a bit more before spitting it out. But here's an outline. Rumors that we're all fans of the schlockiest TV show to disgrace the Sat AM airwaves and that Performer 2.0 will be named the Mighty Morphing Performer Release are utterly false. We're morphing because it's important for 1) morph LOD and 2) real-time character animation. Morph LOD has visual advantages over hard-switching and performance advantages over fading (fade LOD has some bad characterstics since stress-based LOD scaling may draw both models, thereby increasing geometric load before decreasing it.) Real-time character animation is useful in entertainment applications (like Disney Imagineering's Aladdin VR ride), and in digital production where it permits performance-driven animation and recording real-time to video rather than frame-by-frame. The basic capabilities for geometric morphing are: 1) weighted (linear) combination of pfGeoSet attribute arrays (e.g. coords, normals, colors, texcoords) as inputs to generate a renderable output for each attribute. 2) multiprocessing of the morph computation across host CPUs. 3) multibuffering of the output arrays to support the multiprocessing. So morphing isn't a standalone feature, it also overlaps with dynamic multibuffered geometry and with LOD. You could implement these features on top of Performer right now, or wait. But in either case, if you're modeling new databases, you might want to construct extra LOD models with the vertex correspondence required for morph LOD, e.g. when modelling a house with 2 LOD's you need an extra intermediate model for the morphing: /\ / \ / \ / \ ________ ________ /\ /| / / /| / /| / \ / | / / / | / / | / \ / | / / / | / / | /______\/ | /___/___/ | /_______/ | | | | | | | | | | | | / | | / | | / | | / | | / | | / | | / | | / | | / |______|/ |______|/ |______|/ high detail intermediate low detail model model model rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From jimh@surreal Mon Sep 19 23:22:44 1994 Date: Mon, 19 Sep 94 23:19:12 -0700 From: jimh@surreal (Jim Helman) To: askins@hrlban1.aircrew.asu.edu Cc: iris-performer@sgi.sgi.com Subject: Re: 2D distortions of resulting imagery In-Reply-To: Your message of "Wed, 14 Sep 94 16:23:42 MST." -------- > I've obviously thought of copying the contents of the back-buffer into texture > memory each frame, but I don't think this could be done at a rate even close > to real-time. (If I'm wrong please tell me!) Depends on the resolution, but it can be expensive. When loading an 8-bit RGB texture, fbsubtexload will give you about 8-9 MTexel/sec, which means doing 512x512 would take up most of a 30Hz frame time. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From johnson@vrlab.uccb.ns.ca Tue Sep 20 08:37:11 1994 From: "Mark Johnson" Date: Tue, 20 Sep 1994 12:35:58 -0300 In-Reply-To: darken@enews.nrl.navy.mil (Rudy Darken) "X and pf - typedef redefinitions" (Sep 13, 3:13pm) References: <9409131913.AA02061@enews.nrl.navy.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com, info-performer-dist, aschaffe (Allan Schaffer) Subject: Re: X and pf - typedef redefinitions Cc: tonnesen@enews.nrl.navy.mil Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 729 On Sep 13, 3:13pm, Rudy Darken wrote: > Subject: X and pf - typedef redefinitions > In my performer application, I am creating a GL X-window with > GLCreateMDraw() that performer will draw in . The problem is: how to you > get this to compile? GL typedefs Boolean to a long in gl.h and X typedefs > Boolean to a char in X11/Intrinsic.h The IRIX C++ Compiler (3.2.1) errors > out on this redefinition. Is there a way to get around this? > >-- End of excerpt from Rudy Darken I have had this same problem. It occurs for other types as well. The solution is to always include X headers before others. Things like Performer and Viewkit seem able to live with the X definitions. Mark Johnson johnson@vrlab.uccb.ns.ca From aschaffe Wed Sep 21 18:13:25 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409211813.ZM6460@holodeck.asd.sgi.com> Resent-Date: Wed, 21 Sep 1994 18:13:25 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 19 Sep 94 21:04:44 -0700 From: jimh@surreal (Jim Helman) To: stiles@aic.lockheed.com (Randy Stiles) Cc: info-performer Subject: Re: Perfomer Morph Node In-Reply-To: Your message of "Fri, 16 Sep 94 11:39:32 PDT." <9409161839.AA00391@aic.lockheed.com> -------- The SIGGRAPH paper describes what we've done, which is (usually) more than what we've released. pfMorph won't go out until the next major release. At this point, specifics aren't that useful, since we'll be chewing on it a bit more before spitting it out. But here's an outline. Rumors that we're all fans of the schlockiest TV show to disgrace the Sat AM airwaves and that Performer 2.0 will be named the Mighty Morphing Performer Release are utterly false. We're morphing because it's important for 1) morph LOD and 2) real-time character animation. Morph LOD has visual advantages over hard-switching and performance advantages over fading (fade LOD has some bad characterstics since stress-based LOD scaling may draw both models, thereby increasing geometric load before decreasing it.) Real-time character animation is useful in entertainment applications (like Disney Imagineering's Aladdin VR ride), and in digital production where it permits performance-driven animation and recording real-time to video rather than frame-by-frame. The basic capabilities for geometric morphing are: 1) weighted (linear) combination of pfGeoSet attribute arrays (e.g. coords, normals, colors, texcoords) as inputs to generate a renderable output for each attribute. 2) multiprocessing of the morph computation across host CPUs. 3) multibuffering of the output arrays to support the multiprocessing. So morphing isn't a standalone feature, it also overlaps with dynamic multibuffered geometry and with LOD. You could implement these features on top of Performer right now, or wait. But in either case, if you're modeling new databases, you might want to construct extra LOD models with the vertex correspondence required for morph LOD, e.g. when modelling a house with 2 LOD's you need an extra intermediate model for the morphing: /\ / \ / \ / \ ________ ________ /\ /| / / /| / /| / \ / | / / / | / / | / \ / | / / / | / / | /______\/ | /___/___/ | /_______/ | | | | | | | | | | | | / | | / | | / | | / | | / | | / | | / | | / | | / |______|/ |______|/ |______|/ high detail intermediate low detail model model model rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Wed Sep 21 18:29:47 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409211829.ZM6561@holodeck.asd.sgi.com> Resent-Date: Wed, 21 Sep 1994 18:29:47 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Tue, 20 Sep 1994 12:14:35 -0700 From: hitchner@netcom.com (Lew Hitchner) To: jimh@surreal Subject: Re: Perfomer Morph Node Cc: info-performer I don't understand your example for suggested LOD models to take advantage of future Performer morphing capabilities: >> You could implement these features on top of Performer right >> now, or wait. But in either case, if you're modeling new >> databases, you might want to construct extra LOD models with >> the vertex correspondence required for morph LOD, e.g. when >> modelling a house with 2 LOD's you need an extra intermediate >> model for the morphing: >> >> /\ >> / \ >> / \ >> / \ ________ ________ >> /\ /| / / /| / /| >> / \ / | / / / | / / | >> / \ / | / / / | / / | >> /______\/ | /___/___/ | /_______/ | >> | | | | | | | | | >> | | / | | / | | / >> | | / | | / | | / >> | | / | | / | | / >> |______|/ |______|/ |______|/ >> >> high detail intermediate low detail >> model model model Aren't the high and intermediate detail models above identical topologically. Seems to me when morphing from the high detail model to the low detail model, you could just start with the high model, morph the vertices of the roof ridgeline til they match the positions shown in the intermediate model, then switch LOD nodes. Why would you need the extra intermediate model? Of course somewhere you'd need to store the starting (higher detail) and ending (lower detail) vertex, normal, color, etc. info for those attribute elements that get changed during morphing. But, wouldn't it depend on how many attribute elements need to be morphed as to whether you need a whole extra model (node), or just some user data stashed in shared memory? Am I missing something? Perhaps the "morph release" of Performer could support a partitioning of pfGeoset primitive attributes (for the PER_VERTEX case) into static, dynamic-begin, and dynamic-end sets (or, more generally, just any number of partitions and let the user choose which partitions to morph between). Then, for your example above there could be, say, 10 vertices in the user's shared memory data (similar for normals, colors, etc.), and 8 indices into that data for static attributes, 2 indices into that data for dynamic-begin data (the high detail version), and 2 indices into the dynamic-end data (low detail version). Performer could then automatically interpolate between the respective pairs of data for the begin/end (high/low) versions of the morphed attributes. Seems like this can be done in v1.2 in the CULL or DRAW callbacks if a user just manages his/her own index lists for dynamic attribute elements. Lew P.S. Have you thought about how to morph vertex normals when they're composed from face normals of static (non-morphed) tri's and tri's with morphed vertices, e.g., the four bottom vertices of your house roof (if you had a Gouraud shaded house (:-))? -- maybe just linearly interpolate between the starting and ending normals? From mtj@babar Wed Sep 21 21:52:04 1994 From: "Michael Jones" Date: Wed, 21 Sep 1994 21:51:44 -0700 In-Reply-To: hitchner@netcom.com (Lew Hitchner) "Re: Perfomer Morph Node" (Sep 20, 12:14pm) References: <199409201914.MAA16465@netcom3.netcom.com> X-Mailer: Z-Mail (3.2a.627 27jun94 MediaMail) To: hitchner@netcom.com (Lew Hitchner), jimh@surreal, info-performer-dist, aschaffe (Allan Schaffer) Subject: Re: Perfomer Morph Node Cc: info-performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 20, 12:14pm, Lew Hitchner wrote: > Subject: Re: Perfomer Morph Node :I don't understand your example for suggested LOD models to take advantage :of future Performer morphing capabilities. :>> :>> /\ :>> / \ :>> / \ :>> / \ ________ ________ :>> /\ /| / / /| / /| :>> / \ / | / / / | / / | :>> / \ / | / / / | / / | :>> /______\/ | /___/___/ | /_______/ | :>> | | | | | | | | | :>> | | / | | / | | / :>> | | / | | / | | / :>> | | / | | / | | / :>> |______|/ |______|/ |______|/ :>> :>> high detail intermediate low detail :>> model model model : :Aren't the high and intermediate detail models above identical :topologically. Yes, they are. The high-detail model has the mediation (linear morph parameter) of 1.0 and the "intermediate model" has the mediation parameter of 0.0, so for this case Performer would: use the higher model with parameter 1.0 out to say 500m; move the parameter from 1.0 to 0.0 over the range 500m to 1500m; instantly switch without fade to the lower model at 1500m; use the lower model at all greater ranges. This is a very simple case of a much more powerful mechanism. :Seems to me when morphing from the high detail model to :the low detail model, you could just start with the high model, morph :the vertices of the roof ridgeline til they match the positions shown :in the intermediate model, then switch LOD nodes. Why would you need :the extra intermediate model? As you say, it's not necessary. Jim was just showing the two extremes of interpolation as an example. :Of course somewhere you'd need to store :the starting (higher detail) and ending (lower detail) vertex, normal, :color, etc. info for those attribute elements that get changed during :morphing. But, wouldn't it depend on how many attribute elements need :to be morphed as to whether you need a whole extra model (node), or :just some user data stashed in shared memory? Am I missing something? The amount of memory is fixed by the model itself in that it's possible to have initial and final values for vertices (v0 and v1), as one way of using the new features. :Perhaps the "morph release" of Performer could support a partitioning :of pfGeoset primitive attributes (for the PER_VERTEX case) into static, :dynamic-begin, and dynamic-end sets (or, more generally, just any :number of partitions and let the user choose which partitions to morph :between). Then, for your example above there could be, say, 10 :vertices in the user's shared memory data (similar for normals, colors, :etc.), and 8 indices into that data for static attributes, 2 indices :into that data for dynamic-begin data (the high detail version), and 2 :indices into the dynamic-end data (low detail version). Performer :could then automatically interpolate between the respective pairs of :data for the begin/end (high/low) versions of the morphed attributes. :Seems like this can be done in v1.2 in the CULL or DRAW callbacks if a :user just manages his/her own index lists for dynamic attribute :elements. Yep. It could certainly be made to work just as you describe. ;-) : Lew : :P.S. Have you thought about how to morph vertex normals when they're : composed from face normals of static (non-morphed) tri's and tri's : with morphed vertices, e.g., the four bottom vertices of your : house roof (if you had a Gouraud shaded house (:-))? -- maybe just : linearly interpolate between the starting and ending normals? As a matter of fact, we've thought about it quite a bit. There are several choices, of which simple interpolation is one reasonable approach. One other extreme is to compute face normals from vertex positions after morphing and to subsequently compute vertex normals from explicitly indicated sets of face normals. Simple interpolation (with and without) normalization can be made to work quite well in many cases actually encountered in practice. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From aschaffe Thu Sep 22 01:03:28 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409220103.ZM7614@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 01:03:28 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 19 Sep 94 23:19:12 -0700 From: jimh@surreal (Jim Helman) To: askins@hrlban1.aircrew.asu.edu Cc: iris-performer@sgi.sgi.com Subject: Re: 2D distortions of resulting imagery In-Reply-To: Your message of "Wed, 14 Sep 94 16:23:42 MST." -------- > I've obviously thought of copying the contents of the back-buffer into texture > memory each frame, but I don't think this could be done at a rate even close > to real-time. (If I'm wrong please tell me!) Depends on the resolution, but it can be expensive. When loading an 8-bit RGB texture, fbsubtexload will give you about 8-9 MTexel/sec, which means doing 512x512 would take up most of a 30Hz frame time. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Thu Sep 22 14:59:49 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221459.ZM9862@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 14:59:48 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: blubaron@MIT.EDU To: info-performer@sgi.sgi.com Cc: blubaron@beamish.mit.edu Subject: Waves Date: Thu, 15 Sep 94 20:33:47 EDT Hello, I am trying to create the impression of moving waves, like in the lake database that comes with the friends of performer distribution. Does anyone know how this was done? Thank You, Brett Reid From aschaffe Thu Sep 22 15:25:57 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221525.ZM10061@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 15:25:57 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist (5.65b/IDA-1.4.3 for info-performer@sgi.com); Fri, 16 Sep 94 10:47:40 GMT From: Simon Gibbs Subject: Inventor loader To: info-performer@sgi.sgi.com Date: Fri, 16 Sep 94 14:47:39 MDT The Performer FAQ mentions that a fully functional loader for IRIS Inventor files will be relased via this mailing list - has this happened already (I just joined the list recently)? If not, are there any guesses as to when it's likely to happen? (We have some Inventor models with per-vertex colors - the Performer 1.2 LoadIv routine does not handle these correctly.) Many thanks, Simon Gibbs ---------------------------------------------------------------------------- Simon Gibbs GMD Schloss Birlinghoven 53574 Sankt Augustin GERMANY ---------------------------------------------------------------------------- Email: Simon.Gibbs@gmd.de WWW: http://cui_www.unige.ch/OSG/Simon Tel: +49 (2241) 14.2697 (direct) +49 (2241) 14.2366 (department office) +49 (2241) 14.2040 (fax) ---------------------------------------------------------------------------- From aschaffe Thu Sep 22 15:41:39 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221541.ZM10173@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 15:41:39 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist From: jrohlf@tubes (John Rohlf) Subject: Re: Crimson RE with 1 RM To: aschaffe (Payton White) Date: Tue, 20 Sep 94 16:16:04 PDT Cc: info-performer@sgi.sgi.com, sbrown@sgva-inhc.ucsd.edu In-Reply-To: <9409132321.AA16214@sgva-inhc>; from "Payton White" at Sep 13, 94 4:21 pm X-Mailer: ELM [version 2.3 PL8] > > Please help, > We have just installed a Crimson RE (in our Crimson... > running OS 5.2 and Performer 1.2). The RE only has one raster > manager, and our local SGI rep warned us that there are some > limitations as far as alpha-blending and anti-aliasing on a one RM > RE. The only help he could give us is that these things are only > available in a 640x512 or smaller window. This is obviously just > part of the fix because this didn't change anything. Please let me > know about all of the other tweaks that we must implement, and any > source would be helpful. By the way, the code has run successfully > on a number of other RE machines with no changes. > > Thanks, > > -- Visualization << SGI >> Simulation -- > Payton R. White > http://jupiter.ucsd.edu/prw/myhomepage.html > prwhite@ucsd.edu __ __ __ > / / /_/ _/ /_ > ______ _____ __ __ / /___ __ / __/______ > / __ // .__// /__/ // __ // / / / / ____/ > / /_/ // / / _ // / / // /_ / /_ / __/_ > / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ > / /When the going gets weird, the weird turn pro. > /_/ - Hunter S. Thompson > > > > You need to restart the Xserver after you set the lower resolution VOF. From a terminal or remote host type: /usr/gfx/stopgfx /usr/gfx/startgfx From aschaffe Thu Sep 22 16:04:34 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221604.ZM10503@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 16:04:34 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist To: hitchner@netcom.com (Lew Hitchner) Cc: info-performer Subject: Re: Perfomer Morph Node In-Reply-To: Your message of "Tue, 20 Sep 94 12:14:35 PDT." <199409201914.MAA16465@netcom3.netcom.com> Date: Tue, 20 Sep 94 16:23:36 -0700 From: Jim Helman > Why would you need the extra intermediate model? Of course somewhere > you'd need to store the starting (higher detail) and ending (lower > detail) vertex, normal, color, etc. info for those attribute elements > that get changed during morphing. Really the only point is that you need to specify the additional geometric information for the intermediate model. Most modelling tools and file formats don't provide any place to store that information except as a new model. Once you have such an intermediate model, it's just a matter of writing a loader that can appropriately combine that model with its topological twin and decide which attributes need to morph and which do not. Better modelling tools will make this easier. I believe that Multigen V14 has support for morph LOD specification. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Thu Sep 22 16:13:36 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221613.ZM10555@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 16:13:35 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 19 Sep 94 10:02:11 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) To: info-performer@sgi.sgi.com Subject: data base interpolation .... Hello ... This is a question for SGI people ... I think you are surely working on data base interpolation for some futur release .... anyway you may help me in my search cause I have to include some interpolation stuff in my application ... I would like to know if possible in which direction you are thinking about interpolation so that I may be able in the futur to jump from my implementation to the Performer one at the time it will be available without to many code rewritting ... Can you help me this way ? or may be more ? or less ! ... Merci ... Cedric Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From aschaffe Thu Sep 22 16:23:34 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221623.ZM10603@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 16:23:34 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer-dist Date: Mon, 19 Sep 94 15:01:30 +0100 From: "Dr. Markus Lappe" To: info-performer@sgi.sgi.com Subject: Simple shapes Reply-To: lappe@neuroinformatik.ruhr-uni-bochum.de I would like to build a scene containing a number of simple rounded shapes, namely circles and cylinders, and load it into a performer animation. I was thinking that Inventor provides an easy file format to accomplish this. However, it seems that Performer only loads Inventor files that do not contain these simple predefined shapes. Only those parts of the Inventor file that are defined by vertices and traingles are displayed. Is this functionality missing in the Performer .iv file loader? Is there a fix? Is there another way of creating such simple shapes in a high level manner, i.e. without programming every vertex and every triangle? I am using Performer 1.2 and Inventor 2.0 on an Indigo 2 XZ running IRIX 5.2 Thanks, Markus --- Dr. Markus Lappe Allg. Zoologie und Neurobiologie Ruhr-Universitaet Bochum D-44780 Bochum Germany Phone +234-700-4369 Fax +234-709-4278 email lappe@neuroinformatik.ruhr-uni-bochum.de From aschaffe Thu Sep 22 17:00:05 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221700.ZM10868@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 17:00:04 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: bill@rap.ucar.EDU (Bill Myers) Subject: Picking Example Code Request To: info-performer@sgi.sgi.com Date: Mon, 19 Sep 1994 09:56:19 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 144 Hello, Could someone please send me a simple program demonstrating how picking is done in Performer? Thanks. Bill Myers myers@ncar.ucar.ecu From aschaffe Thu Sep 22 17:32:58 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221732.ZM11029@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 17:32:58 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Mon, 19 Sep 94 15:41:35 -0700 From: shung@ernie.arc.nasa.gov (Felix Shung) To: info-performer@sgi.sgi.com I am trying to create a scene which simulates what can be seen through 3 cockpit windows. The code is based on the example "perfly" provided by the Performer 1.2. The 3 channels are initialized in the "InitChannel" as following: for (i=0; i< NumChans; i++){ Chan[i] = pfNewChan(pfGetPipe(0)); } pfuConfigMCO(Chan, NumChans); ViewState->masterChan = Chan[ChanOrder[1]]; ViewState->leftChan = Chan[ChanOrder[0]]; ViewState->rightChan = Chan[ChanOrder[2]]; /* Attach channels to master channel to form a channel group. */ for (i=0; i< NumChans; i++) if (Chan[i] != ViewState->masterChan) pfAttachChan(ViewState->masterChan, Chan[i]); /* define the offset angles for the left and right screen */ if(ViewState->displayMode != MCO_MODE0){ /* Set each channel's viewing offset */ pfSetVec3(xyz, 0.0f, 0.0f, 0.0f); pfSetVec3(hpr, OFFSET_ANGLE, 0.0f, 0.0f); pfChanViewOffsets(ViewState->leftChan, xyz, hpr); pfSetVec3(hpr, -OFFSET_ANGLE, 0.0f, 0.0f); pfChanViewOffsets(ViewState->rightChan, xyz, hpr); } /* set up the master(center screen ) channel */ /* Set the callback routines for the pfChannel */ pfChanCullFunc(ViewState->masterChan, CullFunc); pfChanDrawFunc(ViewState->masterChan, DrawFunc); /* Attach the visual database to the center */ pfChanScene(ViewState->masterChan, ViewState->scene); /* Attach the EarthSky model to the center */ pfChanESky(ViewState->masterChan, ViewState->eSky); /* Initialize the near and far clipping planes */ pfChanNearFar(ViewState->masterChan, ViewState->near, ViewState->far); /* Vertical FOV is matched to window aspect ratio. */ pfChanAutoAspect(ViewState->masterChan, PFFRUST_CALC_VERT); pfMakeSimpleFrust(ViewState->masterChan, ViewState->fov); /* Initialize the viewing position and direction */ pfChanView(ViewState->masterChan, ViewState->initView.xyz, ViewState->initView.hpr); ********************************************* and the viewpoint and direction of the masterChan is updated once per frame in the realtime loop by using pfChanView(...) Somehow, all the previous definitions are lost in the real time and the viewport and fov are default value( ie. fov = 45.0....). Can anybody can give me any suggestion what goes wrong? ViewState is a structre variable defined in Shared memory. Felix . From aschaffe Thu Sep 22 17:45:12 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409221745.ZM11074@holodeck.asd.sgi.com> Resent-Date: Thu, 22 Sep 1994 17:45:12 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: watsen@netcom.com (Kent Watsen) Subject: Bug in pfflt To: info-performer@sgi.sgi.com (performer) Date: Mon, 19 Sep 1994 19:45:39 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 385 I've discovered that the cleanTree routine employed by LoadFlt does not retain NodeNames. Although one may register a CB_CLEANNODE callback, there is no way to set the new node's name without extensive programming. The line of code in line 2196 of hier.c fixes this error: pfNodeName (cnode, pfGetNodeName(child)); Kent Watsen DCS Corporation Simulation Branch 703.683.8430 x369 From guest Fri Sep 23 06:54:52 1994 Date: Fri, 23 Sep 94 08:51:37 CDT From: lac@gothamcity.jsc.nasa.gov (Lac Nguyen) Apparently-To: A way back I heard from the info-performer that the full loader of Inventor will be available on ftp site. I wonder when it will happen. I think a lot of people as I know are waiting for this. Because more and more people are interesting the Inventor format. From guest Fri Sep 23 07:20:45 1994 Fri, 23 Sep 94 08:56:04 CST From: m218822@fltsim.MDC.COM (Bill Balloni) Subject: C++ class library To: info-performer@sgi.sgi.com Date: Fri, 23 Sep 1994 08:52:55 -0600 (CDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 683 Hello, Realizing from the SIGGRAPH paper that libpf is written in C++, is there an object-oriented interface that is part of Performer? If so, can I get at it for application development? If not, is there any class library out there that makes OO Performer application development easier? It seems that the conversion of the libpf interface to C (by Performer) and then writing a C++ wrapper around that (by me or ???) is overly wasteful. Thanks, Bill Balloni McDonnell Douglas Aerospace St. Louis, MO Flight Simulation Laboratory email: balloni@fltsim.MDC.COM phone: (314) 234-0944 From guest Fri Sep 23 08:57:54 1994 (5.65c/IDA-1.4.4 for ); Fri, 23 Sep 1994 11:57:38 -0400 Date: Fri, 23 Sep 1994 11:57:38 -0400 From: John C Vanderburgh To: info-performer@sgi.sgi.com Subject: Re: C++ class library Cc: mstytz@afit.af.mil Regarding inquiries about an object-oriented framework for Performer like this one: ======================================================================= > Hello, > > Realizing from the SIGGRAPH paper that libpf is written in C++, is there > an object-oriented interface that is part of Performer? If so, can I get > at it for application development? If not, is there any class library > out there that makes OO Performer application development easier? > > It seems that the conversion of the libpf interface to C (by Performer) > and then writing a C++ wrapper around that (by me or ???) is overly > wasteful. > > ======================================================================= Last year a student here at the AF Institute of Technology wrote an object-oriented framework for Performer simulations as part of a thesis effort. We use his framework for all of our VR applications. This framework, called "ObjectSim", is written in C++ and makes it easier to get Performer applications going in an object-oriented, C++ environment. If anyone would like more info on this, or would like a copy of the software, please e-mail: Lt Col Martin Stytz (mstytz@afit.af.mil) or myself. John Vanderburgh AF Institute of Technology Wright-Patterson AFB, OH (jvanderb@afit.af.mil) From guest Fri Sep 23 09:10:17 1994 Date: Fri, 23 Sep 94 09:10:09 PDT From: stiles@aic.lockheed.com (Randy Stiles) To: info-performer@sgi.sgi.com In-Reply-To: Lac Nguyen's message of Fri, 23 Sep 94 08:51:37 CDT <9409231351.AA12336@gothamcity.jsc.nasa.gov> Date: Fri, 23 Sep 94 08:51:37 CDT From: lac@gothamcity.jsc.nasa.gov (Lac Nguyen) Apparently-To: A way back I heard from the info-performer that the full loader of Inventor will be available on ftp site. I wonder when it will happen. I think a lot of people as I know are waiting for this. Because more and more people are interesting the Inventor format. Ditto - My sentiments exactly. It is a very important format, especially for SGI. Judging by the number of requests for this in the newsgroups, and on this mailing list over the past year and a half, it probably should recieve a high priority. -Randy # Randy Stiles Lockheed AI Center # stiles@aic.lockheed.com Orgn 9620 Bldg 254F # Office: 415.354.5256 3251 Hanover Street # Fax: 415.354.5235 Palo Alto, CA 94304-1191 From guest Fri Sep 23 09:48:14 1994 From: "Michael Jones" Date: Fri, 23 Sep 1994 09:48:02 -0700 In-Reply-To: lac@gothamcity.jsc.nasa.gov (Lac Nguyen) "" (Sep 23, 8:51am) References: <9409231351.AA12336@gothamcity.jsc.nasa.gov> X-Mailer: Z-Mail (3.2a.627 27jun94 MediaMail) To: lac@gothamcity.jsc.nasa.gov (Lac Nguyen), Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 23, 8:51am, Lac Nguyen wrote: > Subject: :A way back I heard from the info-performer that the full loader of Inventor :will be available on ftp site. I wonder when it will happen. I think a lot :of people as I know are waiting for this. Because more and more people are :interesting the Inventor format. : >-- End of excerpt from Lac Nguyen We have a better loader for the IRIS Inventor format that we'll be making available soon. News of it's arrival will appear here first. There will still be efficiency and other such issues, but people with data in that format will at least be able to import it. We have used it to load 3D text. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Sep 23 10:38:17 1994 (5.65c/IDA-1.4.4 for ); Fri, 23 Sep 1994 13:36:43 -0400 Date: Fri, 23 Sep 1994 13:36:43 -0400 From: John C Vanderburgh To: info-performer@sgi.sgi.com Hey all, I'm working on a Performer application that models satellites in near-Earth orbit. I position the viewpoint arbitrarily out in "space" to view the satellites. One of the options for the user is to show satellite "trails" , i.e. lines showing where the satellite has been in its orbit. I render the satellite trails after I call "pfDraw", so my draw callback looks like this: ---------------------------------------------- void DrawChannel(pfChannel *chan, void *data) { /* Draw some terrain */ . . . /* Check for and process user-input via the "qread" call */ . . . pfClearChan(chan); pfDraw(); /* Now draw my satellite trails: */ pfPushState (); pfBasicState (); Draw_Satellite_Trails (); pfPopState (); } ----------------------------------------------- Whenever the viewpoint is stationary, the satellite trails are drawn correctly. However, as I'm moving the viewpoint the satellite trails appear to be one "step" behind the viewpoint movement. (As the viewpoint moves faster, the problem is more evident.) Inside "Draw_Satellite_Trails", I compute the position of each trail point relative to the current viewpoint position. If I output the viewpoint position from my app-thread and compare it to the viewpoint position inside "Draw_Satellite_Trails", they are identical. Does anyone have any ideas as to what I'm doing wrong? One explanation would be that Performer is swapping buffers between the "pfDraw" call and my "Draw_Satellite_Trails" call... (but that doesn't sound quite right). Thanks in advance, John Vanderburgh Air Force Institute of Technology Wright-Patterson AFB, OH (jvanderb@afit.af.mil) From guest Fri Sep 23 11:16:12 1994 ; Fri, 23 Sep 1994 14:16:01 -0400 id AA02034; Fri, 23 Sep 1994 11:19:47 PST Organization: MultiGen Inc X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Fri, 23 Sep 1994 10:19:50 PST Subject: Re: Bug in pfflt Reply to: RE>Bug in pfflt >From: watsen@netcom.com (Kent Watsen) >Message-Id: <199409200245.TAA17857@netcom.netcom.com> >Subject: Bug in pfflt >To: info-performer@sgi.com (performer) >Date: Mon, 19 Sep 1994 19:45:39 -0700 (PDT) > >I've discovered that the cleanTree routine employed >by LoadFlt does not retain NodeNames. Although one >may register a CB_CLEANNODE callback, there is no >way to set the new node's name without extensive >programming. The line of code in line 2196 of hier.c >fixes this error: pfNodeName (cnode, pfGetNodeName(child)); > >Kent Watsen >DCS Corporation >Simulation Branch >703.683.8430 x369 But Kent, cleanTree() does not create new nodes. It recursively: [1] removes groups that have no children and [2] collapses singleton group hierarchies (paths) from the bottom. Apparently you find it useful, in case [2], to transfer the name of the group being deleted into its (former and only) child. Hmm ... so you're trying to preserve some set path? What about the child's original name? It may have been important too? Renaming like this could occur repeatly during the process, leaving the ultimate child (say a pfDCS) with the name of the top most group that was removed. What if said pfDCS's name was important too? I understand the need to track the nodes that cleanTree() is removing from the hierarchy. My intention is to provide a better loader callback facility that gives the user various veto powers and node (subtree) substitution. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4118 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Fri Sep 23 13:23:45 1994 Date: Fri, 23 Sep 94 15:23:32 CDT From: bmc@autobahn.mayo.EDU (Bruce Cameron) To: info-performer@sgi.sgi.com Subject: Stereo Questions Part of my continuing quest to understand stereo as it relates to performer... I have an existing application that I'd like to add stereo on-the-fly to (i.e. press F2 to for stereo/mono). My first attempt to do this was to create an addition set of channels: for (i = 0; i < NumChans; i++) { left[i] = pfNewChan (pfGetPipe(0)); pfChanViewport (left[i], 0.0f, 1.0f, 0.0f, 0.5f); right[i] = pfNewChan (pfGetPipe(0)); pfChanViewport (right[i], 0.1f, 1.0f, 0.5f, 1.0f); pfAttachChan (left[i], right[i]); } oldMaster = left[ChanOrder[(NumChans -1 ) >> 1]]; for (i = 0; i < NumChans; i++) { pfSetVec3 (hpr, (((NumChans - 1)*0.5f) - i)*fov, 0.0f, 0.0f); pfSetVec3 (xyz, -ioc, 0.0f, 0.0f); pfChanViewOffsets(left[ChanOrder[i]], xyz, hpr); pfChanAutoAspect (left[ChanOrder[i]], PFFRUST_CALC_VERT); pfMakePerspFrust (left[ChanOrder[i]], -x+ioc, x+ioc, -x, -x); pfSetVec3 (xyz, -ioc, 0.0f, 0.0f); pfChanViewOffsets(right[ChanOrder[i]], xyz, hpr); pfChanAutoAspect (right[ChanOrder[i]], PFFRUST_CALC_VERT); pfMakePerspFrust (right[ChanOrder[i]], -x-ioc, x-ioc, -x, -x); } Then to swap the ViewState->masterChan at the keystroke to swap between stereo and mono while using setmonitor to change monitor modes. tmp = oldMaster; oldMaster = ViewState->masterChan; ViewState->masterChan = oldMaster; This fails to produce the desired results. Any clues as to how to get stereo from performer on the fly? I've looked at sfly, but it requires the graphics to be left in a "stereo" mode. Any hints as to how to modify this to be on-demand? From guest Fri Sep 23 13:27:32 1994 (5.65c/IDA-1.4.4 for ); Fri, 23 Sep 1994 16:27:18 -0400 Date: Fri, 23 Sep 1994 16:27:18 -0400 From: John C Vanderburgh To: info-performer@sgi.sgi.com Subject: C++ framework for Performer Cc: mstytz@afit.af.mil, ssheasby@afit.af.mil To all who have expressed interest in our C++ Object-Oriented framework for Performer apps (ObjectSim): Wow! Glad to see there's so much interest! We are gathering all the software and documentation and are in the process of placing it in our anonymous ftp archive. The software comprises one object library and we also have 5 or 6 small examples to get you started. Our current version is based on Performer 1.2 under IRIX 5.2. The actual thesis that was written will also be available in PostScript form. We should have everything available by the end of the month... (Some of us are trying to wrap up our own thesis work!) I'll keep all of you posted. If you won't be able to ftp the software, let me know and we can make other arrangements. Thanks again! John Vanderburgh AF Institute of Technology Wright-Patterson AFB, OH From aschaffe Fri Sep 23 14:11:59 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409231411.ZM14534@holodeck.asd.sgi.com> Resent-Date: Fri, 23 Sep 1994 14:11:59 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Tue, 20 Sep 1994 08:05:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: Culling on large terrain... I'm creating a large terrain database, about 400x400 points total. It is created like this intially: _______________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------- Then each of the four regions is subdivided recursively into smaller sections. This technique would assure that spatial division of the database would be efficient for culling. Here is the scene.out from perfly on the database: (Note: This example had *six* regions, 3 recursive subdivides, and 2 levels of detail) [0:0]pfScene pfId=1 0x736730 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(160455.437500, 104274.804688, -5057.523437) rad=391957.312500 Num Children: 2 [1:0]pfDCS pfId=2 0x7367b0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(160455.437500, 104274.804688, -5057.523437) rad=391957.312500 Max Scale: 1.000000 Num Children: 1 [2:0]pfGroup pfId=3 0x7368e0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(160455.437500, 104274.804688, -5057.523437) rad=391957.312500 Num Children: 1 [3:0]pfGroup pfId=4 0x767f00 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(160455.437500, 104274.804688, -5057.523437) rad=391957.312500 Num Children: 6 [4:0]pfGroup pfId=5 0xbdb8a0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(49087.117188, 47265.011719, 380.046875) rad=164186.468750 Num Children: 4 [5:0]pfGroup pfId=6 0xbdb960 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(26172.380859, 28422.234375, 380.046875) rad=80346.929688 Num Children: 4 [6:0]pfGroup pfId=7 0xbdb9c0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(12706.021484, 13289.599609, 199.027832) rad=24068.851563 Num Children: 4 [7:0]pfLOD pfId=8 0xbdba20 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(6354.295410, 6643.194336, 129.411011) rad=9194.072266 Num Children: 2 [8:0]pfGeode pfId=9 0xbddff0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(6354.295410, 6643.194336, 129.411011) rad=9194.072266 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbddf60 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=13, glPrims=72, verts=98 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbddf60 [9:0]} pfGeoSet [8:0]} pfGeode 9 0xbddff0 [8:1]pfGeode pfId=10 0xbdb900 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(6354.295410, 6643.194336, 129.411011) rad=9194.072266 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbdda10 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=9, glPrims=30, verts=48 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbdda10 [9:0]} pfGeoSet [8:1]} pfGeode 10 0xbdb900 [7:0]} pfLOD 8 0xbdba20 [7:1]pfLOD pfId=11 0xbdcde0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(6350.196289, 19924.792969, 305.026611) rad=9196.046875 Num Children: 2 [8:0]pfGeode pfId=12 0xbdd320 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(6350.196289, 19924.792969, 305.026611) rad=9196.046875 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbde0e0 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=13, glPrims=72, verts=98 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbde0e0 [9:0]} pfGeoSet [8:0]} pfGeode 12 0xbdd320 [8:1]pfGeode pfId=13 0xbdd8b0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(6350.196289, 19924.792969, 305.026611) rad=9196.046875 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbdd820 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=9, glPrims=30, verts=48 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbdd820 [9:0]} pfGeoSet [8:1]} pfGeode 13 0xbdd8b0 [7:1]} pfLOD 11 0xbdcde0 [7:2]pfLOD pfId=14 0xbde050 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(19045.185547, 19933.226563, 93.834595) rad=9196.852539 Num Children: 2 [8:0]pfGeode pfId=15 0xbdd970 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(19045.185547, 19933.226563, 93.834595) rad=9196.852539 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbdc900 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=13, glPrims=72, verts=98 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbdc900 [9:0]} pfGeoSet [8:0]} pfGeode 15 0xbdd970 [8:1]pfGeode pfId=16 0xbdd790 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(19045.185547, 19933.226563, 93.834595) rad=9196.852539 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbdd700 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=9, glPrims=30, verts=48 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbdd700 [9:0]} pfGeoSet [8:1]} pfGeode 16 0xbdd790 [7:2]} pfLOD 14 0xbde050 [7:3]pfLOD pfId=17 0xbdf070 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(19058.333984, 6651.091797, 104.956177) rad=9199.560547 Num Children: 2 [8:0]pfGeode pfId=18 0xbddea0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(19058.333984, 6651.091797, 104.956177) rad=9199.560547 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbe0a30 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=13, glPrims=72, verts=98 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbe0a30 [9:0]} pfGeoSet [8:0]} pfGeode 18 0xbddea0 [8:1]pfGeode pfId=19 0xbe36b0 { trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(19058.333984, 6651.091797, 104.956177) rad=9199.560547 Num Children: 1 [9:0] - pfGeoSet{ GeoSet: 0xbdf5c0 { Primitive: PFGS_TRISTRIPS, NON-INDEXED, pfPrims=9, glPrims=30, verts=48 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_VERTEX PFGS_TEXCOORD2=PFGS_PER_VERTEX } GeoSet: 0xbdf5c0 [9:0]} pfGeoSet [8:1]} pfGeode 19 0xbe36b0 [7:3]} pfLOD 17 0xbdf070 (and so on...) When "flying" over the terrain, I can keep 36fps while keeping only one of the four regions in my viewing frustrum. When I turn so that I see the edge of another region, the frame rate drops suddenly to 12 fps! _______________________________________________ | \ | / | | \| / | | | / | | |\ / | | | \ / | | | \ / | | | \ / | | | \ / | | | \ / | | | \ / | | | X | ------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------- I'm thinking that there may be a problem with the culling. While watching the Cull process thru the stats display in Perfly I don't see an increase in the culling activity when I view two regions, and switching thru the different cull options has no effect. And I think the Cull masks are set right. I believe the database is built correctly, using pfGroups for parents and pLODs for leaf nodes. Is there something I'm implementing wrong here, or is the additional polygon load of the tiny part of the second region really a good reason for slowing me down this much? Thanks! 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 Fri Sep 23 18:52:39 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9409231852.ZM19759@holodeck.asd.sgi.com> Resent-Date: Fri, 23 Sep 1994 18:52:39 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Wed, 21 Sep 1994 21:14:06 -0400 From: girish prabhu To: info-performer@sgi.sgi.com Cc: prabhu@eng.buffalo.edu Hello: I recently bought a copy of performer software.. and will be using it to develop a driving simulator. I am planning to use the sample perfly code itself, along with the town and village databases (Software systems' .flt files provided with the performer). However, I have certain other requirements too... for example.. I want things like speedometer, temperature guage etc. (the usual car cockpit display stuff) and track-up or north-up maps of the town/village displayed as shown below... ********************************************************* ** ** ** ** ** ** ** 3D Visual Scene ** ** ** ** ** ** ** ** ** ********************************************************* ** ** ** ** ** Speedo ** Temp ** North Up ** ** meter ** Guage ** or ** ** ** ** Track Up ** ** ** ** maps ** ** ** ** ** ********************************************************* The navigation maps (track-up/north-up) and speedometer has to be hooked up with the 3D visual simulation, so that the data presented in all the windows is in sync. I am new to performer.. so any pointers/help will be greatly appreciated.. Thanks Girish From guest Sat Sep 24 17:42:12 1994 To: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Cc: info-performer Subject: Re: Culling on large terrain... In-Reply-To: Your message of "Tue, 20 Sep 94 08:05:35 PDT." <199409201505.IAA17694@archimedes.chinalake.navy.mil> Date: Sat, 24 Sep 94 17:42:08 -0700 From: Jim Helman > and switching thru the different cull options has no effect. GeoSet bounding box culling is turned off under DCSes, so toggling that should have no effect. This also means that it's very important for the pfGeodes to have tight bounding spheres, e.g. square rather than oblong terrain pfGeodes. (Note that because of the way that 1.2 computes some bounding spheres, those of pfGroups can become somewhat bloated. However, pfGeode bspheres are not affected, so this has no impact on the amount of stuff sent to the gfx pipe.) It would be useful to compare the gfx stats of geodes/geosets and triangles drawn before and after your view frustum steps over the tile edge. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Sep 24 17:51:23 1994 To: bill@rap.ucar.edu (Bill Myers) Cc: info-performer@sgi.sgi.com Subject: Re: Picking Example Code Request In-Reply-To: Your message of "Mon, 19 Sep 94 09:56:19 MDT." <199409191556.JAA08512@rap.rap.ucar.EDU> Date: Sat, 24 Sep 94 17:51:14 -0700 From: Jim Helman There is a picking example in /usr/src/Performer/src/sample/pickfly. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Sep 24 17:54:27 1994 To: bill@rap.ucar.edu (Bill Myers) Cc: info-performer@sgi.sgi.com Subject: Re: Ortho Projection Question In-Reply-To: Your message of "Tue, 13 Sep 94 21:26:09 MDT." <199409140326.VAA03525@rap.rap.ucar.EDU> Date: Sat, 24 Sep 94 17:54:19 -0700 From: Jim Helman Under 1.2, calling pfMakeOrthoFrust on the pfChannel (which is subclassed from pfFrustum) should suffice. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Hello all, Can someone send me an example of how to render a scene with an ortho projection matrix? I assume one uses a pfFrustrum, but I don't understand where it would get attached in the hierarchy? The code I am working with was written under Performer Rev 1.0, and I don't see anything having to do with perspective projections in there either (other than near/far clip planes). So I'm really sure where to start. From guest Sat Sep 24 18:02:20 1994 To: askins@hrlban1.aircrew.asu.edu Cc: info-performer Subject: Re: 2D distortions of resulting imagery In-Reply-To: Your message of "Wed, 14 Sep 94 16:23:42 MST." Date: Sat, 24 Sep 94 18:02:17 -0700 From: Jim Helman Using two-pipes with a Sirius on each would give higher performance than fbsubtexload from the backbuffer of a single pipe machine, since you have one pipe for rendering and one for distorting. But texture loading is still a limiting factor. The Sirius guys indicate that 720x243_60 or 720x486_30 would be possible. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Also, I've thought about the possibility of a hardware solution. I know that the Sirius video option allows video to be loaded directly into texture memory, and as I have a 2-pipe system, I was wondering if there is something similar to the Sirius that would allow me to load the screen buffer of one graphics pipe into the texture memory of the other pipe. {I think that 2 Sirius boards (one on each pipe, with the output of one hooked to the input of the other) would do this From guest Sat Sep 24 18:52:35 1994 To: blubaron@mit.edu Cc: info-performer Subject: Re: Waves In-Reply-To: Your message of "Thu, 15 Sep 94 20:33:47 EDT." <9409160033.AA04511@milanese.MIT.EDU> Date: Sat, 24 Sep 94 18:52:33 -0700 From: Jim Helman Waves are a special case of dynamic geometry, usually combining: 1) Texture animation, i.e. changing the texture coordinates to "move" the texture across the surface. 2) dynamic goemetry, i.e. moving the vertex positions. Both of these require changing the contents of attribute arrays in pfGeoSets. In a single processor environment, just change them whenever you want. In an MP environment, you could do the same in the DRAW process, but this takes time away from rendering, so it's best to modify the data in the APP (in the non-latency critical section after pfFrame, but before pfSync). But since libpr objects are not automatically multibuffered, this means you must be careful to avoid changing the vertex arrays while the DRAW is drawing from them, or you may see the geometry tear. The easiest way to avoid MP data collisions is with multiple copies so you can update one copy in the APP while the DRAW is working on another. Just create a pfSwitch node with three copies underneath it (three copies is usually enough for a three stage APP+CULL+DRAW software pipeline). In the APP, set the switch node to the "next" child and update the geometry for that child. The only trick is deciding who's next. Using child = (child+1)%4 in the APP each frame works well in the absence of frame extensions. You can protect against DRAW extensions by incrementing the child count one more if the DRAW happens to be working on the chosen child. In general, covering all the bases to guarantee no collisions in any phase with multipipe operation and frame extensions can get nasty. So, we'll be making MP-safe dynamic geometry easier in 2.0. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Sep 24 19:07:49 1994 To: Simon Gibbs Cc: info-performer@sgi.sgi.com Subject: Re: video textures In-Reply-To: Your message of "Tue, 23 Aug 94 17:08:03 MDT." <9408231308.AA01575@viswiz.gmd.de> Date: Sat, 24 Sep 94 19:07:40 -0700 From: Jim Helman pfGetGLHandle gives you the GL texture ID of a pfTexture, so you can make your own GL calls in a draw callback. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From: Simon Gibbs Subject: video textures To: info-performer@sgi.sgi.com Date: Tue, 23 Aug 94 17:08:03 MDT We are interested in using Performer and a Sirius board to create video textures. The video input is a CCIR 601 4:4:4:4 signal. We want to create a 4 component texture and then use subtexload to dynamically modify the texture. The problem: subtexload needs a texture id and these are not visible when using Performer. Is there a Performer equivalent of subtexload or a way of getting hold of texture ids for textures created with pfNewTex? ---------------------------------------------------------------------------- Simon Gibbs GMD Schloss Birlinghoven 53574 Sankt Augustin GERMANY ---------------------------------------------------------------------------- Email: Simon.Gibbs@gmd.de WWW: http://cui_www.unige.ch/OSG/Simon Tel: +49 (2241) 14.2697 (direct) +49 (2241) 14.2366 (department office) +49 (2241) 14.2040 (fax) ---------------------------------------------------------------------------- From guest Sat Sep 24 19:34:49 1994 To: m218822@fltsim.mdc.com (Bill Balloni) Reply-To: performer-feedback@surreal Cc: info-performer@sgi.sgi.com Subject: Re: C++ class library In-Reply-To: Your message of "Fri, 23 Sep 94 08:52:55 MDT." <9409231352.AA02255@fltsim.MDC.COM> Date: Sat, 24 Sep 94 19:34:39 -0700 From: Jim Helman At the Friends of Performer gathering at SIGGRAPH, quite a few people requested a native C++ Performer API, so we're thinking about doing one for 2.0. If a C++ API is high on your list of desired features, please drop me an email saying why (e.g. elegance, extensibility, etc.). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun Sep 25 00:58:32 1994 (5.65c/IDA-1.4.4 for <@datasrv.co.il:info-performer@sgi.com>); Sun, 25 Sep 1994 09:59:27 +0200 From: "Ran Yakir" Date: Sun, 25 Sep 1994 09:51:05 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: C++ class library Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 > At the Friends of Performer gathering at SIGGRAPH, quite a > few people requested a native C++ Performer API, so we're > thinking about doing one for 2.0. If a C++ API is high on > your list of desired features, please drop me an email saying > why (e.g. elegance, extensibility, etc.). > rgds, > -jim helman Before its too late, let me ask (or better, beg) that the good old (understandable) C API for Performer will still be supplied. C++ philosophy has a tendency to make hostile takeovers and throw other languages out, and I sure hope this won't happen here. Tanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Sun Sep 25 01:21:33 1994 ; Sun, 25 Sep 1994 04:21:46 -0400 From: giraffe.asd.sgi.com!sgi.sgi.com!uunet.uu.net!uunet!robcad!hindin Date: Sun, 25 Sep 94 10:19:44 +0200 To: uunet.uu.net!uunet!sgi.com!info-performer Subject: unsubscribe unsubscribe From guest Mon Sep 26 06:00:51 1994 Date: Mon, 26 Sep 94 07:57:13 CDT From: lac@gothamcity.jsc.nasa.gov (Lac Nguyen) Apparently-To: On Sun, 25 Sep 1994 jim helman says > At the Friends of Performer gathering at SIGGRAPH, quite a > few people requested a native C++ Performer API, so we're > thinking about doing one for 2.0. If a C++ API is high on > your list of desired features, please drop me an email saying > why (e.g. elegance, extensibility, etc.). > rgds, > -jim helman I think Performer should have two versions one C and one C++ like the Open Inventor. Because in the future more and more people using C++. Since C++ is such an elegance, extensibility language. I also think Open Performer and Open Inventor is a perfect product for Graphic World. Lac From guest Mon Sep 26 09:20:06 1994 From: "Eugenio Castillo Hidalgo" Date: Mon, 26 Sep 1994 18:20:16 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Please un-subscribe me From guest Mon Sep 26 10:15:27 1994 From: hodeckes@VNET.IBM.COM Mon, 26 Sep 94 10:50:23 EDT Date: Mon, 26 Sep 94 10:49:18 EDT To: INFO-PERFORMER@sgi.sgi.com Subject: Peformer rendering Hi all, I am having problems with Performer rendering my scene incorrectly. Geometry which is behind other geometry is being drawn on top of the closer objects. In other words, a box positioned 2 km away from the viewpoint is being drawn on top of a box only 1km away. I create the geometry by adding a node containing geometry as a child to a pfSCS. I create this SCS with a matrix that I have scaled, rotated and translated. A section of the code follows. By the way, I have Performer 1.2, IRIX 5.2 and an Onyx with RE. geomNode = (pfNode *)LoadFile("file.dwb", NULL); for (i=0; i X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: hodeckes@VNET.IBM.COM, INFO-PERFORMER@sgi.sgi.com Subject: Re: Peformer rendering Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Sep 26, 10:49am, hodeckes@VNET.IBM.COM wrote: > > I am having problems with Performer rendering my scene incorrectly. > Geometry which is behind other geometry is being drawn on top of the > closer objects. In other words, a box positioned 2 km away from the > viewpoint is being drawn on top of a box only 1km away. > > I create the geometry by adding a node containing geometry as a child > to a pfSCS. I create this SCS with a matrix that I have scaled, > rotated and translated. A section of the code follows. By the > way, I have Performer 1.2, IRIX 5.2 and an Onyx with RE. This problem may not be related to Performer, but rather an issue of how much framebuffer space is available for Performer to allocate. Check the output of 'perfly' to see if you are getting the mssize() configuration you expect. You might also run 'gldebug' on your program. On the same theme -- In IRIX 5.2 some of the System Administration tools (ie 'chost' and 'clogin') make use of the ImageVision library to scale & display bitmaps of users faces & other pictures -- on RealityEngine this eats up a lot of the frame buffer because it uses hardware acceleration. So, if you run those tools and a Performer program at the same time, you won't get any Z buffer. Once you kill them off and re-start the Performer application it will be able to allocate the multisampling & zbuffer memory it needs. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Mon Sep 26 12:26:18 1994 Date: Mon, 26 Sep 94 12:25:48 -0700 From: spelk@bert.arc.nasa.gov (Steve Elkins) To: info-performer@sgi.sgi.com Subject: Using paths? Performer Folks, We are using Performer 1.2 perfly for the basis of an airport simulation and we need to add traffic to the scene. In the friends/town/orig/pfpath directory there are several path files. At the top of these files is a comment on how to use them with perfly ie.: # This file is a path for use in perfly. For example: # perfly -A esprit.flt,city.path,Lotus 002_002.flt However if I try to run perfly with this command line I get the following message: Illegal option -- A. It appears that the version of perfly included with Performer 1.2 does not support paths. I wanted to see if the path processing supplied in /usr/src/Performer/src/lib/libpfutil/path.c would be sufficent for our needs. Is there a seperate version of perfly which uses the path code from /usr/src/Performer/src/lib/libpfutil/path.c? If there is a version of perfly which uses paths where is it located? Thanks for your help. Steve Elkins Sterling Software Nasa Ames Division From guest Mon Sep 26 13:35:10 1994 X-Sender: ovebj@stein1.u.washington.edu Date: Mon, 26 Sep 1994 13:35:06 -0700 (PDT) From: Ove Bjorneseth Subject: unsubscribe To: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII please unsubscribe me from the list -ove From guest Mon Sep 26 18:18:14 1994 (5.67b8/IDA-1.5 for info-performer@sgi.com); Tue, 27 Sep 1994 11:17:38 +1000 (5.65c/IDA-1.5 for ); Tue, 27 Sep 1994 10:53:15 +1000 (5.65c/IDA-1.4.4 for ); Tue, 27 Sep 1994 10:52:31 +1000 Date: Tue, 27 Sep 1994 10:52:25 +1000 (EST) From: Kathryn Loynes Sender: Kathryn Loynes Reply-To: Kathryn Loynes Subject: PFTRAV_IS_PATH problem with pfSegsIsectNode (again) To: Performer Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, I have been trying to obtain the traversal path to an intersected node by setting PFTRAV_IS_PATH in the segSet mode passed to pfSegsIsectNode. I have no problem obtaining correct intersections with geometry when the mode is set to other combinations (PFTRAV_IS_PRIM|PFTRAV_IS_NORM). However, when PFTRAV_IS_PATH is ORed in (and absolutely no other change made) not only is the path not returned but the entire intersection request fails. If it makes a difference, the geometry with which the segment should be intersecting is under a pfDCS which is under a pfSwitch which is attached directly to the pfScene. Does anyone have any ideas ? I know that exactly the same question was asked a few months ago by someone else but there did not seem to be any (public) response. ---------------------------------------------------------------------- Kathy Loynes | Wormald Technology kathyl@wormald.com.au | Advanced Systems Engineering Ph: +61 2 981 0611 | Sydney, Australia From guest Mon Sep 26 18:51:50 1994 To: "Ran Yakir" Cc: info-performer@sgi.sgi.com Subject: Re: C++ class library In-Reply-To: Your message of "Sun, 25 Sep 94 09:51:05 -0000." <9409250951.ZM9158@amcor.bvr.co.il> Date: Mon, 26 Sep 94 11:12:34 -0700 From: Jim Helman > Before its too late, let me ask (or better, beg) that the good old > (understandable) C API for Performer will still be supplied. C++ > philosophy has a tendency to make hostile takeovers and throw other > languages out, and I sure hope this won't happen here. A native C++ API would be in addition. We would *never* abandon Performer's C API nor its relatively short and understandable names (we hate typing long names, too). One can write a C++ program using Performer's current C API, which is already OO in it's argment and naming structure, i.e. pf(pfobject, attribute, ...) Some of the replies I've gotten have indicated a general desire for OO-style programming. Please be specific about what you want, i.e. just object->method calling notation or do you expect to do a lot of subclassing and extending of our node types, e.g. do you want to do your own LOD. Some types of featural extension require more than just a C++ API. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Sep 26 20:28:55 1994 To: Kathryn Loynes Cc: Performer Subject: Re: PFTRAV_IS_PATH problem with pfSegsIsectNode (again) In-Reply-To: Your message of "Tue, 27 Sep 94 10:52:25 +1000." Date: Mon, 26 Sep 94 20:28:42 -0700 From: Jim Helman Performer 1.2 has a bug which causes PFTRAV_IS_PATH to prune intersection traversals at pfSwitch nodes. A workaround is to use a pfGroup instead of a pfSwitch and select the desired child by setting draw and isect traversal masks on all the children. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Sep 27 01:05:00 1994 From: "Angus Henderson" Date: Tue, 27 Sep 1994 08:00:59 +0000 In-Reply-To: spelk@bert.arc.nasa.gov (Steve Elkins) "Using paths?" (Sep 26, 12:25pm) References: <9409261925.AA16813@bert.arc.nasa.gov> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: spelk@bert.arc.nasa.gov (Steve Elkins) Subject: Re: Using paths? Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I have a version of perfly that supports paths and the "tether" option too I promised it to other people too but I wanted to distibute it via the Performer public ftp system. I dont know where that is yet but ALLAN SCHAFFER could tell me so I will cc this to he ANgus ( Henderson The Reality Centre ) From guest Tue Sep 27 02:07:04 1994 From: jeando@rnd.thomson-di.fr (Jean-Dominique Lauwereins) Subject: unsubscribe To: info-performer@sgi.sgi.com Date: Tue, 27 Sep 1994 09:08:05 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 51 Please unsubscribe me. Thanks. JD Lauwereins. From guest Tue Sep 27 07:24:21 1994 Date: Tue, 27 Sep 1994 15:16:12 -0100 (GMT-1:00) From: E Hendon To: info-performer@sgi.sgi.com Subject: Node Traversal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Performer, I wish to change the viewing matrix for a particular node so that the object remains "apparently" always in front of my viewpoint. Of course one could solve this by making this object a DCS. However, I wanted to try pfPushIdentMatrix in a Traversal callback (is this ok?). I does not seem to work, for the ovject is transformed as normal according to the view matrix for the channel (pfChanView). Here is sample code. Where have I gone wrong? //During APP, before simloop: setup() { pfNodeTravMask(node, PFTRAV_CULL,0L,PFTRAV_SELF|PFTRAV_DESCEND,PF_SET); pfNodeTravMask(node,PFTRAV_DRAW,0xffffffff,PFTRAV_SELF|PFTRAV_DESCEND,PF_SET); pfNodeTravFuncs(node,PFTRAV_CULL,x_precull,x_postcull); pfNodeTravFuncs(node, PFTRAV_DRAW, x_predraw, x_postdraw); } static long x_precull(pfTraverser *trav, void *data) { return(PFTRAV_CONT); } static long x_postcull(pfTraverser *trav, void *data) { return(0); } static long x_predraw(pfTraverser *trav, void *data) { pfPushIdentMatrix(); return(PFTRAV_CONT); } static long x_postdraw(pfTraverser *trav, void *data) { pfPopMatrix(); return(PFTRAV_CONT); } will subordinate nodes of "node" likewise obey this traversal rule? Thanks for hints and help!! --------------------------------------------------------------------------- E. Hendon Atlas Elektronik GmbH, D-28305 Bremen, Sebaldsbruecker Heerstr. 235, Simulation Division elke@tyrann.atlas.de --------------------------------------------------------------------------- From guest Tue Sep 27 10:47:01 1994 id AA13698; Tue, 27 Sep 94 13:46:30 -0400 From: "lee robie" Date: Tue, 27 Sep 1994 13:46:30 -0400 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 When using a pfuXformer, why does Perfly sometimes update the channel view, and sometimes update a DCS? from perfly.c: void updateView(pfChannel *chan) { pfMatrix mat; pfuUpdateXformer(ViewState->xformer); switch (pfuGetXformerMode(ViewState->xformer)) { case PFUXF_FLY: case PFUXF_DRIVE: pfuGetXformerCoord(ViewState->xformer, &ViewState->viewCoord); pfuGetXformerMat(ViewState->xformer, mat); pfChanViewMat(chan, mat); <============= break; case PFUXF_TRACKBALL: pfuGetXformerMat(ViewState->xformer, mat); pfDCSMat(ViewState->sceneDCS, mat); <============= break; } } if these are really just different viewing models, why are different update mechanisms used? could you use pfChanViewMat for the 2nd case? thanks, -lee r. Lee Robie Internet: lee.robie@sdrc.com SDRC 2000 Eastman Drive Voice: 513-576-2576 Milford, Ohio 45150 Fax: 513-576-5919 From guest Tue Sep 27 17:46:41 1994 From: aschaffe (Allan Schaffer) Date: Tue, 27 Sep 1994 17:46:35 -0700 In-Reply-To: "lee robie" "" (Sep 27, 1:46pm) References: <9409271346.ZM13696@sgini1> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "lee robie" , info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Sep 27, 1:46pm, lee robie wrote: > When using a pfuXformer, why does Perfly sometimes update the channel > view, and sometimes update a DCS? from perfly.c: > > case PFUXF_DRIVE: > pfChanViewMat(chan, mat); <============= > > case PFUXF_TRACKBALL: > pfDCSMat(ViewState->sceneDCS, mat); <============= > > if these are really just different viewing models, why are different > update mechanisms used? could you use pfChanViewMat for the 2nd case? The conceptual purpose is (I believe) an easy way of implementing pre- vs post-multiplication of eyepoint transformations. With DRIVE and FLY modes, this is the typical out-the-window post-mult style where transformations are relative to the axis defined by the current eyepoint xyz and hpr. That means, for example, if I am looking at the esprit model and change the pitch by +90 degrees, the esprit will slide off the bottom of the screen and I'll be looking straight up into the sky. TRACKBALL mode is one where transformations are pre-multiplied, meaning they are relative to the axis' defined by the scene itself. So if I (again) gaze at the esprit and change the pitch by +90 degrees, the esprit itself will rotate 90 degrees on its axis and will now be standing on its side. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Sep 28 07:38:51 1994 Date: Wed, 28 Sep 94 09:40:29 CDT From: tpravata@rts.dseg.ti.com (Todd R Pravata) To: info-performer@sgi.sgi.com Subject: Multiple sensor views - single scene graph Reply-To: I am working on a DIS project for reconfigurable simulators. We need to be able to provide two different sensor views of the same scene graph (eg. OTW and FLIR). Does anyone know of any way to do this without flushing the entire scene graph and rebuilding it each time the view is changed? We need to leave the geometry alone but be able to change the texture mapping. It seems that the problem is that geostates (texture references) are tightly bound to geosets, otherwise we could use a pfswitch at the geodes or geosets. Any suggestions? Thanks From guest Wed Sep 28 09:21:20 1994 (5.65c/IDA-1.4.4 for ); Wed, 28 Sep 1994 12:21:16 -0400 Date: Wed, 28 Sep 1994 12:21:16 -0400 From: Jimmie J Rohrer To: info-performer@sgi.sgi.com Subject: Billboards using LoadFlt Cc: jrohrer@afit.af.mil Hi, Does anyone happen to have any sample code using flight format files as a source for a billboard? We have been unsuccessful in our attempts. We are using LoadFlt and we have tried typecasting that to a pfBillboard - that didn't work. We also tried typecasting LoadFlt to a pfGeode and then extracting its pfGeoSet and inserting it into a pfBillboard, but we couldn't get the pfGeoSet. Any suggestions or examples would be appreciated. JJ Rohrer and Jim Kestermann (Hoping to graduate in December - M.S.) e-mail jrohrer@afit.af.mil - or - jkesterm@afit.af.mil From guest Wed Sep 28 11:17:38 1994 Date: Wed, 28 Sep 94 13:19:03 CDT From: tpravata@rts.dseg.ti.com (Todd R Pravata) To: jrohrer@afit.af.mil Cc: info-performer@sgi.sgi.com In-Reply-To: <199409281621.AA14867@stealth.afit.af.mil> (jrohrer@afit.af.mil) Subject: Billboards using LoadFlt Reply-To: > We are using LoadFlt and we have tried typecasting that to a > pfBillboard - that didn't work. We also tried typecasting LoadFlt to > a pfGeode and then extracting its pfGeoSet and inserting it into a > pfBillboard, but we couldn't get the pfGeoSet. > > Any suggestions or examples would be appreciated. Here's the code I am using to do the same thing (pretty straightforward). I have not tried it with FLT format files. /* FUNCTION * * find_geode * * DESCRIPTION * * Finds the first geode in the input DAG by recursively decending * to "leaf" nodes. Assumes that the DAG is built for a single * stamped model. * * RETURNS * * pointer to a Geode * * NOTES * * AUTHOR * * Todd Pravata, Texas Instruments, 6/94 */ static pfGeode *find_geode(pfNode *node) { long type; long num_children; pfGeode *geode; int i; type = pfGetType(node); if (type & PFCLASS_GROUP) { num_children = pfGetNumChildren(node); for (i = 0; i < num_children; ++i) { geode = find_geode(pfGetChild((pfGroup *)node, i)); if (geode != NULL) return(geode); } } else if (type == PFTYPE_GEODE) return((pfGeode *)node); return(NULL); } /* FUNCTION * * add_stamp_geoset * * DESCRIPTION * * Add the geometry from the stamp (built from S1000 data) to the * input billboard. The billboard contains multiple Geosets each * with their own stamp geometry. * * RETURNS * * void * * NOTES * * AUTHOR * * Todd Pravata, Texas Instruments, 6/94 */ static void add_stamp_geoset(pfBillboard *bboard, pfNode *stamp) { pfGeode *geode; geode = find_geode(stamp); if (geode != NULL) { if (pfGetNumGSets(geode) != 1) fprintf(stderr, "pfS1K: Warning - geode has wrong number of geosets %d\n", pfGetNumGSets(geode)); pfAddGSet((pfGeode *)bboard, pfGetGSet(geode, 0)); } else fprintf(stderr, "pfS1K: cannot find geode for stamp\n"); } From guest Wed Sep 28 12:47:54 1994 To: todd.pravata@dseg.ti.com Cc: info-performer@sgi.sgi.com Subject: Re: Multiple sensor views - single scene graph In-Reply-To: Your message of "Wed, 28 Sep 94 09:40:29 CDT." <9409281440.AA23056@rts.dseg.ti.com> Date: Wed, 28 Sep 94 11:11:08 -0700 From: Jim Helman The real solution is coming in 2.0: indexable geostates. All you'd need to do then is to change the geostate table when switching between FLIR and OTW. You can even use the same scene graph in different channels with different geostate tables. If you don't need *simultaneous* FLIR and OTW views, you can do OK in 1.2. Just traverse the scene graph and build up a list of all pfGeoStates with both OTW and FLIR pfTextures. When you want to switch, just blast through the list setting the pfTexture for each pfGeoState with pfGStateAttr. Caveats: Switching will cause a large pause for texture download unless both sets of textures are resident in the pipe. When MPed, unless you hold off the CULL and DRAW (e.g. don't call pfFrame for a couple frame times), you may end up drawing the scene with a mixed set of textures for a frame since pfGeoStates are not multibuffered. Or you could do the switch at the beginning of the CULL or CULLDRAW. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Sep 28 12:46:44 1994 To: E Hendon Cc: info-performer@sgi.sgi.com Subject: Re: Node Traversal In-Reply-To: Your message of "Tue, 27 Sep 94 15:16:12 -0100." Date: Wed, 28 Sep 94 11:31:23 -0700 From: Jim Helman The DCS approach sounds a bit safer. Monkeying with the matrix stack to this extent is a bit tricky, since it includes the transformation from GL (Zin) to Performer (Zup) coordinates. If you take this into account though, what you describe should work. The cull callbacks in your code aren't required since setting the cull mask to zero will guarantee that the object is drawn if traversal reaches that point. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Sep 28 12:45:26 1994 To: Jimmie J Rohrer Cc: info-performer@sgi.sgi.com Subject: Re: Billboards using LoadFlt In-Reply-To: Your message of "Wed, 28 Sep 94 12:21:16 EDT." <199409281621.AA14867@stealth.afit.af.mil> Date: Wed, 28 Sep 94 11:21:11 -0700 From: Jim Helman The easiest thing to do is to model the geometry as billboards in MultiGen. If yous really need to convert non-billboard geometry, first make sure that it meets the orientation and planarity requirements for billboardable geometry (see the man pfBillboard page). If so, you should be able to call LoadFlt on the file and then extract the appropriate pfGeoSets and parent them under pfBillboards. If you know the name of the pfGeode, you could use pfFindGeode and then use pfGetGSet on the returned pfGeode. If names are not available, you can traverse the scene graph using pfuTraverse (see trav.c in /usr/src/Performer/src/lib/libpfutil) and extract the pfGeoSets that way. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Sep 28 12:47:37 1994 ; Wed, 28 Sep 1994 15:47:20 -0400 id AA02065; Wed, 28 Sep 1994 12:52:00 PST Organization: MultiGen Inc X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 28 Sep 1994 11:45:47 PST Subject: Re: Billboards using LoadFlt Reply to: RE>Billboards using LoadFlt >Date: Wed, 28 Sep 1994 12:21:16 -0400 >From: Jimmie J Rohrer >Message-Id: <199409281621.AA14867@stealth.afit.af.mil> >To: info-performer@sgi.com >Subject: Billboards using LoadFlt >Cc: jrohrer@afit.af.mil > > Does anyone happen to have any sample code using flight format >files as a source for a billboard? We have been unsuccessful in our >attempts. > > We are using LoadFlt and we have tried typecasting that to a >pfBillboard - that didn't work. We also tried typecasting LoadFlt to >a pfGeode and then extracting its pfGeoSet and inserting it into a >pfBillboard, but we couldn't get the pfGeoSet. Typecasting the return from LoadFlt() like this isn't recommended. > Any suggestions or examples would be appreciated. > > JJ Rohrer and Jim Kestermann Axial billboards are specified in Flight at the face level. In MultiGen: model a face about the origin (seen from -Y) , select modify attributes, check "Template Axis" (same as axial billboard). To place the billboard off the origin, insert a [T] matrix in the object or group above the face and translate from the origin to the desired location. You don't want to translate the vertices directly. For more information, please contact MultiGen Product Support at (408) 261 4110 or multigen!techsupport@uunet.UU.NET. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4110 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Wed Sep 28 16:05:46 1994 ; Wed, 28 Sep 1994 19:04:28 -0400 id AA02066; Wed, 28 Sep 1994 16:09:15 PST Organization: MultiGen Inc X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 28 Sep 1994 15:57:57 PST Subject: Re: Axial billboards, but po Reply to: RE>Axial billboards, but point billb Hi Mr. Rohrer, Yes, I'm aware the point billboards hadn't been implemented in the Flight loader(s). It is on my todo list. I hope to get it done sometime in Oct '94. As a workaround, you might try modelling your point billboards as axial, with special names. It may be easy to traverse the scene graph and find the resulting pfBillBoard nodes and change them to point. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4118 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET -------------------------------------- Date: 9/28/94 2:38 PM To: Marcus From: Jimmie J Rohrer From jrohrer@afit.af.mil Wed Sep 28 17:05:31 1994 AA23052 (5.65c/IDA-1.4.4 for ); Wed, 28 Sep 1994 17:05:27 -0400 Date: Wed, 28 Sep 1994 17:05:27 -0400 From: Jimmie J Rohrer To: multigen!marcus@uunet.uu.net Subject: Axial billboards, but point billboards? Cc: jrohrer@afit.af.mil Mr. Barnes, Thanks for your response. As suggested, the Multigen axial billboard works just fine. Unfortunately, our application requires a point billboard. According to a member of your technical staff, this option described in the current Multigen manual is not yet available (a bit frustrating). Again, thanks for your help. JJ Rohrer and Jim Kestermann From guest Thu Sep 29 12:08:57 1994 (5.65c/IDA-1.4.4 for ); Thu, 29 Sep 1994 15:08:51 -0400 Date: Thu, 29 Sep 1994 15:08:51 -0400 From: John C Vanderburgh To: info-performer@sgi.sgi.com Hey all, In my Performer application, I'm rendering some stars in a space environment as point light sources. I use actual celestial coordinates converted to Earth-centered rectangular coordinates, so my stars end up as a "celestial sphere" surrounding the Earth. This was working well until I discovered that if I move far enough in my world, objects that aren't within my "celestial sphere" (such as the Sun or a distant planet, etc) will appear "behind" the stars. For various reasons, I don't want to increase the radius of my "celestial sphere" (in order to physically enclose all my objects). If I could somehow "clamp" the depth of the star pixels (in screen space) to the largest z-buffer value, it would seem that the stars would always appear "farther" than any other objects in my world. I read the man pages on "zbuffer", "zfunction", "zdraw", etc., but didn't find exactly what I was looking for. So, is there a way to alter the values used for z-buffer calculations for my stars? (or, for that matter, any other suggestions on how to solve this dilemma?) Thanks, John Vanderburgh AF Institute of Technology Wright-Patterson AFB, OH (jvanderb@afit.af.mil) From guest Thu Sep 29 13:10:02 1994 From: "Mark Johnson" Date: Thu, 29 Sep 1994 17:10:00 -0300 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfDeleteFunc Cc: johnson@vrlab.uccb.ns.ca Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 1381 Hello all, We are using user data attached to nodes in our scene. To prevent memory leaks, a UserDataDelete function is registered using pfDeleteFunc(). This Delete function counts the number of times it is called. The number of times that user data are assigned is also counted. When pfDelete is used to clear all the children of a scene, the registered user data delete function is called only once for each child of the pfScene, and not for any of their children. There is a large discrepancy between the number of allocations of the user data, and the number of times the delete function is called. According to the man page on pfDelete, it decrements the reference count of all pfObjects referenced by its argument, and deletes those that have counts <= 0. However, this does not appear to include their user defined data pointers! We had to write code that would traverse the entire scene graph, and delete the user data. Why should this be so? The man pages do say that user data cannot be reference counted, but I can handle this myself since it calls my function to delete it! Is this problem a problem with Performer? Or my code? A second problem is that the delete function is often called with a NULL object pointer forcing the function to check the validity of its argument since pfGetUserData(NULL) crashes. Mark Johnson johnson@vrlab.uccb.ns.ca From guest Thu Sep 29 15:11:32 1994 From: jrohlf@tubes (John Rohlf) Subject: Re: your mail To: guest (John C Vanderburgh) Date: Thu, 29 Sep 94 13:26:25 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199409291908.AA09358@stealth.afit.af.mil>; from "John C Vanderburgh" at Sep 29, 94 3:08 pm X-Mailer: ELM [version 2.3 PL8] > > Hey all, > In my Performer application, I'm rendering some stars in a space environment as point light sources. > I use actual celestial coordinates converted to Earth-centered rectangular > coordinates, so my stars end up as a "celestial sphere" surrounding the > Earth. This was working well until I discovered that if I move far > enough in my world, objects that aren't within my "celestial sphere" (such > as the Sun or a distant planet, etc) will appear "behind" the stars. For > various reasons, I don't want to increase the radius of my > "celestial sphere" (in order to physically enclose all my objects). > If I could somehow "clamp" the depth of the star pixels (in screen > space) to the largest z-buffer value, it would > seem that the stars would always appear "farther" > than any other objects in my world. I read the man pages on > "zbuffer", "zfunction", "zdraw", etc., but didn't find exactly what > I was looking for. So, is there a way to alter the > values used for z-buffer calculations for my stars? (or, for that matter, > any other suggestions on how to solve this dilemma?) Try: lsetdepth(getgdesc(GD_ZMAX), getgdesc(GD_ZMAX)) when drawing your stars. From guest Thu Sep 29 16:21:53 1994 Date: Thu, 29 Sep 94 19:22:30 EDT From: panisset@cae.ca (Jean-Francois Panisset) To: info-performer@sgi.sgi.com Subject: Questions on MCO configurations This is not a Performer question per se, but I think it is close enough to justify its presence here, where multi-channel gurus are likely to hang around... I have a few questions about the Multi Channel Option board for RealityEngine. 1) Can a single MCO board read from multiple RE (hardware) pipes, or does it have to be 1 RE pipe - 1 MCO board? 2) I understand that an MCO can drive 6 displays at two different timings, 4 displays on one timing and 2 on the other. Are there any other restrictions? In particular, given a mix of 1280x1024 and 640x480 channels and a 4 RM RE pipe, are the following combinations legal? - 1 x 1280*1024 (obvious) - 2 x 1280*1024 (I think so) - 2 x 1280*1024 + n x 640*480 (I don't think so) - 1 x 1280*1024 + 1 x 640*480 - 1 x 1280*1024 + 2 x 640*480 - 1 x 1280*1024 + 3 x 640*480 - 1 x 1280*1024 + 4 x 640*480 - 1 x 1280*1024 + 5 x 640*480 (I don't think so) - 6 x 640*480 - 5 x 640*480 - 4 x 640*480 (I think so) - 3 x 640*480 (I think so) - 2 x 640*480 (I think so) - 1 x 640*480 (obvious) Are there any other possible combinations? Are there any restrictions I should be aware of? Thanks in advance, JF From guest Thu Sep 29 17:50:40 1994 To: panisset@cae.ca (Jean-Francois Panisset) Cc: info-performer@sgi.sgi.com Subject: Re: Questions on MCO configurations In-Reply-To: Your message of "Thu, 29 Sep 94 19:22:30 EDT." <9409292322.AA05687@cae.ca> Date: Thu, 29 Sep 94 17:50:27 -0700 From: Jim Helman One MCO per pipe. Supported MCO vofs are: /hosts/rose/usr/gfx/ucode/RE/vs2/vof/1rm: 2@640x480_60/ 2@640x486_30i/ 4@640x480_60/ 4@640x486_30i/ /hosts/rose/usr/gfx/ucode/RE/vs2/vof/2rm: 1@1280x1024_60/ 3@640x486_30i/ 1@640x486_30i/ 3@800x600_60/ 2@1025x768_60/ 3@850x850_60/ 2@1200x900_72/ 3@960x680_60/ 2@1280_twovof/ 4@640x480_60/ 2@1280x1024_50/ 4@640x486_30i/ 2@1280x1024_60/ 4@640x640_60/ 2@640x480_180q/ 4@720x544_60/ 2@640x480_60/ 4@960x620_60/ 2@640x480_60+1@1280x1024_60/ 6@640x480_60/ 2@640x486_30i/ 6@640x486_30i/ 2@960x680_60/ 6@745x224_60/ /hosts/rose/usr/gfx/ucode/RE/vs2/vof/4rm: 2@1025x768_60/ 3@850x850_60/ 2@1200x900_72/ 3@960x680_60/ 2@1280x1024_50/ 4@640x480_60/ 2@1280x1024_60/ 4@640x486_30i/ 2@640x480_180q/ 4@640x640_60/ 2@640x480_60/ 4@720x544_60/ 2@640x480_60+1@1280x1024_60/ 4@960x620_60/ 2@640x486_30i/ 6@640x480_60/ 3@1025x768_60/ 6@640x486_30i/ 3@800x600_60/ 6@745x224_60/ rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Sep 30 01:54:04 1994 (5.65c/IDA-1.4.4 for <@datasrv.co.il:info-performer@sgi.com>); Fri, 30 Sep 1994 10:53:19 +0200 From: "Ran Yakir" Date: Fri, 30 Sep 1994 10:50:29 +0000 In-Reply-To: John C Vanderburgh "" (Sep 29, 3:08pm) References: <199409291908.AA09358@stealth.afit.af.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: John C Vanderburgh Cc: info-performer@sgi.sgi.com Subject: Re: Start Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Sep 29, 3:08pm, John C Vanderburgh wrote: > Subject: > Hey all, > In my Performer application, I'm rendering some stars in a space environment as point light sources. > I use actual celestial coordinates converted to Earth-centered rectangular > coordinates, so my stars end up as a "celestial sphere" surrounding the > Earth. This was working well until I discovered that if I move far > enough in my world, objects that aren't within my "celestial sphere" (such > as the Sun or a distant planet, etc) will appear "behind" the stars. For > various reasons, I don't want to increase the radius of my > "celestial sphere" (in order to physically enclose all my objects). > If I could somehow "clamp" the depth of the star pixels (in screen > space) to the largest z-buffer value, it would > seem that the stars would always appear "farther" > than any other objects in my world. I read the man pages on > "zbuffer", "zfunction", "zdraw", etc., but didn't find exactly what > I was looking for. So, is there a way to alter the > values used for z-buffer calculations for my stars? (or, for that matter, > any other suggestions on how to solve this dilemma?) > > Thanks, > > John Vanderburgh > AF Institute of Technology > Wright-Patterson AFB, OH > (jvanderb@afit.af.mil) > > >-- End of excerpt from John C Vanderburgh Hi John, What you should do is 1. Have the distant starts arranged under a separate node, drawn first. This is done by adding this node to the scene first : pfAddChild (scene, celestial_sphere_node); pfAddchild (scene, close_objects_node); 2. Assign a post draw callback to that node, which will clear the zbuffer : Assigning - pfNodeTravFuncs (celestial_sphere_node, PFTRAV_DRAW, NULL, clear_zbuf); function - long clear_zbuf (pfTraverser *trav, void *data) { zclear(); } Or else you can assign a pre draw callback to that node that will disable zbuffer (zbuffer(0), zwritemask(0)) and z post draw callback that will enable it. Hope that helps Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Fri Sep 30 08:31:09 1994 id <29934-0@smtpgw.unizh.ch>; Fri, 30 Sep 1994 16:31:09 +0100 Fri, 30 Sep 1994 16:31:05 --100 From: suter@rsl.geogr.unizh.ch (Martin Suter) Fri, 30 Sep 94 17:31:04 +0200 Subject: pfReplaceChild To: info-performer@sgi.sgi.com Date: Fri, 30 Sep 1994 15:31:04 +0000 (MET) Reply-To: suter@rsl.geogr.unizh.ch X-Organization: Remote Sensing Laboratories, University of Zurich X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 558 Ciao In my application I use the call: 'long ret = pfReplaceChild(group, old, new);' Is the memory associated with 'old' freed? What about the texture memory if the node 'old' is textured? Merci -- Martin Suter suter@rsl.geogr.unizh.ch Phone: +41 - 1 / 257 51 63 Remote Sensing Laboratories FAX: +41 - 1 / 362 52 27 University of Zurich Winterthurerstrasse 190 CH-8057 Zurich; Switzerland From guest Fri Sep 30 10:12:21 1994 Date: Fri, 30 Sep 1994 13:12:24 -0400 From: girish prabhu To: info-performer Subject: Using joystick as an input device for Performer. I need to interface a joystick as an input device to the driving simulator I am developing using performer. I am using the perfly software code supplied with performer 1.2 (modified offcourse). The code uses pfuFormer utilities to update the views. and in the PFUXF_DRIVE mode, the transformation matrix is updated automatically by the position changes in the mouse. I would like to know how to delink the mouse interface and get inputs from joystick. I have joystick input routines available to me... Girish From guest Fri Sep 30 12:51:57 1994 Date: Fri, 30 Sep 1994 15:52:01 -0400 From: girish prabhu To: info-performer Subject: Running performer --- Hardware question ?? I have installed IRIS performer 1.2 on IRIX Indigo running 4.0.5F, with 96M memory (the software is kept on the server (/usr/local). The program "run_town" works fine when run from the main machine.. However, when run from other machines on the net, it gives a run time "out of memory" error. THe other machines that I used had 32M and 64M memory. Could anybody shed some light on why this could be happening.. Thanks Girish From guest Fri Sep 30 14:39:10 1994 From: "Smith, Jeff W." To: "Performer User Group ( SMPT )" Subject: pfOpenStats Date: Fri, 30 Sep 94 14:37:00 PDT Encoding: 23 TEXT X-Mailer: Microsoft Mail V3.0 To All: I'm trying to use Performer stats using multiple viewports. I use a hotkey to invoke and turn off the stats. To do this I call pfStatsClass( pfGetChanFStats( chan ), .... for each viewport. I get the results I want but Performer spews this warning out for every pfDrawChanStats call: Performer Warning:pfOpenStats(pfStats*) for 0x8ad270 ignored Already have a different opened pfStats=0x8a32b0 mask=0x1. These channels are shared but, I get the warning regardless whether the token for sharing channel stats is set. Any ideas? Thanks in advance. Jeff From guest Fri Sep 30 14:52:35 1994 From: "Ken Hughes" Date: Fri, 30 Sep 1994 14:48:39 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: subscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 subscribe -- Ken Hughes phone: (206) 649-5619 Silicon Graphics Computer Systems fax: (206) 746-7563 13810 S.E. Eastgate Way #300 vmail: 59600 Bellevue, WA 98005 email: kenh@seattle.sgi.com From guest Fri Sep 30 15:20:21 1994 Date: Fri, 30 Sep 94 15:20:25 -0700 From: spelk@bert.arc.nasa.gov (Steve Elkins) To: info-performer@sgi.sgi.com Subject: LOD switch problem Performer Folks, I'm having a problem with LOD's. I'm running on an ONYX RE2 with 4 CPU's and 2 RM4's. If I run my simulation with a 1280x1024 video output format everything is fine. If I setmon to a 640x512 window the LOD switch ranges appear to be screwed up and don't switch until the eyepoint is much closer to the LOD center. I need to run with the smaller video output format since this gives a higher frame rate. Why would changing the video output format effect LOD ranges? Thanks for any insight. Steve Elkins Sterling Software NASA Ames Division From guest Fri Sep 30 16:09:06 1994 From: "Michael Jones" Date: Fri, 30 Sep 1994 16:08:53 -0700 In-Reply-To: spelk@bert.arc.nasa.gov (Steve Elkins) "LOD switch problem" (Sep 30, 3:20pm) References: <9409302220.AA23438@bert.arc.nasa.gov> X-Mailer: Z-Mail (3.2a.627 27jun94 MediaMail) To: spelk@bert.arc.nasa.gov (Steve Elkins), info-performer@sgi.sgi.com Subject: Re: LOD switch problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 30, 3:20pm, Steve Elkins wrote: > Subject: LOD switch problem :I'm having a problem with LOD's. I'm running on an ONYX RE2 with :4 CPU's and 2 RM4's. If I run my simulation with a 1280x1024 video :output format everything is fine. If I setmon to a 640x512 window :the LOD switch ranges appear to be screwed up and don't switch until :the eyepoint is much closer to the LOD center. This is not a bug, it's a feature. Really. See below... :I need to run with the smaller video output format since this :gives a higher frame rate. Reasonable when fill limited. :Why would changing the video output format effect LOD ranges? Because "distance" is not the real criterion for LOD selection. If it were, then looking through a narrow field-of-view channel (such as a special sensor or telescope) would always show low LOD versions of models. It's pretty easy to see that the FOV should effect the LOD as follows: small FOV == maginification == higher LOD than normal, so: decrease the actual range when computing LOD's large FOV == minification == lower LOD than normal, so: increase the actual range when computing LOD's The other factor is the number of pixels used to represent the channel on the screen. When few pixels are used, sampling theory suggests that there is a minimum spatial frequency which can be properly reconstructed, so: large channel extent in pixels == higher LOD than normal, so: decrease the actual range when computing LOD's small channel extent in pixels == lower LOD than normal, so: increase the actual range when computing LOD's These factors combine linearly to make LOD selection have the same visual "quality" impact irrespective of channel size and FOV. IMHO, this is a good feature in IRIS Performer and should not be seen as a bug. Even so, you may not want this auto-LOD-scaling processing for any number of reasons, and we thought about that. If you take a look at the pfChanLODAttr man-page, you'll see that this behind-the-scenes processing can be disabled by setting the PFLOD_FRUST_SCALE factor to zero. Also, the magic LOD scaling process is described there as well. Here's the text: IRIS Performer level-of-detail behavior is primarily dependent on pfChannel viewing parameters such as view position, field-of-view, and viewport pixel size. IRIS Performer assumes that LODs are modeled for a canonical FOV of 45 degrees and a viewport size of 1024 pixels. IRIS Performer computes a scale value for pfChannels whose FOV or viewport size differ from the defaults. This scale value is used to modify LOD ranges so that correct LOD behavior is maintained. If your LODs were not modeled with the above defaults you may use PFLOD_SCALE(see below) to adjust the LOD ranges. Other LOD modification parameters are set with pfChanLODAttr. attr is a symbolic token that specifies which LOD parameter to set and is one of: PFLOD_FRUST_SCALE The range multiplier based on chan's viewport and FOV is multipled by val. Typically, this feature is enabled with a value of 1.0 and disabled with a value of 0.0. Hope this helps, Michael Jones -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311