From: VSM (marseille++at++vsm.fr)
Date: 05/25/2000 08:16:39
RE :Question about Isector intersection test agents the scene graph
>
Do you use a Asynchrone Isect Process?
Have you got the same problem if you use a synchrone isect on APP process ?
Your BD is static or dynamic ( see PFTRAV_IS_CACH or UNCACHE mask)
Yoel.
----- Message d'origine -----
De : info-performer Mailing List <info-performer++at++sgi.com>
À : <allan++at++holodeck.engr.sgi.com>
Envoyé : jeudi 25 mai 2000 11:00
Objet : info-performer May 24 2000
> Welcome to the info-performer mailing list DIGEST for May 24 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:
>
> Virtual Cliptexture
> Re: Virtual Cliptexture
> Inventor file format loader
> pfProject Texture and transparent textures
> Re: Inventor file format loader
> Re: Inventor file format loader
> Re: pfProject Texture and transparent textures
> RE: Inventor file format loader
> Re: Inventor file format loader
> Re: pfProject Texture and transparent textures
> Multipipe on Linux
> Re: Multipipe on Linux
> Re: Multipipe on Linux
> Re: Multipipe on Linux
> Re: Multipipe on Linux
> Re: Multipipe on Linux
> Re: Multipipe on Linux
> Re: Multipipe on Linux
> Question about Isetor intersection test against the scene graph
> Re: Question about Isetor intersection test against the scene graph
>
>
****************************************************************************
**
>
> From: Andreas Ekstrand <Andreas.Ekstrand++at++saab.se>
> Date: Wed, 24 May 2000 12:11:39 +0200
> Subject: Virtual Cliptexture
> Reply-To: Andreas.Ekstrand++at++saab.se
>
> pfHi!
>
> How come I get a framerate of approximately 1Hz (instead of 60Hz) when I
> try to reduce the number of effective levels in my 16-level
> (32768x32768) clipmap? Doing pfMPClipTextureNumEffectiveLevels in the
> code or specifying effective_levels in the ct-file with any number less
> than 16 results in this strange behaviour.
>
> I'd appreciate any suggestions, comments or solutions.
>
> pfThanks,
> Andreas Ekstrand
>
> --
> ------------------------------------------------------------
> Andreas Ekstrand, FGA-AE |E-mail: Andreas.Ekstrand++at++saab.se
> Saab AB - Simulation Center|Phone: +46 (0)13 - 18 40 42
> SE-581 88 Linkoping |Fax: +46 (0)13 - 18 41 77
> SWEDEN |
> ------------------------------------------------------------
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 12:05:33 -0700
> Subject: Re: Virtual Cliptexture
>
> I'm not sure why this should be, but this is invalid. The offset and
> number of effective levels are controls for manipulating the virtual
> clip stack within the larger clip stack. Basically you choose which 16
> levels (or less using num effective levels) you need when drawing a
> given set of geometry. So if you want to use these controls you need to
> use a larger cliptexture (that can be faked).
>
> You shouldn't need to adjust num effective levels with a non virtual
> cliptexture. Are you seeing jello effects or were you just
> experimenting?
>
> Cheers,Angus.
>
> Andreas Ekstrand wrote:
> >
> > pfHi!
> >
> > How come I get a framerate of approximately 1Hz (instead of 60Hz) when I
> > try to reduce the number of effective levels in my 16-level
> > (32768x32768) clipmap? Doing pfMPClipTextureNumEffectiveLevels in the
> > code or specifying effective_levels in the ct-file with any number less
> > than 16 results in this strange behaviour.
> >
> > I'd appreciate any suggestions, comments or solutions.
> >
> > pfThanks,
> > Andreas Ekstrand
> >
> > --
> > ------------------------------------------------------------
> > Andreas Ekstrand, FGA-AE |E-mail: Andreas.Ekstrand++at++saab.se
> > Saab AB - Simulation Center|Phone: +46 (0)13 - 18 40 42
> > SE-581 88 Linkoping |Fax: +46 (0)13 - 18 41 77
> > SWEDEN |
> > ------------------------------------------------------------
> > -----------------------------------------------------------------------
> > 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: "Dickinson, John" <John.Dickinson++at++nrc.ca>
> Date: Wed, 24 May 2000 15:41:04 -0400
> Subject: Inventor file format loader
>
> A bunch of us have noted that inventor files we load into scenes are
often,
> if not always, rotated 90 degrees.
> Investigation has shown that loaders can sometimes be made to perform
> imports differently using the methods:
> pfdConverterMode, pfdGetConverterMode, pfdConverterAttr,
> pfdGetConverterAttr, pfdConverterVal and pfdGetConverterVal allow the
> user to access and alter the modes, attributes and values of specific
> loaders. These modes, attributes and values are defined inside each
> individual loader. These functions are provided as a means for the
user
> to communicate with the loaders which are usually loaded as Dynamic
> Shared Objects at run-time.
>
> However documentation on the loaders is sparse (read almost non-existent)
> and leaves me wondering if the loader for inventor files can be "tweaked".
>
> Anyone had similar experience with inventor files being rotated while
> loading or tweaked the loader using this or other methods?
>
> John
>
>
> --
> -((Insert standard disclaimer here))-|--- Anonymous (Contemporary) ----
> John Kenneth Dickinson, Ph.D. | "Measure with micrometer;
> Research Council Officer IMTI-NRC | Mark with chalk;
> email: john.dickinson++at++nrc.ca | Cut with axe."
>
>
>
>
****************************************************************************
**
>
> From: devrim <devrim++at++infotron.com.tr>
> Date: Wed, 24 May 2000 22:59:15 +0300
> Subject: pfProject Texture and transparent textures
>
> Hi,
>
> I have been using performer projected textures within my application (
> based on the sample in the man page ) . We also have transparent
> textured billboards which are used for lens flare and static shadows. At
> some point project texture is enabled and then at some point again it is
> disabled. I have noticed that when I use projected textures transparent
> textures look as if alpha bits are set to 1. When I don't enable
> projected textures, it is just fine, we have nice transparency. It looks
> like the color bit count has also decreased.
>
> Any ideas ?
>
> /*===============================================
> M. Devrim Erdem devrim++at++infotron.com.tr
> Simulation Software Development
> info(+)TRON, Turkey
> Tel: +90 216 4921002, Ext 138
> Fax: +90 216 3432132
> http://www.infotron-tr.com
> http://abone.turk.net/mderdem
> ===============================================*/
>
>
>
>
****************************************************************************
**
>
> From: allan++at++sgi.com (Allan Schaffer)
> Date: Wed, 24 May 2000 12:57:16 -0700 (PDT)
> Subject: Re: Inventor file format loader
>
> On May 24, 3:41pm, Dickinson, John wrote:
> > A bunch of us have noted that inventor files we load into scenes are
often,
> > if not always, rotated 90 degrees.
> [...]
> > However documentation on the loaders is sparse (read almost
non-existent)
> > and leaves me wondering if the loader for inventor files can be
"tweaked".
>
> Definitely. Source code for the Inventor loader is shipped in
> the performer_dev.src.loader subsystem in Performer 2.2; look to
> /usr/share/Performer/src/lib/libpfdb/libpfiv
>
> > Anyone had similar experience with inventor files being rotated while
> > loading or tweaked the loader using this or other methods?
>
> This (the rotation) is intentional. Inventor has a Y-up world
> coordinate system, whereas Performer's is Z-up. So when loading
> inventor files we give it a 90 degree rotation about the X axis so
> that something modelled "upright" in inventor will appear "upright"
> in Performer. See line ~2156 of pfiv.C:
>
> // Transform from GL/Inventor's Y-up coordinate system to Performer's
Z-up
> mat.makeRot(90.0f, 1, 0, 0);
> pfRoot = new pfSCS(mat);
>
> Allan
>
> --
> Allan Schaffer allan++at++sgi.com
> Silicon Graphics http://reality.sgi.com/allan
>
>
****************************************************************************
**
>
> From: Erik Brisson <ebrisson++at++tonka.bu.edu>
> Date: Wed, 24 May 2000 16:09:07 -0400
> Subject: Re: Inventor file format loader
>
> Just to be sure that the obvious is not overlooked, people might want to
> be sure that the 90 degree rotation they are getting is not due to the
> difference between Inventor's y-up and Performer's z-up assumptions,
> i.e., sometimes you get what you asked for and it's not what you wanted.
>
> Erik Brisson
> ebrisson++at++bu.edu
>
>
> On Wed, May 24, 2000 at 03:41:04PM -0400, Dickinson, John wrote:
> > A bunch of us have noted that inventor files we load into scenes are
often,
> > if not always, rotated 90 degrees.
> > Investigation has shown that loaders can sometimes be made to perform
> > imports differently using the methods:
> > pfdConverterMode, pfdGetConverterMode, pfdConverterAttr,
> > pfdGetConverterAttr, pfdConverterVal and pfdGetConverterVal allow
the
> > user to access and alter the modes, attributes and values of
specific
> > loaders. These modes, attributes and values are defined inside
each
> > individual loader. These functions are provided as a means for the
user
> > to communicate with the loaders which are usually loaded as Dynamic
> > Shared Objects at run-time.
> >
> > However documentation on the loaders is sparse (read almost
non-existent)
> > and leaves me wondering if the loader for inventor files can be
"tweaked".
> >
> > Anyone had similar experience with inventor files being rotated while
> > loading or tweaked the loader using this or other methods?
> >
> > John
> >
> >
> > --
> > -((Insert standard disclaimer here))-|--- Anonymous (Contemporary) ----
> > John Kenneth Dickinson, Ph.D. | "Measure with micrometer;
> > Research Council Officer IMTI-NRC | Mark with chalk;
> > email: john.dickinson++at++nrc.ca | Cut with axe."
> >
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 13:10:37 -0700
> Subject: Re: pfProject Texture and transparent textures
>
> You can't project texture onto a transparent texture and expect it to
> remain transparent.
>
> The projected texture pass will draw the transparent object with the
> projected texture on it and if the projected texture has alpha ==1 then
> you will see the object as opaque. At the very best you are going to see
> some sort of problems due to transparency. Performer tries to work
> around some of these issues using stencil operations or depth equal
> tests but there is no perfect solution without something like hardware
> multitexture.
>
> CHeers,Angus.
>
> devrim wrote:
> >
> > Hi,
> >
> > I have been using performer projected textures within my application (
> > based on the sample in the man page ) . We also have transparent
> > textured billboards which are used for lens flare and static shadows. At
> > some point project texture is enabled and then at some point again it is
> > disabled. I have noticed that when I use projected textures transparent
> > textures look as if alpha bits are set to 1. When I don't enable
> > projected textures, it is just fine, we have nice transparency. It looks
> > like the color bit count has also decreased.
> >
> > Any ideas ?
> >
> > /*===============================================
> > M. Devrim Erdem devrim++at++infotron.com.tr
> > Simulation Software Development
> > info(+)TRON, Turkey
> > Tel: +90 216 4921002, Ext 138
> > Fax: +90 216 3432132
> > http://www.infotron-tr.com
> > http://abone.turk.net/mderdem
> > ===============================================*/
> >
> > -----------------------------------------------------------------------
> > 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: "Dickinson, John" <John.Dickinson++at++nrc.ca>
> Date: Wed, 24 May 2000 16:13:50 -0400
> Subject: RE: Inventor file format loader
>
> Maybe I should clarify. We had surmised that the rotation was to address
> the y-up vs.
> z-up differences between Inventor and performer but we didn't want it for
> various reasons.
>
> We are now investigating our options for eliminating it within the context
> of our simulations.
>
> John
>
> -----Original Message-----
> From: Erik Brisson [mailto:ebrisson++at++tonka.bu.edu]
> Sent: May 24, 2000 4:09 PM
> To: Dickinson, John
> Cc: info-performer++at++sgi.com
> Subject: Re: Inventor file format loader
>
>
> Just to be sure that the obvious is not overlooked, people might want to
> be sure that the 90 degree rotation they are getting is not due to the
> difference between Inventor's y-up and Performer's z-up assumptions,
> i.e., sometimes you get what you asked for and it's not what you wanted.
>
> Erik Brisson
> ebrisson++at++bu.edu
>
>
> On Wed, May 24, 2000 at 03:41:04PM -0400, Dickinson, John wrote:
> > A bunch of us have noted that inventor files we load into scenes are
> often,
> > if not always, rotated 90 degrees.
> > Investigation has shown that loaders can sometimes be made to perform
> > imports differently using the methods:
> > pfdConverterMode, pfdGetConverterMode, pfdConverterAttr,
> > pfdGetConverterAttr, pfdConverterVal and pfdGetConverterVal allow
the
> > user to access and alter the modes, attributes and values of
specific
> > loaders. These modes, attributes and values are defined inside
each
> > individual loader. These functions are provided as a means for the
> user
> > to communicate with the loaders which are usually loaded as Dynamic
> > Shared Objects at run-time.
> >
> > However documentation on the loaders is sparse (read almost
non-existent)
> > and leaves me wondering if the loader for inventor files can be
"tweaked".
> >
> > Anyone had similar experience with inventor files being rotated while
> > loading or tweaked the loader using this or other methods?
> >
> > John
> >
> >
> > --
> > -((Insert standard disclaimer here))-|--- Anonymous (Contemporary) ----
> > John Kenneth Dickinson, Ph.D. | "Measure with micrometer;
> > Research Council Officer IMTI-NRC | Mark with chalk;
> > email: john.dickinson++at++nrc.ca | Cut with axe."
> >
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 13:13:45 -0700
> Subject: Re: Inventor file format loader
>
> Allan Schaffer wrote:
> >
> > On May 24, 3:41pm, Dickinson, John wrote:
> > > A bunch of us have noted that inventor files we load into scenes are
often,
> > > if not always, rotated 90 degrees.
> > [...]
> > > However documentation on the loaders is sparse (read almost
non-existent)
> > > and leaves me wondering if the loader for inventor files can be
"tweaked".
> >
> > Definitely. Source code for the Inventor loader is shipped in
> > the performer_dev.src.loader subsystem in Performer 2.2; look to
> > /usr/share/Performer/src/lib/libpfdb/libpfiv
> >
> > > Anyone had similar experience with inventor files being rotated while
> > > loading or tweaked the loader using this or other methods?
> >
> > This (the rotation) is intentional. Inventor has a Y-up world
> > coordinate system, whereas Performer's is Z-up. So when loading
> > inventor files we give it a 90 degree rotation about the X axis so
> > that something modelled "upright" in inventor will appear "upright"
> > in Performer. See line ~2156 of pfiv.C:
> >
> > // Transform from GL/Inventor's Y-up coordinate system to
Performer's Z-up
> > mat.makeRot(90.0f, 1, 0, 0);
> > pfRoot = new pfSCS(mat);
>
> unless this scene is flattened (and it probably is) the object space
> coords will remain in inventor axes and you should be able to work in
> Inventor coordinates at least in the object space below this SCS. You
> might find that useful. If this is not the case then remove pfFlatten
> calls on or above the SCS.
>
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
>
>
****************************************************************************
**
>
> From: Marcin Romaszewicz <marcin++at++asmodean.engr.sgi.com>
> Date: Wed, 24 May 2000 13:22:18 -0700
> Subject: Re: pfProject Texture and transparent textures
>
>
> Hi Devrim,
>
> Which version of performer are you using? We did a major rewrite of the
> projective texture code in 2.2.5 to solve exactly this problem. There are
> sevral flags that you can pass to pfChannel::setTravMode which can be used
>
> to fine-tune the multipass behavior:
> #define PFMPASS_EMISSIVE_PASS 0x2
>
> This must be enabled if you have emissive geometry, which requires an
> extra pass.
>
> #define PFMPASS_NONTEX_SCENE 0x4
>
> This flag lets us skip a pass in the case of a non-textured scene.
>
> #define PFMPASS_NO_TEXTURE_ALPHA 0x8
>
> If there is no texture based transparency, we can skip another pass. For
> your trees, you want this flag off.
>
> #define PFMPASS_FORCE_MULTISAMPLE 0x10
>
> Multisampling greatly simplifies the multipass algorithm. In cases where
> there is no translucency, only full transparency or full opacity, the
> multisample version of the algorithm will work faster even on machines
> without multisampling hardware. This flag forces the multisample
> transparency mode.
>
> #define PFMPASS_BLACK_PASS 0x20
>
> If you see opaque objects in your scene appear translucent, turn on this
> flag, it will fix the problem at the cost of an extra pass.
>
>
> -- Marcin
>
>
> On Wed, 24 May 2000, devrim wrote:
>
> > Hi,
> >
> > I have been using performer projected textures within my application (
> > based on the sample in the man page ) . We also have transparent
> > textured billboards which are used for lens flare and static shadows. At
> > some point project texture is enabled and then at some point again it is
> > disabled. I have noticed that when I use projected textures transparent
> > textures look as if alpha bits are set to 1. When I don't enable
> > projected textures, it is just fine, we have nice transparency. It looks
> > like the color bit count has also decreased.
> >
> > Any ideas ?
> >
> > /*===============================================
> > M. Devrim Erdem devrim++at++infotron.com.tr
> > Simulation Software Development
> > info(+)TRON, Turkey
> > Tel: +90 216 4921002, Ext 138
> > Fax: +90 216 3432132
> > http://www.infotron-tr.com
> > http://abone.turk.net/mderdem
> > ===============================================*/
> >
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
>
>
****************************************************************************
**
>
> From: Jason Daly <jdaly++at++ist.ucf.edu>
> Date: Wed, 24 May 2000 16:29:45 -0400 (EDT)
> Subject: Multipipe on Linux
>
>
> Has anyone had any success getting a multipipe configuration working under
> Linux? Does Performer 2.3 for Linux even support it?
>
> I'm looking to drive a stereo HMD with a Linux box. If anyone has
> any pointers on how this might be done I'd appreciate it.
>
> My configuration is a P2-300 with an Nvidia GeForce DDR card in the AGP
> slot and two 3dfx Voodoo3 3000's in PCI slots. I'm running Redhat 6.2
> with XFree86 4.0.
>
> Thanks,
>
> --"J"
>
> Jason Daly
> jdaly++at++ist.ucf.edu
>
> "I'm a castaway stranded in a desolate land,
> I can see the footprints in the virtual sand."
> --Neil Peart
>
>
>
>
****************************************************************************
**
>
> From: Tom Flynn <flynnt++at++cthulhu.engr.sgi.com>
> Date: Wed, 24 May 2000 13:44:21 -0700
> Subject: Re: Multipipe on Linux
>
> On Wed, 24 May 2000, Jason Daly wrote:
>
> >
> > Has anyone had any success getting a multipipe configuration working
under
> > Linux?
>
> It is possible to use two graphics cards under Linux with XFree86-4.0 and
> the Xinerama extension. However, currently, you cannot use hw-accelerated
> OpenGL and Xinerama together. You are limited to X only.
>
> > Does Performer 2.3 for Linux even support it?
>
> Not at this time. Mainly due to lack of support for multipipe
> hw-accelerated OpenGL with XFree86-4.0.
>
> tom
>
> --
> "Mongooses are famous for their snake-fighting ability, and are
> almost always victorious because of their speed, agility, and timing
> and also because of their thick coat."
>
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 13:52:06 -0700
> Subject: Re: Multipipe on Linux
>
> This cannot work with a single app right now.
>
> It might be possible by running two copies of Performer as separate
> applications but you need DRI based drivers to handle the dispatch of
> OpenGL to the right card with this type of config and the nVidia drivers
> don't use that framework but use their own fast dispatch method so you'd
> need to mess around with which different version of OpenGL libs that the
> two copies of Performer linked to so that the nvidia display got
> hardware acceleration via the SGI nVidia drivers and the voodoo's (SLI I
> assume) worked via the DRI drivers.
>
> This is my best guess as to what you need to do, I haven't tried this, I
> expect you'll be the pioneer if you proceed with your plan.
>
> The stereo will be horrid since there will be no sync of refresh, swaps
> or update. You could do a little bit in software through shared memory
> but you's will at least like to block on frame completion before the
> swap probably just after pfDraw and that will slow you down. There will
> also inevitably be some subtle and perhaps not so subtle differences in
> rendering outbut between the eyes with this kind of heterogeneous
> solution.
>
> This all kind of assumes that you are aiming for a GeForce + voodoo3 SLI
> combo. A more homogeneous 2X voodoo3 solution would be less troublesome
> but slower.
>
> Cheers,ANgus.
>
> Jason Daly wrote:
> >
> > Has anyone had any success getting a multipipe configuration working
under
> > Linux? Does Performer 2.3 for Linux even support it?
> >
> > I'm looking to drive a stereo HMD with a Linux box. If anyone has
> > any pointers on how this might be done I'd appreciate it.
> >
> > My configuration is a P2-300 with an Nvidia GeForce DDR card in the AGP
> > slot and two 3dfx Voodoo3 3000's in PCI slots. I'm running Redhat 6.2
> > with XFree86 4.0.
> >
> > Thanks,
> >
> > --"J"
> >
> > Jason Daly
> > jdaly++at++ist.ucf.edu
> >
> > "I'm a castaway stranded in a desolate land,
> > I can see the footprints in the virtual sand."
> > --Neil Peart
> >
> > -----------------------------------------------------------------------
> > 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: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 14:03:45 -0700
> Subject: Re: Multipipe on Linux
>
> This suggestion won't work.
>
> The DRI does not yet support multicard GLX and you can only have one GLX
> implementation with XFree86 4.0. So, you might be able to rig something
> with two completely separate X servers with their own GLX
> implementations, one from nVidia and the other DRI and change all the
> linking stuff as already mentioned and run multiple copies of Performer.
> There may be other caveats and it may not be possible to configure this
> correctly, at the very least it would be difficult (an understatement
> :-).
>
> Cheers,Angus.
>
> Angus Dorbie wrote:
> >
> > This cannot work with a single app right now.
> >
> > It might be possible by running two copies of Performer as separate
> > applications but you need DRI based drivers to handle the dispatch of
> > OpenGL to the right card with this type of config and the nVidia drivers
> > don't use that framework but use their own fast dispatch method so you'd
> > need to mess around with which different version of OpenGL libs that the
> > two copies of Performer linked to so that the nvidia display got
> > hardware acceleration via the SGI nVidia drivers and the voodoo's (SLI I
> > assume) worked via the DRI drivers.
> >
> > This is my best guess as to what you need to do, I haven't tried this, I
> > expect you'll be the pioneer if you proceed with your plan.
> >
> > The stereo will be horrid since there will be no sync of refresh, swaps
> > or update. You could do a little bit in software through shared memory
> > but you's will at least like to block on frame completion before the
> > swap probably just after pfDraw and that will slow you down. There will
> > also inevitably be some subtle and perhaps not so subtle differences in
> > rendering outbut between the eyes with this kind of heterogeneous
> > solution.
> >
> > This all kind of assumes that you are aiming for a GeForce + voodoo3 SLI
> > combo. A more homogeneous 2X voodoo3 solution would be less troublesome
> > but slower.
> >
> > Cheers,ANgus.
> >
> > Jason Daly wrote:
> > >
> > > Has anyone had any success getting a multipipe configuration working
under
> > > Linux? Does Performer 2.3 for Linux even support it?
> > >
> > > I'm looking to drive a stereo HMD with a Linux box. If anyone has
> > > any pointers on how this might be done I'd appreciate it.
> > >
> > > My configuration is a P2-300 with an Nvidia GeForce DDR card in the
AGP
> > > slot and two 3dfx Voodoo3 3000's in PCI slots. I'm running Redhat 6.2
> > > with XFree86 4.0.
> > >
> > > Thanks,
> > >
> > > --"J"
> > >
> > > Jason Daly
> > > jdaly++at++ist.ucf.edu
> > >
> > > "I'm a castaway stranded in a desolate land,
> > > I can see the footprints in the virtual sand."
> > > --Neil Peart
> > >
> >
> -----------------------------------------------------------------------
> > > 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
> > -----------------------------------------------------------------------
> > 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: Jason Daly <jdaly++at++ist.ucf.edu>
> Date: Wed, 24 May 2000 17:04:52 -0400 (EDT)
> Subject: Re: Multipipe on Linux
>
> On Wed, 24 May 2000, Angus Dorbie wrote:
>
> > This cannot work with a single app right now.
> >
> > This all kind of assumes that you are aiming for a GeForce + voodoo3 SLI
> > combo. A more homogeneous 2X voodoo3 solution would be less troublesome
> > but slower.
> >
>
> Actually, the 2x Voodoo3 configuration was the idea. The concept was to
> have the Nvidia driving a regular CRT and X desktop while the voodoos ran
> the performer app on the HMD (we were optimistic from the start :-) ).
> If I removed the Nvidia from the equation completely (I'm working on this
> at the moment), how much simpler do you think it would be to get it
> working?
>
> --"J"
>
> "I'm a castaway stranded in a desolate land,
> I can see the footprints in the virtual sand."
> --Neil Peart
>
>
>
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 14:17:02 -0700
> Subject: Re: Multipipe on Linux
>
> Perversely it may make it more difficult because you then have a single
> GLX implementation and the multicard support isn't working in the DRI
> yet.
>
> Cheers,Angus.
>
> Jason Daly wrote:
> >
> > On Wed, 24 May 2000, Angus Dorbie wrote:
> >
> > > This cannot work with a single app right now.
> > >
> > > This all kind of assumes that you are aiming for a GeForce + voodoo3
SLI
> > > combo. A more homogeneous 2X voodoo3 solution would be less
troublesome
> > > but slower.
> > >
> >
> > Actually, the 2x Voodoo3 configuration was the idea. The concept was to
> > have the Nvidia driving a regular CRT and X desktop while the voodoos
ran
> > the performer app on the HMD (we were optimistic from the start :-) ).
> > If I removed the Nvidia from the equation completely (I'm working on
this
> > at the moment), how much simpler do you think it would be to get it
> > working?
> >
> > --"J"
> >
> > "I'm a castaway stranded in a desolate land,
> > I can see the footprints in the virtual sand."
> > --Neil Peart
> >
> > -----------------------------------------------------------------------
> > 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: Tom Flynn <flynnt++at++cthulhu.engr.sgi.com>
> Date: Wed, 24 May 2000 14:29:19 -0700
> Subject: Re: Multipipe on Linux
>
> On Wed, 24 May 2000, Angus Dorbie wrote:
>
> > This cannot work with a single app right now.
> >
> > It might be possible by running two copies of Performer as separate
> > applications but you need DRI based drivers to handle the dispatch of
> > OpenGL to the right card with this type of config
>
> slight correction here...currently neither DRI or Nvidia drivers handle
> multiple cards. Both drivers are designed so that such a thing could be
> possible, but it has yet to be implemented.
>
> > and the nVidia drivers
> > don't use that framework but use their own fast dispatch method so you'd
> > need to mess around with which different version of OpenGL libs that the
> > two copies of Performer linked to so that the nvidia display got
> > hardware acceleration via the SGI nVidia drivers and the voodoo's (SLI I
> > assume) worked via the DRI drivers.
> >
> > This is my best guess as to what you need to do, I haven't tried this, I
> > expect you'll be the pioneer if you proceed with your plan.
> >
> > The stereo will be horrid since there will be no sync of refresh, swaps
>
> I don't believe stereo is supported in either driver at this time. As to
> swap on vertical retrace, that can be enabled via an environment variable
> (GL_SYNC_TO_VBLANK) on our 230 systems. I don't believe the DRI driver
> currently supports swap on vertical retrace.
>
> > or update. You could do a little bit in software through shared memory
> > but you's will at least like to block on frame completion before the
> > swap probably just after pfDraw and that will slow you down.
>
> This really needs to be done inside the driver where you can have control
> over when data gets sent down the FIFO. You might be able to fudge
> something using the SYNC extension to XFree86, but it might be
> difficult to make sure OpenGL is sync'd as expected. Again, this should
> really be done in the driver.
>
> tom
> --
> "Mongooses are famous for their snake-fighting ability, and are
> almost always victorious because of their speed, agility, and timing
> and also because of their thick coat."
>
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 14:52:29 -0700
> Subject: Re: Multipipe on Linux
>
> Thanks, I tried to put out a correction in a followon post.
>
> On the stereo issue, the attempt was not to get direct stereo support
> from the card but to use two independent channels to produce stereo. So
> stereo support at the card/driver level is not really the issue in this
> scenario. The sync I was referring to is not of swap to vertical retrace
> but the genlock across eyes and the equivalent of swapready. In this
> instance given that you can't genlock, deliberately not syncing to
> vertical retrace may be a better option since you will need some kind of
> handshake between draw processes. Without genlock this could introduce a
> significant delay with swap sync to refresh, and the stereo artifacts
> aren't necessarily worse in either scenario.
>
> Cheers,Angus.
>
> Tom Flynn wrote:
> >
> > On Wed, 24 May 2000, Angus Dorbie wrote:
> >
> > > This cannot work with a single app right now.
> > >
> > > It might be possible by running two copies of Performer as separate
> > > applications but you need DRI based drivers to handle the dispatch of
> > > OpenGL to the right card with this type of config
> >
> > slight correction here...currently neither DRI or Nvidia drivers handle
> > multiple cards. Both drivers are designed so that such a thing could be
> > possible, but it has yet to be implemented.
> >
> > > and the nVidia drivers
> > > don't use that framework but use their own fast dispatch method so
you'd
> > > need to mess around with which different version of OpenGL libs that
the
> > > two copies of Performer linked to so that the nvidia display got
> > > hardware acceleration via the SGI nVidia drivers and the voodoo's (SLI
I
> > > assume) worked via the DRI drivers.
> > >
> > > This is my best guess as to what you need to do, I haven't tried this,
I
> > > expect you'll be the pioneer if you proceed with your plan.
> > >
> > > The stereo will be horrid since there will be no sync of refresh,
swaps
> >
> > I don't believe stereo is supported in either driver at this time. As
to
> > swap on vertical retrace, that can be enabled via an environment
variable
> > (GL_SYNC_TO_VBLANK) on our 230 systems. I don't believe the DRI driver
> > currently supports swap on vertical retrace.
> >
> > > or update. You could do a little bit in software through shared memory
> > > but you's will at least like to block on frame completion before the
> > > swap probably just after pfDraw and that will slow you down.
> >
> > This really needs to be done inside the driver where you can have
control
> > over when data gets sent down the FIFO. You might be able to fudge
> > something using the SYNC extension to XFree86, but it might be
> > difficult to make sure OpenGL is sync'd as expected. Again, this should
> > really be done in the driver.
> >
> > tom
> > --
> > "Mongooses are famous for their snake-fighting ability, and are
> > almost always victorious because of their speed, agility, and timing
> > and also because of their thick coat."
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
>
>
****************************************************************************
**
>
> From: "Braun, Tom" <tom.braun++at++lmco.com>
> Date: Wed, 24 May 2000 17:55:48 -0400
> Subject: Question about Isetor intersection test against the scene graph
>
>
> I originally posted this question in February. Unfortunately, I still =
> don't
> know if there is a fix for this problem in Performer. Can anyone help?
>
>
> "Braun, Tom (UNKNOWN)" wrote:=20
> >=20
> > Has anyone had a problem with the return vector values from a isector
> test?=20
> > I have set up a isector segment to look straight down in order to =
> perform=20
> > terrain following. Over most all of my terrain the Terrain Height =
> that is=20
> > returned to me is correct. However, over some parts of the terrain, =
> the=20
> > height of the terrain that gets reported back to me is 10 to 50 feet =
> below
>
> > the actual terrain height. Every polygon of my=20
> > database has been flagged at "terrain".=20
> >=20
> > Here is a snippet of how I perform my intersect:=20
> >=20
> > double PerformerDisplayWindow::GetTerrainHeight (double x, double y)=20
> > {=20
> > pfSegSet segset;=20
> > long isect;=20
> > pfHit **hits[10];=20
> > double z=3D 10000.0f;=20
> > double TerrainHeight =3D 0.0f;=20
> >=20
> > segset.activeMask =3D 0x1;=20
> > segset.isectMask =3D 0xFFFF;=20
> > segset.discFunc =3D NULL;=20
> > segset.bound =3D NULL;=20
> > segset.mode =3D PFTRAV_IS_PRIM|PFTRAV_IS_NORM|PFTRAV_IS_CULL_BACK;=20
> > segset.segs[0].dir.set(0.0f, 0.0f, -1.0f);=20
> > segset.segs[0].length =3D 50000.0f;=20
> > segset.segs[0].pos.set(x,y,z);=20
> > isect =3D Shared->model->isect(&segset,hits);=20
> > if(isect){=20
> > pfVec3 pnt;=20
> > (*hits[0])->query(PFQHIT_POINT, pnt.vec);=20
> > TerrainHeight =3D pnt[2];=20
> > }=20
> > else {=20
> > cout << "Warning: No terrain found at this location. TerrainHeight is =
>
> > being set to zero."<<endl;=20
> > TerrainHeight =3D 0;=20
> > }=20
> > return(TerrainHeight);=20
> > }=20
>
> Dirk L=FCsebrink was kind enough to send me a response and said that he =
> had
> the same problem. His solution was to "get all intersections from the
> isector vector and sort this list by hand. with just seven hits and a =
> 300=20
> MHZ cpu that is not such a performance problem, even when there are =
> some
> square roots involved."
>
> To this Angus Dorbie wrote "I don't think intersection results are =
> intended
> to be in depth sorted=20
> order. "
>
> Dirk's solution sounds reasonable to me. Has anyone found another =
> method
> for getting the HAT isector to work?
> =20
>
>
****************************************************************************
**
>
> From: Angus Dorbie <dorbie++at++sgi.com>
> Date: Wed, 24 May 2000 15:51:45 -0700
> Subject: Re: Question about Isetor intersection test against the scene
graph
>
>
> I think you've misunderstood what I was trying to say, especially since
> you are still asking for a 'fix'. There is no fix, isectors are not
> supposed to operate the way you assumed they would.
>
> I was trying to point out that this is not a bug which had previously
> been suggested in the thread. Your application may require the results
> depth ordered but my original response was not intended to be about your
> requirement. I was trying to correct the assumption being made that they
> should be depth sorted by performer in the isector. I'm sorry you've
> been waiting on a further response, I hoped that the solution presented
> by Dirk was sufficient when combined with my offering that the
> functionality you desired was not part of the isector behaviour.
>
> To depth sort hit results you do not require a square root, just compare
> the sum of the squares and for HAT results you probably only need to
> test the z component of the return value, you don't even have to
> subtract to produce the vector components before the test. This should
> be a very fast test.
>
> Cheers,ANgus.
>
>
> "Braun, Tom" wrote:
> >=20
> > I originally posted this question in February. Unfortunately, I still =
> don't
> > know if there is a fix for this problem in Performer. Can anyone help?
> >=20
> > "Braun, Tom (UNKNOWN)" wrote:
> > >
> > > Has anyone had a problem with the return vector values from a isector
> > test?
> > > I have set up a isector segment to look straight down in order to per=
> form
> > > terrain following. Over most all of my terrain the Terrain Height tha=
> t is
> > > returned to me is correct. However, over some parts of the terrain, t=
> he
> > > height of the terrain that gets reported back to me is 10 to 50 feet =
> below
> >=20
> > > the actual terrain height. Every polygon of my
> > > database has been flagged at "terrain".
> > >
> > > Here is a snippet of how I perform my intersect:
> > >
> > > double PerformerDisplayWindow::GetTerrainHeight (double x, double y)
> > > {
> > > pfSegSet segset;
> > > long isect;
> > > pfHit **hits[10];
> > > double z=3D 10000.0f;
> > > double TerrainHeight =3D 0.0f;
> > >
> > > segset.activeMask =3D 0x1;
> > > segset.isectMask =3D 0xFFFF;
> > > segset.discFunc =3D NULL;
> > > segset.bound =3D NULL;
> > > segset.mode =3D PFTRAV_IS_PRIM|PFTRAV_IS_NORM|PFTRAV_IS_CULL_BACK;
> > > segset.segs[0].dir.set(0.0f, 0.0f, -1.0f);
> > > segset.segs[0].length =3D 50000.0f;
> > > segset.segs[0].pos.set(x,y,z);
> > > isect =3D Shared->model->isect(&segset,hits);
> > > if(isect){
> > > pfVec3 pnt;
> > > (*hits[0])->query(PFQHIT_POINT, pnt.vec);
> > > TerrainHeight =3D pnt[2];
> > > }
> > > else {
> > > cout << "Warning: No terrain found at this location. TerrainHeight is
> > > being set to zero."<<endl;
> > > TerrainHeight =3D 0;
> > > }
> > > return(TerrainHeight);
> > > }
> >=20
> > Dirk L=FCsebrink was kind enough to send me a response and said that he=
> had
> > the same problem. His solution was to "get all intersections from the
> > isector vector and sort this list by hand. with just seven hits and a 3=
> 00
> > MHZ cpu that is not such a performance problem, even when there are som=
> e
> > square roots involved."
> >=20
> > To this Angus Dorbie wrote "I don't think intersection results are inte=
> nded
> > to be in depth sorted
> > order. "
> >=20
> > Dirk's solution sounds reasonable to me. Has anyone found another meth=
> od
> > for getting the HAT isector to work?
> >=20
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --=20
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."=20
> --Albert Einstein
>
>
****************************************************************************
**
>
>
>
This archive was generated by hypermail 2b29 : Thu May 25 2000 - 08:18:35 PDT