Info-Performer Mailing List Archives: RE: info-performer Nov 10

-- Profile Computersysteme Ges.m.b.H. A-6020 Innsbruck Eduard-Bodem-Gasse 6 Email: gm++at++profile.co.at Telefon:+43 512 341934-16 Fax:+43 512 341934-20

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i

mQCNAza1s+8AAAEEAJv+dijN5v7KqW8H6kJ/AgUca53v+CARA+JSDV4rEsePd0F7 pgsQw19CKJHZUC3MYbzXmx3q0g3gP8IzOoVmrh5lj3oelwyNjPLl6uXDRmCl4Yy5 4eoMF2xnnHdKd32PIwvCiClmmAc110+xsaBB1VEeQ0FfrHUpF9jMEcGAWbFJAAUR tCNHZXJoYXJkIE1vZWx0bmVyIDxnbUBwcm9maWxlLmNvLmF0PokAlQMFEDa1s+/Y zBHBgFmxSQEBIZoD/0kgCSXkzEv7cM2OqcUCG6XrkHq4yvcIdmtFKXfGcs9f0p6H Hvt+wsy2ONssQX1ZShlif3fjgk8Xlp50bIjcTZzEZw/CQgITkttfQ2xelkUUcmEW EmO9s9/UgV1X6Y4NjlKHdiLE7aA2EQ7SbWJ0JRepgzTCIlQTG79ALQrWJ3D7 =OgNH -----END PGP PUBLIC KEY BLOCK-----

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

From: Scott Herod <herod++at++aspen.evt.com> Date: Wed, 10 Nov 1999 09:29:07 -0700 Subject: Re: Memory leaks I'll second Brian's note and add that I find it really useful to place occasional blocks that you mallinfo() to check arena memory. See the mallinfo man page.

With regards to purify, I think that you should start the project using it. We've found that trying to get it to work with a large, existing project is very hard.

Scott

Brian Furtaw wrote: > > I use Purify and cvd memory leak checking tools to find bugs, I find the > watch points in cvd especially useful. Watch points may exist in dbx but > I have never been able to get them working. A man on ssmalloc_error > (SpeedShop) or cvmalloc_error will explain some environment variables > you can set to help you debug memory problems. Remeber to link with > -lmalloc_cv or -lmalloc_ss respectively. > > Brian > > Satheesh Ganapathi Subramanian wrote: > > > > Hi Performers, > > > > This question might not be related to performer, but I cannot find a more > > resourceful mailing list than this. > > > > I'm looking for possible profiling tools/ tools for finding memory leaks > > etc. Are there any freewares/sharewares available for the SGI platform and > > that are good for debugging graphics apps. > > > > Sorry if this question is really off topic. > > > > Thanks, > > Satheesh > > > >

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

From: Thomas Ruge <Thomas.Ruge++at++gmx.de> Date: Tue, 10 Nov 1998 19:30:44 +0100 Subject: multiscreen and perf2.3b2 Hello everybody,

we are running a 3 channel projection on a 180=B0 wall in our Virtual Reality Labor at Siemens in Munich with an Onyx2 Deskside. =

Now i installed perf2.3b2 on Linux on our PC which worked quite nice and runs. On our PC i am running a Multiscreen, OpenGL capable X-server together with 3 graphic cards. To make 3 different perfly's running on these 3 cards works well, but now i am looking for a way to make one perfly running on the 3 graphic cards calculating the correct perspectives on these 3 projections. I think this needs some work from my side on the perfly source, which is part of =

perf2.3b2. Has somebody a hint what i have to change to get running perfly on my 3 "pipes" ? What i have to change to get 3 different views from one object. =

Thanks in advance,

Thomas

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

From: Bernard Leclerc <bernard.leclerc++at++discreet.com> Date: Wed, 10 Nov 1999 14:36:07 -0500 Subject: Round trip query to the X server. Reply-To: Bernard.Leclerc++at++discreet.com

Platform: O2, IRIX 6.5.4f, performer_dev 2.2, performer_eoe 2.2.5

We all know that doing a round trip request to the X server is a NO when real-time and stable update rates are required. Somehow, it seems to be the case here. I've been able to observe this behavior with simple.C

Here is how. Use "par" to monitor the system activity while "simple" is running. The following command will monitor system calls to "read" and "select" for 3 seconds and write the results into file "simple.par".

$ par -s -SS -n read -n select -o simple.par -u -t 3 simple x29.sv

The file is fairly long but, near the end, you'll notice a steady state that resemble this:

2159mS: read(7, <01 18 01 49 00>..., 32) =3D 32 2161mS: read(7, 0x7fff28c0, 32) errno =3D 11 (Resource temporarily unavailable) 2161mS: select(8, [7], 0, 0, 0) 2162mS: END-select(8, [7], 0, 0, 0) =3D 1

Notice the "Resource temporarily unavailable" message while reading from file descriptor 7. Also notice that the process will go to sleep because of the call to select().

Now if we use dbx to find out where the program calls read(), the stack trace looks like this (I've simplified the output to increase readability):

(dbx) t > 0 __select() [".../select.s":17, 0xfafc008] 1 _select() [".../selectSCI.c":30, 0xfb059f0] 2 _XRead() [".../XlibInt.c":492, 0xf71c29c] 3 _XReply() [".../XlibInt.c":1858, 0xf71e368] 4 XGetGeometry() [".../GetGeom.c":43, 0xf6f7890] 5 __glXGetDrawableSize() [".../glx_direct.c":358, 0xd993bd0] 6 FindWindowSize() [".../crm_context.c":260, 0xda51730] 7 ApplyViewport() [".../crm_context.c":274, 0xda51844] 8 __glim_Viewport() [".../so_xform.c":555, 0xdb39ce0] 9 pfChannel::pf_applyView() [".../pfChannel.C":4518, 0x5860e90] 10 ::pfFrame() [".../pfProcess.C":6283, 0x58a5278] 11 ::main() [".../simple.C":144, 0x10002cd4] 12 __start() [".../crt1text.s":177, 0x100025d8] (dbx) q

This is strange. If you follow the trace from level 9, you see that Performer calls the Open GL library to re-apply the viewport. In turn, OpenGL calls X to obtain the window size. THAT'S causing the round trip request to the X server... and that breaks the stable update rate.

Ok, you're gonna say that the O2 isn't capable of real-time performance. I know! But I still don't see why there's a need to get the window size when it hasn't changed.

I also tried with

pw->setWinType(PFPWIN_TYPE_X | PFPWIN_TYPE_NOXEVENTS); pw->setFullScreen();

but that didn't helped.

So the question remains: why is Performer/OpenGL doing a round trip request to the X server when no X event has been received to justify the query?

Is this a bug in Performer? Or is it a problem with OpenGL on O2?

Note that this behavior can't be seen on the Octane. It seems to be specific to the O2.

-- =

bernard leclerc* *from discreet, a division of AutoDesk t 514.954.7317 10, rue duke f 514.393.0110 montr=E9al (qu=E9bec) canada, H3C 2L7 mailto:bernardL++at++discreet.com http://www.discreet.com

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

From: allan++at++sgi.com (Allan Schaffer) Date: Wed, 10 Nov 1999 13:16:32 -0800 (PST) Subject: Mesa download sites for Beta 2.0 Hello Performers,

Just a quick note for those of you beginning to use Beta 2.0 of Performer 2.3 for Linux:

Our FAQ (http://www.sgi.com/software/performer/linux-faq.html#5) lists the dependencies of this release, among them Mesa 3.1 Beta #3. It also provides some direct links to the Mesa binaries, as well as links to the Mesa web site.

If you downloaded your Mesa binaries from the direct links in the FAQ then all is well, you can quit reading here.

But if you followed the links to www.mesa3d.org, and from there on to the download site listed for precompiled Mesa 3.1 Beta #3 rpm's:

ftp://ftp.falsehope.com/pub/Mesa/

Please go back and follow their further links to:

ftp://ftp.falsehope.com/pub/Mesa/rh6.0/ or ftp://ftp.falsehope.com/pub/Mesa/rh6.1/

or just use our local mirror, http://reality.sgi.com/performer/mesa/

The Mesa RPMs in falsehope.com's base '/pub/Mesa' directory are intended for RedHat 5.2 with glibc 2.0, but aren't clearly labelled as such. Performer requires glibc 2.1.x [shipped in RedHat6.0+] so it won't work with them.

Again, if you followed the direct links in our FAQ then you're fine. Those lead to our own mirror of the '/rh6.0' version. It's only if you got creative that you might encounter this problem.

Allan

-- 
Allan Schaffer                                            allan++at++sgi.com
Silicon Graphics                           http://reality.sgi.com/allan

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

 From: "Dan Mapes" <dmapes++at++roninworks.com>
 Date: Thu, 11 Nov 1999 00:59:36 +0100
 Subject: Re: Round trip query to the X server.
 
This is a multi-part message in MIME format.

------=_NextPart_000_0032_01BF2BE0.062BB6A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I don't know exactly why Performer makes this call but I recently ran =
across
the following unrelated info-performer archive from 1995 complements of =
Wade
Olsen which mentions this problem and provides source code showing a =
work
around by rewriting the following two functions...

void getorigin( long *x, long *y );
void getsize( long *x, long *y );

So I guess it's nothing new. Check it out...

http://reality.sgi.com/performer/perf-95-03/0228.html

-------------------------------------------------------------------------=
---
Dan Mapes                       GSM: +31 621 264589
RoninWorks BV                http://www.RoninWorks.com
Vechtensteinlaan 24
3601 CK Maarssen
Netherlands
-------------------------------------------------------------------------=
---

-----Original Message-----
From: Bernard Leclerc <bernard.leclerc++at++discreet.com>
To: info-performer++at++sgi.com <info-performer++at++sgi.com>
Cc: Jean-Luc.Dery++at++discreet.com <Jean-Luc.Dery++at++discreet.com>
Date: Wednesday, November 10, 1999 8:56 PM
Subject: Round trip query to the X server.


>Platform: O2, IRIX 6.5.4f, performer_dev 2.2, performer_eoe 2.2.5
>
>We all know that doing a round trip request to the X server is a NO =
when
>real-time and stable update rates are required. Somehow, it seems to be
>the case here. I've been able to observe this behavior with simple.C
>
>Here is how. Use "par" to monitor the system activity while "simple" is
>running. The following command will monitor system calls to "read" and
>"select" for 3 seconds and write the results into file "simple.par".
>
> $ par -s -SS -n read -n select -o simple.par -u -t 3 simple x29.sv
>
>The file is fairly long but, near the end, you'll notice a steady state
>that resemble this:
>
>2159mS: read(7, <01 18 01 49 00>..., 32) =3D 32
>2161mS: read(7, 0x7fff28c0, 32) errno =3D 11 (Resource temporarily
>unavailable)
>2161mS: select(8, [7], 0, 0, 0)
>2162mS: END-select(8, [7], 0, 0, 0) =3D 1
>
>
>Notice the "Resource temporarily unavailable" message while reading =
from
>file descriptor 7. Also notice that the process will go to sleep =
because
>of the call to select().
>
>Now if we use dbx to find out where the program calls read(), the stack
>trace looks like this (I've simplified the output to increase
>readability):
>
>(dbx) t
>>  0 __select() [".../select.s":17, 0xfafc008]
>   1 _select() [".../selectSCI.c":30, 0xfb059f0]
>   2 _XRead() [".../XlibInt.c":492, 0xf71c29c]
>   3 _XReply() [".../XlibInt.c":1858, 0xf71e368]
>   4 XGetGeometry() [".../GetGeom.c":43, 0xf6f7890]
>   5 __glXGetDrawableSize() [".../glx_direct.c":358, 0xd993bd0]
>   6 FindWindowSize() [".../crm_context.c":260, 0xda51730]
>   7 ApplyViewport() [".../crm_context.c":274, 0xda51844]
>   8 __glim_Viewport() [".../so_xform.c":555, 0xdb39ce0]
>   9 pfChannel::pf_applyView() [".../pfChannel.C":4518, 0x5860e90]
>   10 ::pfFrame() [".../pfProcess.C":6283, 0x58a5278]
>   11 ::main() [".../simple.C":144, 0x10002cd4]
>   12 __start() [".../crt1text.s":177, 0x100025d8]
>(dbx) q
>
>
>This is strange. If you follow the trace from level 9, you see that
>Performer calls the Open GL library to re-apply the viewport. In turn,
>OpenGL calls X to obtain the window size. THAT'S causing the round trip
>request to the X server... and that breaks the stable update rate.
>
>Ok, you're gonna say that the O2 isn't capable of real-time =
performance.
>I know! But I still don't see why there's a need to get the window size
>when it hasn't changed.
>
>I also tried with
>
> pw->setWinType(PFPWIN_TYPE_X | PFPWIN_TYPE_NOXEVENTS);
> pw->setFullScreen();
>
>but that didn't helped.
>
>
>So the question remains: why is Performer/OpenGL doing a round trip
>request to the X server when no X event has been received to justify =
the
>query?
>
>
>Is this a bug in Performer? Or is it a problem with OpenGL on O2?
>
>
>Note that this behavior can't be seen on the Octane. It seems to be
>specific to the O2.


------=_NextPart_000_0032_01BF2BE0.062BB6A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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







I don't know exactly why Performer makes this call but I recently =
ran=20
across
the following unrelated info-performer archive from 1995 =
complements=20
of Wade
Olsen which mentions this problem and provides source code =
showing a=20
work
around by rewriting the following two functions...

void=20
getorigin( long *x, long *y );
void getsize( long *x, long *y =
);

So I=20
guess it's nothing new. Check it out...

http://rea=
lity.sgi.com/performer/perf-95-03/0228.html

------------------=
----------------------------------------------------------
Dan=20
Mapes           &n=
bsp;          =20
GSM: +31 621 264589
RoninWorks=20
BV            =
;   =20
http://www.RoninWorks.com
Vecht=
ensteinlaan=20
24
3601 CK=20
Maarssen
Netherlands
----------------------------------------------=
------------------------------

-----Original=20
Message-----
From: Bernard Leclerc <bernard.leclerc++at++discreet.com=
>
To:=20
info-performer++at++sgi.com =
<info-performer++at++sgi.com>
=
Cc: Jean-Luc.Dery++at++discreet.com=
 <Jean-Luc.Dery++at++discreet.com=
>
Date:=20
Wednesday, November 10, 1999 8:56 PM
Subject: Round trip query to the =
X=20
server.


>Platform: O2, IRIX 6.5.4f, performer_dev 2.2,=20
performer_eoe 2.2.5
>
>We all know that doing a round trip =
request=20
to the X server is a NO when
>real-time and stable update rates =
are=20
required. Somehow, it seems to be
>the case here. I've been able =
to=20
observe this behavior with simple.C
>
>Here is how. Use=20
"par" to monitor the system activity while "simple"=20
is
>running. The following command will monitor system calls to=20
"read" and
>"select" for 3 seconds and write =
the=20
results into file "simple.par".
>
> $ par -s -SS =
-n read=20
-n select -o simple.par -u -t 3 simple x29.sv
>
>The file is =
fairly=20
long but, near the end, you'll notice a steady state
>that =
resemble=20
this:
>
>2159mS: read(7, <01 18 01 49 00>..., 32) =3D=20
32
>2161mS: read(7, 0x7fff28c0, 32) errno =3D 11 (Resource=20
temporarily
>unavailable)
>2161mS: select(8, [7], 0, 0,=20
0)
>2162mS: END-select(8, [7], 0, 0, 0) =3D =
1
>
>
>Notice=20
the "Resource temporarily unavailable" message while reading=20
from
>file descriptor 7. Also notice that the process will go to =
sleep=20
because
>of the call to select().
>
>Now if we use dbx =
to find=20
out where the program calls read(), the stack
>trace looks like =
this (I've=20
simplified the output to =
increase
>readability):
>
>(dbx)=20
t
>>  0 __select() [".../select.s":17,=20
0xfafc008]
>   1 _select() =
[".../selectSCI.c":30,=20
0xfb059f0]
>   2 _XRead() =
[".../XlibInt.c":492,=20
0xf71c29c]
>   3 _XReply() =
[".../XlibInt.c":1858,=20
0xf71e368]
>   4 XGetGeometry() =
[".../GetGeom.c":43,=20
0xf6f7890]
>   5 __glXGetDrawableSize()=20
[".../glx_direct.c":358, 0xd993bd0]
>   6=20
FindWindowSize() [".../crm_context.c":260,=20
0xda51730]
>   7 ApplyViewport()=20
[".../crm_context.c":274, 0xda51844]
>   8=20
__glim_Viewport() [".../so_xform.c":555,=20
0xdb39ce0]
>   9 pfChannel::pf_applyView()=20
[".../pfChannel.C":4518, 0x5860e90]
>   10 =
::pfFrame()=20
[".../pfProcess.C":6283, 0x58a5278]
>   11 =
::main()=20
[".../simple.C":144, 0x10002cd4]
>   12 =
__start()=20
[".../crt1text.s":177, 0x100025d8]
>(dbx)=20
q
>
>
>This is strange. If you follow the trace from =
level 9,=20
you see that
>Performer calls the Open GL library to re-apply the=20
viewport. In turn,
>OpenGL calls X to obtain the window size. =
THAT'S=20
causing the round trip
>request to the X server... and that breaks =
the=20
stable update rate.
>
>Ok, you're gonna say that the O2 =
isn't=20
capable of real-time performance.
>I know! But I still don't see =
why=20
there's a need to get the window size
>when it hasn't=20
changed.
>
>I also tried with
>
>=20
pw->setWinType(PFPWIN_TYPE_X | PFPWIN_TYPE_NOXEVENTS);
>=20
pw->setFullScreen();
>
>but that didn't=20
helped.
>
>
>So the question remains: why is =
Performer/OpenGL=20
doing a round trip
>request to the X server when no X event has =
been=20
received to justify the
>query?
>
>
>Is this a =
bug in=20
Performer? Or is it a problem with OpenGL on =
O2?
>
>
>Note=20
that this behavior can't be seen on the Octane. It seems to =
be
>specific=20
to the O2.


------=_NextPart_000_0032_01BF2BE0.062BB6A0--


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

 From: Phil Keslin 
 Date: Wed, 10 Nov 1999 16:08:07 -0800
 Subject: Re: Round trip query to the X server.
 
On the O2 the glViewport request is actually performed in the library as =
opposed
to the graphics pipe. To function properly, the code needs the geometry o=
f the
window at the time the viewport request is made.

At present, Performer does not track the viewport state. This requires th=
at the
viewport be reset every frame (and hence the window geometry is retrieved=
 every
frame). We have looked at fixing this in the past, but haven't addressed =
it yet.
This problem is only exhibited on the O2.

- Phil

Bernard Leclerc wrote:
>=20
> Platform: O2, IRIX 6.5.4f, performer_dev 2.2, performer_eoe 2.2.5
>=20
> We all know that doing a round trip request to the X server is a NO whe=
n
> real-time and stable update rates are required. Somehow, it seems to be
> the case here. I've been able to observe this behavior with simple.C
>=20
> Here is how. Use "par" to monitor the system activity while "simple" is
> running. The following command will monitor system calls to "read" and
> "select" for 3 seconds and write the results into file "simple.par".
>=20
>         $ par -s -SS -n read -n select -o simple.par -u -t 3 simple x29=
.sv
>=20
> The file is fairly long but, near the end, you'll notice a steady state
> that resemble this:
>=20
> 2159mS: read(7, <01 18 01 49 00>..., 32) =3D 32
> 2161mS: read(7, 0x7fff28c0, 32) errno =3D 11 (Resource temporarily
> unavailable)
> 2161mS: select(8, [7], 0, 0, 0)
> 2162mS: END-select(8, [7], 0, 0, 0) =3D 1
>=20
> Notice the "Resource temporarily unavailable" message while reading fro=
m
> file descriptor 7. Also notice that the process will go to sleep becaus=
e
> of the call to select().
>=20
> Now if we use dbx to find out where the program calls read(), the stack
> trace looks like this (I've simplified the output to increase
> readability):
>=20
> (dbx) t
> >  0 __select() [".../select.s":17, 0xfafc008]
>    1 _select() [".../selectSCI.c":30, 0xfb059f0]
>    2 _XRead() [".../XlibInt.c":492, 0xf71c29c]
>    3 _XReply() [".../XlibInt.c":1858, 0xf71e368]
>    4 XGetGeometry() [".../GetGeom.c":43, 0xf6f7890]
>    5 __glXGetDrawableSize() [".../glx_direct.c":358, 0xd993bd0]
>    6 FindWindowSize() [".../crm_context.c":260, 0xda51730]
>    7 ApplyViewport() [".../crm_context.c":274, 0xda51844]
>    8 __glim_Viewport() [".../so_xform.c":555, 0xdb39ce0]
>    9 pfChannel::pf_applyView() [".../pfChannel.C":4518, 0x5860e90]
>    10 ::pfFrame() [".../pfProcess.C":6283, 0x58a5278]
>    11 ::main() [".../simple.C":144, 0x10002cd4]
>    12 __start() [".../crt1text.s":177, 0x100025d8]
> (dbx) q
>=20
> This is strange. If you follow the trace from level 9, you see that
> Performer calls the Open GL library to re-apply the viewport. In turn,
> OpenGL calls X to obtain the window size. THAT'S causing the round trip
> request to the X server... and that breaks the stable update rate.
>=20
> Ok, you're gonna say that the O2 isn't capable of real-time performance.
> I know! But I still don't see why there's a need to get the window size
> when it hasn't changed.
>=20
> I also tried with
>=20
>         pw->setWinType(PFPWIN_TYPE_X | PFPWIN_TYPE_NOXEVENTS);
>         pw->setFullScreen();
>=20
> but that didn't helped.
>=20
> So the question remains: why is Performer/OpenGL doing a round trip
> request to the X server when no X event has been received to justify th=
e
> query?
>=20
> Is this a bug in Performer? Or is it a problem with OpenGL on O2?
>=20
> Note that this behavior can't be seen on the Octane. It seems to be
> specific to the O2.
>=20
> --
> bernard leclerc*                 *from discreet, a division of AutoDesk
> t 514.954.7317                   10, rue duke
> f 514.393.0110                   montr=E9al (qu=E9bec) canada, H3C 2L7
> mailto:bernardL++at++discreet.com     http://www.discreet.com
> -----------------------------------------------------------------------
> 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
Phil Keslin 

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

 From: allan++at++sgi.com (Allan Schaffer)
 Date: Wed, 10 Nov 1999 16:27:10 -0800 (PST)
 Subject: Re: multiscreen and perf2.3b2
 
On Nov 10,  7:30pm, Thomas Ruge wrote:
> 
> we are running a 3 channel projection on a 180 wall in our Virtual
> Reality Labor at Siemens in Munich with an Onyx2 Deskside.  Now i
> installed perf2.3b2 on Linux on our PC which worked quite nice and
> runs. On our PC i am running a Multiscreen, OpenGL capable X-server
> together with 3 graphic cards. To make 3 different perfly's running
> on these 3 cards works well, but now i am looking for a way to make
> one perfly running on the 3 graphic cards calculating the correct
> perspectives on these 3 projections.  I think this needs some work
> from my side on the perfly source, which is part of perf2.3b2. Has
> somebody a hint what i have to change to get running perfly on my 3
> "pipes" ? What i have to change to get 3 different views from one
> object.

I'm sorry to disappoint but I don't think this will work with either
Beta or the upcoming first release of Performer for Linux.

Multiprocessing is not supported (yet) and it is required in order to
utilize multiple pfPipe objects.  Calls to 'pfMultipipe(n)' will fail
and 'pfGetPipe(1)' will return NULL..

Sorry,
Allan

-- 
Allan Schaffer                                            allan++at++sgi.com
Silicon Graphics                           http://reality.sgi.com/allan

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

 From: "Zhou Tian" 
 Date: Thu, 11 Nov 1999 09:13:17 +0800
 Subject: How can I make collision detection?
 
This is a multi-part message in MIME format.

------=_NextPart_000_0010_01BF2C24.FD9A5CE0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

    Hi, thank you for looking at my question!
    I used vrml to make my model. Then I used performer programming to =
make=20
it be navigated. But how can I make collision detection? Thanks!
                               =20
                                    ZhouTian

------=_NextPart_000_0010_01BF2C24.FD9A5CE0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable










    Hi, thank=20
you for looking at my question!
    I used=20
vrml to make my model. Then I used performer programming to=20
make 
it be =
navigated. But how can=20
I make collision detection? Thanks!
         &nb=
sp;           &nbs=
p;         =20

         &nb=
sp;           &nbs=
p;            =
; =20
ZhouTian

------=_NextPart_000_0010_01BF2C24.FD9A5CE0--


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

 From: "ShiYiHui" 
 Date: Thu, 11 Nov 1999 09:31:42 +0800
 Subject: how can I convert .wrl into .sv format
 Reply-To: "ShiYiHui" 

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF2C27.9072C2D0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

hello,
    I am a user of IRIS Performer.Now I meet a question,when I replace =
the model node(the file is VRML format,*.wrl),the processor down into =
dead lock.And *.sv files can work successfully.How can I resolve this =
question?
    And how can I convert *.wrl into *.sv format?
    Thank you very much!

ShiYiHui
Zhejiang,P.R.China

------=_NextPart_000_0005_01BF2C27.9072C2D0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable









hello,
    I am a user of =
IRIS=20
Performer.Now I meet a question,when I replace the model node(the file =
is VRML=20
format,*.wrl),the processor down into dead lock.And *.sv files can work=20
successfully.How can I resolve this question?
    And how can I =
convert *.wrl=20
into *.sv format?
    Thank you very=20
much!
 
ShiYiHui
Zhejiang,P.R.China

------=_NextPart_000_0005_01BF2C27.9072C2D0--


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






Next message: Robin Hewitt: "dataglove"
Previous message: Kenneth R. Sewell III: "Re: OpenGL app kills Performer app."
In reply to: Kenneth R. Sewell III: "OpenGL app kills Performer app."






New Message
Reply
Date view
Thread view
Subject view
Author view







This archive was generated by hypermail 2.0b2 
on Thu Nov 11 1999 - 15:08:05 PST




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

RE: info-performer Nov 10 1999