David,
Without textures and without polygons to fill this sounds like a
reasonable load on the graphics card. And if they are static points
Java 3D should be able to optimize fully.
If the points form a 2D plane then why not use 2D graphics?
I've not tried to render a large number of static points so all my
comments are pure guesses. Perhaps someone else has done something like
this?
- John Wright
Starfire Research
"Krikheli, David" wrote:
>
> 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".
===========================================================================
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".
