From: gangdang++at++nudt.edu.cn
Date: 01/01/2000 10:27:55
info-performer Mailing List wrote:
>
> Welcome to the info-performer mailing list DIGEST for May 02 2000
>
> 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:
>
> Re: converting FROM pfb ?
> Re: swap ready connector
> Flossmoor Jr. High
> Re: Compiler warnings
> Extensions to PerFly
> Re: cliptexture wobble
> Re: Compiler warnings
> E&S format
> Re: E&S format
> Re: target frame rate in stats
>
> ******************************************************************************
>
> From: Simon Mills <simon++at++wgs.estec.esa.nl>
> Date: Tue, 02 May 2000 10:37:18 +0200
> Subject: Re: converting FROM pfb ?
>
> Brian Furtaw wrote:
> >
> > My apologies for the misinformation I assumed that since MultiGen was
> > Performer based it could read all the file types Performer reads. Bad
> > assumption.
> >
> > Brian
>
> Multigen is OpenGL based, not Performer based so it can't help you here.
>
> For what you want to do you could try to use the 'pfconv' utility. The
> trouble is very few of the Performer file loaders support the store
> function. I have seen a version of the Inventor loader with a store
> function implemented, I think I saw it on info-performer a long time
> ago. It was never very successful for me so I've deleted it. Check the
> archives though.
>
> Personally I've developed a store function for the OpenFlight loader
> using the OpenFlight API which I've found convenient many times for
> converting from PFB (I'm not really at liberty to give this away
> though).
>
> > Ran Yakir wrote:
> > >
> > > Does MultiGen read pfb files? What version?
> > >
> > > Brian Furtaw wrote:
> > >
> > > > You could read it into Multigen and save it out as flight, assuming you
> > > > have a copy of Multigen. I don't know of an Inventor file writer and the
> > > > Inventor database format does not support all of the node features that
> > > > are in the Performer scenegraph.
> > > >
> > > > Brian
> > > >
> > > > Francois Sillion wrote:
> > > > >
> > > > > Hello Performers,
> > > > >
> > > > > I have access to a complex model in pfb format, which has been created from a
> > > > > very large number of individual files of various formats. Is there a tool
> > > > > available to convert this into another 3D format (e.g., inventor) ?
> > > > > the pfb file is fine for direct use in our Performer based applications, but
> > > > > we would also like to be able to edit and otherwise manipulate the 3d objects
> > > > > in a modeling program.
> > > > >
> > > > > It seems the libpfb code has some (empty) stubs for functions that would
> > > > > output Inventor files. Does this code exist anywhere, or has anyone developed
> > > > > a similar tool?
> > > > >
> > > > > Thanks in advance,
> > > > > --
> > > > > >>>>> PLEASE NOTE OUR NEW ADDRESS ! EFFECTIVE October 4th, 1999
> > > > > +------------------+--------------------------------------------------------+
> > > > > | Francois SILLION | iMAGIS, Laboratoire GRAVIR/IMAG (CNRS,INRIA,INPG,UJF) |
> > > > > | ' | INRIA Rhone-Alpes, 655 Av de l'Europe, 38330 Montbonnot|
> > > > > | Senior researcher| France. Tel: +33 4 76 61 54 23 - Fax: +33 4 76 61 54 40|
> > > > > +------------------+--------+-----------------------------------------------+
> > > > > | Francois.Sillion++at++imag.fr | http://www-imagis.imag.fr/~Francois.Sillion |
> > > > > +---------------------------+-----------------------------------------------+
> > > > > -----------------------------------------------------------------------
> > > > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > > > Submissions: info-performer++at++sgi.com
> > > > > Admin. requests: info-performer-request++at++sgi.com
> > > >
> > > > --
> > > > ----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
> > > >
> > > > Brian Furtaw (brian++at++sgi.com)
> > > > Graphics Guru Office:(301)572-3293 Fax: (301)572-3280
> > > > 12200-G Plum Orchard Drive OpenGL/Performer/OpenInventor/ImageVision
> > > > Silver Spring, Maryland 20904 Volumizer/Optimizer/React/PCI Device
> > > > Drivers
> > > > -----------------------------------------------------------------------
> > > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > > Submissions: info-performer++at++sgi.com
> > > > Admin. requests: info-performer-request++at++sgi.com
> > >
> > > --
> > > __ | Ran Yakir
> > > /_) _ __ \ / _ / o __ | RT-SET Ltd.
> > > / )_ (_(_) ) \/ (_(_/<_(_)( |
> > > _/ |
> > > -------------------------------------+--------------------------------
> > > Phone : | E-mail : rany++at++rtset.com
> > > Work : 972-9-9552236 Ext #118 | rany++at++netvision.net.il
> > > Res. : 972-9-7489974 |
> > > Cell.: 972-58-713040 |
> > > Fax : 972-9-9552239 |
> > >
> > > http://rtset.co.il/rany
> >
> > --
> > ----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
> >
> > Brian Furtaw (brian++at++sgi.com)
> > Graphics Guru Office:(301)572-3293 Fax: (301)572-3280
> > 12200-G Plum Orchard Drive OpenGL/Performer/OpenInventor/ImageVision
> > Silver Spring, Maryland 20904 Volumizer/Optimizer/React/PCI Device
> > Drivers
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> Regards, Simon
> ________________________________________________________________________
>
> Simon Mills
> Silicon Worlds S.A.
> c/o Modelling & Simulation Section (TOS-EMM) Tel: +31 (0)71 565 3725
> European Space Agency (ESA/ESTEC) Fax: +31 (0)71 565 5419
> Postbus 299, 2200AG Noordwijk e-mail: simon++at++wgs.estec.esa.nl
> The Netherlands http://www.estec.esa.nl/wmwww/EMM
> ________________________________________________________________________
>
> ******************************************************************************
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Tue, 02 May 2000 01:44:20 -0700
> Subject: Re: swap ready connector
>
> PFCHAN_SWAPBUFFERS != PFCHAN_SWAPBUFFERS_HW
>
> This will sync up the channels on a single image system, the hardware
> sync is only marginally better.
>
> Cheers,Angus.
>
> Calvin Lu wrote:
> >
> > By default, Vega enables the following,
> >
> > k = PFCHAN_SCENE | PFCHAN_STRESS | PFCHAN_SWAPBUFFERS |
> > PFCHAN_STATS_DRAWMODE | PFCHAN_CULLFUNC | PFCHAN_DRAWFUNC;
> > pfChanShare( pfchan, k);
> >
> > The vgObservChanShareMask function can be used to enable the
> > PFCHAN_NEARFAR, PFCHAN_LOD, and PFCHAN_LPOINTFUNC bits. Another
> > way to manipuate the channel share group is to retrieve the
> > pfChannel pointer from vgChannel and use pfChanShare to change
> > the mask directly.
> >
> > cLu
> >
> > > -----Original Message-----
> > > From: Luc Leblanc [mailto:luc.leblanc++at++AdacelCanada.com]
> > > Sent: Monday, May 01, 2000 12:44 PM
> > > To: Performer Mailing List; Vega Mailing List
> > > Subject: Re: swap ready connector
> > >
> > >
> > > Hi.
> > >
> > > Does anybody know how performer channel groups are handled
> > > (more specifically
> > > the PFCHAN_SWAPBUFFERS_HW token) by Vega on SGI ?
> > >
> > > Thanks...
> > >
> > > Angus Dorbie wrote:
> > >
> > > > It can be important when you intend to run at less than the vertical
> > > > retrace rate of video, especially if you unexpectedly frame
> > > extend but
> > > > in practice, with the right pfPhase set the it isn't essential on a
> > > > single image system. It is essential when using multiple
> > > systems. You
> > > > should try and channel share PFCHAN_SWAPBUFFERS_HW and wire
> > > swapready
> > > > even on a single image system though, it's easy enough.
> > > >
> > > > CHeers,Angus.
> > > >
> > > > Luc Leblanc wrote:
> > > > >
> > > > > Hi.
> > > > >
> > > > > We're using a Vega 3.4 application on a 6 pipes Onyx2
> > > IR2. The pipes
> > > > > are properly genlocked (according to gfxinfo -v and to
> > > the Genlock In
> > > > > and the Genlock Loop Through connectors) but the Swap
> > > Ready connectors
> > > > > are not connected together. How important is it to connect those
> > > > > connectors together ? What impact can that have on the
> > > frame rate ?
> > > > >
> > > > > Thanks...
> > >
> > > --
> > > Luc Leblanc
> > > Software Designer
> > > Adacel Technologies Canada Ltee
> > > EMail: leblanc++at++adacelcanada.com
> > > Tel: 450-672-1114 #270
> > > Fax: 450-672-4434
> > >
> > >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
>
> ******************************************************************************
>
> From: "Garnet Frankenburger" <garnie++at++evcom.net>
> Date: Tue, 2 May 2000 07:55:44 -0400
> Subject: Flossmoor Jr. High
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0005_01BFB40B.D20758C0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Are you the Denny that went to school with John Frankenburger?
>
> ------=_NextPart_000_0005_01BFB40B.D20758C0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META content=3D"text/html; charset=3Diso-8859-1" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT size=3D2> Are you the Denny that went to =
> school with=20
> John Frankenburger?</FONT></DIV></BODY></HTML>
>
> ------=_NextPart_000_0005_01BFB40B.D20758C0--
>
> ******************************************************************************
>
> From: Larry Lachman <larry++at++paradigmsim.com>
> Date: Tue, 02 May 2000 07:58:42 -0600
> Subject: Re: Compiler warnings
> Reply-To: larry++at++paradigmsim.com
>
> --------------F69D6ABB811F845A8D9957B3
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Guy Wallis wrote:
>
> > Hallo,
> > I've just started using Performer and decided to compile the examples in
> > /usr/share/Performer/src/pguide/libpf/C
> > They compiled OK but I got a lot of compiler warnings of the following type:
> >
> >
> > /usr/bin/cc -DN32 -DIRIX6_5 -I/usr/include -fullwarn -nostdinc
> > -I/usr/include -mips3 -n32 -O --MDupdate Makedepend -woff
> > 1685,515,608,658,799,803,852,1048,1233,1499 -c ../text3D.c
> > cc-1164 cc: WARNING File = ../text3D.c, Line = 96
> > Argument of type "float (*)[4]" is incompatible with parameter of type
> > "const float (*)[4]".
> >
> > pfStringMat(GSetStrings[EXTRUDED], mat);
> > ^^^
> >
> > This is true for many other function calls with pfMatrix as an argument e.g.:
> >
> > pfPostTransMat(), pfLoadMatrix(), pfMultMatrix().
> >
> > I guess removing-fullwarn would hide this problem, but like the writers of the
> > original Makefile in the pguide directory, I like to use this feature. Is
> > there some way of eradicating this warning rather than ignoring it.
>
> Yes. You can keep the -fullwarn level while eliminating this particular
> warning. What you will
> need to do is instruct the compiler to not generate warning number 1164. The
> way to do this is
> surround your line (or block) of code with the following pragmas:
>
> #pragma set woff 1164
> pfMultMatrix( mat );
> #pragma reset woff 1164
>
> Larry
>
> --
> _______________________________________________________________
>
> Larry Lachman WWW: http://www.multigen-paradigm.com
> Computer Associates, Inc. larry++at++paradigmsim.com
> 14900 Landmark, Suite 400 (972) 960-2301 ext 287 voice
> Dallas, Texas 75240 USA (972) 960-2303 fax
>
> --------------F69D6ABB811F845A8D9957B3
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Guy Wallis wrote:
> <blockquote TYPE=CITE>Hallo,
> <br>I've just started using Performer and decided to compile the examples
> in <b>/usr/share/Performer/src/pguide/libpf/C</b>
> <br>They compiled OK but I got a lot of compiler warnings of the following
> type:
> <br>
> <p><tt> /usr/bin/cc -DN32 -DIRIX6_5
> -I/usr/include -fullwarn -nostdinc -I/usr/include -mips3 -n32 -O
> --MDupdate Makedepend -woff 1685,515,608,658,799,803,852,1048,1233,1499
> -c ../text3D.c</tt>
> <br><tt>cc-1164 cc: WARNING File = ../text3D.c, Line = 96</tt>
> <br><tt> Argument of type "float (*)[4]" is incompatible with parameter
> of type</tt>
> <br><tt> "const float
> (*)[4]".</tt>
> <p><tt> pfStringMat(GSetStrings[EXTRUDED],
> mat);</tt>
> <br><tt>
> ^^^</tt>
> <p>This is true for many other function calls with <b>pfMatrix</b> as an
> argument e.g.:
> <p><tt>pfPostTransMat(), pfLoadMatrix(), pfMultMatrix()</tt>.
> <p>I guess removing<b>-fullwarn</b> would hide this problem, but like the
> writers of the original Makefile in the pguide directory, I like to use
> this feature. Is there some way of eradicating this warning rather than
> ignoring it.</blockquote>
>
> <p><br>Yes. You can keep the -<b>fullwarn</b> level while eliminating
> this particular warning. What you will
> <br>need to do is instruct the compiler to not generate warning number
> 1164. The way to do this is
> <br>surround your line (or block) of code with the following pragmas:
> <p>#pragma set woff 1164
> <br> pfMultMatrix( mat );
> <br>#pragma reset woff 1164
> <p>Larry
> <pre>--
> _______________________________________________________________
>
> Larry Lachman WWW: <A HREF="http://www.multigen-par
> Computer Associates, Inc. larry++at++paradigmsim.com
> 14900 Landmark, Suite 400 (972) 960-2301 ext 287 voice
> Dallas, Texas 75240 USA (972) 960-2303 fax</pre>
> </html>
>
> --------------F69D6ABB811F845A8D9957B3--
>
> ******************************************************************************
>
> From: 340 Project Grp using Performer <s340gb++at++start.com.au>
> Date: Wed, 3 May 2000 00:06:35 +1000
> Subject: Extensions to PerFly
>
> Hi,
>
> I am working in a 3rd year Uni group doing a year long project to make
> several extensions to PerFly for our Uni's Architecture department. We
> had no previous experience with IRIS Performer or PerFly, so the
> project is proving quite a challenge! We are using the Linux version
> of Performer and Perfly, running on Redhat 6.2 .
>
> What we are doing is the following:
>
> 1. Improving the sun modelling in PerFly to include Angle of lighting
> and position in the sky, and will also add a sliding bar to change the
> season.
>
> 2. Adding the ability for scene designers to specify "triggers". This
> will allow eg. clicking on a light switch to switch on a light. We are
> planning to have these triggers specified in a text file which will be
> parsed in with each model file.
>
> 3. Allowing the scene designer to add stereo sounds to certain objects
> eg. Bird noises to trees. Once again, these would be specified in a
> file to be read in.
>
> 4. Allowing the scene designer to specify paths certain objects should
> move along, and how quickly they move along said paths.
>
> 5. Logging any triggers interacted with by the user, and also
> regularly sampling the user's location and orientation.
>
> Any help on how to approach any of these points would
> be greatly appreciated. Performer functions likely to help, useful
> books or websites etc. would really help us get up to speed.
>
> Cheers,
> Patrick Sunter
>
> s340gb++at++start.com.au
> s340gb++at++students.cs.mu.oz.au
>
> __________________________________________________________________
> Get your free Australian email account at http://www.start.com.au
>
> ******************************************************************************
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Tue, 02 May 2000 07:11:43 -0700
> Subject: Re: cliptexture wobble
>
> It sounds like it is probably jello. The best way to describe the
> difference I've heard is you can take a screen shot of jello which shows
> the problem but you can't take a screen shot of wobble.
>
> The methods you derscibe to fix this reduce the active area of good
> texture and buy you back texture coordinate interpolation precision. If
> you look again at your situation you may find that the polygons in
> question are being clipped which is one set of circumstances which can
> expose the issue and may be why the problem seems to be related to your
> underlying triangulation.
>
> The problem looks like it could be a misinterpretation of the meaning of
> the box distances, the algorithm attempts to optimize LOD useage to
> those required when rendering the geometry within the specified box
> ranges assuming a simple surface, by asking the lod computation a
> question which requires all those levels it cannot optimize for jello.
> The idea is that you supply a ring (actually two concentric squares)
> where all geometry lies between those squares. If your inner square is
> very close and your outer two far away the algorithm will try to
> estimate usefull texture LOD's for that region. It neither knows nor
> cares about your geometry granularity, it has no impact on the
> algorithm, the application must ensure the appropriate LOD's are applied
> to the geometry in the specified regions.
>
> There is an algorithmically simpler approach to this whole affair which
> doesn't require all this complexity and is actually much more elegant.
>
> First, you determine how many LODs you require by experimentation for
> two or three different ranges (sounds like you've already done this as
> most people do). Then on the fly you determine how far a tile is away.
> You know the scale of your texture so all you need to do is ensure you
> go far enough up your MIP pyramid to include the texture required by
> that tile i,e make sure your highest level clipsize region fully
> includes that geometry (pad it a lot by subtracting a level and remember
> the invalid border). So it all boils down to a simple range test which
> maps directly to an offset+numeffectivelevels value, and you already
> know what numeffectivelevels should be for that range. A sufficiently
> large numeffectivelevels then gives you the higher resolution you need
> nearer the eye (i.e. means a smaller offset). If your database is too
> coarse grained then you will lose resolution towards the eye with this
> method but will see no artifacts and you will know to either increase
> numeffectivelevels (in which case you might introduce jello) or create a
> finer grained database with more frequent LOD adjustments.
>
> CHeers,Angus.
>
> ihawkes2++at++csc.com wrote:
> >
> > Hi,
> > Our Performer application currently has some problems with cliptexture wobble.
> > The Performer documentation suggests that jello strikes the high texel quadrant
> > of the cliptexture relative to the clipcenter, but in this case the "wobble"
> > seems to be aligned with polygons and is independent of the quadrant. Only a few
> > polygons seem to be affected. When clipflying the problem area, the cliptexture
> > wobble can be fixed by either increasing the LOD Offset or decreasing the number
> > of effective levels.
> > Does this sound like jello, or is this some other problem that we are seeing?
> >
> > I am using IRIX 6.5.6f and Performer 2.2.7 on an Onyx2 system. I am currently
> > using a 19 level (ie 262144 texels per side) virtual cliptexture, although we
> > plan to eventually increase the number of levels. In our application, I am
> > setting the virtual cliptexture parameters per tile, and the texture wobble is
> > visible on various polygons on the closest tiles. The side length of the tile
> > in texture coordinates is approximately 0.02798 (ie 7335 finest level texels). I
> > have implemented an algorithm to calculate the virtual cliptexture parameters
> > based on what I found in the virtcliptex.c and pfspherepatch.C samples, using
> > pfuCalcSizeFinestMipLOD and pfuCalcVirtualClipTexParams (see attached
> > pseudo-code):
> > (See attached file: ctAlgorithm.pseudo)
> > The results from the algorithm are as follows:
> >
> > for the closest tiles (when tile closest distance = 160.877472):
> > nLevels = 19 clipSize = 1024 invalidBorder = 16 min_dst_dxyz = 0.000004
> > minLODTexPix = 0.000000
> > minLODLoaded= 0.000001 maxLODLoaded =18.000000 bboxMinDist = 0.000000
> > bboxMaxDist = 0.025390 tradeoff = 1.000000
> > LODOffset 0 numEffectiveLevels 16 minLOD 0.000001 maxLOD 6.000000
> >
> > for intermediate distance tiles (when tile closest distance = 1056.229858) I
> > get:
> > nLevels = 19 clipSize = 1024 invalidBorder = 16 min_dst_dxyz = 0.000004
> > minLODTexPix = 0.000000
> > minLODLoaded= 0.000001 maxLODLoaded =18.000000 bboxMinDist = 0.002594
> > bboxMaxDist = 0.030579 tradeoff = 1.000000
> > LODOffset 1 numEffectiveLevels 15 minLOD 0.000001 maxLOD 7.000000
> >
> > and for more distant tiles (when tile centre distance = 26882.296875) I get:
> > nLevels = 19 clipSize = 1024 invalidBorder = 16 min_dst_dxyz = 0.000004
> > minLODTexPix = 4.078858
> > minLODLoaded= 0.000001 maxLODLoaded =18.000000 bboxMinDist = 0.081358
> > bboxMaxDist = 0.109342 tradeoff = 1.000000
> > LODOffset 6 numEffectiveLevels 12 minLOD 0.000001 maxLOD 12.000000
> >
> > I was surprised to see that the algorithm is giving me numEffectiveLevels = 16
> > for the closest tiles, rather than a smaller value that will reduce the
> > likelihood of jello. Looking at the pfuCalcVirtualClipTexParams code, it appears
> > that if I reduce my bboxMaxDist in the case of the closest tile (ie reduce the
> > tile size), then the calculated numEffectiveLevels will decrease and perhaps the
> > "cliptexture wobble" will improve. However, the tile is already pretty small in
> > terms of finest-level texels and is well under the recommended 16K limit. Is
> > tile size likely to be the problem here, or are there some other factors
> > involved? Perhaps some of my other inputs to pfuCalcVirtualClipTexParams are
> > incorrect?
> >
> > Also, what is the meaning of the minLOD & maxLOD values calculated by
> > pfuCalcVirtualClipTexParams? Aren't the LODOffset & numEffectiveLevels enough to
> > specify the levels in use?
> >
> > Any suggestions would be most appreciated!
> >
> > Thanks,
> > Ian Hawkes
> > CSC Australia
> >
> > ------------------------------------------------------------------------
> > Name: ctAlgorithm.pseudo
> > ctAlgorithm.pseudo Type: unspecified type (application/octet-stream)
> > Encoding: base64
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
>
> ******************************************************************************
>
> From: Christian Skluzacek <c.skluzacek++at++fokkerspace.nl>
> Date: Tue, 02 May 2000 17:44:03 +0200
> Subject: Re: Compiler warnings
>
>
> Larry Lachman schreef:
>
> > Yes. You can keep the -fullwarn level while eliminating this
> > particular warning. What you will
> > need to do is instruct the compiler to not generate warning number
> > 1164. The way to do this is
> > surround your line (or block) of code with the following pragmas:
> >
> > #pragma set woff 1164
> > pfMultMatrix( mat );
> > #pragma reset woff 1164
>
> or would it be easier to use the compiler flag -woff 1164?
>
> Chris
>
> ******************************************************************************
>
> From: Christian Skluzacek <c.skluzacek++at++fokkerspace.nl>
> Date: Tue, 02 May 2000 19:05:56 +0200
> Subject: E&S format
>
> Wasn't able to find in quick search through documentation:
> - does Performer support Evans & Sutherland format files?
> - there's a library: /usr/lib32/libpfdb/libpfevt_?gl.so. Does anyone
> know which loader this is? It's not in the list in the Performer
> Programmers Guide.
>
> Thanks,
> Chris
>
> --
> ------------------------------------------------------------------------
>
> Christian Skluzacek | FokkerSpace B.V.
>
> Software Engineer | Newtonweg 1
>
> Program Operations - Simulation | 2333 CP Leiden
>
> +31 71 524 5718 | The Netherlands
>
> mailto:c.skluzacek++at++fokkerspace.nl | http://www.fokkerspace.nl
>
> ------------------------------------------------------------------------
>
> ******************************************************************************
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Tue, 02 May 2000 13:04:44 -0700
> Subject: Re: E&S format
>
> Christian Skluzacek wrote:
> >
> > Wasn't able to find in quick search through documentation:
> > - does Performer support Evans & Sutherland format files?
>
> No, although Acusoft in Orlando has been working with SGI to take SEDRIS
> files from E&S and converted them to .pfb files. This was demonstrated
> at IITSEC last year. You still have to get E&S to produce the SEDRIS
> files and often the databases are still owned by E&S anyways.
>
> > - there's a library: /usr/lib32/libpfdb/libpfevt_?gl.so. Does anyone
> > know which loader this is? It's not in the list in the Performer
> > Programmers Guide.
> >
> > Thanks,
> > Chris
> >
> > --
> > ------------------------------------------------------------------------
> >
> > Christian Skluzacek | FokkerSpace B.V.
> >
> > Software Engineer | Newtonweg 1
> >
> > Program Operations - Simulation | 2333 CP Leiden
> >
> > +31 71 524 5718 | The Netherlands
> >
> > mailto:c.skluzacek++at++fokkerspace.nl | http://www.fokkerspace.nl
> >
> > ------------------------------------------------------------------------
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
>
> ******************************************************************************
>
> From: allan++at++sgi.com (Allan Schaffer)
> Date: Tue, 2 May 2000 13:44:35 -0700 (PDT)
> Subject: Re: target frame rate in stats
>
> On May 2, 8:22am, Yoram Shahak wrote:
> > Using performer statistics, I get '???' in the left upper corner in the
> > status line as if performer
> > Does not know the desired frame rate. for example :
> >
> > 16.7Hz/???
> >
> > Why does this happpen ?
>
> The stats will print this if Performer can't determine the monitor
> refresh rate for some reason. Set the PFNFYLEVEL to 5 (PFNFY_DEBUG)
> and look for either 'Query of swap buffer rate returns'... or 'Taking
> median of (xxx) video rate samples'..., this might give some clues.
>
> Allan
>
> --
> Allan Schaffer allan++at++sgi.cominfo-performer Mailing List wrote:
>
> Welcome to the info-performer mailing list DIGEST for May 02 2000
>
> 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 Sub
> Silicon Graphics http://reality.sgi.com/allan
>
> ******************************************************************************
This archive was generated by hypermail 2b29 : Mon Jul 03 2000 - 20:49:17 PDT