John,
I appreciate your spending time thinking about the question. My answers
follow. Also, I've included a general description of the application I am
thinking about.
I am to visualise spatial points carrying information about some
measurements. The points form a surface - not a solid body. The measurements
are to be presented to the viewer as colors of the points. The actual
database may (will) contain more than 1E6 data points, however, I am
assuming that aggregation will be done to provide reasonable levels of
detail. Thinking about what the word reasonable means in this case I
identified the worst case scenario as follows:
- at a certain level of detail data points form a grid similar to a common
screen layout (1024x768);
- the user zooms out to see them all;
- I'd prefer the user to be happy.
Hence 1,000,000 points - this is just an approximate figure that for this
particular screen resolution would look like 1024x768=786432.
>> Are you talking about 1,000,000 vertices visible at all times?
Yes, this is a valid assumption in a context of the worst case scenario
above.
>> Are you going to do collision detection or not as you navigate?
No, I am not - the points have static locations and there is no active
objects in the scene.
>> How texture intensive will your scene be?
My current state of mind is No Textures. This is because I am inclined to
think that the PointArray Color capability would perform better compared to
the Texture capability. Please, let me know if you disagree on the
assumption.
>> How many lights would you be using?
either 0 or 1 directional & 1 ambient.
Regards,
David Krikheli
-----Original Message-----
From: John Wright [mailto:[EMAIL PROTECTED]]
Sent: 26 June 2001 00:56
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Skin and Bones/Muscles and brains
David,
Are you talking about 1,000,000 vertices visible at all times? Are you
going to do collision detection or not as you navigate? How texture
intensive will your scene be? How many lights would you be using?
Just as a guess you probably could approach that without CD (collision
detection) and only a few lights and reasonable texturing. Also the
horsepower of the CPU is going to factor in. We run a reasonably large
world but we dynamically load terrain as the user moves and hence we
probably don't have more than 10-20K polygons at a time and on an Athlon
800 with a Geforce 256 we typically have frame rates running from 40 to
100 fps. Our scene includes full collision detection though too and
some fairly heavy textures.
I've not had the opportunity to test a GeForce 3 so I don't know if it
will deliver a lot of extra performance. The big feature of the GeForce
3 sounds like the ability to custom program it and I don't know if or
when we'll see Java 3D take advantage of that.
- John Wright
Starfire Research
"Krikheli, David" wrote:
>
> Thank you for the reply, John. Do you think GeForce 2 would be sufficient
to
> keep the frame rate above 10 when visualising a point array containing
> 1,000,000 points (with the simplest navigation scene graph structure
> possible)? Would performance be roughly proportional to the price when
> moving from GeForce 2 to GeForce 3?
>
> Regards,
> David Krikheli
>
> -----Original Message-----
> From: John Wright [mailto:[EMAIL PROTECTED]]
> Sent: 25 June 2001 10:32
> To: [EMAIL PROTECTED]
> 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".
>
>
===========================================================================
> 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".
