gdalgorithms-list

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Stefan B. <ste...@te...>]

> What is happening with Fahrenheit BTW? Is it dead? I found a news link
> yesterday that seemed to say it was alive and doing well but I couldn't
> confirm it.

  XSG (Nee FSG) 1.0 has been released by Microsoft, but it is not available
for free.

> Also has anyone got any good links to some Fahrenheit technical
> documentation?

  Since the SDK is not free, there is no freely available documentation, I'm
afraid!

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Stefan B. <ste...@te...>]

> I had the Beta docs. - not sure whether I am suppose to make it generally
> available or not.

  Most definitely not! They're not public docs and your NDA does not allow
you to share that material.

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

Re: [Algorithms] transforming a plane

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

Charles,

I think it's best using the Center + Extents way for an AABB. Here's what I
use, for what it's worth. Obviously it does not gives you the minimal AABB
possible after the transformation, but it usually is well enough to handle
most situations correctly.

If some of you know a faster way, I'm deeply interested - I use that one
pretty often.

Pierre

////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////
/**
 * A method to recompute the min & max point of an AABB after an arbitrary
transform by a 4x4 matrix.
 * \param  mtx   the transform matrix
 * \param  aabb  the transformed AABB
 * \return  Self-reference
 */
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////
AABB& AABB::Rotate(Matrix4x4& mtx, AABB& aabb)
{
 // Compute new extents
 Point Ex = mtx.GetRow(0) * mExtents.x;
 Point Ey = mtx.GetRow(1) * mExtents.y;
 Point Ez = mtx.GetRow(2) * mExtents.z;

 aabb.mExtents.x = FastFabs(Ex.x) + FastFabs(Ey.x) + FastFabs(Ez.x);
 aabb.mExtents.y = FastFabs(Ex.y) + FastFabs(Ey.y) + FastFabs(Ez.y);
 aabb.mExtents.z = FastFabs(Ex.z) + FastFabs(Ey.z) + FastFabs(Ez.z);

 // Compute new center
 aabb.mCenter = mCenter * mtx;

 return *this;
}

----- Original Message -----
From: Charles Bloom <cb...@cb...>
To: <gda...@li...>
Sent: Wednesday, September 06, 2000 9:19 PM
Subject: [Algorithms] transforming a plane


>
> Is there a fast way to transform a plane?
>
> Right now I'm doing it by rotating the normal and tranforming
> a point on the plane, then re-generating the 4d-vector form of
> the plane.  It seems there should be a way to do it with a
> single 4x4 matrix multiply in some funny coordinate space.
>
> On a related note, is there a fast way to transform an
> axis-aligned bounding box?  With an AABB defined by a 'min'
> and a 'max', I'm doing this :
>
> // the min transformed :
> VECTOR3D vMinT;
>
> frXForm.XFormVector(vMinT,min);
>
> // the three edges transformed :
> VECTOR3D vx,vy,vz;
>
> vx = (max.x - min.x) * frXForm.Axis(X_AXIS);
> vy = (max.y - min.y) * frXForm.Axis(Y_AXIS);
> vz = (max.z - min.z) * frXForm.Axis(Z_AXIS);
>
> min.x = vMinT.x + min(vx.x,0) + min(vy.x,0) + min(vz.x,0);
> min.y = vMinT.y + min(vx.y,0) + min(vy.y,0) + min(vz.y,0);
> min.z = vMinT.z + min(vx.z,0) + min(vy.z,0) + min(vz.z,0);
> max.x = vMinT.x + max(vx.x,0) + max(vy.x,0) + max(vz.x,0);
> max.y = vMinT.y + max(vx.y,0) + max(vy.y,0) + max(vz.y,0);
> max.z = vMinT.z + max(vx.z,0) + max(vy.z,0) + max(vz.z,0);
>
> Basically, transform the low corner (the 'min'), and then
> transform the edges along x,y, and z.  I can't think of anything
> better.
>
>
>
>
> --------------------------------------
> Charles Bloom           www.cbloom.com
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Quaternions in IK

[Robert D. <RD...@ac...>]

> In the rotation group SO(3), how can one characterize a maximal
> neighborhood of the identity that has a unique analytic Euler
> angle parametrization?

My days of really understanding mathematical phraseology are long past I'm
afraid, but surely there is no case which has a unique Euler representation,
given that even the identity matrix has two representations in any given
axis sequence.

Rob

Re: [Algorithms] Quaternions in IK

[Auday <au...@so...>]

Actually the main problem with Eulers is the sequence dependency , so if 
you know the sequence you want to get the Eulers in ( from a quaternion or 
a matrix )  then you will usually have only 2 solutions , for example if 
your sequence is ZYX then you will get 2 solutions for Y , one less than 
180 and the other is greater then 180 , and selecting 1 of them will give 
you 1 solution for each of X and Z .
I agree with Ron that Euler angles are not a natural representation of 
rotation, they are just like applying 3 rotations in quaternions or 
matrices, and obviously you have the same problem of dependency if you 
apply any 3 matrices or quaternions. We use the axis aligned Eulers just 
because they make sense and they give us better imagination of the rotation .
For your question Ron , sorry I didn't understand what you meant , maybe if 
you explain I can answer :)

Thanks

Auday




>It is not a question of loss of information, but of absence of
>information from the start.  What I mean by this is that the real
>geometric thing is the rotation (or orientation) not an Euler angle
>construction of it.  The rotation does not uniquely determine the
>Euler angles.  If FREE rotation is allowed (think a ship on the sea or
>an aircraft or spacecraft) , then a given rotation can be decomposed
>into Euler components in infinitely many ways.
>
>So if you start with an Euler construction to get a rotation matrix
>(or a quaternion) then use a routine such as one that Dave Eberly
>points to on his site to get Euler angles from that quaternion or
>matrix, then there is no guarantee that they will be the same Euler
>angles you started with....The rotation does not determine the Euler
>angles.
>
>On the other hand, for the systems at issue in IK problems, viz.,
>linked structures with constrained joints, such as robots and animated
>characters, the rotation of the end effectors are NOT free, but
>constrained. Typically, the Euler axes DO have a mechanical reality in
>the construction of your robot as a linkage of defined 1-DOF joints,
>and the range of rotation of each joint is limited.  In many such
>cases, no doubt, the Euler angles ARE uniquely determined by the
>orientation of the end effector, and in principle one could find an
>algorithm to determine them from the rotation.  But it would be
>fortuitous if one of Dave's routines gave the correct decomposition in
>your particular case.
>
>These considerations lead to a question that keeps coming up for me,
>but for which I have not found the answer.  I've posted it on various
>forums and lists from time to time, without response.  I'm going to
>ask it again here, because at least a few will understand its
>statement, and maybe Dave or Jeff's grad student or someone will
>remember seeing it discussd somewhere:   In the rotation group SO(3),
>how can one characterize a maximal neighborhood of the identity that
>has a unique analytic Euler angle parametrization?
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] transforming a plane

[Brian M. <bma...@ra...>]

If you are wanting the AABB that encloses the original after transformation
try:

Arvo, James, Transforming Axis-Aligned Bounding Boxes, p. 548-550
http://www.acm.org/tog/GraphicsGems/gems.html

It works by figuring out which of the corners of the bounding box produces
the largest extent along each axis for the new coordinate space.
I'm not sure if this is what you want - but exploiting the extent properties
of a AABB is normally a good way to get fast code with them so hopefully the
concept may help if nothing else.

-Brian.

Re: [Algorithms] transforming a plane

[Eric L. <le...@c4...>]

> Is there a fast way to transform a plane?
> 
> Right now I'm doing it by rotating the normal and tranforming
> a point on the plane, then re-generating the 4d-vector form of
> the plane.  It seems there should be a way to do it with a
> single 4x4 matrix multiply in some funny coordinate space.

Yes, planes can be transformed with a single 4x4 matrix multiply.  Planes
transform contravariantly like normal vectors do, meaning that you need to
transform it using the inverse transpose of the matrix that you would
transform normal points with.

Suppose you have a 4D column vector V representing a plane and a 4x4
transformation matrix M.  Let V = <Nx, Ny, Nz, -d> where N is the plane's
normal vector and d = (P dot N) for any point P on the plane.  Then the
transformed plane V' is given by

   V' = Transpose(Inverse(M)) * V

-- Eric Lengyel

RE: [Algorithms] PNG w/ no libs

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

>call me anal
being anal does not get anyone anywhere.
to get beyond where "most" are, you must be willing to stand on the
shoulders of giants :)
i often wonder why "those guys" are never in the credits of games.

people have spent countless hours on designing these classes, functions,
templates, etc.,
and i assure you that most of those guys* spend more than your "10 minutes"
in writing and desiging your code block.

*some of them even do this for a living (get paid to sit around and write
classes/functions for us to use)


peace.
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Jeremy Bake
Sent: Wednesday, September 06, 2000 5:03 PM
To: 'gda...@li...'
Subject: RE: [Algorithms] PNG w/ no libs


Actually...

call me anal but what I want to do is be able to read png's with my
own code  (not use libpng or zlib)
and I all I really can't get is the decompress of the IDAT chunk
(the part zlib handles)  that explained better?

Jeremy Bake
RtroActiv
RAMetal

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

RE: [Algorithms] FW: [CsMain] Scene Graphs (long tangent rant on "standards")

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

informing people notice:

>I could go on another complete rant about NASA and money.
recently raytheon and nasa are hiring/looking for programmers.

but i'm not sure if the "game/graphics programmer" would do,
imho- i'm pretty sure they are looking for people with "fluid simulation"
experience
, experience with "complicated stuff"; tossing around very large equations;
occlusion culling does not count ;), etc.."

iirc mostly embedded right now.
but imho- it's not fun coding some "old-school" hardware just because it's
"proven" and they can't take the risk of something crashing... <smiles>

with games we are given an opportunity to run our code on the biggest
baddest systems (excluding consoles) and you don't get more "next-gen tech"
then that. we are also allowed a crash every now and then ;)
and trust me, taking a step back is NO FUN.

peace,
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Graham S. Rhodes
Sent: Wednesday, September 06, 2000 4:54 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (long tangent rant
on "standards")


Akbar wrote,

> i know quite a few people that get paid decent money (better than
> most game modelers) to do just that. take old model's and convert
> them a new file format/program. imho i somewhat encourage this
> cause it opens up a lot of jobs.

Good point. Yes, there is this positive side, I suppose. Its just
frustrating when it takes weeks or months to convert a very complex model. I
think it took 6 man-months to convert NASA's NGST model from NASTRAN to
COMET-AR. And that model isn't that complex.

> it's not like we are company owners. and i am sure nasa and raytheon can
spare a few million ;)

As an occasional project manager, I'm responsible for managing schedules and
budgets. And it happens that I've been involved in this STEP project I
described, where it is our *job* to automate the conversion process. Its
just frustrating, really. And, as a stock holder, I *am* one of my company's
owners!

I could go on another complete rant about NASA and money. But that topic is
not something for this forum.

> peace,

Yes, absolutely. Peace!

Graham

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

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Aaron D. <ri...@ho...>]

I've been also looking for info on this. The best one I've found so far is
Numerical Design's whitepaper on their game engine.

http://www.ndl.com/wpapers/bishop.html

It provides a good general overview of design philosophies and their
implementations for collision detection, culling, traversal, etc. without
delving into their API specifics.

I've also seen several good pages on Java3D that talk about its design's
pro's/con's but I don't have the references. A search should turn up
something.

Graham's posted a few links earlier which I found were very useful. (Thanks
Graham!)

- Aaron

-----Original Message-----
From: Dave Smith <Dav...@sd...>
To: gda...@li...
<gda...@li...>
Date: Thursday, 7 September 2000 13:06
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs


>
>Jonathan Wight wrote:
>> Which reminds me, are there any design patterns relating to scene graphs
>> anywhere? Had a quick look but didn't find anything.
>>
>>     Jon.
>>
>
>Good question.  I have just been browsing the popular
>API's (Performer, Java3D, PHIGS, etc..) for ideas but that's
>a major pain.
>
>-DaveS
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] ECTS

[Conor S. <cs...@tp...>]

> I visited the ECTS computer game trade show in london over the weekend.
Bit
> dissapointing really, not much cool stuff to see. Metal gear solid 2
looked
> amazing, as did the "dinasour" demo at the nvidia stand (Developed by
crytek
> www.crytek.com) I believe our very own connor stokes has just got a job
> there, so connor, give the team my congratulations on producing, in my
> opinion,  the best (visible) thing at ECTS!
>
Actually, I had a job there for a while and left :) I'm currently an
unemployed miandering Cyber Hobo.

But, congrats to the crytek guys all the same. A very talented lot in deed.

Conor Stokes

RE: [Algorithms] Fahrenheit (was FW: [CsMain] Scene Graphs)

[Eugene F. <fo...@dr...>]

Jonathan Wight wrote:
> What is happening with Fahrenheit BTW? Is it dead? I found a news link
> yesterday that seemed to say it was alive and doing well but I couldn't
> confirm it.
>
> Also has anyone got any good links to some Fahrenheit technical
> documentation?

SGI pulled out when they finally realized what Fahrenheit was...a
poorly-concealed attempt by Microsoft to kill OpenGL.  Microsoft had little
use for it after SGI made it clear that they weren't going to obsolete
OpenGL in favor of it.  So they both just let it drop.

I was truly worried about SGI when they announced they were working on
Fahrenheit in the first place.  Companies that "partner" with Microsoft have
a funny way of disappearing one way or another.  When SGI pulled out of
Fahrenheit my heart sang.

Eugene

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Matthew M. <ma...@me...>]

Well, I can tell you that I was accepted into the Fahrenheit eXtensible
Scene Graph beta program about six months ago and never received a single
build...not the best indication of health.

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Jonathan Wight
Sent: Wednesday, September 06, 2000 2:46 PM
To: gda...@li...
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs


on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:

> Now there isn't. But you should be familiar with Performer and Fahrenheit
as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.

What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.

Also has anyone got any good links to some Fahrenheit technical
documentation?

    Jon.

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

RE: [Algorithms] FW: [CsMain] Scene Graphs

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

I had the Beta docs. - not sure whether I am suppose to make it generally
available or not.

-----Original Message-----
From: Jonathan Wight [mailto:jw...@bi...]
Sent: Wednesday, September 06, 2000 2:46 PM
To: gda...@li...
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs


on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:

> Now there isn't. But you should be familiar with Performer and Fahrenheit
as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.

What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.

Also has anyone got any good links to some Fahrenheit technical
documentation?

    Jon.

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

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Gavan H. <gh...@si...>]

yet XSG has been released by MS and work discontinued I believe, I think
that it is not supported either... this would make a nice candidate for open
source, if MS don't want the code then others might be able to give it some
life....

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stefan Boberg
Sent: Thursday, September 07, 2000 8:24 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open
source + Performer for Linux)


> Hewlett-Packard did an elaborate scene-graph API with fairly advanced
> OCCLUSION CULLING, (i.e. more than just portals or HOMs)
> originally as part of Fahrenheit. It was called DirectModel, and it has
been
> used to ship products. (by EAI, for one.) Its primary focus was extremely
> large datasets (engine simulations, etc.) It was originally only part of
the
> Visualize Toolkit.

  Wasn't this also the basis for the LMX component of XSG?

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

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

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Stefan B. <ste...@te...>]

> Hewlett-Packard did an elaborate scene-graph API with fairly advanced
> OCCLUSION CULLING, (i.e. more than just portals or HOMs)
> originally as part of Fahrenheit. It was called DirectModel, and it has
been
> used to ship products. (by EAI, for one.) Its primary focus was extremely
> large datasets (engine simulations, etc.) It was originally only part of
the
> Visualize Toolkit.

  Wasn't this also the basis for the LMX component of XSG?

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Stefan B. <ste...@te...>]

> With instance sharing a scene graph is not a DAG.

  How is it not? Instance sharing merely means that there can be more than
one arc to a node, but it does not introduce any cycles in the graph.

Cheers,
Stef
--
Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd.
bo...@te...

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Graham S. R. <gr...@se...>]

Matt wrote,

> Hewlett-Packard did an elaborate scene-graph API with fairly advanced
> OCCLUSION CULLING, (i.e. more than just portals or HOMs)
> originally as part
> of Fahrenheit. It was called DirectModel, and it has been used to ship
> products. (by EAI, for one.) Its primary focus was extremely
> large datasets
> (engine simulations, etc.) It was originally only part of the Visualize
> Toolkit.

Wasn't DirectModel supposed to be rolled into Fahrenheit? I think someone at
Sense8 (owned by EAI now) mentioned that to me a year or two ago.

Also, SGI OpenGL Optimizer is similar, and is available for free for
Windows, in its binary form. I'm not sure what they've done on it recently.

I know someone who has used Optimizer and Performer enough to compare their
level-of-detail features. I wish I remembered what he said, but I do
remember that one or the other provided much better performance than the
other. I'm thinking that Performer was better, but I wouldn't swear to it.

I have an SGI 320 workstation running Windows NT on my desktop here at the
office.  It uses the SGI Cobalt 3D chipset. Its performance is abysmal
compared to the new nVidia and ATI offerings. But it does have an
interesting hardware-assisted occlusion culling capability, and a
corresponding OpenGL extension. I think the HP fx graphics have something
like this as well.

> Now, the interesting part is that they recently gave a grant to the
> University of Tuebingen (Germany?) to convert DirectModel to Linux and
> release it as open source.

Now that is interesting...

Graham Rhodes

RE: [Algorithms] PNG w/ no libs

[Jeremy B. <Jer...@in...>]

Actually...

call me anal but what I want to do is be able to read png's with my
own code  (not use libpng or zlib) 
and I all I really can't get is the decompress of the IDAT chunk
(the part zlib handles)  that explained better?

Jeremy Bake
RtroActiv
RAMetal

RE: [Algorithms] FW: [CsMain] Scene Graphs (long tangent rant on "standards")

[Graham S. R. <gr...@se...>]

Akbar wrote,

> i know quite a few people that get paid decent money (better than
> most game modelers) to do just that. take old model's and convert
> them a new file format/program. imho i somewhat encourage this
> cause it opens up a lot of jobs.

Good point. Yes, there is this positive side, I suppose. Its just
frustrating when it takes weeks or months to convert a very complex model. I
think it took 6 man-months to convert NASA's NGST model from NASTRAN to
COMET-AR. And that model isn't that complex.

> it's not like we are company owners. and i am sure nasa and raytheon can
spare a few million ;)

As an occasional project manager, I'm responsible for managing schedules and
budgets. And it happens that I've been involved in this STEP project I
described, where it is our *job* to automate the conversion process. Its
just frustrating, really. And, as a stock holder, I *am* one of my company's
owners!

I could go on another complete rant about NASA and money. But that topic is
not something for this forum.

> peace,

Yes, absolutely. Peace!

Graham

Re: [Algorithms] Heightfield to NURBS conversion

[Tom H. <to...@3d...>]

At 01:47 AM 9/6/2000, you wrote:
>Could anyone of you point me to an algorithm on heightfield
>to NURBS conversion i.e an algorithm which takes as input
>an heightfield and returns the control points of the NURBS-
>surface which APPROXIMATES the heightfield to a user given
>error?
>I'd really like to avoid meddling with the later chapters
>of Piegl & Tillers NURBS book! Maybe you even know a pro-
>gram?

What I've seen done is to select a direction (vertical in my example, but 
could use horizontal) in the height filed data and curve fit a spline 
through each row of points (making sure that the curve passes through the 
points .. example of this in Watt and Watt I think).  Next, loft a surface 
between the resulting splines. This makes a very complex NURB with a ton of 
knots, but it works.

Another possibility is to make a series of cubic Bezier patches through the 
height field (four height samples make the four corners of the bezier) and 
preserve continuity between patches (There was a Game Developer article by 
Brian Sharp on this). I believe you can take all of these Bezier's and 
stitch them together into a single NURBS patch, but I've never done it. I 
know you can go the other way (single NURBS patch to multiple Bezier 
patches) so it makes sense that you could do it.

In neither of these situations do you have a "user error". The height field 
will pass through all of the samples and give you a continuous function for 
your height field with interpolation between the samples. The second method 
seems to be the cleanest to me. In both solutions you're going to have a 
ton of knots to deal with, and that will probably slow down your final 
rendering.

One possible way to reduce the number of knots would be to remove height 
samples within an error threshold before doing method #1. This would reduce 
the number of knots for each curve, but would remove the uniform sampling 
and make the lofting between the curves a bit more complex because each 
curve would have a different number of knots.

I don't have a MakeNURBSfromHeightField() function I can give you, but 
hopefully with the above or with some of the other responses you can 
construct what you need.

Tom

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Jonathan W. <jw...@bi...>]

on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:

> Now there isn't. But you should be familiar with Performer and Fahrenheit as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.

What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.

Also has anyone got any good links to some Fahrenheit technical
documentation?

    Jon.

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Jonathan W. <JW...@bi...>]

on 9/6/00 1:53 PM, Graham S. Rhodes at gr...@se... wrote:

>> Which reminds me, are there any design patterns relating to scene graphs
>> anywhere? Had a quick look but didn't find anything.
> 
> "Directed Acyclic Graph"? Could that be considered a pattern?
> 
> Graham

There's just a little bit more to it than that :-)

    Jon.

RE: [Algorithms] FW: [CsMain] Scene Graphs

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

With instance sharing a scene graph is not a DAG.

-----Original Message-----
From: Graham S. Rhodes [mailto:gr...@se...]
Sent: Wednesday, September 06, 2000 11:54 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs


Jon wrote,

> Which reminds me, are there any design patterns relating to scene graphs
> anywhere? Had a quick look but didn't find anything.

"Directed Acyclic Graph"? Could that be considered a pattern?

Graham

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

RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Matthew M. <ma...@me...>]

You Know;

Hewlett-Packard did an elaborate scene-graph API with fairly advanced
OCCLUSION CULLING, (i.e. more than just portals or HOMs) originally as part
of Fahrenheit. It was called DirectModel, and it has been used to ship
products. (by EAI, for one.) Its primary focus was extremely large datasets
(engine simulations, etc.) It was originally only part of the Visualize
Toolkit.

Now, the interesting part is that they recently gave a grant to the
University of Tuebingen (Germany?) to convert DirectModel to Linux and
release it as open source.

While such release has not yet happened, I do believe I've found the group
that's doing the conversion:

http://www.gris.uni-tuebingen.de/~bartz/proj/large/#occlusion

The project has been renamed to "Large Model Rendering Toolkit."

They don't specifically mention it on the site (I assume it's not ready,)
but there are some enticing papers up there in Acrobat format.

-- Matt

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Graham S. Rhodes
Sent: Wednesday, September 06, 2000 11:27 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open
source + Performer for Linux)


Steve wrote,

> Yes - but Inventor isn't really appropriate for high performance
> stuff - that's why SGI have the 'Performer' scene graph for that kind
> of thing.

I agree! You'll note that I stated as much in my original post, at the
bottom, item #5 and the following paragraph. (I sometimes have the same
habit as you----replying to a message before I read or fully comprehend the
entire message. Or before I check to see if someone else has replied with
the same response. But I'm getting better!) Its probably good that you
stated your comment on Performer vs. Inventor at the top of your message,
since possibly someone else didn't read to the bottom of my long message.

Even so, you'll be interested to know that our customer has been able to
display models up to around 250,000 polygons (tris and quads) in Inventor,
on an HP Kayak PC with fx2 graphics. Frame rates were not good, though, for
this model. With a 100,000 polygon model frame rates were much better, of
course. Modern consumer T&L boards, which are much better than fx2 graphics,
would result in better performance for the larger model.

It is absolutely true that Inventor does not actively manage performance the
way Performer does. It really is meant for inspecting objects and
manipulating objects rather than navigating through large worlds. I do think
Performer is going to be a better engine for games. But, alas, Performer
doesn't work on Windows or Macintosh. Only Linux and IRIX. And it is
unlikely that it will ever be ported to the more popular platforms.

> Inventor is more for makeing cute presentations, rapid prototyping,
> that kind of thing.

We use it for a bit more than that. We have an Inventor-based model
assembler (developed from 1996 through present) that we use to build models
of NASA's Next Generation Space Telescope (NGST), pressure vessels for
studying Mars habitats. And others have used our tool to assemble various
large aircraft models (e.g., high speed civil transport). We assemble the
model and apply loads and boundary conditions/constraints in our Inventor
app, then invoke a multidisciplinary analysis of the assemblies, and finally
import and animate the results in Inventor. For example, we've done an
analysis of the NGST where nonlinear structural vibration was induced by
radiation loading from the sun in space. The animation data is over 300MB of
motion and scalar contour data (12000 time steps) for the vibrating space
telescope. Inventor handles it just fine. The model itself is not as big as
the large models mentioned above, though. We do the postprocessing as well
in a Performer app, which maintains a relatively constant frame rate
compared with the Inventor app.

> > It is an extensible/programmable scene graph engine that is
> quite powerful.
> > It has a "standard" file format as well...
>
> It's essentially VRML...or more accurately - VRML is essentially
> Inventor.

Folks should keep one thing straight. VRML is a file format. Inventor is
both a file format and an extensible C++ scene graph toolkit. When comparing
Inventor and VRML, you can compare their file formats. And you can compare
the Inventor toolkit with VRML file browsers. In general, it is *not*
accurate to say "VRML is essentially Inventor" or vice versa.

It is true that the VRML version #1 file format was based on the Inventor
file format. Inventor's file format is both a superset and subset of VRML 1.
Inventor has features, such as calculator engines, that the VRML 1 file
format does not have. And VRML 1 has features that were not in Inventor
(billboard node, sky/background node?). VRML 1 is quite obsolete, and
Inventor is not related to the more current VRML97 (version #2 of VRML).

Inventor the *engine* as opposed to inventor the *file format* is a HELL of
a lot more than simple VRML #1 viewers in terms of programmability and
extensibility. It is *not* merely a viewer for simple files. It does allow
you to build interactive scenes and customized 3D interaction, even though
it is not the best SG engine for this kind of application. You can write
OpenGL callbacks to implement cinematics, etc. VRML97 viewers that support
ECMA scripting or EAI allow significant customization and interactivity, but
performance is not as good as Inventor (since customization is often done
with a slower language than C++, such as Java).

There, I think I'm through talking about Inventor and Performer now.

Intrinsic Alchemy (www.intrinsic.com) is a scene graph engine developed I
think by folks who worked on or with Performer. Alchemy does specifically
target the game development market. There are versions for Windows and PS2.

NetImmerse from NDL (www.ndl.com) is another example of a gaming scene graph
engine that works on Windows and PS2.

Both of these engines are going to be far more expensive than Inventor or
Performer, but probably offer better performance for games and better
portability options.

Graham Rhodes

>
> ----
> Science being insufficient - neither ancient protein species deficient.
>
> 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
>
> _______________________________________________
> 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