Mark Hood wrote:
Indexed geometry is great for storage and convenient for representation,
but terrible for rendering. Graphics hardware wants contiguous streams
of vertex data for the best performance. With indices you can skip
around vertex data -- this destroys all locality of reference and
creates shorter data packets across the graphics bus.
Except that you have also destroyed the end user's request that they
want to optimise in a different way - minimal bus usage. By using
indexed geometry, that's what they are asking for. If they wanted to
provide interleaved data, then there is the facilities to do so in
Java3D. Don't screw around with the data in the way we want it
presented. We know best how to render our geometry and how we want to
optimise. Not you. If we want to pass it in indexed, leave it that way.
The low level graphics APIs support that form, so there is no reason not
to let it be that way.
We have never characterized indexed geometry as high-performance and
don't recommend it for performance-sensitive applications. Using
by-reference mode for the vertex data doesn't improve the situation.
What do you define as "performance sensitive"? If I have an application
that uses minimal geometry but heavy textures, I want that bus allocated
to shipping my textures in and out of main memory. I don't want it lost
to someone else deciding to unindex the geometry on me and generating
bucketloads of garbage. My code wants to optimise for minimal geometry
being passed over the bus because other far more important things need
it, and rendering performance is going to be impacted by something else
far greater.
There isn't any way for Java 3D to find out if you've changed a normal
or a texture coordinate in one or more of the array elements addressed
by the reference without iterating through all the data and keeping a
copy itself for comparison.
What's that got to do with it? If I've told you I've changed the normal
data, but nothing else, then that's all I've changed. Assume it has
changed and just update the normal information appropriately. Why do you
even need to check if something has changed? There's no need to throw
out all the geometry and re-index it. You've still got reference to the
other source arrays, so just copying the normals back is easy. Besides,
you shouldn't be doing anything at all to it, just passing that array
straight through to the appropriate OpenGL or DX call. Sure, if I've
compiled the scene graph go ahead and make those changes, but if I've
not asked for optimisations to be done, don't do it.
Allowing more fine-grained update sematics to the API could be a
reasonable RFE for the next major release of Java 3D. If anybody thinks
this is important for their indexed geometry application, please submit
the RFE.
There is no reason for one. All I want you to do is honour what I've
requested of the rendering API, not what you happen to think might be best.
--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
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".
