BTW, I just bought a GeForce2 MX400 w/ 64 megs and S-video out for US$98,
including shipping. If you're willing to spend about $30 more than that,
buy a Pro. I don't suggest getting a MX200.
----- Original Message -----
From: "John Wright" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 24, 2001 6:32 PM
Subject: Re: [JAVA3D] Skin and Bones/Muscles and brains
> David,
>
> I doubt you'll find anything that will beat the performance for the
> price of a GeForce 2 MX card. You should be able to buy one for less
> than $150 (depending on brand and memory they run about $70 to $150).
> If you want a higher end card then go with a GeForce 3 chipset (about
> $400).
>
> I'd recommend buying a name brand manufacturer (like Elsa) that you know
> will release regular driver updates. Brand is irrelevant to performance
> (not enough difference to care or notice in real world usage).
>
> - John Wright
> Starfire Research
>
> "Krikheli, David" wrote:
> >
> > Just want to get myself a decent graphics card - Does anybody know a
> > location of recent performance/price benchmarks on the net?
> >
> > Regards,
> > David Krikheli
> > (03) 9273-4841
> >
> > -----Original Message-----
> > From: David Yazel [mailto:[EMAIL PROTECTED]]
> > Sent: 24 June 2001 04:11
> > To: [EMAIL PROTECTED]
> > Subject: [JAVA3D] Skin and Bones
> >
> > I thought you all might be interested to read this note I posted to our
> > internal Cosm list. It contains design notes on our skin and bones
system.
> > we (unfortunatly) will not be releasing this code until Cosm goes live,
and
> > by then it might be redundant with the Java Gaming API, but in case you
were
> > planning on building this, you might find the information helpful.
> >
> > We are coming in at 530 nanoseconds to compute a full skin and bones
frame
> > on a 700 MHz PC. My C++/OpenGL friend was staggered to hear that. Seems
> > that Java still maintains a reputation for being slow, and much slower
than
> > C++. I wonder how long until the world wakes up and realizes how much
Java
> > has evolved. I was able to animate one character every frame at 180
frames
> > per second with a medium filled scene. Throttling the char animation
down
> > to an artificial 20 fps (which looks great btw) the frame rate on the
card
> > went up to 310 fps. This is in the test viewer, not in our full app.
Our
> > full app runs about 60 fps on a GeforceII right now, mostly due to a bug
in
> > java3d that causes it not to use display lists for multi-textured
geometry.
> >
> > Some information:
> >
> > 1. The system completely separates the animation data from the things
being
> > animated. An Animation is a collection of JointAnimations. Animations
> > have a bunch of info including the time in milliseconds that it should
take
> > to run its course, whether they cycle, etc.
> > 2. Each JointAnimation has a name which corresponds to the bone it is
> > allowed to influence. Its stores position and rotation animation tracks
> > which are keyframes for animation.
> > 3. A Skeleton is what is being animated. It has a set of bones which
form
> > the hierarchy of bones which make up the skeleton. We will be using the
> > standard character studio Biped, but any arbitrary bone hierarchy is
> > allowed.
> > 4. Skeletons also store the set of active animations, queued animations
and
> > dorment animations.
> > 5. When an Animation is attached to a skeleton, a LivingAnimation is
> > constructed and put in the active list. A LivingAnimation has a
reference
> > to an Animation plus data related to this particular instance like start
> > time, elapsed time and the current fractional keyframe. It also
establishes
> > a list of LivingJointAnimations.
> > 6. LivingJointAnimations have a reference one to one with a
JointAnimation,
> > plus they keep some speed up points into the frames for faster lookup.
> > 7. When the LivingAnimation is attached to the skeleton it is mapped to
the
> > bones. It creates LivingJointAnimations only for the JointAnimations
which
> > have a matching name in the bone hierarchy. This allows for partial
body
> > animations to be applied.
> > 8. As each LivingJointAnimation is constructed it registers itself with
the
> > bone it is modifying. Each bone can have as many animations effecting
it as
> > we want, with an alpha controlling the weight of one JointAnimation to
> > another. Mostly this will be for animation transitions.
> > 9. When a skeleton is asked to animate for a frame, it takes the time
and
> > looks through its active LivingAnimations and tells them to update
> > themselves for this frame. This in turn updates the rotation and
position
> > of all the LivingJointAnimations.
> > 10. The bones are then processed and each bone looks at its registered
> > LivingJointAnimations and adjusts its internal matrices for the bone,
> > weighting them appropriately.
> > 11. Skins are collections of Sinews, Vertex and Triangles. Each Sinew
forms
> > a bond between a vertex and a bone with a weight.
> > 12. After the skeleton has been updated, all the Vertex objects are
updated.
> > This causes all the Sinews to calcuate the position of the vertex as if
they
> > were the only bone influencing the vertex. These positions are then
> > weighted and combined to produce a new vertex position.
> > 13. Then all the triangles are processed and their normals are adjusted
> > using the same technique used for calculating vertex.
> > 14. Skins will be implemented as SingleSkin and MultiSkin. They inherit
all
> > the capabilities of skins, but they take the triangles and manage the
> > display. SingleSkin will be the first and simpler method and used for a
lot
> > of animals and early avatars. MultiSkins will be used by our advanced
> > texturing.
> >
> > While we are still working on a method to get or own animations out of
Max,
> > I wrote a Milkshape parser and took some Halflife models and loaded them
> > into the system. I wrote a VisualSkeleton object which can take any
> > Skeleton and update itslef to show the bones.
> >
> > We plan all sorts of things to handle the load of multiple
> > characters/animals/monsters in the scene at one time. Some of these
> > techniques include having several layers of animating queues, with
different
> > promotion policies depending on number of characters in view and thier
> > relative distance from the view. So in a crowded scene, the characters
> > nearest to you might be animated more frequently than ones further away.
But
> > if there are only a few then we will speed them up, even though they
might
> > be a bit further away.
> >
> > The other thing we can do and should do is that as we design our skins
we
> > have lower polygon version. This would be true of the whole naked
figure as
> > well as the item meshes. Basically just two versions. This saves time
on
> > the triangle and vertex manipulations as well as the load on the card.
> >
> > David Yazel
> >
> >
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> > of the message "signoff JAVA3D-INTEREST". For general help, send email
to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> > of the message "signoff JAVA3D-INTEREST". For general help, send email
to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
