gdalgorithms-list

[Algorithms] Subdivision surfaces

[<bad...@ya...>]

Hello, 

I'm writing a demo that shows what the effect is of
using subdivision surfaces instead of other modeling 
techniques, but I've a little problem. I'm searching
for an efficient mesh structure. Could somebody tell
me where I can find some information on the net about
efficient mesh structures.

Thanks!

Danny Laarmans, bad...@ya...

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Re: [Algorithms] a fur- paper

[Pierre T. <p.t...@wa...>]

> if any of you know of any other fur papers, please let me know.

From the ACM Digital Library:

Fake fur rendering; Dan B. Goldman; Proceedings of the 24th annual
conference on Computer graphics & interactive techniques, 1997, Pages 127 -
134

Art-based rendering of fur, grass, and trees; Michael A. Kowalski, Lee
Markosian, J. D. Northrup, Lubomir Bourdev, Ronen Barzel, Loring S. Holden
and John F. Hughes; Proceedings of the SIGGRAPH 1999 annual conference on
Computer graphics, 1999, Pages 433 - 438

Wet and messy fur; Armin Bruderlin; Proceedings of the conference on
SIGGRAPH 99: conference abstracts and applications, 1999, Page 284

Rendering fur with three dimensional textures; J. T. Kahiya and T. L. Kay;
Conference proceedings on Computer graphics, 1989, Pages 271 - 280


I have Kajiya's one but only as a paper version.
Want some ugly scanned pics? :)

Pierre

[Algorithms] a fur- paper

[Akbar A. <sye...@ea...>]

hey,
i am looking for this paper, preferably some where that doesn't charge.

J. Kajiya, "Rendering Fur With Three Dimensional Textures,"
i scroured the net, but ended up in failure. it would be really cool if
somebody could point me out to this one if they have seen it lying around.

if any of you know of any other fur papers, please let me know.

http://www.research.microsoft.com/profiles/kajiya.htm
that was the closest i found, and apparently kajiya does not have any papers
up on his site;
all i could find was his "profile" :-|

this was rather odd cause _most_ of the other ms research guys have "web
sites".
i even tried www.research.microsoft.com/~kajiya in conformance with the
_other_ "websites", it popped up the "profile";
maybe it's cause he is the Assistant Director.
oh well...

it was rather humorous skimming through the profile though.
"Now, Kajiya is working on an equally dramatic project, the convergence of
the television and the computer. "

does this mean ms is going to sell tv's?



peace.
akbar A.

Re: [Algorithms] Help with Archive Search

[<fa...@no...>]

I also tried myself to find something in the archives about "VIPM" or ROAM"
for instance,  and nothing was found. Isn'it strange ?

Fred

----- Original Message -----
From: Pai-Hung Chen <pa...@ac...>
To: <gda...@li...>
Sent: Friday, August 11, 2000 6:03 AM
Subject: [Algorithms] Help with Archive Search


> Hi,
>
> I tried to search the list in the archive but I ended up with nothing no
> matter what info I provided.  Am I doning something wrong?
>
> Thanks for the help,
>
> Pai-Hung Chen
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

[Algorithms] confused

[Akbar A. <sye...@ea...>]

hey,
okay, i have not given this question my 48 hour lookup, review time.. but...

in watt and watt "advanced animation and rendering techniques"

page 70
"The net of control points forms a polyhedron in Cartesian space and the
position of the points in this space controls the shape of the surface"

note: "this space" -exclusive...

page 72
"Deformation of a parametric surface is achieved by moving the control
points that define it"
?
shouldn't it say something like...

sorry for the brief message, i hope you understand what i mean :)
but i have to get back to reading this :D
it's 4:43 am and i am on a role :D

peace.
akbar A.

Re: [Algorithms] OBBs & Max

[<Nik...@ao...>]

Hmmm, that's odd, I sent that message to the list about 2 weeks ago, and it 
just appeared.  I found out that the problem was that I wasn't transposing my 
matrices when I was feeding them to RAPID.  I haven't gotten my own 
implementation of the OBB collision detection working fully yet; however 
fixing that will be easy with RAPID working.  Thanks for the help though.

-Ni...@ao...

[Algorithms] Help with Archive Search

[Pai-Hung C. <pa...@ac...>]

Hi,

I tried to search the list in the archive but I ended up with nothing no
matter what info I provided.  Am I doning something wrong?

Thanks for the help,

Pai-Hung Chen

Re: [Algorithms] GJK

[Pierre T. <p.t...@wa...>]

> I assume by Johnson's algorithm you mean the sub-algorithm that computes
> the minimal convex simplex that contains the new support point that is
> closer to the origin?

Absolutely.

> I think all descriptions I have read of it have
> been just hacky ways to determine how to convex-ly combine (by finding the
> best lamda values to use) the points in the previous simplex and the new
> support point to find the minimal convex simplex that contains that new
> support point.  Does that seem correct?

I think so - as far as I can tell, and including the word "hacky" :)

> By the way, what is the *intuitive* reason that the simplex can be up to
> four dimensions (i.e. the tetrahedron)?  Is it because the closest points
> can be from two edges?

Sorry, I'm a newbie to GJK and for the moment there's nothing intuitive in
the whole thing. I'll try to dig some more into it before giving you my
probably totally wrong answers...

Pierre

Re: [Algorithms] Ray-AABB intersection

[Pierre T. <p.t...@wa...>]

Thanks! I'll have a look - I don't need the intersection point indeed.

Anyway I found why Woo's code wasn't working - it was a bug, but in my code.
Ok, thanks guys.

----- Original Message -----
From: <Chr...@Pl...>
To: <gda...@li...>
Sent: Friday, August 11, 2000 1:58 AM
Subject: Re: [Algorithms] Ray-AABB intersection


>
>
>
>
> Pierre, do you need the intersection point to be calculated or
> are you merely interested in the boolean hit/miss result?
>
> If the latter, you can use a separating axis approach, which
> is quite cheap (relatively).
>
> For a description (with pseudo code), see the paper:
>
> Arthur Gregory, Ming C. Lin, Stefan Gottschalk, Russell Taylor
> "A Framework for Fast and Accurate Collision Detection for
> Haptic Interaction"
>
>
> Christer Ericson
> SCEA, Santa Monica
>
>
>
>
>
> "Pierre Terdiman" <p.t...@wa...>@lists.sourceforge.net on
08/10/2000
> 02:51:59 PM
>
> Please respond to gda...@li...
>
> Sent by:  gda...@li...
>
>
> To:   <gda...@li...>
> cc:
> Subject:  Re: [Algorithms] Ray-AABB intersection
>
>
> Weird. Looks like mine, but it still doesn't work well.
>
> ......ok once again I think I'd better rederive everything from scratch
and
> write my own, yeepa.... (sigh)
>
> ----- Original Message -----
> From: Zhang Zhong Shan <Zha...@ub...>
> To: <gda...@li...>
> Sent: Thursday, August 10, 2000 8:36 AM
> Subject: RE: [Algorithms] Ray-AABB intersection
>
>
> > There is an error in the book. But the source i downloaded from the
> Internet
> > seems right.
> >
> > /* Check final candidate actually inside box */
> > if (maxT[whichPlane] < 0.) return (FALSE);
> > for (i = 0; i < NUMDIM; i++)
> > if (whichPlane != i) {
> > coord[i] = origin[i] + maxT[whichPlane] *dir[i];
> > if (coord[i] < minB[i] || coord[i] > maxB[i])
> > return (FALSE);
> > } else {
> > coord[i] = candidatePlane[i];
> > }
> > return (TRUE); /* ray hits box */
> >
> > -----Original Message-----
> > From: Pierre Terdiman [mailto:p.t...@wa...]
> > Sent: Thursday, August 10, 2000 12:03 PM
> > To: gda...@li...
> > Subject: [Algorithms] Ray-AABB intersection
> >
> >
> > Is there any known problem with Andrew Woo's Ray-AABB intersection code?
> (in
> > Graphic Gems I). It seems to miss some intersections... (?)
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Ray-AABB intersection

[<Chr...@Pl...>]

Pierre, do you need the intersection point to be calculated or
are you merely interested in the boolean hit/miss result?

If the latter, you can use a separating axis approach, which
is quite cheap (relatively).

For a description (with pseudo code), see the paper:

Arthur Gregory, Ming C. Lin, Stefan Gottschalk, Russell Taylor
"A Framework for Fast and Accurate Collision Detection for
Haptic Interaction"


Christer Ericson
SCEA, Santa Monica





"Pierre Terdiman" <p.t...@wa...>@lists.sourceforge.net on 08/10/2000
02:51:59 PM

Please respond to gda...@li...

Sent by:  gda...@li...


To:   <gda...@li...>
cc:
Subject:  Re: [Algorithms] Ray-AABB intersection


Weird. Looks like mine, but it still doesn't work well.

......ok once again I think I'd better rederive everything from scratch and
write my own, yeepa.... (sigh)

----- Original Message -----
From: Zhang Zhong Shan <Zha...@ub...>
To: <gda...@li...>
Sent: Thursday, August 10, 2000 8:36 AM
Subject: RE: [Algorithms] Ray-AABB intersection


> There is an error in the book. But the source i downloaded from the
Internet
> seems right.
>
> /* Check final candidate actually inside box */
> if (maxT[whichPlane] < 0.) return (FALSE);
> for (i = 0; i < NUMDIM; i++)
> if (whichPlane != i) {
> coord[i] = origin[i] + maxT[whichPlane] *dir[i];
> if (coord[i] < minB[i] || coord[i] > maxB[i])
> return (FALSE);
> } else {
> coord[i] = candidatePlane[i];
> }
> return (TRUE); /* ray hits box */
>
> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: Thursday, August 10, 2000 12:03 PM
> To: gda...@li...
> Subject: [Algorithms] Ray-AABB intersection
>
>
> Is there any known problem with Andrew Woo's Ray-AABB intersection code?
(in
> Graphic Gems I). It seems to miss some intersections... (?)
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] GJK

[Will P. <wi...@cs...>]

On Thu, 10 Aug 2000, Pierre Terdiman wrote:
> I'd like to implement my own version of the GJK algorithm involved in
> collision detection, without just using any of the available packages
> (Solid, Stephen Cameron's version, etc). But I admit I have some
> difficulties with the theory behind it. Is there any GJK expert here, who
> would be kind enough to briefly summarize that algorithm? For example, even
> Gilbert's underlying layer - that is, Johnson's algorithm to compute the
> closest point to the origin for a simplex - looks quite weird to me. The
> original paper by Gilbert is quite painful to read IMHO, and I don't really
> understand what's going on here. So, to start with, if someone can explain
> in a few words Johnson's algorithm, it would be cool. I'm familiar with
> Minkowski sums, supporting vertices and most of the usual terminology, so
> don't be afraid to use the right words in the right place.

I'm actually implementing this algorithm now, and I find that I do not
have the background in this area of mathematics yet to understand
everything that is going on.  So the disclaimer: I'm not an expert on this
algorithm.  I welcome Ron Levine's input. :)

I assume by Johnson's algorithm you mean the sub-algorithm that computes
the minimal convex simplex that contains the new support point that is
closer to the origin?  I think all descriptions I have read of it have
been just hacky ways to determine how to convex-ly combine (by finding the
best lamda values to use) the points in the previous simplex and the new
support point to find the minimal convex simplex that contains that new
support point.  Does that seem correct?

By the way, what is the *intuitive* reason that the simplex can be up to
four dimensions (i.e. the tetrahedron)?  Is it because the closest points
can be from two edges?

Will

Re: [Algorithms] Ray-AABB intersection

[Pierre T. <p.t...@wa...>]

Weird. Looks like mine, but it still doesn't work well.

......ok once again I think I'd better rederive everything from scratch and
write my own, yeepa.... (sigh)

----- Original Message -----
From: Zhang Zhong Shan <Zha...@ub...>
To: <gda...@li...>
Sent: Thursday, August 10, 2000 8:36 AM
Subject: RE: [Algorithms] Ray-AABB intersection


> There is an error in the book. But the source i downloaded from the
Internet
> seems right.
>
> /* Check final candidate actually inside box */
> if (maxT[whichPlane] < 0.) return (FALSE);
> for (i = 0; i < NUMDIM; i++)
> if (whichPlane != i) {
> coord[i] = origin[i] + maxT[whichPlane] *dir[i];
> if (coord[i] < minB[i] || coord[i] > maxB[i])
> return (FALSE);
> } else {
> coord[i] = candidatePlane[i];
> }
> return (TRUE); /* ray hits box */
>
> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: Thursday, August 10, 2000 12:03 PM
> To: gda...@li...
> Subject: [Algorithms] Ray-AABB intersection
>
>
> Is there any known problem with Andrew Woo's Ray-AABB intersection code?
(in
> Graphic Gems I). It seems to miss some intersections... (?)
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] GJK

[Pierre T. <p.t...@wa...>]

Actually I posted the mail *because* the details included in the original
paper were... well, not so clear :)
I know the rough theory, but some parts of it remain unclear (eg the Johnson
algorithm, as I was telling in the previous mail).

----- Original Message -----
From: Jenny Alexandre <aj...@fr...>
To: <gda...@li...>
Sent: Thursday, August 10, 2000 8:56 AM
Subject: RE: [Algorithms] GJK


>
> I studied this algorithm months ago, so let's go :
>
> I suppose that you have two polytope, that is two set of vertices, which
> are supposed to be convex (for concave object, you have to decompose the
> object in a sum of concave object, but that's quiet complex).
>
> So finding, these closest points is equivalent to find the closest point
> from origin to minkoski sum of the object (quiet easy to check).
>
> The GTK algorithm creates a set of simplex which is imbricated, that is
> the new simplex is smaller that the previous one and so on. And as the
> number
> of vertex is not infinite, the algorithm ends in a finite time.
>
> For the details of the set construction, I'm afraid that you should read
> original paper, or this one, which improves time coherance of the
algorithm
> :
>
> A fast and robust GTK implementation for collision detection of convex
> objects, Gino van den Bergen
> http://www.win.tue.nl/cs/tt/gino/solid/index.html#papers
>
> Alexandre
>
> -----Message d'origine-----
> De : Pierre Terdiman [mailto:p.t...@wa...]
> Envoyé : jeudi 10 août 2000 02:03
> À : gda...@li...
> Objet : [Algorithms] GJK
>
>
> Hi,
>
> I'd like to implement my own version of the GJK algorithm involved in
> collision detection, without just using any of the available packages
> (Solid, Stephen Cameron's version, etc). But I admit I have some
> difficulties with the theory behind it. Is there any GJK expert here, who
> would be kind enough to briefly summarize that algorithm? For example,
even
> Gilbert's underlying layer - that is, Johnson's algorithm to compute the
> closest point to the origin for a simplex - looks quite weird to me. The
> original paper by Gilbert is quite painful to read IMHO, and I don't
really
> understand what's going on here. So, to start with, if someone can explain
> in a few words Johnson's algorithm, it would be cool. I'm familiar with
> Minkowski sums, supporting vertices and most of the usual terminology, so
> don't be afraid to use the right words in the right place.
>
> Pierre
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] 3DS woes.

[Pierre T. <p.t...@wa...>]

Yes.
www.codercorner.com\Flexporter.htm

----- Original Message -----
From: Leigh McRae <lei...@ro...>
To: <gda...@li...>
Sent: Wednesday, July 19, 2000 7:24 PM
Subject: Re: [Algorithms] 3DS woes.


>   Yuppers.  I am using the Max R3.1 and the export plugin.  I will look at
> the code and try the switch your talking about.  I find the whole thing
> wierd as MAX will read the file back in correct.  So what do others do
when
> it comes to MAX, write thier own plugin?
>
> Leigh McRae
>
> ----- Original Message -----
> From: Robert Dibley <RD...@ac...>
> To: <gda...@li...>
> Sent: Wednesday, July 19, 2000 12:10 PM
> Subject: RE: [Algorithms] 3DS woes.
>
>
> > > I have a  house.3ds file that is basicly a box and roof but the
> > > roof never lands on top of the house.  If I join the roof and box then
> it
> > > works ok.
> >
> > Are you by any chance using the MAX exporter that writes 3DS files ?
> > If so, then that may be your problem - when I looked at it, it seemed to
> be
> > bugged.  Something to do with using the wrong matrix I think.  Something
> > like GetNodeTM being used where GetObjectTM should have been perhaps ?
> >
> > hope thats some small help,
> >
> > Robert
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] OBBs & Max

[Pierre T. <p.t...@wa...>]

Apparently this issue has been bugging you for a long time now....

Well. I've been using RAPID and MAX together as well, and it just works.
I've never had such troubles - that's also why I was surprised by Kent
Quirk's recent post about the wrong matrix in RAPID.

I export from MAX 3.1 using this, ...
http://www.codercorner.com/Flexporter.htm

...then use my enhanced RAPID version...
http://www.codercorner.com/RAPID_Hack.htm

...packed in my collision detection lib:
http://www.codercorner.com/ZCollide.htm

On a side note, a related link:
http://www.codercorner.com/Gottschalk.htm

It just works. A friend of mine nonetheless, started using RAPID some months
ago now, and reported some problems : collisions weren't detected. We looked
into it, and it appeared he was using an old RAPID version (1.04 I think). I
gave him the last one. He recompiled. And... it just worked like the
proverbial charm. It's been working for months now.

So, to make things clear once and for all, I really think the problem lies
somewhere in your code, not in MAX nor in RAPID. Or maybe you're using an
old RAPID version as well ? I suspect you just feed RAPID with wrong
rotation matrices, even if that's something you must have checked to death
now... Here's the way I use:

Say you matrix is defined as an array of 16 floats:

float   m[4][4];

That matrix is D3D-compliant. That is, I can send that directly to D3D as a
world matrix. Now, here's the rotation matrix to send to RAPID:

float R1[3][3];

Say M1 is a pointer to a D3D-compliant matrix. The transform is:

R1[0][0] = M1->m[0][0];
R1[0][1] = M1->m[1][0];
R1[0][2] = M1->m[2][0];

R1[1][0] = M1->m[0][1];
R1[1][1] = M1->m[1][1];
R1[1][2] = M1->m[2][1];

R1[2][0] = M1->m[0][2];
R1[2][1] = M1->m[1][2];
R1[2][2] = M1->m[2][2];

In other words, you must transpose the rotation part of the D3D matrix
before sending it to RAPID.
Once again, everything else (MAX, RAPID) ... just works.

Pierre


----- Original Message -----
From: <Nik...@ao...>
To: <gda...@li...>
Sent: Thursday, July 27, 2000 8:00 AM
Subject: [Algorithms] OBBs & Max


> Recently, I've been creating an OBB collision detection system for my
engine,
> and I loosely used the RAPID library as a guide when creating my own
> functions.  The data that I use originates from 3D Studio Max 3.1.  I have
> been having much difficulty with the accuracy of the system, so I
attempted
> to use the RAPID library itself to see if that functioned correctly.
> However, the RAPID library is giving the same results as my own, it
> inaccurately reports collision with even the most simple models (such as
two
> boxes, in which only one has rotation).  Is there a problem with the
library,
> or with Max?  The data I am receiving from Max displays correctly when
> rendered with D3D (in the exporter I change the coordinate system from
Max's
> to D3D's).  Could this change in coordinate systems be the problem?  In
this
> transformation, I change the order of the vertices on each face, and I
flip
> rows 2 and 3 in the transformation matrix, along with the y & z
coordinates
> in the matrix and the vertices.   Also, when a box is created in Max, it
is
> defined with the center being at the bottom of the box, and the rotation
and
> translation matrix compensate for this (depending on where the pivot point
is
> located), to make the scene look correct.   (As I mentioned earlier, the
when
> I render this data in D3D, it looks exactly like what it did in Max, in
> addition, the collision detection is accurate if neither model is rotated.
> Any help would be appreciated.
>
> Thanks,
> Nik...@ao...
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] finding an optimal OBB

[Charles B. <cb...@cb...>]

Ok, so far as I can tell, all he's doing there is a brute
force minimization of the volume by searching the 2d orientation
space of the box.  I suppose that's probably as good as anything
else.  You could probably get a good solution by starting along
the axis of linear-best-fit and just finding a local minimum of
the volume.

I wish the Magic code was better commented, it would make it
10x more useful, but beggars can't be choosers, I suppose...

>Your savior and mine, magic source code.
>http://www.magic-software.com/MgcContainment.html
>Thank you, Dave E. My Dave E. book is on its way, and am looking forward to
>it.
>
>The math here (Ron L. would have to correct me if I were wrong about this)
>is better / more correct than most on-line tutorials, papers and algorithms.
>
>Corrinne Yu
>
--------------------------------------
Charles Bloom           www.cbloom.com

RE: [Algorithms] finding an optimal OBB

[Akbar A. <sye...@ea...>]

btw corrinne,
did you ever get an update from pixar?

peace.
akbar A.

"We want technology for the sake of the story, not for its own sake. When
you look back, say 10 years from now, current technology will seem quaint"
Pixars' Edwin Catmull.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Corrinne Yu
Sent: Thursday, August 10, 2000 8:47 AM
To: gda...@li...
Subject: Re: [Algorithms] finding an optimal OBB


Your savior and mine, magic source code.
http://www.magic-software.com/MgcContainment.html
Thank you, Dave E. My Dave E. book is on its way, and am looking forward to
it.

The math here (Ron L. would have to correct me if I were wrong about this)
is better / more correct than most on-line tutorials, papers and algorithms.

Corrinne Yu




----- Original Message -----
From: "Charles Bloom" <cb...@cb...>
To: <gda...@li...>
Sent: Thursday, August 03, 2000 2:01 PM
Subject: [Algorithms] finding an optimal OBB


>
> I'm sure there are lots of papers on this - any
> good pointers?  I want to find the tightest
> possible OBB for a collection of points.
>
> --------------------------------------
> Charles Bloom           www.cbloom.com
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] finding an optimal OBB

[Akbar A. <sye...@ea...>]

i guess you could consider this a "late" reply since it's been a few hours,
and the list mail was pretty high today....
but just in case somebody said it.
get the book. he is full of knowledge and it will be a good reference as
well.
he knows what he is talking about :)


peace.
akbar A.

"We want technology for the sake of the story, not for its own sake. When
you look back, say 10 years from now, current technology will seem quaint"
Pixars' Edwin Catmull.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Jason
Frisvold
Sent: Thursday, August 10, 2000 9:02 AM
To: 'gda...@li...'
Subject: RE: [Algorithms] finding an optimal OBB


Are you referring to his new book, "3D Game Engine Design: A Practical
Approach to Real-Time Computer Graphics" ??  I was seriously thinking about
picking that one up...

---------------------------
Jason H. Frisvold
Head ATM Engineer
Engineering Dept.
Penteledata
fr...@co...
---------------------------
"All our science measured against reality, is primitive and childlike--and
yet it is the most precious thing we have." - Albert Einstein

-----Original Message-----
From: Corrinne Yu [mailto:cor...@ho...]
Sent: Thursday, August 10, 2000 9:47 AM
To: gda...@li...
Subject: Re: [Algorithms] finding an optimal OBB


Your savior and mine, magic source code.
http://www.magic-software.com/MgcContainment.html
Thank you, Dave E. My Dave E. book is on its way, and am looking forward to
it.

The math here (Ron L. would have to correct me if I were wrong about this)
is better / more correct than most on-line tutorials, papers and algorithms.

Corrinne Yu




----- Original Message -----
From: "Charles Bloom" <cb...@cb...>
To: <gda...@li...>
Sent: Thursday, August 03, 2000 2:01 PM
Subject: [Algorithms] finding an optimal OBB


>
> I'm sure there are lots of papers on this - any
> good pointers?  I want to find the tightest
> possible OBB for a collection of points.
>
> --------------------------------------
> Charles Bloom           www.cbloom.com
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Terminology Help

[BSteve B. <st...@li...>]

On Thu, 10 Aug 2000, Pai-Hung Chen wrote:

> Could someone explain briefly to me what is "rotoscoping" used in animation?
 
I believe it refers to manually tracing over live-action movie frames in order
to get realistic movement in a cartoon.

Presumably, a 'Rotoscope' is some kind of optical instrument that projects
the movie frames onto the tracing surface...dunno about that though.

Motion-capture in a pre-computer age!

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] Terminology Help

[Tom F. <to...@mu...>]

http://www.geocities.com/Hollywood/3113/roto.html

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> From: Pai-Hung Chen [mailto:pa...@ac...]
> 
> Hi,
> 
> Could someone explain briefly to me what is "rotoscoping" 
> used in animation?
> 
> Thanks in advance,
> 
> Pai-Hung Chen

RE: [Algorithms] FPS Questions

[Steve B. <st...@li...>]

On Thu, 10 Aug 2000, Tom Forsyth wrote:

> Kim, you'll find that if you spend enough time in the pubs, the movies won't
> bother you any more. :-)
 
It'll bother you - you just won't *remember* that it bothered you :-)

> And yes, I think they can be trained. Maybe it's from years of sitting
> staring at a bright white ZX Spectrum(*) screen while coding in basic that
> I've become allergic to low frame rates.
 
Your memory is leaky.  The Spectrum was BLACK.  You're thinking of the
ZX80 and ZX81.

> (*) Home computer, contemporary (and clear superior, obviously) of the C64.
> I think it was called a TRS80 on the other side of the pond? Fantastically
> popular here in Britland.

No!  TRS-80 (Pronounced 'Trash-Eighty') was a Tandy/Radio-Shack machine
with a *real* keyboard, *real* display, etc, etc. V.Superior to anything
Sinclair produced.  I owned three of them at one time!

In the US, the ZX-80/81 was called "Timex 1000" or something like that,
I didn't think the Spectrubbish was ever marketted in the US.

Hmmm - Sinclair computers - the memories...

The wobbly RAM pack - the BlueTac to stop it sliding around
the desk - the 'dead flesh' feel to the so-called "keyboard" (on the
Spectrum).  That the display was generated in software (on the ZX80)
- so the screen went blank whenever you ran a program or hit a key
or something.

The adverts that said that you could control a nuclear power plant
with it. (That same advert showed the Spectrum displaying a Union
Jack - which it cannot do because it's graphics 'cells' could only
contain two colours per cell).

The migrane-simulation it displayed as it loaded stuff from tape.

The *requirement* that you use short-cut keys for all BASIC reserved
words - so their interpreter wouldn't have to actually parse the
source code!  Having to use THREE shift keys to get to some of the
more "unusual" BASIC operators...unusual like '<' and '>' :-)

<shudder>

I remember the ZX80/ZX81 and Spectrum *very* well.  Each was
truly a complete piece of shit - even by the low standards of
the time!

You thought it was better than C64?!?  I *don't* think so.

Still - you could always upgrade to the Sinclair QL (Quick-Lashup)
with it's infamous 'microdrives'.  (If you had two microdrives,
drive A couldn't read tapes written by drive B and vice-versa!)

Clive Sinclair made an "Electric Car" too...can you say "Death Trap" ?

  :-)


Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Algorithms] Terminology Help

[Pai-Hung C. <pa...@ac...>]

Hi,

Could someone explain briefly to me what is "rotoscoping" used in animation?

Thanks in advance,

Pai-Hung Chen

Re: [Algorithms] View-Depend vs. View-Independent LOD

[Daniel R. <dan...@ho...>]

yes, you got it. 100 buble gum donut points for you.

you asked the question of the year.
many,many discussed this topic in the last weeks/months
and the results vary extremly.
depending detailed on what you're goind to do.
...

this will not help, but clarify, re...@ma...

>From: "Pai-Hung Chen" <pa...@ac...>
>Reply-To: gda...@li...
>To: <gda...@li...>
>Subject: Re: [Algorithms] View-Depend vs. View-Independent LOD
>Date: Wed, 9 Aug 2000 14:03:04 -0700
>
>In a HW T&L setting (GeForce), are VIPM/VDPM really worth the extra
>management cost omposed on CPU?  Or a simple Quadtree/Octree paradigm will
>suffice, in which I may well just send the un-LODed polys to the HW T&L
>pipeline that is so fast at handling huge amount of polys that it still
>beats the LOD optimization?
>
>Thank you,
>
>Pai-Hung Chen
>
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Algorithms] View-Depend vs. View-Independent LOD

[Daniel R. <dan...@ho...>]

yes, you got it. 100 buble gum donut points for you.

you asked the question of the year.
many,many discussed this topic in the last weeks/months
and the results vary extremly.
depending detailed on what you're goind to do.
...

this will not help, but clarify, re...@ma...

>From: "Pai-Hung Chen" <pa...@ac...>
>Reply-To: gda...@li...
>To: <gda...@li...>
>Subject: Re: [Algorithms] View-Depend vs. View-Independent LOD
>Date: Wed, 9 Aug 2000 14:03:04 -0700
>
>In a HW T&L setting (GeForce), are VIPM/VDPM really worth the extra
>management cost omposed on CPU?  Or a simple Quadtree/Octree paradigm will
>suffice, in which I may well just send the un-LODed polys to the HW T&L
>pipeline that is so fast at handling huge amount of polys that it still
>beats the LOD optimization?
>
>Thank you,
>
>Pai-Hung Chen
>
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

RE: [Algorithms] class parser

[Ko, M. <MAN...@ca...>]

That is a bad way to go about it: your problem was you didn't design the
persistent interface ahead of time. I use a "schema driven" method - sort of
like database systems. 
 
1) You need to think of the on-disk persistent structure as separate
data-structures from the runtime/in-memory rep. Remember, C/C++ structures
have compiler imposed alignments that are not obvious. NEVER writes a
structure or class directly to disk. VERY BAD!!!
Besides, there are always fields in a class that are meant for runtime only.
Don't want to persist those.
2) The on disk record structures are defined explicitily using a schema. 
3) with schemas you never need to write another line of IO code. The byte
swapping code can be writing once. It uses the schema to do the swapping.
4) More important when you change compilers or compiler options - your
alignment never changes! Otherwise when you go from 32bit to 64 bit. You
will go nuts.
 
Next the question is how to map runtime/in memory objects that need to be
persistented to their schema.
1) Use some macros around each member variable that u need to be
persistented in the class - complicated and fragile. But if u get it to
work, less maintainence.
2) Define a static method for each class that u need to persist and register
itself with the schema manager. Simple and robust. Problem is only when u
extend the class u need to update the registration method.
 
I use 2) - it works well.
 
Next - you have to deal with pointers. If you are currently reading and
writing in memory structures that are graphs or lists. Then you might have
to deal with pointers. I don't persistent those structures. I use arrays.
But if you do, use a persistent ID scheme. For every ptr. define a unique ID
that will be saved on disk.

-----Original Message-----
From: Blade S.N [mailto:he...@ci...]
Sent: Tuesday, August 01, 2000 6:55 AM
To: gda...@li...
Subject: [Algorithms] class parser


Hi all, 
We are going to port our game to Mac and begin to experience problem of
small_big endian conversion.It is concerned  with too many class and
structure .It's impossible to write all the conversion code for every data
file type. So I am going to implement a head file parser to parse the
definition of each class and generate the conversion code  automatically
.It's surely not the most convenient way to make that.But I haven't any good
idea.
Can anyone here enlighten me.Is there any simple way?
Thanks in advance.
S.N