From guest Mon Jun 20 02:24:31 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406201223.ZM11761@rea1.bvr.co.il> Date: Mon, 20 Jun 1994 12:23:18 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfApplyTex Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi, My problem regards the calling of pfApplyTex(). After calling pfDraw() in my drawChannel cb, I draw some geometry involving texture. My code looks something like this: .... pfEnable(PFEN_TEXTURE); pfApplyTEnv(texenv); pfApplyTex(txt); .... draw geometry .... Sadly no texture appears on the geometry, gldebug confirms that neither tevbind nor texbind are called. However when calling pfPushState() just before the settings (and pfPopState() after drawing), makes all the difference. Now Performer draws the geometry using the desired texture (GLdebug.history recorded the calls to tevbind and texbind). One could argue and say that there was probably some overrides on the pfstate stack but calling pfGetOverride() yields no overrides. Well what is it that makes pfPushState() enable the texture calls? Thanks Alon From guest Tue Jun 21 11:47:04 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406211846.AA09416@tubes.asd.sgi.com> Subject: Re: pfApplyTex To: guest (Alon Rosenfeld 18 Hatzedef street Jaffa) Date: Tue, 21 Jun 94 11:46:54 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406201223.ZM11761@rea1.bvr.co.il>; from "Alon Rosenfeld 18 Hatzedef street Jaffa" at Jun 20, 94 12:23 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi, > > My problem regards the calling of pfApplyTex(). > > After calling pfDraw() in my drawChannel cb, I draw some geometry > involving texture. My code looks something like this: > > .... > pfEnable(PFEN_TEXTURE); > pfApplyTEnv(texenv); > pfApplyTex(txt); > > .... draw geometry .... > > Sadly no texture appears on the geometry, gldebug confirms that neither tevbind > nor texbind are called. However when calling pfPushState() just before the > settings (and pfPopState() after drawing), makes all the difference. Now > Performer draws the geometry using the desired texture (GLdebug.history > recorded the calls to tevbind and texbind). One could argue and say that there > was probably some overrides on the pfstate stack but calling pfGetOverride() > yields no overrides. > > Well what is it that makes pfPushState() enable the texture calls? > Darned if I know. Perhaps pfGetOverride is faulty. Are you overriding any texture state in other places? As an experiment, call pfFlushState instead of pfPush/PopState. From guest Thu Jun 16 01:40:28 1994 From: desmond@iss.nus.sg (Desmond Hii Toh Onn) Message-Id: <9406160846.AA12867@charon> Subject: TG_CONTOUR To: info-performer@sgi.sgi.com Date: Thu, 16 Jun 1994 01:46:25 -0800 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 277 Status: O Greetings, I've implemented texgen using the predraw and postdraw callbacks and it works pretty well for TG_SPHEREMAP So one day, I tried it with TG_CONTOUR and It doesn't look like it's working. Is there anything that i missed. The effect is like TG_LINEAR. thanks des' From guest Thu Jun 16 13:21:40 1994 From: "Chris Tanner" Message-Id: <9406161321.ZM1110@faith.asd.sgi.com> Date: Thu, 16 Jun 1994 13:21:08 -0700 In-Reply-To: desmond@iss.nus.sg (Desmond Hii Toh Onn) "TG_CONTOUR" (Jun 16, 1:46am) References: <9406160846.AA12867@charon> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: desmond@iss.nus.sg (Desmond Hii Toh Onn), info-performer@sgi.sgi.com Subject: Re: TG_CONTOUR Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Jun 16, 1:46am, Desmond Hii Toh Onn wrote: > Subject: TG_CONTOUR > Greetings, > I've implemented texgen using the predraw and postdraw > callbacks and it works pretty well for TG_SPHEREMAP > > So one day, I tried it with TG_CONTOUR and It doesn't look > like it's working. Is there anything that i missed. The effect > is like TG_LINEAR. > > thanks > > des' > > > > >-- End of excerpt from Desmond Hii Toh Onn I originally had the same problem when recently implementing callbacks to attenuate light points using texgen. The answer is that texgen uses the model viewing matrix when texgen is actually called verses the model view matrix when the geometry is draw to figure out the transforms necessary for TG_CONTOUR. Thus, because you attach the callbacks to the leaf nodes in performer, the model view matrix is always the same when you call texgen as when you draw the geometry. Thus the effect is that of TG_LINEAR. The workaround is quite simple, just load the model view matrix with the identity matrix before calling texgen then pop it afterwards. SO... example performer code: long pfuPreDrawContour(pfTraverser *trav, void *data) { (trav, trav); (data, data); mmode(MVIEWING); pushmatrix(); loadmatrix(IdentMat); texgen(TX_S, TG_CONTOUR, params2); texgen(TX_T, TG_CONTOUR, params3); texgen(TX_S, TG_ON, NULL); texgen(TX_T, TG_ON, NULL); popmatrix(); return NULL; } long pfuPostDrawContour(pfTraverser *trav, void *data) { (trav, trav); (data, data); texgen(TX_S, TG_OFF, NULL); texgen(TX_T, TG_OFF, NULL); return NULL; } -- _____________________________________________________________ Chris Tanner (cct@faith.asd.sgi.com) Silicon Graphics - Advanced Graphics Division _____________________________________________________________ From guest Wed Jun 15 12:24:54 1994 From: (Randy Hudson ("Better Living Through Mathematics")) Message-Id: <9406151426.ZM2647@eecs.uic.edu> Date: Wed, 15 Jun 1994 14:26:15 -0500 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Texture Mapping Cc: gokhale@mcs.anl.gov Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi. Our Performer application reads in several Inventor-format models and builds a scene hierarchy. The files do not, as far as we know, contain texture coordinates. Is it possible to texture map one or more of the models without knowing anything about their internal makeup (e.g., the geosets they may be built from)? Thanks. R. Hudson. -- Randy Hudson Electronic Visualization Lab hudson@eecs.uic.edu University of Illinois at Chicago (M/C 154) (312) 996-3002 851 S. Morgan, room 1120 SEO (312) 413-7585 FAX Chicago, IL 60607-7053 From guest Tue Mar 1 06:56:16 1994 Message-Id: <9403011455.ZM25234@unknown.zmail.host> Date: Tue, 1 Mar 1994 14:55:33 +0000 In-Reply-To: Bernd Froehlich "point in bounding volume test" (Mar 1, 3:37pm) References: <9403011337.AA07820@viswiz.gmd.de> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Hangup during pfswitch Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi I have a problem using Performer, which I hope someone will be able to explain. I have a pfswitch, which has two nodes, 0,1. When I switch on node 1 (node 0 being the default) the display hangs for up to 3 seconds, then it starts going again with the correct node switched in. Interestingly, the application process keeps going during the hangup. Indeed, printing the results of pfFrame, which appears to return the number of the rendered frame, then it returns as if the frames have been rendered. When I switch back to node 0 then there are no problems. Other aspects of this is that CPU usage seems to become very high during the hangup. I have a 4 150 MHZ cpu Onyx with VTX graphics. Does anyone have any explanations or advice? Thanks Richard Gallery From guest Tue Mar 1 09:20:59 1994 Date: Tue, 1 Mar 94 09:20:51 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9403011720.AA22801@tubes.asd.sgi.com> To: info-performer@sgi.sgi.com, Richard Gallery Subject: Re: Hangup during pfswitch References: <9403011337.AA07820@viswiz.gmd.de> Status: OR >I have a problem using Performer, which I >hope someone will be able to explain. I >have a pfswitch, which has two nodes, 0,1. >When I switch on node 1 (node 0 being the >default) the display hangs for up to 3 seconds, then >it starts going again with the correct node switched in. >Interestingly, the application process keeps >going during the hangup. Indeed, printing the results of pfFrame, >which appears to return the number of the rendered >frame, then it returns as if the frames have been >rendered. When I switch back to node 0 then there >are no problems. Other aspects of this is that CPU >usage seems to become very high during the hangup. >I have a 4 150 MHZ cpu Onyx with VTX graphics. Does >anyone have any explanations or advice? You might have switched in geometry which contains textures. The first time a texture is rendered it must be formatted by the GL which takes a long time. When multiprocessing (which is the default for your system) the application process is independent of the draw and will continue even if the draw completely stops. pfFrame's return value is the application processes' frame count, not the number of frames rendered. From guest Tue Mar 1 10:26:48 1994 From: "Michael Jones" Message-Id: <9403010952.ZM583@babar.asd.sgi.com> Date: Tue, 1 Mar 1994 09:52:43 -0800 In-Reply-To: jrohlf@tubes (John Rohlf) "Re: Hangup during pfswitch" (Mar 1, 9:20am) References: <9403011337.AA07820@viswiz.gmd.de> <9403011720.AA22801@tubes.asd.sgi.com> X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com, Richard Gallery Subject: Re: Hangup during pfswitch Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Mar 1, 9:20am, John Rohlf wrote: > Subject: Re: Hangup during pfswitch : :>I have a problem using Performer, which I :>hope someone will be able to explain. ... :You might have switched in geometry which contains textures. :The first time a texture is rendered it must be formatted by the GL which :takes a long time. When multiprocessing (which is the default for :your system) the application process is independent of the draw and :will continue even if the draw completely stops. pfFrame's return :value is the application processes' frame count, not the number of :frames rendered. If so, the way to resolve it is to download all the textures *before* you start your program. If you use the LoadFlight() function to read in your databases, then use GetSharedFltTexList() to get the textures. Otherwise you can write a simple traverser to do this yourself. Let me know if you want the code to do this. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jan 7 00:32:35 1994 From: "knut" Message-Id: <9401070905.ZM1944@knut.oslo.sgi.com> Date: Fri, 7 Jan 1994 09:05:58 +0100 X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: info-performer@sgi.sgi.com Subject: Questions RE> Performer Cc: knut@knut.oslo.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR I have a number of short questions. I'd be happy if someone could point me in the right directions on these matters.: HW : Onyx RE^2 SW : Performer 1.2a55, IRIX 5.1.1.2 1. Textures on polygon on another polygon ... ============================================= The scene is created using MultiGen. It seems like performer has some problems regarding rendring of "double polygons". As when you have a house wall with window on. These windows are texture mapped. If you move perpendicular with regards to the window performer tart flickering between draing the window and drawing the plain wall. If you have an angle it's ok. For me as an old gl programmer. It seems like performer has problems giving the window a correct z-buffer value. ( since it changes when you move your eye posision away from the polygons normal line) 2. Yello road line gets blurred ================================== We are using road textures to produce a good looking road with a yellow middle line. the problem is that these textures gets blurred in perfromer. They look ok in Multigen but not in Preformer. It seems like some information regarding how the texture is supposed to be mapped onto the polygon is lost when moving from multigen to Performer. 3. Intesity Alpha textures ============================== In multigen -- works ok (i.e. using the whole intensity range) In perfromer -- does not work correctly ( look ditherd ) 4. Textures sometimes vanishes for short while: ================================================ This is probably the strangest problem. If you drive a long a textured road. On certain spotsparts of the road dissappears. My customer has installed a MCO option aswell as a normal screen. If we run the application using MCO and three channels, the texure can dissappear in one of the cannels but not in the others. 5. Releases =========== Maybe problems 1-4 are bugs in Performer .... What is the current release of Performer ? When is a MR version of perforemer 1.2 ready ? If someone can take the time to read this an d help me I'd be "over-happy"!! Thanks and best regards Knut Ivar Foshaug -- ********************************************************************** | Knut Ivar Foshaug | Customer Support | | | Silicon Graphics AS | | | | Engebretsv.3 | knut@oslo.sgi.com | | | N-0275 OSLO | Phone: +47 22 73 20 15 | VoiceMail: 8930 | | Norway | Fax: +47 22 73 22 11 | Mail-Stop: NO-335 | ********************************************************************** From guest Fri Jan 7 13:03:23 1994 Message-Id: <9401072103.AA14558@surreal.asd.sgi.com> To: "knut" Cc: info-performer@sgi.sgi.com Subject: Re: Questions RE> Performer In-Reply-To: Your message of "Fri, 07 Jan 94 09:05:58 +0100." <9401070905.ZM1944@knut.oslo.sgi.com> Date: Fri, 07 Jan 94 13:03:01 -0800 From: Jim Helman Status: OR | | 1. Textures on polygon on another polygon ... | ============================================= | The scene is created using MultiGen. It seems like performer has some | problems regarding rendring of "double polygons". As when you have a house | wall with window on. These windows are texture mapped. | | If you move perpendicular with regards to the window performer tart | flickering between draing the window and drawing the plain wall. | | If you have an angle it's ok. | | For me as an old gl programmer. It seems like performer has problems | giving the window a correct z-buffer value. ( since it changes when you | move your eye posision away from the polygons normal line) You can handle nearly-co-planar polygons with a Z-offset in the model, but will probably run into z-buffer resolution problems at large ranges. Performer supports pfLayer for defining a base polygon and a set of decals to be rendered on top of it. 1.0/1.1 uses stencil for this (render base polygons setting stencil, render decal polygon testing for stencil). This does a perfect job, but stenciling significantly reduces pixel-fill rates both for the base and decal polygons. So 1.2 adds layering based on displacepolygon. This is a lot faster, but can cause artifacts. If you model using "subfaces" in Multigen, the LoadFlt() should convert them to pfLayer's for rendering. | 2. Yello road line gets blurred | ================================== | We are using road textures to produce a good looking road with a yellow | middle line. | | the problem is that these textures gets blurred in perfromer. They look ok | in Multigen but not in Preformer. | | It seems like some information regarding how the texture is supposed to be | mapped onto the polygon is lost when moving from multigen to Performer. You are seeing mipmapping in action. To avoid aliasing and texture scintillation, the graphics hardware selects a subsampled version of the texture based on the sizez relationship between screen pixels and texels projected onto the screen. Mipmapping subsamples by a factor of two in *both* u and v. When you view a square texture very obliquely, as when looking down a road, the graphics hardware has to choose whether to go to a fuzzy version of the image because the texels are densely squished (minified) onto the screen along the road or use a sharp version based on the spread out texels across the road. Since the latter would cause scintallation along the road, the hardware does the former and selects the fuzzier copy. If the road is mainly viewed along it, as when driving. The solution is to make the aspect ratio of the texture image match the *typical* aspect ratio it has when projected onto the screen, e.g. make the texture image 512 pixels wide (across the road) but only 64 pixels long (along the road). This will look great along the road, but fuzzy when the road is viewed perpendicularly. This is how the Performer town/village demos handle the issue. | 3. Intesity Alpha textures | ============================== | In multigen -- works ok (i.e. using the whole intensity range) | | In perfromer -- does not work correctly ( look ditherd ) You are not seeing dithering, but color quantization. For full speed texturing, Performer uses 16bit texels. RGB textures: (R,G,B) (5bits, 6bits, 5bits) RGBA textures: (R,G,B,A) (4bits, 4bits, 4bits, 4bits) If you call pfTexFormat(tex, PFTEX_INTERNAL_FORMAT, TX_RGBA8), you'll get 32bit texels, but pixel-fill will run at half speed for those textures. | 4. Textures sometimes vanishes for short while: | ================================================ | This is probably the strangest problem. If you drive a long a textured | road. On certain spotsparts of the road dissappears. | | My customer has installed a MCO option aswell as a normal screen. If we | run the application using MCO and three channels, the texure can | dissappear in one of the cannels but not in the others. Strange. Maybe someone else has an idea. | 5. Releases | =========== | | Maybe problems 1-4 are bugs in Performer .... 1-3 are not. Don't know about 4. | What is the current release of Performer ? 1.1 for 5.X and 1.0 for 4.0.5. From guest Mon Jan 10 10:56:53 1994 Date: Mon, 10 Jan 94 10:55:28 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401101855.AA10163@tubes.asd.sgi.com> To: Jim Helman , "knut" Subject: Re: Questions RE> Performer Cc: info-performer@sgi.sgi.com Status: OR >| 3. Intesity Alpha textures >| ============================== >| In multigen -- works ok (i.e. using the whole intensity range) >| >| In perfromer -- does not work correctly ( look ditherd ) > >You are not seeing dithering, but color quantization. >For full speed texturing, Performer uses 16bit texels. > > RGB textures: (R,G,B) (5bits, 6bits, 5bits) > RGBA textures: (R,G,B,A) (4bits, 4bits, 4bits, 4bits) > >If you call pfTexFormat(tex, PFTEX_INTERNAL_FORMAT, TX_RGBA8), >you'll get 32bit texels, but pixel-fill will run at half speed >for those textures. The "dithered" look may be a result of using screen-door transparency which Performer uses on multisample-capable Onyxes. In this case you will only get a maximum of 16 transparency levels rather than 256 but performance will be much better. If you want smooth transparency you have to use the PFTR_HIGH_QUALITY token. >| 4. Textures sometimes vanishes for short while: >| ================================================ >| This is probably the strangest problem. If you drive a long a textured >| road. On certain spotsparts of the road dissappears. >| >| My customer has installed a MCO option aswell as a normal screen. If we >| run the application using MCO and three channels, the texure can >| dissappear in one of the cannels but not in the others. > >Strange. Maybe someone else has an idea. An older IRIX release had a bug where a specific mipmap level would drop out. What release are you running? From guest Mon Jan 10 17:35:25 1994 From: "Wade Olsen" Message-Id: <9401101735.ZM16738@fnord.asd.sgi.com> Date: Mon, 10 Jan 1994 17:35:18 -0800 In-Reply-To: jrohlf@tubes (John Rohlf) "Re: Questions RE> Performer" (Jan 10, 10:55am) References: <9401101855.AA10163@tubes.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Questions RE> Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Jan 10, 10:55am, John Rohlf wrote: > Subject: Re: Questions RE> Performer > > > >| 4. Textures sometimes vanishes for short while: > >| ================================================ > >| This is probably the strangest problem. If you drive a long a textured > >| road. On certain spotsparts of the road dissappears. > >| > >| My customer has installed a MCO option aswell as a normal screen. If we > >| run the application using MCO and three channels, the texure can > >| dissappear in one of the cannels but not in the others. > > > >Strange. Maybe someone else has an idea. > > An older IRIX release had a bug where a specific mipmap level would > drop out. What release are you running? >-- End of excerpt from John Rohlf First you say the texture disappears but later you say "parts of the road" disappear. Now if you mean the latter, is it possible the bounding boxes of the road are incorrect and therefore culled out? Are the roads procedurally generated? I don't remember what version of performer you are using but I seem to recall some perf1.0 bug about culling multiple levels of DCS's. I'm not sure though. Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Thu Jun 16 01:30:08 1994 Date: Thu, 16 Jun 94 09:54:29 +0100 From: arnaud@thomson-dsi.fr (AST ) Message-Id: <9406160854.AA23933@thodsic.cergy.thomson-dsi.fr> To: info-performer@sgi.sgi.com Subject: Textured geosets in multiple windows Status: OR I seem unable to draw one textured geoset in 2 separate windows created by winopen. The call to pfDrawGSet in the 1st window gives a correct result, but I get no texture in the 2nd window. Any ideas ? Here is one simple code that reproduces this bug: void main( int argc, char *argv[] ) { pfGeoSet *gset; pfGeoState *gset_state; pfTexture *tex; pfTexEnv *tex_env; /* ---------------------------- Initialization of Performer ---------------------------- */ pfInit(); arena = pfGetSharedArena(); /* ----------------------- Creation of one geoset ----------------------- */ gset = build_gset(); pfInitState(NULL); pfNewState(); gset_state = pfNewGState(arena); pfGStateMode(gset_state, PFSTATE_ENTEXTURE, PFTR_ON); /* -------------------------------------------- Creation of one pfTexture and one pfTexEnv -------------------------------------------- */ tex = pfNewTex(arena); tex_env = pfNewTEnv(arena); pfLoadTexFile(tex, "image.rgb"); pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex); pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex_env); /* ------------------------------------ Creation of 2 windows with winopen ------------------------------------ */ init_windows(); /* ------------------------------------ Drawing of geoset in first window --> correctly textured ------------------------------------ */ winset(wid1); pfApplyTEnv(tex_env); pfApplyTex(tex); pfEnable(PFEN_TEXTURE); pfDrawGSet(gset); sleep(1); /* ------------------------------------ Drawing of geoset in second window --> no texture !? ------------------------------------ */ winset(wid2); pfApplyTEnv(tex_env); pfApplyTex(tex); pfEnable(PFEN_TEXTURE); pfDrawGSet(gset); sleep(10); } From guest Thu Jun 16 02:32:34 1994 From: "Sharon Fischler" Message-Id: <9406160230.ZM11111@rose.asd.sgi.com> Date: Thu, 16 Jun 1994 02:30:58 -0700 In-Reply-To: arnaud@thomson-dsi.fr (AST ) "Textured geosets in multiple windows" (Jun 16, 9:54am) References: <9406160854.AA23933@thodsic.cergy.thomson-dsi.fr> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: arnaud@thomson-dsi.fr (AST ), info-performer@sgi.sgi.com Subject: Re: Textured geosets in multiple windows Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR +>---- On Jun 16, 9:54am, AST wrote: > Subject: Textured geosets in multiple windows -> ->I seem unable to draw one textured geoset in 2 separate windows created by winopen. The call to ->pfDrawGSet in the 1st window gives a correct result, but I get no texture in the 2nd window. ->Any ideas ? No problem. You simply need a separate pfState for each window and select corresponding state for the current window (pfSelectState). A full working test program (adapted from your test case) is included below. -> ->Here is one simple code that reproduces this bug: FYI: your test case also did have one bad typo: -> pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex); -> pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex_env); ^^^^^^^^^^^^^^ should be PFSTATE_TEXENV #include "Performer/pr.h" pfVec3 coords[] ={ {-1.0f, -1.0f, -5.0f }, { 1.0f, -1.0f, -5.0f }, { 1.0f, 1.0f, -5.0f }, {-1.0f, 1.0f, -5.0f } }; pfVec4 colors[] ={ {1.0f, 1.0f, 1.0f, 1.0f}, {0.0f, 0.0f, 1.0f, 1.0f}, {1.0f, 0.0f, 0.0f, 1.0f}, {0.0f, 1.0f, 0.0f, 1.0f} }; pfVec2 texcoords[]={ {0.0f, 0.0f}, {1.0f, 0.0f}, {1.0f, 1.0f}, {0.0f, 1.0f} }; long Wid1, Wid2; static void init_windows(void); static pfGeoSet *build_gset(void); long main( int argc, char *argv[] ) { pfGeoSet *gset; pfGeoState *gset_state; pfTexture *tex; pfTexEnv *tex_env; pfState *s1, *s2; /* ---------------------------- Initialization of Performer ---------------------------- */ pfInitState(NULL); s1 = pfNewState(); s2 = pfNewState(); /* ----------------------- Creation of one geoset ----------------------- */ gset = build_gset(); gset_state = pfNewGState(NULL); pfGSetGState (gset, gset_state); pfGStateMode(gset_state, PFSTATE_ENTEXTURE, PFTR_ON); /* -------------------------------------------- Creation of one pfTexture and one pfTexEnv -------------------------------------------- */ tex = pfNewTex(NULL); tex_env = pfNewTEnv(NULL); pfLoadTexFile(tex, "brick.rgba"); pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex); pfGStateAttr(gset_state, PFSTATE_TEXENV, tex_env); /* ------------------------------------ Creation of 2 windows with winopen ------------------------------------ */ init_windows(); winset(Wid1); pfSelectState(s1); pfDrawGSet(gset); sleep(1); winset(Wid2); pfSelectState(s2); pfDrawGSet(gset); sleep(10); return 0; } static void init_windows(void) { long xs, ys; foreground(); prefposition(0, 400, 0, 400); Wid1 = winopen("Performer cubes"); RGBmode(); gconfig(); mmode(MVIEWING); lsetdepth(getgdesc(GD_ZMIN), getgdesc(GD_ZMAX)); subpixel(TRUE); backface(FALSE); getsize(&xs, &ys); ortho(-1, 1, -1, 1, 1, 10); prefposition(0, 400, 400, 800); foreground(); Wid2 = winopen("Performer cubes"); RGBmode(); gconfig(); mmode(MVIEWING); lsetdepth(getgdesc(GD_ZMIN), getgdesc(GD_ZMAX)); subpixel(TRUE); backface(FALSE); getsize(&xs, &ys); ortho(-1, 1, -1, 1, 1, 10); } pfGeoSet* build_gset(void) { pfGeoSet *gset; gset = pfNewGSet(NULL); pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL); pfGSetAttr(gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, texcoords, NULL); pfGSetAttr(gset, PFGS_COLOR4, PFGS_PER_VERTEX, colors, NULL); pfGSetPrimType(gset, PFGS_QUADS); pfGSetNumPrims(gset, 1); return gset; } -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Mon Jun 27 08:27:14 1994 Message-Id: <9406271526.AA18350@wb.com> Date: 27 Jun 1994 11:28:04 U From: "Weiblen, Mike" Subject: Massive Texture To: "Pf Mail List" Status: OR I realize this isn't strictly a Performer question, but I am using Performer to load the textures... =============================================================================== I'm doing stress experiments to determine what limits the amount of texture I can load into RAM. The system I'm experimenting with is a 4-proc ONYX, 512MB RAM, 2 RM5s. My tests consist of loading many of our hi-res NELLIS geospecific photo textured terrain tiles (3.7MB of texture memory each). My initial experiments ended with "ERROR #2 texdef2d: ERR_OUTMEM" after Performer pfuDownloadTexList() reports ~114MB of texture loaded. I then set my filesize, datasize, stacksize, memoryuse and vmemoryuse limits to "unlimited". I watch the memory consumption with gr_osview and Performer's output as the RMs texdef() and page out the textures. gr_osview's memory bargraph goes up to 128M of some unspecified unit (words?). When it gets to ~122M, I see disk activity which bumps it down to ~118M. At the time of the first disk swap, pfuDownloadTexList() is reporting about 250MB texture loaded. Paging from the RM to RAM is bad enough, but swapping to disk is a real killer, and I'm looking for what kind of control I have over the texture swap threshold. Is there a manifest limit on the total RAM texture capacity? It has been difficult for me to get time on our 1500MB ONYX to test if the limit is a percentage of total mem. The bottom line: On the big ONYX, will it be possible for me to load our entire hi-res NELLIS database (total 525 MB of texture) without swapping textures to disk? -- mew From guest Mon Jun 27 19:19:44 1994 Message-Id: <9406280219.AA13885@surreal.asd.sgi.com> To: "Weiblen, Mike" Cc: "Pf Mail List" Subject: Re: Massive Texture In-Reply-To: Your message of "27 Jun 94 11:28:04 +0800." <9406271526.AA18350@wb.com> Date: Mon, 27 Jun 94 19:19:34 -0700 From: Jim Helman Status: O > At the time of the first disk swap, pfuDownloadTexList() > is reporting about 250MB texture loaded. Keep in mind that there can be up to three copies of a texture: 1) The image array that you handed Performer with pfTexImage() or the array allocated within pfLoadTexFile(). Unless you plan on changing texture attributes after the texture has been defined, you don't need this image at run time. To free the storage call pfFreeTexImage() after the texture has been used the first time (so you're sure it has been GL texdef'd.) This is in external format, typically 8 bits per component. 2) The image array inside GL on the host that GL uses to page down to the graphics pipe when needed. This is in internal format, 16bits per texel by default (e.g. RGB_5), and is necessary. 3) The copy (sometimes) down in the graphics hardware. If pfuDownLoadTexList() was reporting 250MB of texture loaded, that means there should be 250MB inside GL. Unless you have called pfuFreeTexImage, Performer has another 250MB to 500MB (depending on whether the internal and external formats have the same number of bytes per texel). 250MB is a LOT of texture. If you plan to do real-time paging of these textures through the 4-16MB of RM memory, you may run into some performance problems when GL deals with a large number of textures ids. If the textures are not mipmapped, you might look at using subtexload or tx_nocopy to reuse Performer (and hence GL) texture IDs. If the textures are mipmapped, you might look at combining several small textures that are used together onto larger single textures to reduce the number of GL texture IDs to a few hundred. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 28 01:44:51 1994 From: "Harald Kaul" Message-Id: <9406281043.ZM1007@harald.munich.sgi.com> Date: Tue, 28 Jun 1994 10:43:58 -0600 In-Reply-To: "Weiblen, Mike" "Massive Texture" (Jun 27, 11:28am) References: <9406271526.AA18350@wb.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Weiblen, Mike" , "Pf Mail List" Subject: Re: Massive Texture Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 27, 11:28am, Weiblen, Mike wrote: > Subject: Massive Texture > I realize this isn't strictly a Performer question, but I am using Performer to > load the textures... > > =============================================================================== > gr_osview's memory bargraph goes up to 128M of some unspecified unit (words?). > When it gets to ~122M, I see disk activity which bumps it down to ~118M. At > the time of the first disk swap, pfuDownloadTexList() is reporting about 250MB > texture loaded. > > Paging from the RM to RAM is bad enough, but swapping to disk is a real killer, > and I'm looking for what kind of control I have over the texture swap > threshold. > > Is there a manifest limit on the total RAM texture capacity? It has been > difficult for me to get time on our 1500MB ONYX to test if the limit is a > percentage of total mem. The bottom line: On the big ONYX, will it be > possible for me to load our entire hi-res NELLIS database (total 525 MB of > texture) without swapping textures to disk? > > -- mew > > >-- End of excerpt from Weiblen, Mike in addition to Jim's comments: the memory bargraph uses pages as unit, I don't think it says 118M but 118k, this is 118k * 4k = 472 MB, ==> you are reaching the limit of the memory of your "small" system. Jim pointed out why you needed such much memory. -Harald -- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ Harald Kaul @ @ SiliconGraphics GmbH @ @ D-85630 Grasbrunn-Neukeferloh @ @ Mail Stop IMU-315 @ @ Tel.: (+int) 89/46108-123 @ @ FAX: -222 @ @ VM: #59195 @ @ E-Mail: @ @ haraldk@munich.sgi.com @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ From guest Tue Jun 28 00:16:31 1994 Date: Tue, 28 Jun 94 00:20:01 -0700 From: Stephen Lau Message-Id: <9406280720.AA04689@Crazypete.AI.SRI.COM> To: info-performer@sgi.sgi.com, "Weiblen, Mike" Subject: Re: Massive Textures Status: OR Mike, I routinely page gigabytes of textures in and out of texture map memory on a 4 proc Onyx with RM4 boards, i.e. 4 MB of texture map memory. In the application I'm developing, textures are being read across a high speed network and paged into texture map memory as needed and paged out of texture map memory when no longer visible to the user. What you need to do is handle the paging yourself, if you let the GL try to page it, you'll have real poor performance. If you know the extent of the textures at runtime you can use subtexload() to specify what part of a very large texture you are about to load. In my case, the textures are being delivered across an unreliable high speed network, so what I do is treat texture map memory as about 110 128x128 16 bit textures. The number doesn't add up to exactly 4MB, since I keep some static textures around for clouds and buildings. I use TX_FASTDEFINE when I do a texdef2d() and keep track of which texture is associated to which "slot" in the 100 texture maps available. When I want to swap out a texture in a particular slot, since it is no longer visible or for whatever reason, I use TX_TEXTURE_IDLE with texture id "n", where "n" corresponds to the number of the texture that I want to toss out. This works real well and I've paged in and out of texture map memory gigabytes of textures. The end user perceives it as a very large area they can "roam" around in both in 2D and 3D. Hope this helps. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "If there's nothing wrong with me, SRI International | there must be something wrong 333 Ravenswood Ave., Menlo Park, CA. 94025| with the universe!" (415) 859-2925 (415) 326-6200| - Beverly Crusher, Star Trek:TNG ------------------------------------------------------------------------------- From guest Tue Jun 28 11:20:26 1994 Message-Id: <9406281820.AA26597@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com, "Weiblen, Mike" , Stephen Lau Subject: Re: Massive Textures In-Reply-To: Your message of "Tue, 28 Jun 94 00:20:01 PDT." <9406280720.AA04689@Crazypete.AI.SRI.COM> Date: Tue, 28 Jun 94 11:20:10 -0700 From: Jim Helman Status: O A couple more bits of info. Currently subtexload and fast define only work for non-mipmapped textures. Better things are coming with OpenGL. When you're using idling textures (TX_TEXTURE_IDLE) and then pfApplying or texbinding new ones to page them down to the graphics pipe, keep in mind that texture memory fragmentation can occuar. To completely avoid fragmentation, you need to keep all your pagable textures the same size and type. And if you're making a major scene transition in your database (e.g. a VR portal), you can reduce potential fragmentation by idling the whole set of old textures before starting to bind/apply the new ones. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 28 13:03:00 1994 Date: Tue, 28 Jun 94 13:06:28 -0700 From: Stephen Lau Message-Id: <9406282006.AA07453@Crazypete.AI.SRI.COM> To: info-performer@sgi.sgi.com, Jim Helman Subject: Re: Massive Textures Status: O Yeah, texture fragmentation was a problem that I noticed after doing some timing tests. All of my textures are the same size and type, 128x128. Too bad there isn't any more hooks into the GL to examine and manage texture map memory. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "If there's nothing wrong with me, SRI International | there must be something wrong 333 Ravenswood Ave., Menlo Park, CA. 94025| with the universe!" (415) 859-2925 (415) 326-6200| - Beverly Crusher, Star Trek:TNG ------------------------------------------------------------------------------- From guest Tue Jun 28 13:19:12 1994 Message-Id: <9406282017.AA26821@surreal.asd.sgi.com> To: Stephen Lau Cc: info-performer@sgi.sgi.com Subject: Re: Massive Textures In-Reply-To: Your message of "Tue, 28 Jun 94 13:06:28 PDT." <9406282006.AA07453@Crazypete.AI.SRI.COM> Date: Tue, 28 Jun 94 13:17:30 -0700 From: Jim Helman Status: O > All of my textures are the same size and type, 128x128. > Too bad there isn't any more hooks into the GL to examine > and manage texture map memory. With OpenGL, it's less problematic to eliminate fragmentation in this way, since you can define your own mipmaps. This means that you can make all of your pagable textures the same size (say 256x256) and then combine multiple images into a single texture (say 4 128x128's into a 256x256) without worrying about the "mixing" of adjacent images that occurs in the automatically generated Iris GL mipmaps. Does anyone have texture paging/fragmentation issues that could not be addressed in this way? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Jun 29 04:54:15 1994 Date: Wed, 29 Jun 94 13:54:06 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9406291154.AA24765@scl> To: info-performer@sgi.sgi.com Subject: Environment mapping ... Status: OR Bonjour a tous ... I'm using environment mapping with 1.2 version and I'd like to find the binary and/or source code which allows to transform a standard map image to a spherical one as in the buttonfly envmap demos ... does any one knows anything about where to find this ? ... Merci a tous ... Thank's to everybody ... Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Thu Apr 14 10:21:13 1994 From: Mark Coyle Subject: Texture performance To: info-performer@sgi.sgi.com Message-Id: <9404141720.AA26611@dexter.psych.umn.edu> X-Mailer: ELM [version 2.4 PL6] Content-Type: text Content-Transfer-Encoding: 7BIT Content-Length: 2229 Status: OR I am trying to get as much performance out of our (ancient) SGI, and I would appreciate any help I could get. The specifics: Hardware: SGI 310 VGXT 64 Meg Memory 1 Processor Application: I'm lucky in that the entire animation is controlled by me, with no user input to control the scene. Other than the texture, which I will get to in a moment, the only objects in the world is a road, very basic, non-textured and not a performance problem. There are 4 other objects, each of which represents road signs. They will be placed at about 1/4 mile intervals along the road (basically, you can only see one of them at a time). These signs are texture mapped using Designers Work Bench and saved as .flt files. The texture is put on in the DWB application, so I do no explicit texture calls in my application program. The animation simply goes along the x coordinate at a designated speed, for example 30 MPH, towards the signs. My frame requirements aren't all that great, I could live with 15 frames/sec, but not much lower than that. The problem: I start out fine, going along towards sign # 1 at about 15 frames/second. Once I pass sign # 1, and sign # 2 comes into view, I can get only 7-12 frames/second. This is the same for the sign #2 and #3 boundries as well, i.e. the effect is not cummulative in lowering my frame rate. What I have done and what I know: If I make sign#2 the same as sign # 1 (by just loading the same file 2X), I do NOT get the performance degradation. I have done some profiling of the code, and it seems that when the frame rate is low, both the CPU usage by sys and GFX (finowt) are much higher. Also, my CPU usage during those times jumps way up, from about 20% to 80%. SInce I know exactly what movement will happen, I have set my scene up so that only the current sign is under the scene root. Once I pass it, I remove and delete that child, and add the new sign to the scene. This has some positive effects, but not much. Am I doing somthing that I shouldn't? Or is there somthing I could do that I'm not? I'd like to think I could get at least 15 frames/sec out of this application. Any ideas? Thanks Mark Coyle HFRL Computer Science Department U of Minnesota From guest Thu Apr 14 10:56:10 1994 Date: Thu, 14 Apr 94 10:52:29 -0700 From: mars@clubted.csd.sgi.com (David Marsland) Message-Id: <9404141752.AA29627@clubted.csd.sgi.com> To: Mark Coyle , info-performer@sgi.sgi.com Subject: Re: Texture performance Status: OR Just a guess, but it sounds like you're overflowing the texture memory and swapping to main memory when you load the second sign texture. Have you tried using a lower resolution texture? On a VGXT 128x128 is a good texture size. Here's an old table, posssibly outdated, of texture memory size: Also, using a non-mipmapped minification filter may help load bigger textures. > 1) Does the execution time of texdef2d vary with the size of the > image array passed to it? Yes. the GL makes a copy of the texture in the format the hardware actually uses. That copy is also used for re-loading texture memory if necessary during context switching (VGX,VGX/T). The bigger the texture, the longer it takes to process it. Here is a table that indicates how many textures of what size can fit in VGX, VGX/T. ------- Here is a summary of the texture memory on 5 and 10 span VGX and VGXT with some notes on how the texture memory is managed differently on VGX and VGXT. Some I conclusions reached are: - VGXT uses texture memory much more efficiently - since textures sizes are rounded up to the next multiple of 32, fewer textures can fit than is possible. e.g. a 5-span VGXT can really store 3 128 x 128 MIPMAP textures instead of 2 and there probably are other shoehorn cases for the real-life 10-span VGXT. airey says we can fix the 32-texel chunksize but the hassle factor and performance issues are not yet clear. - 5 span has 64K texels texel == 32 bits - 10 span has 64K + 32K + 64K(acbuf) texels - VGX textures cannot span bank boundaries - VGXT textures can span bank boundaries - VGX textures need borders for wrapping so size is (size+2)*(size+2) - 1-component takes same amount of space as 4-component - MIPMAP size is floor(size * 4/3) - all textures not multiples of 32 are rounded up to next multiple of 32 since gl sends textures down in 32 texel chunks VGX: Spans(texels) Spans(texels) texture size not MIPMAP 5(64) 10(160) MIPMAP 5(64) 10(160) ------------------------------------------------------------------------------- 16 x 16 352 186 465 512 128 320 32 x 32 1184 = 1.16K 55 137 1664 = 1.62K 39 97 64 x 64 4384 = 4.28K 14 35 6016 = 5.88K 10 25 128 x 128 16928 = 16.53K 3 7 22912 = 22.38K 2 5 256 x 256 66592 = 65.03K 1* 2* 89472 = 87.38K 0 0 512 x 512 264224 = 258.03K 0 0 353664 = 345.37K 0 0 *special ucode allows non-mipmapped 256 x 256 textures to work on VGX. VGXT: Spans(texels) Spans(texels) texture size not MIPMAP 5(64) 10(160) MIPMAP 5(64) 10(160) ------------------------------------------------------------------------------ 16 x 16 256 256 640 352 186 465 32 x 32 1K 64 160 1376 = 1.34K 47 119 64 x 64 4K 16 40 5472 = 5.34K 11 29 128 x 128 16K 4 10 21856 = 21.34K 2 7 256 x 256 64K 1 2 87392 = 85.34K 0 1 512 x 512 256K 0 0 349536 = 341.34K 0 0 > 2) What is the optimum size for MIP mapped bilinearly interpolated > texture maps for > a) VGX > b) VGX/T > c) Indigo Starter > d) Elan See the table. /* David Marsland "On Spaceship Earth * * MTS, Worldwide Education R&D there are no passengers, * * Silicon Graphics Computer Systems only crew." * * Internet: mars@csd.sgi.com Buckminster Fuller */ From guest Tue Mar 22 09:25:48 1994 Date: Tue, 22 Mar 94 17:25:30 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9403221725.AA10007@death.reading.sgi.com> To: info-performer Subject: Detail Texture Status: OR I can't work out how to get a nice detail texture into my scene. I would much rather do it through the libpfflt loader but I have a feeling that it does not allow me to control my "pfTexSpline" Does anyone know if I have fine control of detail texture directly through MultiGen and Loadflt ? I can set all the TX_CONTROL point values in the .attr files but it seems to have no effect on the scene. ANgus "Imagine your witty quote here" From guest Fri May 27 03:10:18 1994 From: hodeckes@VNET.IBM.COM Message-Id: <199405271010.DAA05745@sgi.sgi.com> Date: Fri, 27 May 94 06:09:31 EDT To: info-performer@sgi.sgi.com Subject: Textures Status: OR Here are a few questions I have specific to Performer's texturing and coplanar polygons. I am running with the Performer Version 1.2 1. How can I find out how much Texture Memory is being used and how much is still available, under program control. 2. How can I get a Texture to reflect changes to the image array specified in the pfTexImage function call in real-time? I have not been successful getting the Texture to change after its initial creation, even though the image array has changed. 3. Finally, I am seeing coplanar flashing of polygons in the ocean of a terrain database. The swapping seems to be ocurring between the polygons of the ocean and the Performer earth model. Is this possible? Thanks, Steve Hodecker Loral Federal Systems hodeckes@lfs.loral.com From guest Sun Feb 27 20:23:50 1994 From: fraser@BanffCentre.AB.CA (Glen Fraser) Message-Id: <9402280412.AA19045@moose.BanffCentre.AB.CA> Subject: Texture matrix transformations To: info-performer@sgi.sgi.com Date: Sun, 27 Feb 1994 21:12:38 -0700 (MST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 657 Status: OR I am trying to apply textures using different texture transformation matrices. Is there some way I can link the texture transformation matrix to the pfGeoState, so that the MTEXTURE matrix is modified automatically on a per-texture basis? Thanks, Glen. ------------------------------------------------------------------ | Glen D. Fraser | fraser@banffcentre.ab.ca | | Work: (403)762-6669 | | | Virtual Reality Developer | "Let it well be known, | | The Banff Centre for the Arts | These opinions are my own." | ------------------------------------------------------------------ From guest Sun Feb 27 23:39:12 1994 Message-Id: <9402280738.AA16587@surreal.asd.sgi.com> To: fraser@banffcentre.ab.ca (Glen Fraser) Cc: info-performer@sgi.sgi.com Subject: Re: Texture matrix transformations In-Reply-To: Your message of "Sun, 27 Feb 94 21:12:38 MST." <9402280412.AA19045@moose.BanffCentre.AB.CA> Date: Sun, 27 Feb 94 23:38:50 -0800 From: Jim Helman Status: O I am trying to apply textures using different texture transformation matrices. Is there some way I can link the texture transformation matrix to the pfGeoState, so that the MTEXTURE matrix is modified automatically on a per-texture basis? Nope. You'll need to use a pre-draw callbacks on the pfGeodes to change the texture matrix for the included pfGeoSets (best to restore the matrix in the pfGeode's post-draw callback). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151