gdalgorithms-list

Re: [Algorithms] Skeletal Animation...

[Frag_ D. <fra...@ho...>]

     Wow, Jeff Lander's on this list!  How did I miss this list for so 
long!?!  Anyways, I've been reading like twenty-thousand emails, and am very 
glad that I joined this list.  Just wanted to comment on it...


>From: Jeff Lander <je...@di...>
>Reply-To: gda...@li...
>To: gda...@li...
>Subject: Re: [Algorithms] Skeletal Animation...
>Date: Mon, 28 Aug 2000 20:49:18 -0700
>
>
>Has Game Developer got some issues for you.  I have written several 
>articles on deformation of a mesh using an imbedded skeleton.  That will 
>handle the rendering aspect of a kinematic animation.
>
>http://www.darwin3d.com/gdm1999.htm#gdm1099
>http://www.darwin3d.com/gdm1998.htm#gdm0598
>
>For the physics, Chris Hecker wrote a multi-part series on linked rigid 
>body dynamics.  Specifically the example was a ponytail that moved 
>dynamically connected to a kinematic head.
>
>www.d6.com
>
>I don't know if Chris posted his ponytail app yet but if he hasn't send him 
>a note bugging him.  It should be there :)
>
>The person you were thinking of is Brian Mirtich from MERL.  His website is 
>http://www.merl.com/people/mirtich/
>
>-Jeff
>
>At 10:58 PM 8/28/2000 -0700, you wrote:
> >Hello.
> >
> >I was wondering if anyone had links to some good skeletal animation
> >techniques and perhaps some information about the kinematics involved.
> >
> >For example, if I was a model to have a ponytail which moves 
>realistically.
> >Given gravity and the mass of my character, I should be able to generate 
>the
> >normal force produced by walking (feet hitting the ground).
> >
> >Assuming the ponytail is just a couple bones end-to-end sharing 
>intermediate
> >vertices, the problem I arrive at is the way to correctly propogate a 
>force
> >applied at the origin vertex (ie the one connecting the ponytail to the
> >head) down into the other vertices.
> >
> >Any possible links would be great.  I heard that someone wrote quite a 
>few
> >papers on the physics involved in this, but I can't remember his name
> >exactly.  I know his last name is something like Mirich, but thats not 
>quite
> >it.
> >
> >Thanx!
> >Brandon Moro
> >
> >_______________________________________________
> >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

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

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

RE: [Algorithms] Alpha Channel

[Frag_ D. <fra...@ho...>]

     Have you tried using targa files?  You can create these with some 
programs.  If you can't afford Photoshop, Paint Shop Pro, Corel Draw, or 
something, you can get Gimp for free.  If all you need's the 8-bit alpha 
value (or 32-bit pixmap), then this works.  Then again, if you're looking 
for how you'd use this, I can only say how you'd do it in Open GL, not 
Direct3D (unless you wanted no hardware support, or decided to code for a 
specific card, but that would be crazy in this day, wouldn't it?)

>From: "Discoe, Ben" <ben...@in...>
>Reply-To: gda...@li...
>To: "'gda...@li...'"  
><gda...@li...>
>CC: vt...@eg...
>Subject: RE: [Algorithms] Alpha Channel
>Date: Sat, 26 Aug 2000 20:32:41 -0700
>
>
>Pai-Hung,
>
>It is indeed a difficult process to generate a good 8-bit alpha channel for
>a 32-bit texture.  For nearly any photographic data source, it cannot be
>done procedurally.  It requires a human artist to produce usable results.
>Here is a tutorial i wrote on how to produce the alpha using PhotoShop:
>http://vterrain.org/Plants/Create/
>
>Part of why it is so difficult is that along the perimeter of the shape
>(e.g. tree) there are pixels with alpha between 0 and 1, so bits of the
>surrounding (non-tree) texel color will appear on the output.  This is very
>difficult to fix.  No matter what color you choose (black is a common
>choice), you will get a "fringe" of that color around the resulting texture
>billboard, unless you hand-edit on a nearly pixel basis.
>
>One popular simplification is to use single-bit alpha (alpha testing, not
>alpha blending).  The advantages are that the art task is easier, and you
>don't have to draw the texture billboards in back-to-front order, which can
>be a significant performance hit since it is faster to sort by texture to
>avoid context switches.  The drawbacks are harsh, unnatural aliased edges
>for your texture billboards.
>
>In the VTP software, we currently use 8-bit alpha blending for quality, but
>i'm considering switching to alpha-testing for speed.  A forest may be more
>convincing with 2-3x as many trees even if the trees have jittery edges.
>
>Good luck,
>Ben
>http://vterrain.org/
>
> > -----Original Message-----
> > From: Pai-Hung Chen [mailto:pa...@ac...]
> > Sent: Saturday, August 26, 2000 1:09 PM
> > To: gda...@li...
> > Subject: [Algorithms] Alpha Channel
> >
> > Hi,
> >
> > I want to use billboard in my program but cannot find a good
> > way to create 32-bit bitmap with alpha channel of appropriate
> > values.  Basically I want to create a bitmap of tree with leaves
> > in various green colors (with alpha = 255) and all non-green
> > colors transparent (alpha = 0) so that I can use it
> > as the texture for my billboarded trees.
>
>
>_______________________________________________
>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.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

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

I completely agrees with akbar and Stephen on this. Even if you decided not
to use an off the shelf scene graph API. Do built one yourself. If you think
you can do a good one. It is not a trivial task to built a good one. This is
an area that I have done quite a lot of work on.

The SGI/Microsoft ill-fated Fahrenheit would be the cross-platform Opengl++.
You know what happened to it. Fahrenheit is actually architected quite well.
But that is another story....

-----Original Message-----
From: Akbar A. [mailto:sye...@ea...]
Sent: Tuesday, September 05, 2000 1:20 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs


hey,

>Hence, whilst it's theoretically possible to make your game
>run faster by writing it all in machine code
you would have to be one very smart person to pull this one off. topping of
what the compilers' are generating is getting harder and harder (iirc vc7 is
coming out later this year), plus there is the time it takes to write good
low-level code :|

>When it first appeared, everyone wanted to get at some lower level
>'bare metal' interface to the hardware for speed.
yes, i find this quite funny. remeber when everyone was like "give us the
metal" and saying other things like this. then when they finnally got it
with the psx2 a lot of them ran into problems (but they learnt a lot ;)


>lots of people complained that it stifled their
>creativity and wouldn't let them get at pixels in the
this is somewhat true. there where some really cool demos back in the dos
days that never made the converge to OpenGL.

in general scenegraphs are good, they lay out a lot of foundation work so
you don't have to reinvent "to much" of the wheel.

btw, new movies up at www.sgi.com.




peace,
akbar A.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stephen J Baker
Sent: Tuesday, September 05, 2000 1:22 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs



> At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs:
Wired
> or Tired" to discuss this, although not necessarily from a game
development
> standpoint.


I think scene graphs are like so many other aspects of making high
performance applications - we used to write machine code - compilers
were considered terribly inefficient.  Now compilers are getting
better (so they are less wasteful) - machines are getting faster
(so we care less) - and machines and our programs are getting
COMPLICATED (so writing machine code is less possible).

Hence, whilst it's theoretically possible to make your game
run faster by writing it all in machine code - nobody does
that anymore.

I think the same thing happens with API's like OpenGL.  When
it first appeared, everyone wanted to get at some lower level
'bare metal' interface to the hardware for speed.  I don't think
anyone is advocating that anymore...for much the same reason
that we don't use raw machine code anymore.

Well, Scene Graph API's are quite possibly the next stage of
evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
DOING you can get better performance by writing your own
low level engine to the 'raw' OpenGL.  But as multi-pass
rendering, shadows, etc get more and more complicated and
the machines get faster and the scene graph API's get better,
I believe there comes a point where you shrug your shoulders
and say "who cares" about the small performance loss that
comes from a generic rendering API versus something more
optimised to your application that you could have written
yourself.

Just as with compiler technology, the point where you decide
to switch depends a lot on how demanding your application
is and how skilled you are.  Red hot x86 machine coders
writing state of the art games were writing machine code
long after the amateur Tetris clone writers had switched
to C compilers.

Another aspect to this was that when OpenGL first appeared
on the PC, lots of people complained that it stifled their
creativity and wouldn't let them get at pixels in the
frame buffer.  It's really noticable how those sorts of
complaints have tailed off over the last few years...I
think we hear the same things about scene graph API's.

  For some people "it forces us all into the same mold"
  For other people "it liberates me from having to think
     about the polygons so I can concentrate on higher
     level stuff"  -- like physics for example.

Finally, what forced people into using OpenGL (or D3D
for that matter) was sheer hardware necessity - and it's
my view that this too will happen to scene graph API's.

We are already seeing with nVidia T&L cards that you
need to lock your data into particular chunks of memory
and send data to the card in carefully chosen chunk sizes
if you want to get the very best performance.  Those are
the kinds of *ugly* things that applications shouldn't
have to deal with - they should be hidden inside a well
written scene graph API - and if it were standardized
across various cards, it could hide these kinds of
hardware differences that OpenGL and D3D cannot.

SGI's new 'shader language' is an example of this too -
it's not a 'scene graph' API - but another way to look
at a higher level rendering API.  As scene graph API's
are to geometry, so shader languages are to state. They
can play nicely together too.

Scene Graph/Shader API's *will* be the next step - it's
just a matter of when the balance tips in their favor.

One thing that DOES concern me though is the lack of any
prior 'open' standardization efforts in this area.  I was
saddened that OpenGL++ didn't ever appear.

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

RE: [Algorithms] an opengl problem

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

hey Gabor,
this really isn't the right list for that ;)
there is a opengl-gamedev list which would be right for this question.
OPE...@fa...

if your not on the list, ask in your message for them to cc you.

>problem is that it is very slow.
card, driver ? maybe you could be calling a sleep function?
ask this on the opengl-gamedev list

you might also want to try these links next time a OpenGL question comes up
www.opengl.org
www.flipcode.com
check for "nehe's" site, he has some beg OpenGL programs which would suit
you.
www.gamedev.net
also www.google.com imho this is the best search engine in the world

peace,
akbar A.



-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of tSG
Sent: Tuesday, September 05, 2000 3:35 PM
To: gda...@li...
Subject: [Algorithms] an opengl problem


Hi!

I'm new on this list, so i describe myself. :)
I'm Gabor Simko (tSG), and I'm hungarian.
I like visualc,asm,free pascal and opengl.
This was that. :)

So my question:
  i have made a little program in opengl.
  It puts out 500 textured cube, but the
  problem is that it is very slow.
  I don't use any lights or fog etc...
  The resolution is 640x480x16million colors.
  Why could it be so slow?

Thx to everybody
    tSG


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

[Algorithms] an opengl problem

[tSG <ts...@ma...>]

Hi!

I'm new on this list, so i describe myself. :)
I'm Gabor Simko (tSG), and I'm hungarian.
I like visualc,asm,free pascal and opengl.
This was that. :)

So my question:
  i have made a little program in opengl.
  It puts out 500 textured cube, but the
  problem is that it is very slow.
  I don't use any lights or fog etc...
  The resolution is 640x480x16million colors.
  Why could it be so slow?

Thx to everybody
    tSG

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

[Scott L. <va...@be...>]

> Hence, whilst it's theoretically possible to make your game
> run faster by writing it all in machine code - nobody does
> that anymore.

Unless of course they're Playstation 2 developers and they
have no other choice >-)...

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

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

hey,

>Hence, whilst it's theoretically possible to make your game
>run faster by writing it all in machine code
you would have to be one very smart person to pull this one off. topping of
what the compilers' are generating is getting harder and harder (iirc vc7 is
coming out later this year), plus there is the time it takes to write good
low-level code :|

>When it first appeared, everyone wanted to get at some lower level
>'bare metal' interface to the hardware for speed.
yes, i find this quite funny. remeber when everyone was like "give us the
metal" and saying other things like this. then when they finnally got it
with the psx2 a lot of them ran into problems (but they learnt a lot ;)


>lots of people complained that it stifled their
>creativity and wouldn't let them get at pixels in the
this is somewhat true. there where some really cool demos back in the dos
days that never made the converge to OpenGL.

in general scenegraphs are good, they lay out a lot of foundation work so
you don't have to reinvent "to much" of the wheel.

btw, new movies up at www.sgi.com.




peace,
akbar A.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stephen J Baker
Sent: Tuesday, September 05, 2000 1:22 PM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs



> At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs:
Wired
> or Tired" to discuss this, although not necessarily from a game
development
> standpoint.


I think scene graphs are like so many other aspects of making high
performance applications - we used to write machine code - compilers
were considered terribly inefficient.  Now compilers are getting
better (so they are less wasteful) - machines are getting faster
(so we care less) - and machines and our programs are getting
COMPLICATED (so writing machine code is less possible).

Hence, whilst it's theoretically possible to make your game
run faster by writing it all in machine code - nobody does
that anymore.

I think the same thing happens with API's like OpenGL.  When
it first appeared, everyone wanted to get at some lower level
'bare metal' interface to the hardware for speed.  I don't think
anyone is advocating that anymore...for much the same reason
that we don't use raw machine code anymore.

Well, Scene Graph API's are quite possibly the next stage of
evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
DOING you can get better performance by writing your own
low level engine to the 'raw' OpenGL.  But as multi-pass
rendering, shadows, etc get more and more complicated and
the machines get faster and the scene graph API's get better,
I believe there comes a point where you shrug your shoulders
and say "who cares" about the small performance loss that
comes from a generic rendering API versus something more
optimised to your application that you could have written
yourself.

Just as with compiler technology, the point where you decide
to switch depends a lot on how demanding your application
is and how skilled you are.  Red hot x86 machine coders
writing state of the art games were writing machine code
long after the amateur Tetris clone writers had switched
to C compilers.

Another aspect to this was that when OpenGL first appeared
on the PC, lots of people complained that it stifled their
creativity and wouldn't let them get at pixels in the
frame buffer.  It's really noticable how those sorts of
complaints have tailed off over the last few years...I
think we hear the same things about scene graph API's.

  For some people "it forces us all into the same mold"
  For other people "it liberates me from having to think
     about the polygons so I can concentrate on higher
     level stuff"  -- like physics for example.

Finally, what forced people into using OpenGL (or D3D
for that matter) was sheer hardware necessity - and it's
my view that this too will happen to scene graph API's.

We are already seeing with nVidia T&L cards that you
need to lock your data into particular chunks of memory
and send data to the card in carefully chosen chunk sizes
if you want to get the very best performance.  Those are
the kinds of *ugly* things that applications shouldn't
have to deal with - they should be hidden inside a well
written scene graph API - and if it were standardized
across various cards, it could hide these kinds of
hardware differences that OpenGL and D3D cannot.

SGI's new 'shader language' is an example of this too -
it's not a 'scene graph' API - but another way to look
at a higher level rendering API.  As scene graph API's
are to geometry, so shader languages are to state. They
can play nicely together too.

Scene Graph/Shader API's *will* be the next step - it's
just a matter of when the balance tips in their favor.

One thing that DOES concern me though is the lack of any
prior 'open' standardization efforts in this area.  I was
saddened that OpenGL++ didn't ever appear.

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

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

[Stephen J B. <sj...@li...>]

 
> At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs: Wired
> or Tired" to discuss this, although not necessarily from a game development
> standpoint.


I think scene graphs are like so many other aspects of making high
performance applications - we used to write machine code - compilers
were considered terribly inefficient.  Now compilers are getting
better (so they are less wasteful) - machines are getting faster
(so we care less) - and machines and our programs are getting
COMPLICATED (so writing machine code is less possible).

Hence, whilst it's theoretically possible to make your game
run faster by writing it all in machine code - nobody does
that anymore.

I think the same thing happens with API's like OpenGL.  When
it first appeared, everyone wanted to get at some lower level
'bare metal' interface to the hardware for speed.  I don't think
anyone is advocating that anymore...for much the same reason
that we don't use raw machine code anymore.

Well, Scene Graph API's are quite possibly the next stage of
evolution.  There is no doubt that IF YOU KNOW WHAT YOU ARE
DOING you can get better performance by writing your own
low level engine to the 'raw' OpenGL.  But as multi-pass
rendering, shadows, etc get more and more complicated and
the machines get faster and the scene graph API's get better,
I believe there comes a point where you shrug your shoulders
and say "who cares" about the small performance loss that
comes from a generic rendering API versus something more
optimised to your application that you could have written
yourself.

Just as with compiler technology, the point where you decide
to switch depends a lot on how demanding your application
is and how skilled you are.  Red hot x86 machine coders
writing state of the art games were writing machine code
long after the amateur Tetris clone writers had switched
to C compilers.

Another aspect to this was that when OpenGL first appeared
on the PC, lots of people complained that it stifled their
creativity and wouldn't let them get at pixels in the
frame buffer.  It's really noticable how those sorts of
complaints have tailed off over the last few years...I
think we hear the same things about scene graph API's.

  For some people "it forces us all into the same mold"
  For other people "it liberates me from having to think
     about the polygons so I can concentrate on higher
     level stuff"  -- like physics for example.
 
Finally, what forced people into using OpenGL (or D3D
for that matter) was sheer hardware necessity - and it's
my view that this too will happen to scene graph API's.

We are already seeing with nVidia T&L cards that you
need to lock your data into particular chunks of memory
and send data to the card in carefully chosen chunk sizes
if you want to get the very best performance.  Those are
the kinds of *ugly* things that applications shouldn't
have to deal with - they should be hidden inside a well
written scene graph API - and if it were standardized
across various cards, it could hide these kinds of
hardware differences that OpenGL and D3D cannot.

SGI's new 'shader language' is an example of this too -
it's not a 'scene graph' API - but another way to look
at a higher level rendering API.  As scene graph API's
are to geometry, so shader languages are to state. They
can play nicely together too.

Scene Graph/Shader API's *will* be the next step - it's
just a matter of when the balance tips in their favor.

One thing that DOES concern me though is the lack of any
prior 'open' standardization efforts in this area.  I was
saddened that OpenGL++ didn't ever appear.

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] FW: [CsMain] Scene Graphs

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

Yes - and of coz read the classic Performer paper. I believe it is Siggraph
96 by Ruelfe and Hellman.

-----Original Message-----
From: Graham S. Rhodes [mailto:gr...@se...]
Sent: Tuesday, September 05, 2000 7:14 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs


At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs: Wired
or Tired" to discuss this, although not necessarily from a game development
standpoint.

Here are a couple of links that should give you part of the content of that
presentation (if you don't have the SIGGRAPH proceedings already):

http://www.intrinsic.com/technology/presentations.htm
http://www.cs.brown.edu/research/graphics/research/siggraph99/scenegraph/

Graham Rhodes

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Aaron
> Drew
> Sent: Saturday, September 02, 2000 7:56 PM
> To: gda...@li...
> Subject: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> I've read many discussions on this list as to the pro's and con's
> of various
> solutions to storing, rendering and processing 3D objects but the
> scene-graph hasn't really made much discussion since I've been subscribed.
>
> I can't seem to find much on the web in regards to their usefulness apart
> from a few papers on VRML and Java3D.
>
> I'm having trouble seeing how the added cost of unnecessary traversal of
> nodes and the memory overheads of parent/child links in a scene would be
> worth the added effort but I'm curious as to the thoughts of the many
> experienced developers on this list.
>
> Do scene-graphs pay off?
>
> If so, how?
>
> Managing vertex buffers, textures, multiple instances of objects (with
> shared vertex data), etc can get rather clumsy without a consistant system
> yet everything I've read about scene-graphs suggests that they are simply
> traversed and the objects in them rendered. How would I represent (say) an
> octree implementation within a construct like
> this?
>
> - Aaron
>
> _______________________________________________
> 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] FW: [CsMain] Scene Graphs

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

At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs: Wired
or Tired" to discuss this, although not necessarily from a game development
standpoint.

Here are a couple of links that should give you part of the content of that
presentation (if you don't have the SIGGRAPH proceedings already):

http://www.intrinsic.com/technology/presentations.htm
http://www.cs.brown.edu/research/graphics/research/siggraph99/scenegraph/

Graham Rhodes

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Aaron
> Drew
> Sent: Saturday, September 02, 2000 7:56 PM
> To: gda...@li...
> Subject: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> I've read many discussions on this list as to the pro's and con's
> of various
> solutions to storing, rendering and processing 3D objects but the
> scene-graph hasn't really made much discussion since I've been subscribed.
>
> I can't seem to find much on the web in regards to their usefulness apart
> from a few papers on VRML and Java3D.
>
> I'm having trouble seeing how the added cost of unnecessary traversal of
> nodes and the memory overheads of parent/child links in a scene would be
> worth the added effort but I'm curious as to the thoughts of the many
> experienced developers on this list.
>
> Do scene-graphs pay off?
>
> If so, how?
>
> Managing vertex buffers, textures, multiple instances of objects (with
> shared vertex data), etc can get rather clumsy without a consistant system
> yet everything I've read about scene-graphs suggests that they are simply
> traversed and the objects in them rendered. How would I represent (say) an
> octree implementation within a construct like
> this?
>
> - Aaron
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

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

[Stephen J B. <sj...@li...>]

On Sun, 3 Sep 2000, Jonathan Wight wrote:

> on 9/2/00 6:55 PM, Aaron Drew at ri...@ho... wrote:
> 
> > Managing vertex buffers, textures, multiple instances of objects (with
> > shared vertex data), etc can get rather clumsy without a consistant system
> > yet everything I've read about scene-graphs suggests that they are simply
> > traversed and the objects in them rendered. How would I represent (say) an
> > octree implementation within a construct like
> > this?
> 
> The scene graph could just be thought of as a convenient logical structure
> used to organise your data. It's actually more than just that (for example
> it lends itself well to a portal based scheme or a hierarchical bone based
> animation system). Keep the octree separate from your scene graph but have
> it share the leaf nodes of your scene graph.
 
Or...

  Get a hold of a user-extensible scene graph and add Octree functionality
into it.  Since scene graphs are really well suited to object oriented
approaches, many are written in C++ which enables you to use class
inheritance to customise specific node types to your needs. Adding an
octree node type should be fairly easy in any decent SceneGraph API.

I wrote and support an OpenSource scene graph API that you might
find interesting - there are LOTS of others out there...

   http://plib.sourceforge.net/ssg

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] FW: [CsMain] Scene Graphs

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

The scene-graph should be the foundation of any realtime renderer. The
parent-child is to put a good heirarchy. I don't find it essential to have
both a parent and child link. And the child link is jst a concept. U can
use an array for containers (which I do).

A good heirarchy is essential to any good culling or collision testing. Or
for sharing sub-trees. A well abstracted heirarchy allows a good separation
of overall scene access function be separated from the most optimal
renderer specific representation. Which allows a single RT core rendering
but supports multiple DirectX versions, or OpenGL and Direc3D. Besides, the
scene-graph is needed to interface to an animation or physics engine well.

-----Original Message-----
From: Aaron Drew [mailto:ri...@ho...]
Sent: Saturday, September 02, 2000 4:56 PM
To: gda...@li...
Subject: [Algorithms] FW: [CsMain] Scene Graphs


I've read many discussions on this list as to the pro's and con's of various
solutions to storing, rendering and processing 3D objects but the
scene-graph hasn't really made much discussion since I've been subscribed.

I can't seem to find much on the web in regards to their usefulness apart
from a few papers on VRML and Java3D.

I'm having trouble seeing how the added cost of unnecessary traversal of
nodes and the memory overheads of parent/child links in a scene would be
worth the added effort but I'm curious as to the thoughts of the many
experienced developers on this list.

Do scene-graphs pay off?

If so, how?

Managing vertex buffers, textures, multiple instances of objects (with
shared vertex data), etc can get rather clumsy without a consistant system
yet everything I've read about scene-graphs suggests that they are simply
traversed and the objects in them rendered. How would I represent (say) an
octree implementation within a construct like
this?

- Aaron

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

[Algorithms] Quaternions in IK

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

Hi all ,

Does any one know an efficient way of constraining quaternions in IK 
without factorizing them into 3 axis quaternions ?
Finding the required rotation quaternion in IK is pretty easy , but how can 
we make sure that it doesn't violate or 3 constrains of the 3DOFs of the 
joint ? what I'm doing now is factorizing the IK result quaternion of the 
joint into xrotation quaternion yrotation quaternion and zrotation 
quaternion , constrain them by their maximums and recombine them again , 
which is obviously a very expensive process.

any ideas ? or maybe references ?

Thanks

Auday

Re: [Algorithms] Projecting a point on a plane

[Aldo S. <al...@ho...>]

Thanks, guys!


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

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

[Algorithms] Problem: ProgMesh Texturing

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

...hi guys,

i've got a BIG problem with progressive meshes ...

normaly our 3d designer are modelling the complete
modell in one piece so it's easy for our 3d engine
to create a progressive mesh (@ this point simply
via the d3dx library function) ...

now our designers are texturing the modells by
creating one textures and simply splitting/breaking
each vertex into multiple so they're able to move
each triangle on a special position on the texture
(this wil create some special effects when mipmaping
  but this is no real problem for us...)

the real problem now is that: first d3dxprogmesh
has mulitple problems with these multiple uv coords
... (broken verts / multiple verts with the same
x/y/z position and different uv coords)

so ... now my question ... how do i texture a complex
modell / mesh so i can use it as a progressive mesh

...and tips would be nice ... my first idea was some
sort of polar coordinates spherecial wraping to begin
with ... or more badly just to split the mesh into
multiples ... which would lower the use of the
progmesh concept ...

thx, re...@ma...


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

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

[Scott L. <va...@be...>]

In my experience, flight sims, space shooters, and just about
any other external environment can benefit greatly from either
a plain old scene graph or some sort of minor extension to the
approach since there's relatively little occlusion and lots and
lots of offscreen and out of range culling.  I spent some time
last year considering how to write a portal engine within the
formalism and it seemed like they were apples and oranges
approaches to the same thing in that one is great with external
environments and the other is fantastic when there's lots of
occlusion.

There are some hybrid approaches for situations like dense
urban scenes involving lots of precalculation and bitmasks,
but those would waste a ton of memory if used in a situation
more appropriate for portals.

And that's my two cents and worth every penny!

Scott

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

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

on 9/2/00 6:55 PM, Aaron Drew at ri...@ho... wrote:

> Managing vertex buffers, textures, multiple instances of objects (with
> shared vertex data), etc can get rather clumsy without a consistant system
> yet everything I've read about scene-graphs suggests that they are simply
> traversed and the objects in them rendered. How would I represent (say) an
> octree implementation within a construct like
> this?

The scene graph could just be thought of as a convenient logical structure
used to organise your data. It's actually more than just that (for example
it lends itself well to a portal based scheme or a hierarchical bone based
animation system). Keep the octree separate from your scene graph but have
it share the leaf nodes of your scene graph.

    Jon.

Re: [Algorithms] Graphics Gems repository now at www.graphicsgems.org

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

> The Graphics Gems series code repository now has an easier-to-remember
> forwarding URL:
>
>     http://www.graphicsgems.org
>
> (.com was already grabbed, maybe a squatter). On a similar note, I also
> grabbed:
>
>     http://www.raytracingnews.com
>
> for the Ray Tracing News archives.

Cool, now I don't have to bookmark so many RTN volumes. (great stuff by the
way :)

>
> In case you're interested, I went with www.namesecure.com for
> forwarding; not the cheapest prices, but their interface for managing
> the URLs is fairly nice.
>

You still paid for them? namezero and namedemo offer them free.

Conor Stokes

[Algorithms] FW: [CsMain] Scene Graphs

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

I've read many discussions on this list as to the pro's and con's of various
solutions to storing, rendering and processing 3D objects but the
scene-graph hasn't really made much discussion since I've been subscribed.

I can't seem to find much on the web in regards to their usefulness apart
from a few papers on VRML and Java3D.

I'm having trouble seeing how the added cost of unnecessary traversal of
nodes and the memory overheads of parent/child links in a scene would be
worth the added effort but I'm curious as to the thoughts of the many
experienced developers on this list.

Do scene-graphs pay off?

If so, how?

Managing vertex buffers, textures, multiple instances of objects (with
shared vertex data), etc can get rather clumsy without a consistant system
yet everything I've read about scene-graphs suggests that they are simply
traversed and the objects in them rendered. How would I represent (say) an
octree implementation within a construct like
this?

- Aaron

[Algorithms] Graphics Gems repository now at www.graphicsgems.org

[Eric H. <er...@ac...>]

The Graphics Gems series code repository now has an easier-to-remember
forwarding URL:

    http://www.graphicsgems.org

(.com was already grabbed, maybe a squatter). On a similar note, I also
grabbed:

    http://www.raytracingnews.com

for the Ray Tracing News archives.

In case you're interested, I went with www.namesecure.com for
forwarding; not the cheapest prices, but their interface for managing
the URLs is fairly nice.

Eric

Re: [Algorithms] Curves...

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

> >Bezier patches are easy to render.
> opinion:
> imho patches are horrible, after talking with a whole lot of people (i
used
> to like patches) writing some code...

They aren't horrible - They do have their disadvantages. But they also have
their advantages.

>
> there are just to many problems with patches, it's not worth the effort.
> they get split back to triangles, artists can do more with a higher mesh
of
> triangles.
> there are "so" many problems with patches that people don't see when
> starting out :|
> someone should really right an article on the downsides of patch
rendering.

Most are solvable problems. Easily solvable. Arstist can get a higher mesh
yes, but it costs a lot more in terms of memory.

Especially when you do animations.

If you think beziers into the design of your engine/feature set, you can do
very well and not have a single problem.

>
> sigh, this will probably start a debate why patches are good, if only i
had
> the energy to discuss more about this. i think i might have already
written
> a few points about this in a previous e-mail.
>
I think they are good, but only when used right, and when you have a good
solution to handle them.

Bicubic bezier patches can be rendered blindingly quick (If you used a
bivariate forwards differencing scheme, and make sure you can collapse the
algo all the way down to adds in both the S and the T loop), they are low
memory for the look they can provide and they are biparametric which makes
them perfect to map lightmaps etc to.

One of the things I'm doing at the moment is a biparametric geometry
composite pipeline. Beziers (both curves and patches) fit well into the
scheme, and I think I'm going to have to make regular use of them. I think
the system is a big success so far - I've gotta implement some more
functions, and clean some stuff up though before I see the true worth of the
system.

Conor Stokes

RE: [Algorithms] Curves...

[Lipson, P. <Pet...@br...>]

I have a little energy for a debate...
  For my application, the key feature of patches is that it's a tremendous
compression technique. On PSX-2, at least, handling data is very expensive,
while computations aren't. There are a few cunning tricks you can use to
overcome a lot of the problems with patches.  Other problems can be avoided
by selecting content or techniques that don't stress the implementation.

Peter Lipson
Mattel Interactive

> -----Original Message-----
> From: Akbar A. [mailto:sye...@ea...]
> Sent: Friday, September 01, 2000 2:59 PM
> To: gda...@li...
> Subject: RE: [Algorithms] Curves...
> 
> 
> >Bezier patches are easy to render.
> opinion:
> imho patches are horrible, after talking with a whole lot of 
> people (i used
> to like patches) writing some code...
> 
> there are just to many problems with patches, it's not worth 
> the effort.
> they get split back to triangles, artists can do more with a 
> higher mesh of
> triangles.
> there are "so" many problems with patches that people don't see when
> starting out :|
> someone should really right an article on the downsides of 
> patch rendering.
> 
> sigh, this will probably start a debate why patches are good, 
> if only i had
> the energy to discuss more about this. i think i might have 
> already written
> a few points about this in a previous e-mail.
> 
> 

Re: [Algorithms] Curves...

[Ralf S. <rap...@ra...>]

|> Bezier or Nurb:s?? or maybe something else...
| If you want smooth looking terrains, both are good.
| If not, then you will have to do some bump or displacement
| mapping to get nice pits, valleys, and such.

a simple but effective trick i used in an experimental isometric-terrain voxel engine was this:

the terain itself was generated by a spectral-synthese heightfield generation programm written by Klaus Hartmann.
the data(512x512) was stored as a height-map and during runtime converted to 2d-splines.
these splines were rendered to the screen with a resulting size of 65536x65536(the entire "new" "base"-heightfield).

as Dave remarked everything was round and smooth...

to add artificall structure i "added" the initial heightmap with the size of 512x512 to the resulting heightfield(65536x65536) using tiling.
i think i have to remark: 
one nice feature of heightfields generated by spectrale-synthese is: they "tile" perfectly!!

well, there was structure! but unfortunately now the "__repeating__" heightfield "on top" of the base heightfield was visible.

so, as a last step i was computing the roughness at a given position at the base-heightfield and then scaling the detail-heightfield linear to the corresponding roughness.

here are some results:

http://www.rappongi.com/h1.jpg
http://www.rappongi.com/h2.jpg
http://www.rappongi.com/h3.jpg

last remarks:

the roughness was computed by computing the deltas-height of surounding heights.
... the roughness values between four samples on the base-heightfiled were computed using bi-linear interpolation.

finalHeight = heightFromSplines(x, y) + heightFromHeightfield(x & 511, y & 511) * roughness(x, y)


maybe this small trick will be usefull for someone else.

- ralf

RE: [Algorithms] Curves...

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

>Bezier patches are easy to render.
opinion:
imho patches are horrible, after talking with a whole lot of people (i used
to like patches) writing some code...

there are just to many problems with patches, it's not worth the effort.
they get split back to triangles, artists can do more with a higher mesh of
triangles.
there are "so" many problems with patches that people don't see when
starting out :|
someone should really right an article on the downsides of patch rendering.

sigh, this will probably start a debate why patches are good, if only i had
the energy to discuss more about this. i think i might have already written
a few points about this in a previous e-mail.


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 Dave
Smith
Sent: Friday, September 01, 2000 3:46 PM
To: gda...@li...
Subject: Re: [Algorithms] Curves...


Mats Lundberg wrote:
>
> Witch curve-algho "should" you use for a simple terrain rendering?

That's "Which". Not the story book child-eating type. ;-)

> Bezier or Nurb:s?? or maybe something else...
If you want smooth looking terrains, both are good.
If not, then you will have to do some bump or displacement
mapping to get nice pits, valleys, and such.

> Which is more efficient when storing the terrain info and then rendering
it??

There are fast algo's for rendering Bezier patches.
(via forward differencing).  NURBS are usually broken
down into Bezier and then rendered.

> pros - cons...
>

pros:

Bezier patches are easy to render.
Few samples(control points) can yeild large surface areas.

cons:

Gotta watch for cracks between boundaries.
(Look at Excitebike64 on Nintendo, especially the Desert
 course).
Too smooth to be realistic.

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

Re: [Algorithms] Curves...

[Dave S. <Dav...@sd...>]

Mats Lundberg wrote:
> 
> Witch curve-algho "should" you use for a simple terrain rendering?

That's "Which". Not the story book child-eating type. ;-)

> Bezier or Nurb:s?? or maybe something else...
If you want smooth looking terrains, both are good.
If not, then you will have to do some bump or displacement
mapping to get nice pits, valleys, and such.

> Which is more efficient when storing the terrain info and then rendering it??

There are fast algo's for rendering Bezier patches.
(via forward differencing).  NURBS are usually broken
down into Bezier and then rendered.

> pros - cons...
> 

pros:

Bezier patches are easy to render.
Few samples(control points) can yeild large surface areas.

cons:

Gotta watch for cracks between boundaries.
(Look at Excitebike64 on Nintendo, especially the Desert
 course).
Too smooth to be realistic.

-DaveS