From marrou@melange.vsl.ist.ucf.edu Mon Oct 11 09:09:59 1993 Date: Mon, 11 Oct 93 12:11:00 -0400 From: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9310111611.AA23192@melange.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: the new pfMQueryHit() Status: OR Does the pfMQueryHit() in v1.2 (Beta) return world coordinates for the PFQHIT_POINT vector? If not, where is the transformation? Also, is the PFQHIT_NORM vector normalized? So far, these new intersection routines seem a lot easier to implement, but the man pages are horrible. pfSegsIsectNode() doesn't even exist in our copy! :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From jimh@surreal Mon Oct 11 11:12:37 1993 Message-Id: <9310111812.AA22325@surreal.asd.sgi.com> To: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) Cc: info-performer@sgi.sgi.com Subject: Re: the new pfMQueryHit() Date: Mon, 11 Oct 93 11:12:26 -0700 From: Jim Helman Status: OR Date: Mon, 11 Oct 93 12:11:00 -0400 From: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) To: info-performer@sgi.sgi.com Subject: the new pfMQueryHit() Does the pfMQueryHit() in v1.2 (Beta) return world coordinates for the PFQHIT_POINT vector? If not, where is the transformation? Also, is the PFQHIT_NORM vector normalized? As with the now defunct pfIsect structure, the point is in local coordinates. You *would* be able to get the transformation both in discriminator callbacks and upon return of pfSegsIsectNode, except for a bug in the beta (alpha 53), which has since been fixed. The normal is normalized. So far, these new intersection routines seem a lot easier to implement Good. but the man pages are horrible. What would you like to see more detail on? pfSegsIsectNode() doesn't even exist in our copy! :) Then something went wrong with your inst. I just double checked both the Irix4 (/usr/catman/p_man/cat3/Performer_pf/pfSegsIsectNode.z) and Irix5 (/usr/share/catman/p_man/cat3/Performer_pf/pfSegsIsectNode.z) distributions. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Wed Oct 13 19:42:20 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310131942.ZM5184@holodeck.asd.sgi.com> Resent-Date: Wed, 13 Oct 1993 19:42:20 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Wed, 13 Oct 93 16:50:00 -0700 From: cindy@langrenus.arc.nasa.gov (Cindy Ferguson) Message-Id: <9310132350.AA28987@langrenus.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: question on intersections and different hardware Status: OR I have a question about intersection traversals in performer 1.0. The code I have developed works fine on my VGXT and my Indigo XS24. However on my regular simple little Indigo, I get nothing. The code still runs -- it just returns the wrong results of always intersecting nothing. Does anyone know a work-around for this? Thanks, Cindy From aschaffe Thu Oct 14 13:42:35 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141342.ZM6922@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 13:42:35 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Message-Id: <9310141821.AA07757@surreal.asd.sgi.com> To: cindy@langrenus.arc.nasa.gov (Cindy Ferguson) Cc: info-performer@sgi.sgi.com Subject: Re: question on intersections and different hardware In-Reply-To: Your message of "Wed, 13 Oct 93 16:50:00 PDT." <9310132350.AA28987@langrenus.arc.nasa.gov> Date: Thu, 14 Oct 93 11:21:04 -0700 From: Jim Helman Status: O Intersections are not dependent on graphics (or CPU type for that matter), so the Indigo XS24 <-> Indigo Entry difference shouldn't matter. The only thing that comes to mind is that if there were an uninitialized stack variable, you could see an OS version dependency, since earlier versions of the OS zeroed more pages of the stack on startup. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Feb 7 02:59:23 1994 Date: Mon, 7 Feb 94 11:00:44 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9402071100.AA04937@death.reading.sgi.com> To: info-performer@sgi.sgi.com Subject: More Intersection Questions.... Status: OR I am relayin the question from DRA Farnborough in the UK, they own more ONYX's than the rest of the universe but they have no e-mail. The application is line of sight & occulting calculations, if a pfSegsIsectNode is used on a vector between two moving objects they want to test for terrain intersections. It works but there are many intersections being returned and they only need to wait for the first terrain intersection so they are looking to improve performance. They specify a discriminator callback which prints a message that it has been called and returns PFTRAV_TERM. However the callback is invoked multiple times for each intersection instead of just once. Is this a bug or a mis-understanding of the man page ? ANGUS HENDERSON "Imagine your witty quote here" From guest Mon Feb 7 09:21:06 1994 From: "Michael Jones" Message-Id: <9402070839.ZM16807@babar.asd.sgi.com> Date: Mon, 7 Feb 1994 08:39:09 -0800 In-Reply-To: angus@death.reading.sgi.com (Angus Henderson) "More Intersection Questions...." (Feb 7, 11:00am) References: <9402071100.AA04937@death.reading.sgi.com> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: angus@death.reading.sgi.com (Angus Henderson), info-performer@sgi.sgi.com Subject: Re: More Intersection Questions.... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Feb 7, 11:00am, Angus Henderson wrote: > Subject: More Intersection Questions.... This is really Jim Helman's question, but I'll give it a shot... :The application is line of sight & occulting calculations, if a :pfSegsIsectNode is used on a vector between two moving objects :they want to test for terrain intersections. It works but there :are many intersections being returned and they only need to wait :for the first terrain intersection so they are looking to improve :performance. : :They specify a discriminator callback which prints a message that :it has been called and returns PFTRAV_TERM. : :However the callback is invoked multiple times for each intersection :instead of just once. [before we even start: you are specifying CLIP_END, right? and isect caching is on? make sure before proceeding...] I presume that you mean "...callback is invoked multiple times for each intersection _search_ instead of just once." Given that the database is not sorted into a total order in the BSP sense, we must look at all "possible" nodes for each intersection. Possible nodes are those whose bounding volumes are closer at some point along the search vector than the closest known intersection. Here's the idea (boxes represent bounding volumes): * +-------------+ +------|--+ | seg: --------|------|W-|-------S--|-----------------> | +----- B -----+ +--- A ---+ Now if the first node tested in the search is A, and the intersection is found at point W, we still need to test node S, since it's bounding volume extends closer to the origin of the search vector than the closest known intersection point. (This fact is indicated by the small asterisk) The result of searching node B is in this case point 'S', which is seen to be more distant and will thus be discarded. :Is this a bug or a mis-understanding of the man page ? Performance oriented customers (which is just about everyone) can get best performance by minimizing the overlap of nodes. How is this best done? By organizing the database spatially: form a quad-tree or oct-tree like hierarchy with your data. If the nodes A and B above had not been in overlap, there could have been but one search. Also, make sure that your geosets are not too big: 5 to 50 polys makes sense, but thousands of polygons in a geoset can be dangerous since the intersection test must be performed on _each_ primitive in the geoset whenever the set's bounding volume is hit by the vector. For even greater performance in intersection processing, look to IRIS Performer 1.2, which has these important new intersection features: 1. pfPartition node for direct spatial indexing into an automatically built grid-like search structure. 2. parallel intersection processing to let extra CPU's be used for correspondingly greater intersection throughput. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Feb 7 11:08:31 1994 Message-Id: <9402071908.AA19812@surreal.asd.sgi.com> To: angus@death.reading.sgi.com (Angus Henderson) Cc: info-performer@sgi.sgi.com Subject: Re: More Intersection Questions.... In-Reply-To: Your message of "Mon, 07 Feb 94 11:00:44 GMT." <9402071100.AA04937@death.reading.sgi.com> Date: Mon, 07 Feb 94 11:08:21 -0800 From: Jim Helman Status: OR > They specify a discriminator callback which prints a message that > it has been called and returns PFTRAV_TERM. > However the callback is invoked multiple times for each intersection > instead of just once. Three possibilites: 1) You mean multiple callbacks per request, for different pieces of geometry as mtj suggests. 2) The request contains multiple segments and you are only terminating one of them, so you still get callbacks on the others. (You can OR PFTRAV_IS_ALL_SEGS into the return to have PFTRAV_TERM apply to all segments) 3) There's a bug. Also, if all they want is terrain, the best way to speed things up would be to use pfNodeTravMasks to set a bit in the intersection mask of the terrain subgraph and clear it elsewhere and then restrict the intersection request to that subgraph using the request's intersection mask. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 17:31:16 1994 id AA28044; Thu, 30 Jun 94 17:30:04 -0700 Date: Thu, 30 Jun 1994 17:30:02 -0700 (PDT) From: "Payton R. White" Subject: Intersect problems To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: OR I'm getting a crash deep in the collision routines and I would like some feedback on what might be causing it. I can't find anything that says I should call intersect functions from a specific place or process but I wouldn't doubt that this is part of the problem. Currently my collision routines are called from my navigation function in the draw callback. This is what I get back from 'where' in dbx: 0 pfGeode::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x10023100) ["../../../lib/libpf/pfGeode.C":518, 0x499b70] 1 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x10023100) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 2 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x10023100) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 3 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x1) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 4 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x0) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 5 pfNode::segsIsect(_pfSegSet*,_pfHit***)(0x8e02d0, 0x940860, 0x7fffabd8, 0x2, 0x0) ["../../../lib/libpf/pfNode.C":1257, 0x484240] 6 pfSegsIsectNode(0x8e02d0, 0x1001d680, 0x7fffabd8, 0x2, 0x10023100) ["../../../lib/libpf/cNode.C":369, 0x453b70] 7 pfpCollideGrnd(coord = 0x781444, node = 0x8e02d0, zpr = 0x7fffac14) ["/users/guests/u27486/vr/pfpCollide.c":72, 0x42d0b8] 8 full_drive(coord = 0x781444) ["/users/guests/u27486/vr/nav.c":635, 0x4285d8] 9 nav_drive(shared = 0x781440) ["/users/guests/u27486/vr/nav.c":589, 0x42817c] 10 navigate(shared = 0x781440) ["/users/guests/u27486/vr/nav.c":50, 0x42616c] 11 DrawChannel(chan = 0x9497e0, data = (nil)) ["/users/guests/u27486/vr/vr.c":178, 0x42bf40] 12 doDrawChannel(pfChannel*)(0x949c80, 0x0, 0x10023100, 0x2, 0x4038426e) ["../../../lib/libpf/pfProcess.C":1775, 0x44d434] 13 pfFrame(0x9497e0, 0x781444, 0x781450, 0x2, 0x0) ["../../../lib/libpf/pfProcess.C":1500, 0x44c5f8] 14 main(argc = 1, argv = 0x7fffaef4) ["/users/guests/u27486/vr/vr.c":63, 0x42ba88] Thanks, -- Visualization << SGI >> Simulation -- Payton R. White __ __ __ prwhite@ucsd.edu / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From guest Thu Jun 30 18:19:28 1994 Message-Id: <9407010119.AA26287@surreal.asd.sgi.com> To: "Payton R. White" Cc: info-performer@sgi.sgi.com Subject: Re: Intersect problems In-Reply-To: Your message of "Thu, 30 Jun 94 17:30:02 PDT." Date: Thu, 30 Jun 94 18:19:12 -0700 From: Jim Helman Status: O > I can't find anything that > says I should call intersect functions from a specific place or process > but I wouldn't doubt that this is part of the problem. Bad documentation. pfSegsIsectNode() should only be called from the APP or ISECT process, although it probably would also work from the CULL process. The DRAW process does not have a private copy of the scene graph, so it's easy to imagine scene graph changes colliding. Also, intersections can be time consuming, so they are usually the last sort of thing you want to be doing in the DRAW process. > Currently my collision routines are called from my navigation > function in the draw callback. That's probably the cause of the problem. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 20:13:42 1994 Date: Thu, 30 Jun 1994 20:13:55 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199407010313.UAA01452@netcom14.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: Intersect problems Status: O "Payton R. White" wrote and "Jim Helman" replied: >> I can't find anything that >> says I should call intersect functions from a specific place or process >> but I wouldn't doubt that this is part of the problem. > > Bad documentation. pfSegsIsectNode() should only be called from the > APP or ISECT process, although it probably would also work from the > CULL process. The DRAW process does not have a private copy of the > scene graph, so it's easy to imagine scene graph changes colliding. > > Also, intersections can be time consuming, so they are usually the > last sort of thing you want to be doing in the DRAW process. > >> Currently my collision routines are called from my navigation >> function in the draw callback. > > That's probably the cause of the problem. > > rgds, > > -jim helman > > jimh@surreal.asd.sgi.com > 415/390-1151 Actually, this is documented -- in the new and improved IRIS Performer Programming Guide (for v1.2, Doc. # 007-1680-020). In chapter 7: Frames and Load Control, in the section "Rules for Invoking Functions While Multiprocessing" in table 7-4 "Trigger Routines and Associated Processes" on page 177, it says exactly what Jim replied: that pfSegIsectNode should only be called from ISECT or APP processes. The rest of that table and section contain much more good info. This is a new manual and I imagine most users haven't read it much. But thanks to the Performer Group a lot of work was put into improving the v1.2 Prog. Guide -- and it is improved! I recommend it both for learning or reviewing fundamental principles and as a reference (this release of the manual is quite well indexed). Lew Hitchner VR and Visual Sim Consultant Mountain View, CA hitchner@netcom.com From guest Fri Jul 1 03:03:54 1994 From: "Annie SIMEAU" Message-Id: <9407011203.ZM3581@alice.paris.sgi.com> Date: Fri, 1 Jul 1994 12:03:06 -0600 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com, asim@alice.paris.sgi.com Subject: information on pfSegsIsectNode Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi everybody, I need to know if the function pfSegsIsectNode is done on the graphic board or on the cpu board, especially for an INDIGO2 Extreme. Thanks for any help. /| o Annie Simeau /_| _ _ _ asim@paris.sgi.com / | / ) / ) / /_) . Phone Number : 33 1 34 88 80 88 / |_/ /_/ /_/_(_ . Fax Number : 33 1 34 88 80 76 From guest Fri Jul 1 09:40:49 1994 Message-Id: <9407011621.AA08714@surreal.asd.sgi.com> To: "Annie SIMEAU" Cc: info-performer@sgi.sgi.com Subject: Re: information on pfSegsIsectNode In-Reply-To: Your message of "Fri, 01 Jul 94 12:03:06 MDT." <9407011203.ZM3581@alice.paris.sgi.com> Date: Fri, 01 Jul 94 09:21:30 -0700 From: Jim Helman Status: OR pfSegsIsectNode and pfChanPick both perform intersection testing on the host CPU by traversing the scene graph and using its hierarchical bounding volumes. On an MP machine, it can be done in the APP or ISECT process. The latter allows for intersection testing to be asynchronous and run at a slower rate than the application itself, so as not to limit frame rate. When performed as part of the APP (or a combined APPCULLDRAW on a 1P machine like an Indigo2), intersection testing is best done after pfFrame() but before pfSync() so that it can overlap with other processing either on another host CPU or in the graphics hardware. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 09:39:55 1994 From: "Dennis Pierce" Message-Id: <9406301239.ZM11436@sgimco.orlando.sgi.com> Date: Thu, 30 Jun 1994 12:39:51 -0400 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: iris-performer@sgi.sgi.com Subject: collisions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O customer is doing collision detection between ownship and models in his database - he fires off intersection rays and gets hit coordinates returned that are related to his ownship's distance from the world's center, not related to the distance between the ownship and the model is this normal? also, what is the proper method to use to determine if his ownship intersects a moving model? collisions with SCS objects works just fine, but the DCS objects are absolute to the distance from the origin and not the relative distance between models thanks! bye. -- Dennis Pierce, SGI, 900 Winderley Place, Ste 130, Maitland, FL 32751 email: dpierce@sgi.com vmail: 8548 tel : 407.660.0073 late : 407.660.2789 fax : 407.660.8981 cell : 407.256.8447 From guest Thu Jun 30 12:02:43 1994 Message-Id: <9406301902.AA24730@surreal.asd.sgi.com> To: "Dennis Pierce" Cc: iris-performer@sgi.sgi.com Subject: Re: collisions In-Reply-To: Your message of "Thu, 30 Jun 94 12:39:51 EDT." <9406301239.ZM11436@sgimco.orlando.sgi.com> Date: Thu, 30 Jun 94 12:02:32 -0700 From: Jim Helman Status: OR > customer is doing collision detection between ownship and models > in his database - he fires off intersection rays and gets hit > coordinates returned that are related to his ownship's distance > from the world's center, not related to the distance between > the ownship and the model 1) The line segments need to be constructed in world space around the ownship. 2) To avoid detecting ownship, the line segments need to either start outside the ownship model or intersection masks set to ignore ownship. If the customer follows these two rules, it should work fine. > also, what is the proper method to use to determine if his ownship > intersects a moving model? collisions with SCS objects works just > fine, but the DCS objects are absolute to the distance from the > origin and not the relative distance between models Hmm... the behavior of SCSes and DCSes should be identical. Is the user transforming the pfHit collision point into world space? Hits are returned in the local coordinates as specified in the pfGeoSet. If the SCSes have been "flattened" to identity matrices during database loading, the behavior will be different, since the flattened geometry now now includes the transformation formerly represented in the SCS. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Apr 21 06:34:36 1994 To: info-performer@sgi.sgi.com Subject: Pfsegsisectnode Doesn'T Work Date: Thu, 21 Apr 94 15:34:14 CEST From: "Infobyte S.R.L." Message-Id: <9404211534.aa06032@ax433.mclink.it> Status: OR Hi all, I have recompiled a program developed with Performer 1.2 beta, with the final product and I found a problem: the pfSegsIsectNode function doesn't work. The return value is always 0. The same program with the beta version works fine: maybe is it that I have to initialize more things? I don't have callback functions, the isectMask is set to 0xffffffff and the activeMask is correctly set at the number of active segments. Any suggestion? Bye. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Fri Apr 29 14:21:30 1994 Message-Id: <199404292121.OAA25346@sgi.sgi.com> Date: 29 Apr 94 17:02:00 EST From: "Robert Reif" Subject: Re: pfSegsIsectNode PFTRAV_IS_PATH problem To: "info-performer" Status: OR Here is some more info on the problem I am having with pfSegsIsectNode and PFTRAV_IS_PATH. I hacked up the sample program intersect.c until I was able to duplicate my problem. When I add a pfSwitch node above geode and enable PFTRAV_IS_PATH, I no longer get any intersections. With PFTRAV_IS_PATH not set, everything works fine. The following is a diff of /usr/src/Performer/src/pguide/libpf/progs/intersect.c: 70d69 < pfSwitch *sw; 124,126d122 < sw = pfNewSwitch(); < pfAddChild(sw, geode); < pfSwitchVal(sw, PFSWITCH_ON); 131c127 < pfAddChild (scs[loop], sw); --- > pfAddChild (scs[loop], geode); 159c155 < segset.mode = PFTRAV_IS_PRIM|PFTRAV_IS_NORM|PFTRAV_IS_CULL_BACK|PFTRAV_IS_PATH; --- > segset.mode = PFTRAV_IS_PRIM|PFTRAV_IS_NORM|PFTRAV_IS_CULL_BACK; As is, the program fails to find any intersections. When |PFTARV_IS_PATH is commented out, it works fine. Robert Reif reif@ntsc-rd.navy.mil From guest Thu Dec 2 10:39:20 1993 Date: Thu, 2 Dec 93 13:39:12 -0500 From: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Message-Id: <9312021839.AA22534@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Cc: tonnesen@enews.nrl.navy.mil, (Cindy, Tonnesen) Subject: pfSegsIsectNode difficulties Status: OR I'm using the Performer 1.2 Beta Release -- and I'm trying to do something I anticipated would not be too difficult: detecting intersections between a line segment and objects in the scene. Currently, there's only one object in the scene and one line segment to test intersections from. Problems I'm having: pfSegsIsectNode() is currently always returning 1 - that one line segment hit something. When by sight, it is obvious that the line segment was no where near the object. My code looks like: ... pfGeode *root; pfSeg seg; pfHit **hits[1]; float nodehit; _pfSegSet segSet; long numHits; ... root = LoadIcon("/srvr/icons/70.icon"); pfNodeTravMask(root, PFTRAV_ISECT, 0x01, PFTRAV_SELF | PFTRAV_DESCEND | PFTRAV_IS_CACHE, PF_SET); /* I've also tried pfGSetIsectMask() in place of the above line; * both yield the same results. */ ... ... pfMakePtsSeg(&seg, vertics[0], vertices[1]); segSet.typeId = NULL; segSet.userData = NULL; segSet.segs[0] = seg; // set active mask to 0x01; set 0th bit to 1. segSet.activeMask = 0x01; segSet.isectMask = 0x01; segSet.mode = PFTRAV_IS_GSET | PFTRAV_IS_GEODE | PFTRAV_IS_PRIM; segSet.bcyl = NULL; segSet.discFunc = NULL; /* this function is always returning numHits = 1 */ numHits = pfSegsIsectNode(root, &segSet, hits); if (numHits) { nodehit = 0.0; pfQueryHit(hits[0][0], PFQHIT_GSET, &nodehit); if (nodehit != NULL) { /* intersection successful */ processing... } } Part of the difficulty in getting this to work is that I only have man pages as sent with the beta release as documentation, and there are NO examples in it of using the intersection routines. Any light anyone can shed on this would be highly appreciated - even if you do not have the answer to my question, I would *highly* appreciate some sample code that uses these routines successfully! Thank you, Cynthia Tonnesen Naval Research Lab From guest Thu Dec 2 11:14:49 1993 Date: Thu, 2 Dec 93 11:15:33 -0800 From: lblume@miranda (Leo Blume) Message-Id: <9312021915.AA07780@miranda.asd.sgi.com> To: info-performer@miranda Subject: re:pfSegsIsectNode difficulties Status: O Date: Thu, 2 Dec 93 13:39:12 -0500 tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) writes: I'm using the Performer 1.2 Beta Release -- and I'm trying to do something I anticipated would not be too difficult: detecting intersections between a line segment and objects in the scene. [stuff deleted] I too am interested in seeing an example of how pfHit, pfQueryHit, etc is supposed to be used (esp. in the context of pfChanPick). The data struct passed into pfChanPick is supposed to be a: pfHit **pickList[]; Is this supposed to be allocated or does pfChanPick do the allocation? If I am supposed to do the allocation, how big is this array supposed to be? Equal to the max. number of items I think will be hit?? -------------- Leo Blume lblume@sgi.com From guest Fri Dec 3 13:21:54 1993 Date: Fri, 3 Dec 93 16:21:55 -0500 From: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Message-Id: <9312032121.AA04434@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com, performer-beta@crusty Cc: tonnesen@enews.nrl.navy.mil, (Cindy, Tonnesen) Subject: Intersections in Alpha 72 Beta Status: OR 1) What is the proper strategy for detecting intersections between two performer objects? What are the functions that I should look at to do this? 2) What is the proper strategy for detecting intersections of line segments with performer objects? I've been using pfSegsIsectNode(). But since my line is actually contained in a GeoSet that has 3 DCS ancestors I must concatenate 3 matrices together and call pfXformPt3() twice, one for the startpoint and one for the endpoint of my line segment, to transform my line segment into world coords. This all happens before calling pfSegsIsectNode(). This is quite inefficient - What is a better way to do this? Thanks in advance for your help, Cynthia Tonnesen Naval Research Lab From guest Fri Dec 3 14:09:54 1993 Message-Id: <9312032205.AA07539@surreal.asd.sgi.com> To: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Cc: info-performer@sgi.sgi.com Subject: Re: Intersections In-Reply-To: Your message of "Fri, 03 Dec 93 16:21:55 EST." <9312032121.AA04434@enews.nrl.navy.mil> Date: Fri, 03 Dec 93 14:05:01 -0800 From: Jim Helman Status: OR Performer does not currently have routines for volume-volume object collisions, but some are planned for a future release. Your method is correct, and not that terribly inefficient. In the current scheme which uses segments, the transformation you describe from object to world coordinates must be done someplace. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Dec 8 11:41:35 1993 From: Renee Strong Message-Id: <9312081941.AA10135@pat.mdc.com> Subject: performer and collision detection To: info-performer@sgi.sgi.com Date: Wed, 8 Dec 93 13:41:25 CST X-Mailer: ELM [version 2.3 PL11] Status: OR Are there any plans to put body to body collision detection into future releases of Performer? When is Performer 1.2 supposed to come out? We had heard before Christmas. Renee Strong renee@pat.mdc.com From guest Wed Dec 8 12:40:32 1993 Message-Id: <9312082040.AA23122@surreal.asd.sgi.com> To: Renee Strong Cc: info-performer@sgi.sgi.com Subject: Re: performer and collision detection In-Reply-To: Your message of "Wed, 08 Dec 93 13:41:25 CST." <9312081941.AA10135@pat.mdc.com> Date: Wed, 08 Dec 93 12:40:21 -0800 From: Jim Helman Status: OR > Are there any plans to put body to body collision detection into future > releases of Performer? It's on the list, but there are a couple things above it. > When is Performer 1.2 supposed to come out? We had heard before Christmas. I don't think a date has been officially announced. To be honest, I wouldn't expect to find a copy in my Christmas stocking (at least not one with the newly expanded manual), but not long thereafter. Performer 1.2 would certainly make a fine Valentine for the vis sim aficionado in your life. Those with urgent 1.0/1.1 issues should contact us or their SE. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Nov 3 15:12:28 1993 Message-Id: <9311032315.AA04542@mak.com> To: info-performer@sgi.sgi.com Subject: intersections Date: Wed, 03 Nov 93 18:15:43 -0500 From: Len Granowetter Status: OR I am using a beta version of Performer 1.2, and there are a few things that are unclear about the new API for pfSegsIsectNode. In the pfSegSet structure, there is a typeId field. I couldn't find an explanation for what this field does, in the man pages or ReadMe's. What does it do? Also, in the ReadMe, it mentions that picking is "somewhat unreliable". Does anyone know more specifically what this means? I.e. "It will work as long as you are running on such and such machine." or "It won't work in these particular circumstances"? Is the use of pfSegsIsectNode more reliable, or is pfChanPick's unreliablilty based on the lower level intersection stuff's reliability? Thanks, Len Granowetter MaK Technologies From guest Tue Nov 9 11:28:39 1993 Date: Tue, 9 Nov 93 20:26:16 GMT From: gallir@anim.uib.es (Ricardo Galli) Message-Id: <9311092026.AA02098@anim.uib.es> To: info-performer@sgi.sgi.com Subject: about collision Status: OR J. Barrus wrote: > Unfortunately, I can't find any good discussions of collision detection so > if anyone else has some reading suggestions, that might help here. The > above is a very terse description of just a few possible options. (The > Graphics Gems series - GG, GG II, and GG III - do discuss calculating > bounding spheres and intersecting rays with spheres and axis-aligned boxes > for ray-tracing applications.) > I think so, we are developing somme techniques for collision detection and response between solid objects for real time applications, but it's no easy to find literature about these kind of techniques (especially for Performer users). I saw in a demo included in a Onix a very interesting collision detection (I think in this case is just a point, the observer aginst faces, is it perfor mer gurus?) in the Village demo (i.e. when the "observer" collides against a wall or more interesting, in the petrol station (against the "servers", I don't know how is called is English that thing with a rubber tube and meters to put the gas into the car's tank...). SGI performer gurus, can you give to me a "track" to do this kind of stuff very fast? --Ricardo Galli Universitat de les Illes Balears Palma de Mallorca - SPAIN Tel. +34 71 17 3201 FAX. +34 71 17 3003 e-mail. gallir@anim.uib.es +--------------------------------------------------------------------+ |The nice thing about standards is that there are so many of them to | |choose from. | | -- Andrew S. Tanenbaum | +--------------------------------------------------------------------+ From guest Tue Nov 9 13:05:14 1993 Message-Id: <9311092105.AA04530@surreal.asd.sgi.com> To: gallir@anim.uib.es (Ricardo Galli) Cc: info-performer@sgi.sgi.com Subject: Re: about collision In-Reply-To: Your message of "Tue, 09 Nov 93 20:26:16 GMT." <9311092026.AA02098@anim.uib.es> Date: Tue, 09 Nov 93 13:05:07 -0800 From: Jim Helman Status: O Collision detection in Performer is currently based on line segments and hierarchical bounding volumes (spheres and boxes). This is good for some things, like vehicle terrain following and collisions (as Ricardo mentioned in the town demo), but usually not appropriate for determining volume-volume collisions of N objects where N is large and many objects are close, e.g. an MCAD design with hundreds of moving parts with close tolerances. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Nov 19 11:01:33 1993 Message-Id: <9311191901.AA13018@sgi.sgi.com> Date: 19 Nov 93 10:46:00 EST From: "Robert Reif" Subject: pfSegsIsectNode and bounding cylinders To: "info-performer" Status: OR I am having problems getting pfSegsIsectNode to work (it always returns 0) when using a bounding cylinder. I tried using pfCylAroundSegs and creating my own cylinder around my segments but neither works. Is there something else I need to do to get bounding cylinders to work? Robert Reif reif@ntsc-rd.navy.mil From aschaffe Thu Nov 18 18:00:18 1993 From: aschaffe (Allan Schaffer) Message-Id: <9311181800.ZM2427@holodeck.asd.sgi.com> Date: Thu, 18 Nov 1993 18:00:18 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer Subject: (Fwd) pfSegIsectX@!X - Beware Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O David accidentally mailed this to info-performer-request, the administrative address for the mailing list. Forwarding to info-performer ... Allan --- Forwarded mail from David Cooper I have just made the same mistake twice and wasted a few days when I could least afford it. Hopefully by discussing this now I'll stop someone else from doing the same. My problem was with the commands pfSegIsectNode and pfSegIsectGSet, if you will be using these in the near future read on..... These commands can appear similiar to the unwarey: functionally they are alike, the manual entries are almost identical, they take the same number of parameters , the parameters have the same names and definitions, BUT parameters 4 & 5 are REVERSED between the functions. The mode and mask fields switch around between the Node and GSet variations. Even worse, as these fields are just bitmasks the compiler will not flag the error, nor will the command when it is executed. All that will happen is that the command will work but not quite the in way expected, or even worse it will work correctly now but will stop working a few months from now when some other apparently unrelated change is made. My Case ------- I started off by using pfSegIsectNode but decided to switch to the GSet variation. A quick skim through the manual entry left me convinced that it was identical to the other except operating at a lower level, allowing more control. So I just copied the previous command changing the name and some of the parameters but NOT the order. It took me two days and a mail message to this mail board before I was told that my parameters were wrong. Such a stupid mistake made me feel very foolish and permanently ingrained the order into my memory. Yesterday I started using pfSegIsectNode again and again things did not work quite as expected. Imagine my surprise when I discoverd that I had the parameters wrong again. It was only then I read the manual entries closely, and discovered this subtle difference. Another day wasted ! SGI ---- How about a mention in the manual that points out this difference. I am sure that I am not the only one to have experienced this problem and it is very easy to do. David Cooper Division Ltd UK --- End of forwarded mail from David Cooper -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Sat Nov 20 12:43:22 1993 Message-Id: <9311202043.AA26324@surreal.asd.sgi.com> To: aschaffe (Allan Schaffer) Cc: info-performer Subject: Re: (Fwd) pfSegIsectX@!X - Beware In-Reply-To: Your message of "Thu, 18 Nov 93 18:00:18 PST." <9311181800.ZM2427@holodeck.asd.sgi.com> Date: Sat, 20 Nov 93 12:43:21 -0800 From: Jim Helman Status: OR This is the first I've heard of it, but yes, the argument order should have been the same. We try to be consistent in API names and arguments just for this reason. But I blew this one. The intersection API is cleaned up in the next release (1.2), fewer arguments altogether and none are type interchangable. Sorry for the wasted time. -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Jan 24 17:23:12 1994 Date: Mon, 24 Jan 94 17:24:29 -0800 From: goetzjr@gravy5.cs.nps.navy.mil (john goetz) Message-Id: <9401250124.AA18180@gravy5.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: SegIsect Status: OR I am having a problem with performing intersection testing with a pfPlane. Here is the segment of code where I setup the pfPlane and the pfSeg for intersection testing. When the program is executed I get a segmentation violation when pfSegIsectPlane is called. Can anyone please tell me what is wrong. I am running on a Iris 440/4D RE with Performer 1.0. Thank You ************************************************************************** pfPlane *grnd_plane; void main() { pfVec3 grnd_norm; pfVec3 grnd_pos; /* initialize Performer */ pfInit(); pfMultiprocess(PFMP_DEFAULT); pfConfig(); grnd_plane = (pfPlane*)pfMalloc(sizeof(pfPlane), NULL); pfSetVec3(grnd_norm, 0.0f, 0.0f, 1.0f); pfSetVec3(grnd_pos, 0.0f, 0.0f, 0.0f); pfMakeNormPtPlane(grnd_plane, grnd_norm, grnd_pos); pfOffsetPlane(grnd_plane, 0.0f); while (TRUE) { pfSync(); pfChanView(chan, view.xyz, view.hpr); pfFrame(); ground_contact(); } // end while(TRUE) }// end main() void ground_contact() { float *d; pfSeg *foot; foot = (pfSeg*)pfMalloc(sizeof(pfSeg), NULL); PFSET_VEC3(foot->pos, 0.0f, 0.0f, 10.0f); PFSET_VEC3(foot->dir, 0.0f, 0.0f, -1.0f); foot->length = 30.0f; if(pfSegIsectPlane(foot, grnd_plane, d) == PFIS_FALSE) printf("No ground intersection\n"); else printf("ground intersect height = %.3f\n", *d); } ************************************************************************** John Goetz goetzjr@cs.nps.navy.mil From guest Mon Jan 24 21:41:27 1994 Message-Id: <9401250541.AA28849@surreal.asd.sgi.com> To: goetzjr@gravy5.cs.nps.navy.mil (john goetz) Cc: info-performer@sgi.sgi.com Subject: Re: SegIsect In-Reply-To: Your message of "Mon, 24 Jan 94 17:24:29 PST." <9401250124.AA18180@gravy5.cs.nps.navy.mil> Date: Mon, 24 Jan 94 21:41:11 -0800 From: Jim Helman Status: O > float *d; > > ... /* w/no initialization of d */ > > if(pfSegIsectPlane(foot, grnd_plane, d) == PFIS_FALSE) > float d; if(pfSegIsectPlane(foot, grnd_plane, &d) == PFIS_FALSE) will work better. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 14 05:40:20 1994 Date: Tue, 14 Jun 94 15:38:44 +0300 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406141238.AA05524@fred.bvr.co.il> To: info-performer@sgi.sgi.com Subject: Seperate ISECT process Status: O Hi All, My application uses a seperate process for intersection calls. (pfMultiprocess(PFMP_FORK_ISECT)). My problem is the lack of a two-way path between the APP process and the ISECT process. Currently changes done, in the ISECT structure, in the APP process are passed down to isect_func() (the ISECT cb), but sadly enough it is not true the other way around. Is there a way to pass the altered ISECT structure back to the APP other than using some globally-defined shared data structure? Below are some relevant code lines from my application static void isect_func(void *userData) { IsectData *isect_data; isect_data = (IsectData *)userData; . . . } main() { . . . /* Initializing the ISECT cb */ pfIsectFunc(isect_func); isect_data = (IsectData *)pfAllocIsectData(sizeof(IsectData)); . . /* Main loop */ while (1) { . . . pfPassIsectData(); pfFrame(); } } Thanks Alon \________ \___ \_________ \__________ \___ \__________ \___ \___ \___ \___ \___ Alon J Rosenfeld \___ \___ \___ \___ \___ BVR Technologies Ltd. \__________ \___ \___ \_________ 1 Korazim st. Givatayim, Israel \__________ \___ \___ \_________ Tel: 972-3-571 5671 \___ \___ \__________ \___ \___ Fax: 972-3-571 5668 \___ \___ \________ \___ \___ Home: 972-3-683 6020 \___ \___ \______ \___ \___ Email: alon@bvr.co.il From guest Mon Jun 20 03:00:55 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406201259.ZM11921@rea1.bvr.co.il> Date: Mon, 20 Jun 1994 12:59:42 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Seperate ISECT process Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR To: info-performer@sgi.com Hi, A week ago I came up with a problem regarding the use of a separate isect process, but unfortunately I did not receive an answer. Therefore I am sending the message again in case it was never received. ***************************************************************************** My application uses a separate process for intersection calls. (pfMultiprocess(PFMP_FORK_ISECT)). It seems that Performer lacks a two-way path between the APP process and the ISECT process. Currently changes done in the ISECT structure, in the APP process, are passed down to the isect_func() (the ISECT cb), but sadly enough it is not true the other way around. Since isects are done in a separate process and they are quite lengthy in time, it may take the process some time to come up with a result (could even take a couple of frames). Therefore it is important that a two-way data path is available between the two processes to enable a hand-shaking mechanism. Well, could or should Performer support a two-way data path? Meanwhile, is the only solution is the use of a globally defined, pre pfConfig, structure? Below are some relevant code lines from my application static void isect_func(void *userData) { IsectData *isect_data; isect_data = (IsectData *)userData; . . . } main() { . . . /* Initializing the ISECT cb */ pfIsectFunc(isect_func); isect_data = (IsectData *)pfAllocIsectData(sizeof(IsectData)); . . /* Main loop */ while (1) { . . . pfPassIsectData(); pfFrame(); } } Thanks Alon From guest Tue Jun 21 11:42:50 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406211842.AA09399@tubes.asd.sgi.com> Subject: Re: Seperate ISECT process To: guest (Alon Rosenfeld 18 Hatzedef street Jaffa) Date: Tue, 21 Jun 94 11:42:37 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406201259.ZM11921@rea1.bvr.co.il>; from "Alon Rosenfeld 18 Hatzedef street Jaffa" at Jun 20, 94 12:59 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > > To: info-performer@sgi.com > > > Hi, > > A week ago I came up with a problem regarding the use of a separate isect > process, but unfortunately I did not receive an answer. Therefore I am sending > the message again in case it was never received. > > ***************************************************************************** > > My application uses a separate process for intersection calls. > (pfMultiprocess(PFMP_FORK_ISECT)). > > > It seems that Performer lacks a two-way path between the APP process > and the ISECT process. Currently changes done in the ISECT structure, > in the APP process, are passed down to the isect_func() (the ISECT cb), > but sadly enough it is not true the other way around. > > Since isects are done in a separate process and they are quite lengthy in time, > it may take the process some time to come up with a result (could even take a > couple of frames). Therefore it is important that a two-way data path is > available between the two processes to enable a hand-shaking mechanism. > > > Well, could or should Performer support a two-way data path? > Meanwhile, is the only solution is the use of a globally defined, pre pfConfig, > structure? Performer is conceptually structured as pipelines, either intersection or drawing, where data flows only downstream. The semantics of upstream data propagation are a bit sticky so we've left it up to the user. A pre-pfConfig-allocated chunk of shared memory or pfDataPool should work fine for APP/ISECT handshaking. From guest Wed May 25 17:39:33 1994 Date: Wed, 25 May 94 17:40:27 -0700 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9405260040.AA03087@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: pfSegsIsectNode Status: OR I am using Performer 1.0 for 4.0.5 on a SkyWriter--no RE. I am projecting a segment from the tip of my virtual finger and intersecting virtual objects with pfSegsIsectNode. This works fine. Now I would like to report the range of those objects from my finger. According to the manual, the pfIsect contains a pfSeg which should contain the length of the clipped intersecting pfSeg. I leave the discriminator callback NULL, so > the behavior is the same as if the discriminator > returned PFTRAV_CONT | PFTRAV_IS_CLIP_END, so that the intersection > nearest the start of the segment will be returned. However, the length of that pfSeg is always the full length of my original pfSeg. I need that clipped length. -------------------+------------------------------+------------------------ William Briggs | MailStop 262-2 | "The computer screen NASA Ames Research | PO Box 1000 | has become the retina (415) 604-6438 | Moffett Field, CA 94035-1000 | of the mind's eye." -------------------+------------------------------+------------------------ From guest Thu May 26 02:33:53 1994 Message-Id: <9405260648.AA07085@surreal.asd.sgi.com> To: stimpy@niesten.arc.nasa.gov (William Briggs) Cc: info-performer@sgi.sgi.com Subject: Re: pfSegsIsectNode In-Reply-To: Your message of "Wed, 25 May 94 17:40:27 PDT." <9405260040.AA03087@niesten.arc.nasa.gov> Date: Wed, 25 May 94 23:48:38 -0700 From: Jim Helman Status: O There is a bug in the libpfutil code for emulating the old 1.0/1.1 intersection API (pfuSegsIsectNode). The result is that end clipping is not enabled unless you specify a discriminator callback which does so. The fix is to add such a discriminator callback or change line 153 of libpfutil/isect.c: old: retVal = PFTRAV_CONT; new: retVal = PFTRAV_CONT|PFTRAV_IS_CLIP_END; However, that's not an issue here since you are using pfSegsIsectNode directly (as all new code should be). Perhaps you are looking at the request (i.e. the pfSegSet) rather than at the data returned in the pfHit. The pfSeg returned in the pfHit structure is is clipped, but the pfSegSet itself is read-only so the request can be static and reused. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Apr 29 06:55:43 1994 Message-Id: <199404291355.GAA25501@sgi.sgi.com> Date: 29 Apr 94 09:41:00 EST From: "Robert Reif" Subject: pfSegsIsectNode PFTRAV_IS_PATH problem To: "info-performer" Status: OR I just got Performer 1.2 and I am having problems with pfSegsIsectNode's traversal path mode flag PFTRAV_IS_PATH. With the PFTRAV_IS_PATH flag not ored into the mode, everything works fine. However when PFTRAV_IS_PATH is used, I can no longer get intersections with my moving models. The static portion of my scene works fine (I get an intersection with a valid path) but DCSs with cloned geometry below them no longer returns an intersection. Is there something else I need to do to get intersections with my moving models and also get the intersection traversal path? Thanks. Robert Reif reif@ntsc-rd.navy.mil