Returned mail: Host unknown (Name server: darkstar.diginext.fr: host not found)

New Message Reply Date view Thread view Subject view Author view

Mail Delivery Subsystem (MAILER-DAEMON++at++relay-smtp.imaginet.net)
Mon, 8 Mar 1999 07:37:35 +0100 (MET)


The original message was received at Mon, 8 Mar 1999 07:37:35 +0100 (MET)
from sophocle.imaginet.fr [195.68.0.10]

   ----- The following addresses had permanent fatal errors -----
<diginext++at++darkstar.diginext.fr>

   ----- Transcript of session follows -----
550 <diginext++at++darkstar.diginext.fr>... Host unknown (Name server: darkstar.diginext.fr: host not found)


attached mail follows:


Date: Sat Mar 6 02:00:05 PST 1999
From: info-performer++at++sgi.com (info-performer Mailing List)
To: allan++at++holodeck.engr.sgi.com
Subject: info-performer Mar 05 1999
List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
    Send Submissions to: info-performer++at++sgi.com
    Add/Remove requests: info-performer-request++at++sgi.com

Message Subjects:

    performance on lock phase.
    Re: performance on lock phase.
    Re: PBuffer on Onyx2 Reality
    buffer requirment for glPolygonOffsetEXT
    Re: performance on lock phase.
    Re: performance on lock phase.
    Re: saving rgb files (pfuSaveImage)
    Ask for help!
    Re: Ask for help!
    Re: buffer requirment for glPolygonOffsetEXT
    3ds Loading with pthread and Rgba from PC

******************************************************************************

 From: "VSM 13" <vsmsa++at++club-internet.fr>
 Date: Fri, 5 Mar 1999 09:24:30 +0100
 Subject: performance on lock phase.
  
Message en plusieurs parties et au format MIME.

------=_NextPart_000_0013_01BE66E9.F90ACBC0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I made a bench with perfly, on oNYX2 IR2 tripipe
When I use free mode : the application runs at 30 Hz.
When I use lock mode on 30 Hz: the application runs between 20/30Hz.
(I lock the cull and draw process),

How you can explain that?

HALLAKOUN Yoel
VSM sa

------=_NextPart_000_0013_01BE66E9.F90ACBC0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

I made a bench with perfly, on oNYX2 = IR2=20 tripipe
When I use free mode : the = application runs at=20 30 Hz.
When I use lock mode on 30 Hz: the = application=20 runs between 20/30Hz.
(I lock the cull and draw = process),
 
How you can explain = that?
 
HALLAKOUN Yoel
VSM sa
------=_NextPart_000_0013_01BE66E9.F90ACBC0-- ****************************************************************************** From: Rob Jenkins Date: Fri, 05 Mar 1999 00:03:43 -0800 Subject: Re: performance on lock phase. >I made a bench with perfly, on oNYX2 IR2 tripipe >When I use free mode : the application runs at 30 Hz. >When I use lock mode on 30 Hz: the application runs between 20/30Hz. >(I lock the cull and draw process), >How you can explain that? This is an illustration from the PF course notes: Video refresh 60Hz( 16.7 mS /frame ) Frame Rate 30Hz ( 33.3mS /frame ) Frame 1 overrruns | ! | ! | ! | ! | |-F0-|~>|-F1-------------|~~~~~>|-F2-|~>!-F3-----|~~~~~>! | FREE | ! | ! | ! | ! | |-F0-|~~~~~~~~~>|-F1-------------|~~~~~~~~~~~~~>|-F3-----|~~~~~>| LOCK | ! | ! | ! | ! | In FREE run, the draw can start as quickly as possible so no frame get dropped ( in this case though frame rate will vary ) In LOCK F0 has to wait for a fixed frame boundary, then as F1 overruns it hs to wait for another fixed frame boundary so gets even further behind. This isn't exactly what you are seeing but you get the idea, in your test FREE run is managing to always get everything done in 33ms whereas in LOCK the wait for a frame boundary is causing drops. Cheers Rob -- ________________________________________________________________ Rob Jenkins Silicon Graphics mailto:robj++at++sgi.com ****************************************************************************** From: reiners++at++igd.fhg.de Date: Fri, 5 Mar 1999 10:35:19 +0100 (MET) Subject: Re: PBuffer on Onyx2 Reality On Mar 4, 7:37pm, Christian Ernst wrote: > Subject: PBuffer on Onyx2 Reality > Hi all, > > I'm trying to use the SGI PBuffers on different machines. I have read > the old messages from Dec 98, so that I know about the "Bad Alloc " > problem. > When I get the fbconfig list, I'm trying all configs till I'm successful > in > creating a pbuffer. > This works perfect on an Octain, an Indigo2 and an Onyx. But on an Onyx2 > Reality I get no suitable pbuffer. On this machine I can only allocate > pbuffers with no depth buffer and R>=10/G>=10/B>=10, or with depth > buffer > and R>=10/G=0/B=0. > >-- End of excerpt from Christian Ernst Apparently iR/Reality won't give you a usable pbuffer if you only have small pixel depth. When we reduced the managed area so that we got medium pixel depth a usable configuration became available. It's a bit strange, as AFAIK small pixel depth is 128 bit/pixel and Impact has, again AFAIK, 3*36=108 bit/pixel. There are probably some other magic constraints about blocking different groups of bits, but I would have expected more. As you only have a Reality you have a problem there, as even 1024x768 will only get you small pixel depth. You would have to go down to 800x600 or cook up your format in the area of ~960x680. Not a pretty sight in any case, but good enough for testing. But then again I just might be wrong and there is a magic button that will bring us eternal peace and infinite pbuffers. Can anybody tell me which one it is? Dirk -- -- -- Dirk Reiners reiners++at++igd.fhg.de, Dirk.Reiners++at++gmx.net -- IGD - A4 http://www.igd.fhg.de/~reiners -- Rundeturmstrasse 6 -- D-64283 Darmstadt All standard disclaimers apply. -- Truth is stranger than fiction because fiction has to make sense. ****************************************************************************** From: Liu Xiaoyan Date: Fri, 05 Mar 1999 18:36:28 +0800 Subject: buffer requirment for glPolygonOffsetEXT Hi, all, I'm trying to do the same light mapping effect as that in Bumplogo on our VR platform (CAVE). Two coplanar textured polygons are offsetted using glPolygonOffsetEXT before they are blended. I tested this very simple part with different framebuffer setup. It works in Performer but not in CAVE. In CAVE, I can only see the front polygon without any blending. I suspect it's due to different framebuffer configurations. What's the buffer requirement for gl-polygon_offset extension and glTexEnvfv(ENV_BIAS_SGIX)? Does it need stencil? static int PreBlend(pfTraverser *, void *) { pfTransparency(PFTR_BLEND_ALPHA); pfOverride(PFSTATE_TRANSPARENCY, PF_ON); glBlendFunc(GL_ZERO, GL_SRC_COLOR); glPolygonOffsetEXT(-0.5f, -0.00001f); glEnable(GL_POLYGON_OFFSET_EXT); glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_BIAS_SGIX, biasparams); glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, colorparams); return PFTRAV_CONT; } static int PostBlendC(pfTraverser *, void *) { glBlendFunc(GL_ONE, GL_ZERO); pfOverride(PFSTATE_TRANSPARENCY, PF_OFF); pfTransparency(PFTR_OFF); glDisable(GL_POLYGON_OFFSET_EXT); glPolygonOffsetEXT(0.0f, 0.0f); return PFTRAV_CONT; } Thanks. Liu -- *********************************************************************** Liu Xiaoyan Institute of High Performance Computing Research Engineer National University of Singapore Data Visualisation Group http://www.ihpc.nus.edu.sg Tel:(65)7709267 *********************************************************************** ****************************************************************************** From: Phil Keslin Date: Fri, 05 Mar 1999 07:17:33 -0800 Subject: Re: performance on lock phase. > VSM 13 wrote: > > I made a bench with perfly, on oNYX2 IR2 tripipe > When I use free mode : the application runs at 30 Hz. > When I use lock mode on 30 Hz: the application runs between 20/30Hz. > (I lock the cull and draw process), > > How you can explain that? > > HALLAKOUN Yoel > VSM sa Which OS? With IRIX 6.5 there is a bug that can cause the draw sync logic to miss a frame boundary. We're working on a fix. - Phil -- Phil Keslin ****************************************************************************** From: "VSM 13" Date: Fri, 5 Mar 1999 17:55:29 +0100 Subject: Re: performance on lock phase. Thank you all to answer. I'm in ONYX2 IR 2 on 6.5 with 3 pipes. Phil Keslin said to me that it's a bug, I think so because I'm not this g= ap on my old RE2 on 5.3 Marc Simon said that I have to genlock my pipe and use the swapready. I h= ave genlocked with horizontal rate but I haven't use the swapready ( how you configure it ?) Rob Jenkins said that the frame boundary can cause this, does exist some optimisation for that ? -----Message d'origine----- De : Phil Keslin =C0 : VSM 13 Cc : info-performer Date : vendredi 5 mars 1999 16:17 Objet : Re: performance on lock phase. >> VSM 13 wrote: >> >> I made a bench with perfly, on oNYX2 IR2 tripipe >> When I use free mode : the application runs at 30 Hz. >> When I use lock mode on 30 Hz: the application runs between 20/30Hz. >> (I lock the cull and draw process), >> >> How you can explain that? >> >> HALLAKOUN Yoel >> VSM sa > > >Which OS? With IRIX 6.5 there is a bug that can cause the draw sync >logic to miss a frame boundary. We're working on a fix. > >- Phil > >-- >Phil Keslin > ****************************************************************************** From: Colin Bannister Date: Fri, 05 Mar 1999 16:58:33 +0000 Subject: Re: saving rgb files (pfuSaveImage) Thanks to all those who replied to my posting on saving images from a fly-through. This is now working well, including the use of shared memory to pass data into the appropriate callback routines. A lot of this was in the 'perfly' code, but its not always so easy to spot at first glance. Colin -- Dr. Colin Bannister Academic Computing Services Cripps Computing Centre Tel: 0115 9513326 The University of Nottingham Fax: 0115 9513358 Nottingham NG7 2RD www: http://www.nottingham.ac.uk/~cczcb/ email: Colin.Bannister++at++nottingham.ac.uk ****************************************************************************** From: yunda++at++mail.sc.cninfo.net (Publishing User) Date: Fri, 5 Mar 1999 09:14:56 +0800 Subject: Ask for help! Dear Performer Experts, I am a new Performer user.I want to use Performer to develop visual simulation program in locomotive simulator.I use MultiGen to build model,when I use perfly to drive it,the texture on the ground plane exhibit blurr.I want to know how to resolve this problem, maybe there are some tricks. I have another question: whether it is fit for to use the clipmaping in visual simulation of locomotive simulator or not. Thank you very much! Qiujing --------------------------------- QiuJing Tel:(86)28-7600132(o) Email:qiujing5++at++263.net yunda++at++public.sc.cninfo.net qiu_jing++at++usa.net Chengdu,Sichuan P.R.CHINA ****************************************************************************** From: Angus Dorbie Date: Fri, 05 Mar 1999 16:20:35 -0800 Subject: Re: Ask for help! The problem is isotropic MIP mapping. See the "Anisotropic" section on www.dorbie.com for an explanation and sample code which can fix this in Performer. You have a very constrained problem so it should be easy for you to unblur your tracks & approaching objects like buildings and hedge rows. Cheers,Angus. Publishing User wrote: > > Dear Performer Experts, > > I am a new Performer user.I want to use Performer > to develop visual simulation program in locomotive > simulator.I use MultiGen to build model,when I use > perfly to drive it,the texture on the ground plane > exhibit blurr.I want to know how to resolve this problem, > maybe there are some tricks. > I have another question: whether it is fit for to use > the clipmaping in visual simulation > of locomotive simulator or not. > > Thank you very much! > Qiujing > > --------------------------------- > QiuJing > Tel:(86)28-7600132(o) > Email:qiujing5++at++263.net > yunda++at++public.sc.cninfo.net > qiu_jing++at++usa.net > Chengdu,Sichuan > P.R.CHINA > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/ > Submissions: info-performer++at++sgi.com > Admin. requests: info-performer-request++at++sgi.com -- "Only the mediocre are always at their best." -- Jean Giraudoux For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/ ****************************************************************************** From: Angus Dorbie Date: Fri, 05 Mar 1999 16:29:10 -0800 Subject: Re: buffer requirment for glPolygonOffsetEXT There is no requirement, other than a depth buffer. Watch your z precision as the EXT version will vary depending on z bits. Also multisample on iR triggers a different z storage mechanism which improves precision in the distance and will affect the required offset. You can choose to use pfLayers for this, watch that performer may be clobbering your layter information, it makes it's own offset calls. If using pfLayers you could try using the stencil layering instead of offset, the default pf offset values chosen don't work very well on iR because they are excessively large and cause punch through (too much offset), this should be fixed in the 2.2.5 release, and OpenGL 1.1 platforms will use the precision independent 1.1 OpenGL ARB offset instead of the old EXT offset in the next release. Cheers,Angus. Liu Xiaoyan wrote: > > Hi, all, > > I'm trying to do the same light mapping effect as that in > Bumplogo on our VR platform (CAVE). Two coplanar textured > polygons are offsetted using glPolygonOffsetEXT before they > are blended. I tested this very simple part with different > framebuffer setup. It works in Performer but not in CAVE. In > CAVE, I can only see the front polygon without any blending. > I suspect it's due to different framebuffer configurations. > > What's the buffer requirement for gl-polygon_offset > extension and glTexEnvfv(ENV_BIAS_SGIX)? Does it need > stencil? > > static int PreBlend(pfTraverser *, void *) > { pfTransparency(PFTR_BLEND_ALPHA); > pfOverride(PFSTATE_TRANSPARENCY, PF_ON); > glBlendFunc(GL_ZERO, GL_SRC_COLOR); > glPolygonOffsetEXT(-0.5f, -0.00001f); > glEnable(GL_POLYGON_OFFSET_EXT); > glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_BIAS_SGIX, > biasparams); > glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, > colorparams); > return PFTRAV_CONT; > } > > static int PostBlendC(pfTraverser *, void *) > { > glBlendFunc(GL_ONE, GL_ZERO); > pfOverride(PFSTATE_TRANSPARENCY, PF_OFF); > pfTransparency(PFTR_OFF); > glDisable(GL_POLYGON_OFFSET_EXT); > glPolygonOffsetEXT(0.0f, 0.0f); > return PFTRAV_CONT; > } > > Thanks. > > Liu > -- > *********************************************************************** > > Liu Xiaoyan Institute of High > Performance Computing > Research Engineer National University > of Singapore > Data Visualisation Group http://www.ihpc.nus.edu.sg > Tel:(65)7709267 > *********************************************************************** > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/ > Submissions: info-performer++at++sgi.com > Admin. requests: info-performer-request++at++sgi.com -- "Only the mediocre are always at their best." -- Jean Giraudoux For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/ ****************************************************************************** From: "ÀåÀç¿ø" Date: Sat, 6 Mar 1999 10:23:53 +0900 Subject: 3ds Loading with pthread and Rgba from PC This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BE67BB.6F4746C0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGl+ICANCg0KSSdtIHByb2dyYW1taW5nIHdpdGggcGVyZm9ybWVyLg0KDQpUZXN0IHRoaXMgOiBj b21waWxlICYgbGluayAgbW90aWYuQyAoaW4gQysrKSB3aXRoIHB0aHJlYWQgKCAtbHB0aHJlYWQg KSBMaWIuDQoNCmFuZCBMb2FkaW5nICouM2RzICggaW5jbHVkZSAgdGV4dHVyZSBtYXAgaW1hZ2Ug KQ0KDQooIGNoZWNrIGltYWdlIGNvbnZlcnRpbmcgcHJvY2VzcyBqdXN0IGxpa2UganBnLT5yZ2Ig KQ0KDQpPbmUgbW9yZS4uLg0KDQpJIHdhbnQgdG8ga25vdyB0aGlzLi4uDQoNClVtbS4uLiAgSG93 IGRvIEkgaW1wb3J0IGFscGhhICggbWFrZSAqLnJnYmEgKSBmcm9tIG15IFBDICggd29ya2luZyB3 aXRoIDNkc01BWCApLg0KDQpJbiBteSAzZHMsIHRyYW5zcGFyZW5jeSwgb3BhcXVlIGF0dHJpYnV0 ZXMgaGF2ZSBub3QgYmVlbiBpbXBvcnRlZCBjb3JyZWN0bHkuLi4NCg0K ------=_NextPart_000_0014_01BE67BB.6F4746C0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5IaX4mbmJzcDsgPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkknbSBwcm9ncmFtbWluZyB3aXRoIHBlcmZv cm1lci48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMDAwIHNpemU9Mj5UZXN0IHRoaXMgOiBjb21waWxlICZhbXA7IGxpbmsmbmJzcDsgbW90aWYu QyAoaW4gDQpDKyspIHdpdGggcHRocmVhZCAoIC1scHRocmVhZCApIExpYi48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTI+YW5kIExvYWRpbmcgKi4zZHMgKCBpbmNsdWRl Jm5ic3A7IHRleHR1cmUgbWFwIA0KaW1hZ2UgKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ KCBjaGVjayBpbWFnZSBjb252ZXJ0aW5nIHByb2Nlc3MganVzdCBsaWtlIGpwZy0mZ3Q7cmdiIA0K KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPk9uZSBtb3JlLi4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSB3YW50IHRvIGtub3cg dGhpcy4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPlVtbS4uLiZuYnNwOyBIb3cgZG8gSSBpbXBvcnQgYWxwaGEg KCBtYWtlICoucmdiYSApIGZyb20gbXkgUEMgDQooIHdvcmtpbmcgd2l0aCAzZHNNQVggKS48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5JbiBteSAzZHMsIHRyYW5zcGFyZW5jeSwgb3BhcXVlIGF0dHJpYnV0ZXMgaGF2 ZSBub3QgYmVlbiANCmltcG9ydGVkIGNvcnJlY3RseS4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0014_01BE67BB.6F4746C0-- ******************************************************************************

This archive was generated by hypermail 2.0b2 on Sun Mar 07 1999 - 22:42:12 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.