gdalgorithms-list Mailing List for Game Dev Algorithms (Page 1389)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi, i need to sort polygons for alpha blended objects.
Can you point me to some resource to do that?

thank you

This is a classic problem whose solution is described in:

Matrix Animation and Polar Decomposition - Ken Shoemake and Tom Duff.
(Proceedings of Graphics Interface 1992.)

An implementation can be found in the MAX SDK, in Decomp.cpp (this is the
source code for the famous decomp_affine method of the MAX SDK).
Unfortunately the code is really ugly, and I think it's even not included in
the standard SDK (which only contains headers IIRC).

To extract the scale they use a spectral decomposition as described in:

Gene H. Golub and Charles F. Van Loan. Matrix Computations. Hopkins 1983.

Pierre

----- Original Message -----
From: Neal Tringham <ne...@ps...>
To: <gda...@li...>
Sent: Thursday, September 07, 2000 7:17 PM
Subject: Re: [Algorithms] Extracting scale from matrix

>
> De: Jon Anderson [mailto:jan...@on...]
>
> >Are there any good tricks for extracting the scale (x, y, z)  from a 4x4
> >matrix?  It seems pretty trivial to do it for matrices that consist of
> >rotations about a single axis, but I'm having problems doing it for more
> >complex matrices.
>
> If your matrix contains only rotation, scale and translation information,
> could you extract the scale factors by comparing the length of the basis
> vectors to the length of the normalised basis vectors?
>
> Note that (even if this works:-)) I don't believe it would allow you to
> distinguish between a negative sign in a scale factor (a "mirror") and a
> rotation, i.e. it would only allow you to extract the magnitude of the
scale
> factors, not their signs.
>
> Curious as to people's comments on this...
>
> Neal Tringham (Sick Puppies)
>
> ne...@ps...
> ne...@em...
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Isn't there a DecomposeMatrix routine in one of the Graphics Gems?

Pass it a 4x4 matrix and it returns rotation, scale, translation,
shear and probably something more...  

...yeah, it's at page 207 of Graphics Gems 4.

-Blake

-----Original Message-----
From: Neal Tringham [mailto:ne...@ps...]
Sent: Thursday, September 07, 2000 10:18 AM
To: gda...@li...
Subject: Re: [Algorithms] Extracting scale from matrix

De: Jon Anderson [mailto:jan...@on...]

>Are there any good tricks for extracting the scale (x, y, z)  from a 4x4
>matrix?  It seems pretty trivial to do it for matrices that consist of
>rotations about a single axis, but I'm having problems doing it for more
>complex matrices.

If your matrix contains only rotation, scale and translation information,
could you extract the scale factors by comparing the length of the basis
vectors to the length of the normalised basis vectors?

Note that (even if this works:-)) I don't believe it would allow you to
distinguish between a negative sign in a scale factor (a "mirror") and a
rotation, i.e. it would only allow you to extract the magnitude of the scale
factors, not their signs.

Curious as to people's comments on this...

Neal Tringham (Sick Puppies)

ne...@ps...
ne...@em...

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

From: "Stephen J Baker" <sj...@li...>
> Standardization *becomes* necessary the moment that hardware
> comes into the picture.  With increasing need to put things
> into the memory of the graphics card - so will come the need
> to use a standardized scene graph API. 

I agree, as long as the standardized scene graph API is mine :)

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

RE: [Algorithms] FW: [CsMain] Scene Graphs
  From: Scott McCaskill=20

  _Maybe_, but it is a tough problem to solve.  Put too much =
functionality in a scene graph and it starts to look bloated because =
most apps will only use a (small?) subset of that functionality.  OTOH, =
if you make it too simple and people end up having to write a bunch of =
code to use it then they will perceive it to be not very useful.  This, =
combined with having to work within an externally imposed structure, =
could lead a person to consider "just doing it himself".

  I believe that the "Renderware" approach of having many small =
components arranged in hierarchical layers, with the ability to plug in =
different components at any level, is probably the best general approach =
for truly reusable "scene graph" code.  The core or base level can then =
contain no actual scene graph code at all, just helper components such =
as a platform independent interface for rendering blocks of data, matrix =
support, chunk streaming functions, texture and image handling, and so =
on.  The next layer up might be a very basic scene graph / 3d engine, =
and additional functionality such as skinning or animations can be added =
as higher level plugins.

  Having said that, we are no longer actually using RenderWare as =
opposed to our own code written along similar lines, so perhaps even =
this approach may not be quite good enough for everyone:-)

  Neal Tringham (Sick Puppies)

  ne...@ps...
  ne...@em...

>> Use bounding spheres instead?   :-)

Drifting off topic a bit here, but it may be worth looking at swept sphere
volumes for this. The OBB people have a paper on them where they discuss the
pro's and con's from a proximity and collision point of view. Certainly
could be worth supporting line swept spheres or rectangle swept spheres as
an finer bounding volume for the frustrum culling. I think that they are
worth thinking about in places where you would use OBB's.

-Brian.

De: Jon Anderson [mailto:jan...@on...]

>Are there any good tricks for extracting the scale (x, y, z)  from a 4x4
>matrix?  It seems pretty trivial to do it for matrices that consist of
>rotations about a single axis, but I'm having problems doing it for more
>complex matrices.

If your matrix contains only rotation, scale and translation information,
could you extract the scale factors by comparing the length of the basis
vectors to the length of the normalised basis vectors?

Note that (even if this works:-)) I don't believe it would allow you to
distinguish between a negative sign in a scale factor (a "mirror") and a
rotation, i.e. it would only allow you to extract the magnitude of the scale
factors, not their signs.

Curious as to people's comments on this...

Neal Tringham (Sick Puppies)

ne...@ps...
ne...@em...

Silly me, that comes out of the math trivially.  Assuming an
orthonormal matrix, so Transpose(Inverse(M)) = M, then a point
on the plane initially is 

P = d N

Transformed, you get

P' = MP = M d N = d N' + T

where T is the translation in M.  Then d' is just

d' = N' * P' = d N' * N' + T * N' = d + T * N'

In other words, d += T * N' is all you need to transform a plane
(and rotate the normal) by an orthonormal matrix.

At 11:18 PM 9/6/2000 -0700, you wrote:
>> 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
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
--------------------------------------
Charles Bloom           www.cbloom.com

 Ok, standardization is a -necessary- evil. No question that black-box
components that are reliable can be used to enable innovative solutions
built around them. Also no question that certain innovative techniques are
unavailable because the black boxes can't support them.
  And sometimes innovation and production are in direct conflict too :)

Peter

> -----Original Message-----
> From: Stephen J Baker [mailto:sj...@li...]
> Sent: Thursday, September 07, 2000 8:18 AM
> To: gda...@li...
> Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs
> 
> 
> On Thu, 7 Sep 2000, Dave Eberly wrote:
> 
...
> > 
> > Standardization is evil.  Okay, a strong statement
> > to make :)  Perhaps better is to point out that
> > standardization and innovation are in direct conflict.
>  
.......
> 
> The deal is that this higher level of standardization doesn't
> prevent you from innovating - it just frees you from the
> bothersome details and lets you innovate at a higher level.
.....
> 

Hello,

Thursday, September 07, 2000, 5:46:03 AM, Aaron Drew wrote:

> 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 find Performer's docs (from SGI's site) very interesting.
They do delve into API specifics but you can also find some
very nice general design ideas there. Many SGs seems to be
more or less inspired by Performer's design.

-------------------------
Maciej Sinilo

--- 
Duzo drukujesz? Drogo kupujesz? Odwiedz AGAWE - nie pozalujesz! 
Atramenty, tonery, papiery i CD-R - najtaniej w Polsce! http://www.agawa.pl 

Hi everyone, I've been wrestling with a problem for the past few days and it
just won't go away.  :)  I've been rewriting my player vs. world collision
detection and response routines, and I've pretty much got it all finished
except for one problem.  When the player bumps into or walks along a crease
(where two polygon edges meet) the collision response algo seems to make him
oscillate.

So you'll be walking along in a shallow valley bouncing left and right a
tiny bit as you move down the crease.

I've taken a look at the quake source and it does something similiar to what
I'm doing, except it looks like there is some special case code just for
creases.  I'd really like to avoid hacking so I'm hoping some of
the experts on this list have run into this problem and solved it.  Or
can outline a simple "slide along polygons" collision response that handles
crease situations.

What I'm doing now is simply calculating a sliding plane based on the poly
the player is hitting and sliding him along that with the remaining velocity
after the initial collision.  I do this recursively each frame against the
environment until the velocity is so small I can just set it to zero.

Thanks for any help.

- Jason Zisk
- nFusion Interactive LLC

> I did choose the wrong word with "unique".   Rather, I meant
> "analytic", or free of singularities, which would also imply
> one-to-one.  That is, I seek maximal neighborhoods of the identity
> that can be covered analtyically with an Euler-angle coordinate patch.
> 
> Surely, any sufficiently small neighborhood of the identity can be so
> covered (not uniquely, but in multiple ways).  How do I characterize a
> largest such neighborhood.  

If I understand you correctly, the answer I would expect is the
neighbourhood in which all 3 angles are within the range (-PI/2, PI/2) since
you only get singularities once one axis has been pushed onto another. The
problem with this of course is that it only gives you half the coverage.

Robert

On Thu, 7 Sep 2000, Graham S. Rhodes wrote:

> > I agree that ad'hoc standards are a good thing - but there comes a point
> > where they have to be formalized and taken over by a committee to stablise
> > them.
> 
> I agree with you. OpenGL has certainly benefited from the approach you
> suggest. What bothers me is things that are built by committee from the
> ground up.

Yes. Absolutely.  Who wants to program in Ada when there is C++ -
the US govt had to pass laws to force people to use it!  Give
me the work of two or three smart people any day.

I had hoped that OpenGL++ would have worked out that way - since
it would clearly have been a linear descendent of a number of other
SGI scene-graph API's (notably the Cosmo scene graph and Performer)
in just the same way that OpenGL was a descendent of IrisGL.

Those scene graph API's have worked out pretty well but are in need
of standardization/cleanup/portability effort just as IrisGL was.
OpenGL++ might even have gotten there if the Fahrenheit nonense hadn't
"hijacked" the standard *and* all the experienced people at SGI who
were working on it.

> > No standard lasts forever - which is why we are not all writing Algol'60
> > or FORTRAN IV.
> 
> I agree with you statement absolutely. But lasting forever is the *purpose*
> of a lot of true standards....

The formulators of a standard may like to imagine that to be the case - but
it's naive.  Nobody can predict what computers will be like in 10 years
time - and to attempt to define a standard that'll last even 15 years is
pushing it.

> Enough of this nonsense! On to more important discussions!

Indeed.  We are way off-topic.

----
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

On Thu, 7 Sep 2000, Dave Eberly wrote:

> From: "Stephen J Baker" <sj...@li...>
> >The worst part of it is that without a standard SG, there is no
> >way to promote the writing of generic 3D file loaders - which is
> >something that's badly needed IMHO.
> 
> Standardization is evil.  Okay, a strong statement
> to make :)  Perhaps better is to point out that
> standardization and innovation are in direct conflict.

So you don't use OpenGL or D3D?  You prefer to write your
own renderer and forgo the advantages of (say) a GeForce2-Ultra?

Not if you are into 'realtime' I suspect.

I bet you *once* thought that a standardized renderer would
stifle innovation - but it happened and you are still happily
innovating away.  You may once have been one of those people
who did their own T&L rather than using OpenGL because it
was stifling their innovation ... you don't hear much from
those people anymore either.

The deal is that this higher level of standardization doesn't
prevent you from innovating - it just frees you from the
bothersome details and lets you innovate at a higher level.

Standardization *becomes* necessary the moment that hardware
comes into the picture.  With increasing need to put things
into the memory of the graphics card - so will come the need
to use a standardized scene graph API.  There is no reason
why a next-gen graphics card couldn't handle all the field
of view culling and a bunch of other things automatically.

----
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

On Thu, 7 Sep 2000, Tim Johnston wrote:

> What is the best method for coarse bounding box frustum culling?

Use bounding spheres instead?   :-)

    http://web2.airmail.net/sjbaker1/frustcull.html

> From what I can gather you either use axis aligned bound boxes
> (AABBs) or oriented bounding boxes (OBBs), with OBBs having the
> advantage of tighter fitting but need extra computations for the
> culling process.

I'm a fan of poorly fitting shapes and more efficient culling -
if you can cull more efficiently, you can cull to a finer level
which makes up for the poorer fit of the bounding volume to the
shape.

However, opinions are split - between spheres (which don't have
to be axis-aligned), AABBs and OBBs.   All three can work well
for some applications and not so well for others.

> Also which culling method is best, perspective
> transform the BB and the view frustum to the perspective coordinate
> system (which with AABBs can result in testing two AABBs which is just
> 6 comparisons, however you have to transform all 8 vertices of the
> AABB) or testing the BB against the 6 planes of the view frustum (which
> seems much simpler and straightforward if that is all that is needed.)

It depends on the application - I prefer to transform the object into
the eye coordinates - but not do the perspective transform (which would
make the frustum into a cube) because:

  * For spheres, you don't want to do a perspective transform because
    then they are non-spherical - and that's A Bad Thing.

  * If the object passes the test, you'll need it's eye coordinates
    anyway - so the work isn't all lost.

You could also choose to transform the frustum into the coordinate
system of your objects - that's better if a lot of objects are
sharing the same coordinate space.

> So is comparing AABBs against the frustum planes the best way to go...

I think that there is no single 'best' approach if you know
nothing about the nature of the application and its models.
If you know something about the application then maybe you
can find a good reason to go on particular way.

----
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

Steve wrote,

> I agree that ad'hoc standards are a good thing - but there comes a point
> where they have to be formalized and taken over by a committee to stablise
> them.

I agree with you. OpenGL has certainly benefited from the approach you
suggest. What bothers me is things that are built by committee from the
ground up.

> PHIGS *was* a useful standard in it's day - it's just been obsoleted by
> the advent of fast, cheap 3D hardware.

I think there actually was something called "Full PHIGS" or "Complete PHIGS"
that came out around 1997 that was a bit more competitive in terms of
capability. But to be honest I hadn't even heard of this incarnation until
yesterday when I did a search to find out where PHIGS was at these days.

> No standard lasts forever - which is why we are not all writing Algol'60
> or FORTRAN IV.

I agree with you statement absolutely. But lasting forever is the *purpose*
of a lot of true standards, and this purpose leads to their complexity and
sometimes downfall. STEP, which I discussed, is designed to allow aircraft
and automobile manufactures archive their complete design histories for 100
years. Not 5 years or 10 years. 100 years. And that is also the problem with
true standards, in some cases. They are sometimes built for archival
purposes, not practical day-to-day use.

Enough of this nonsense! On to more important discussions!

Graham Rhodes

A followup "informing people" notice:

Akbar wrote,

> 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.."

The folks we work with at Langley have actually been trying to hire. They
were looking for people with a Master's degree in either engineering or CS,
but with fairly strong experience in *both* graphics and engineering. Having
just experience in graphics was decided to be not enough, since the project
managers are overbooked and wouldn't possibly have time to tutor on
engineering mechanics and other things that are absolutely required to do
the work.

The other issue is this. NASA civil servant positions pay government salary
levels, which seem to be quite a bit less than commercial salaries for s/w
developers. The folks at Langley did find just a *few* people who met the
requirements, but those people, recent graduates as it happens, were looking
for starting salaries in the $70K range. And it happens that $70K is more
than the task leader doing the hiring makes (as I was told). And he's been
at NASA for quite a number of years now, has a Ph.D in engineering and a bit
of experience with graphics and VR.

Time to get off this tangent.

Graham

From: "Stephen J Baker" <sj...@li...>
>The worst part of it is that without a standard SG, there is no
>way to promote the writing of generic 3D file loaders - which is
>something that's badly needed IMHO.

Standardization is evil.  Okay, a strong statement
to make :)  Perhaps better is to point out that
standardization and innovation are in direct conflict.

From: "Jonathan Wight" <JW...@bi...>
> Which reminds me, are there any design patterns relating to scene graphs
> anywhere? Had a quick look but didn't find anything.

As an abstract problem, if your scene graph really is
a directed acyclic graph, then a streaming system
should save the nodes and arcs of the graph and be
able to load them and recreate the graph.  I cover this
topic in my game engine book to show how an
object-oriented system can do this assuming that the
classes of the node objects are derived (directly or
indirectly) from a base class that has RTTI and some
other basic support.  The arcs of the graph correspond
to the pointer members that point to objects derived
from the base class.  On "save", the system builds a
list of unique objects by a graph traversal.  Each object
knows how to write itself to disk.  Pointer members are
written as is.  On "load" the system has a lot more work
to do.  The main problem is that the pointer members on
disk no longer correspond to valid memory addresses.
So you really need a loader/linker system.

Such a system is extensible to new objects simply by
class derivation.  Each new class implements the
necessary member functions (5 in my system: create
a new object, load from disk, link pointer members,
add self to save-list, save to disk).

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

Robert Dibley  wrote:

>> 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.
>

I did choose the wrong word with "unique".   Rather, I meant
"analytic", or free of singularities, which would also imply
one-to-one.  That is, I seek maximal neighborhoods of the identity
that can be covered analtyically with an Euler-angle coordinate patch.

Surely, any sufficiently small neighborhood of the identity can be so
covered (not uniquely, but in multiple ways).  How do I characterize a
largest such neighborhood.  

From: "Sam Kuhn" <sa...@ip...>
> a) I've read that its possible to throw the vertices of a model at the 3d
> card (So T&L is possible)
> And just maintain the indexed lists into that vertex array using collapses
> and merges.

The source code for my game engine book has an implementation
of this (actually, the first update does and is available at my web site
for purchasers of the book).  The vertices and indices are ordered so
that as you collapse edges, you just reduce the maximum index for
the vertex array and for the connectivity index array.

> Doesn't that mean you have to make the card (hardware) transform all of
the
> vertices in the highest resolution representation of the model each frame?
> even though the current lod might only need say 100.. or am I missing
> something?

The packed model-space vertices can be cached on the graphics
card.  Each frame you only change the connectivity information and
the model-to-world transforms.  Then let the graphics card do its thing.

> b) Say you wanted 1000 spaceships on screen sharing a single VIPM model,
how
> does this work with (a)?

Yes, both objects share the model-space data that is cached on
the card.  The objects potentially have different LODs and
model-to-world transforms.

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

From: Tim Johnston 

> What is the best method for coarse bounding box frustum culling?

"Best" depends on your application.  There are always
tradeoffs to be considered.

> From what I can gather you either use axis aligned bound
> boxes (AABBs) or oriented bounding boxes (OBBs), with
> OBBs having the advantage of tighter fitting but need extra
> computations for the culling process. Also which culling
> method is best, perspective transform the BB and the view
> frustum to the perspective coordinate system (which with
> AABBs can result in testing two AABBs which is just 6
> comparisons, however you have to transform all 8 vertices
> of the AABB) or testing the BB against the 6 planes of the
> view frustum (which seems much simpler and
> straightforward if that is all that is needed.)

Testing for intersection between box and frustum a plane
at a time is fast, but not conclusive.  You have the situation
where a box is not determined to be completely outside
any plane, but the box does not intersect the frustum.  It
takes more time to determine the actual relationship between
box and frustum.  This is one of the tradeoffs you need to
decide on.  Plane-at-a-time is a fast test for no-intersection,
but you might send a few objects to the renderer only to be
clip-culled or rejected by z-buffer tests a pixel at a time.  The
full test is slower, but you never send objects outside the
frustum to the renderer.  Therefore in computing costs for
the culling methods, you need more than just a cost
comparison of the intersection routines.

> Also what are the extra steps needed to use OBBs instead?

Code and document for culling OBBs against frustum is at
my web site, MgcIntersection.html page.

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

On Wed, 6 Sep 2000, Graham S. Rhodes wrote:

> Steve wrote,
> 
> > There are dozens of OpenSourced scene graph API's out there.
> > Inventor becomes yet another.  There are dozens of file formats
> > out there - .iv becomes yet another (and it's essentially just
> > VRML anyway - IIRC)
> 
> Yes, quite true. I hear you and feel your pain. The same situation exists in
> the CAD world. Every solid modeler has its own native file format. CAD
> vendors don't want portability because their established customers would
> then have a choice, an option to choose a different tool without losing
> their past models, their past investment. Competition would become more
> price based---prices would have to come down and all hell would break loose.

Yes - but I'm not talking about standardizing file formats.  If we had a
scene graph API was some kind of a standard - then loaders for a huge
variety of files formats could be built for it.

<snipped story of STEP - which sound PAINFUL!>

> So, in short, I just don't really believe that truly good standard file
> formats can emerge when they are designed by committee. I see more success
> in standard API's. The OpenGL approach is something I like. A top-notch
> company designs something that is simple, works damn well, and they run with
> it, making it available to the world, teaching the world how to use it,
> proving that it is good, superior, extending it over time----and building in
> an extensions mechanism. De facto standards, I believe, are much better than
> true standards, with very few exceptions.

Although - OpenGL is the direct descendent of IrisGL - which was a one
off ad'hoc API that grew in a rather ugly way.  OpenGL's design was
essentially a major cleanup of something that had evolved over a lot of
years.

I agree that ad'hoc standards are a good thing - but there comes a point
where they have to be formalized and taken over by a committee to stablise
them.

> I'll give you another example. Anyone ever heard of PHIGS/PHIGS PLUS?

Yep.

> Probably a good number of you, depending on how long you've been around
> doing 3D graphics. How many of you use it? What about you Playstation 2
> developers? No? Windows? No? Macintosh? No? Linux? No? And yet...PHIGS and
> PHIGS PLUS are ISO standard APIs for 3D graphics.

PHIGS *was* a useful standard in it's day - it's just been obsoleted by
the advent of fast, cheap 3D hardware.

No standard lasts forever - which is why we are not all writing Algol'60
or FORTRAN IV.

----
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

On Wed, 6 Sep 2000, Graham S. Rhodes wrote:

> 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.

You might also want to look at my scene graph API 'SSG' - which is somewhat
like Performer - but *much* simpler...and runs on anything that supports
OpenGL and can run basic C++ ...and it's OpenSourced/free.

   http://plib.sourceforge.net/ssg

There has been a boom in interest in SSG over the last few months.
SSG has been around for about 3 years now as a more or less solo
project - but for the last 3 or 4 months there have about a dozen
developers actively working on it.

----
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

The product will be turning up shortly as far as I heard, but I am not in
any position to know when. It has had an active beta program. I recvd
regular beta copies, it was one of the few beta programs that sends out hard
copy manuals even.

So as far as committment from the XSG team I cannot fault them, good effort,
even If you are not for MS products don't begrudge the team their efforts
for bringing through a product with little hype and committment to
quality.They supported OpenGL in the product equaly to Direct X.

If you were accepted onto the beta you would have recvd cds, printed manuals
on more than one occasion and access to the private newsgroups. If you did
not get this stuff then something must have went wrong with your details I
would say.

Gavan

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Matthew MacLaurin
Sent: Thursday, September 07, 2000 9:19 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs

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

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

What is the best method for coarse bounding box frustum culling?

From what I can gather you either use axis aligned bound boxes (AABBs) =
or oriented bounding boxes (OBBs), with OBBs having the advantage of =
tighter fitting but need extra computations for the culling process. =
Also which culling method is best, perspective transform the BB and the =
view frustum to the perspective coordinate system (which with AABBs can =
result in testing two AABBs which is just 6 comparisons, however you =
have to transform all 8 vertices of the AABB) or testing the BB against =
the 6 planes of the view frustum (which seems much simpler and =
straightforward if that is all that is needed.)

So is comparing AABBs against the frustum planes the best way to go and =
is it just find the equations and test the vertices or is there some =
more transforming needed in there?

Also what are the extra steps needed to use OBBs instead?

And finally a nice easy question, what is the right way to get the 6 =
equations of the planes if you happen to have an OpenGL matrix?

Any help would be great
thanks,

Tim.

2000	Jan	Feb	Mar	Apr	May	Jun	Jul (390)	Aug (767)	Sep (940)	Oct (964)	Nov (819)	Dec (762)
2001	Jan (680)	Feb (1075)	Mar (954)	Apr (595)	May (725)	Jun (868)	Jul (678)	Aug (785)	Sep (410)	Oct (395)	Nov (374)	Dec (419)
2002	Jan (699)	Feb (501)	Mar (311)	Apr (334)	May (501)	Jun (507)	Jul (441)	Aug (395)	Sep (540)	Oct (416)	Nov (369)	Dec (373)
2003	Jan (514)	Feb (488)	Mar (396)	Apr (624)	May (590)	Jun (562)	Jul (546)	Aug (463)	Sep (389)	Oct (399)	Nov (333)	Dec (449)
2004	Jan (317)	Feb (395)	Mar (136)	Apr (338)	May (488)	Jun (306)	Jul (266)	Aug (424)	Sep (502)	Oct (170)	Nov (170)	Dec (134)
2005	Jan (249)	Feb (109)	Mar (119)	Apr (282)	May (82)	Jun (113)	Jul (56)	Aug (160)	Sep (89)	Oct (98)	Nov (237)	Dec (297)
2006	Jan (151)	Feb (250)	Mar (222)	Apr (147)	May (266)	Jun (313)	Jul (367)	Aug (135)	Sep (108)	Oct (110)	Nov (220)	Dec (47)
2007	Jan (133)	Feb (144)	Mar (247)	Apr (191)	May (191)	Jun (171)	Jul (160)	Aug (51)	Sep (125)	Oct (115)	Nov (78)	Dec (67)
2008	Jan (165)	Feb (37)	Mar (130)	Apr (111)	May (91)	Jun (142)	Jul (54)	Aug (104)	Sep (89)	Oct (87)	Nov (44)	Dec (54)
2009	Jan (283)	Feb (113)	Mar (154)	Apr (395)	May (62)	Jun (48)	Jul (52)	Aug (54)	Sep (131)	Oct (29)	Nov (32)	Dec (37)
2010	Jan (34)	Feb (36)	Mar (40)	Apr (23)	May (38)	Jun (34)	Jul (36)	Aug (27)	Sep (9)	Oct (18)	Nov (25)	Dec
2011	Jan (1)	Feb (14)	Mar (1)	Apr (5)	May (1)	Jun	Jul	Aug (37)	Sep (6)	Oct (2)	Nov	Dec
2012	Jan	Feb (7)	Mar	Apr (4)	May	Jun (3)	Jul	Aug	Sep (1)	Oct	Nov	Dec (10)
2013	Jan	Feb (1)	Mar (7)	Apr (2)	May	Jun	Jul (9)	Aug	Sep	Oct	Nov	Dec
2014	Jan (14)	Feb	Mar (2)	Apr	May (10)	Jun	Jul	Aug	Sep	Oct	Nov (3)	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (12)	Nov	Dec (1)
2016	Jan	Feb (1)	Mar (1)	Apr (1)	May	Jun (1)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec