For performance related issue, Java 3D's perf_guide.txt is a good place to start. Here is the information on how the compile() method works :
- Compile
. Scene graph flattening: TransformGroup nodes that are
neither readable nor writable are collapsed into a
single transform node. . Combining Shape3D nodes: Non-writable Shape3D nodes
that have the same appearance attributes, not pickable,
not collidable, and are under the same TransformGroup
(after flattening) are combined, internally, into a
single. Shape3D node that can be rendered with less
overhead. - View Frustum Culling
The Java 3D implementation implements view frustum culling.
The view frustum cull is done when an object is processed for
a specific Canvas3D. This cuts down on the number of objects
needed to be processed by the low level graphics API.
Note : 1) pickable and collidable of a Node are set to true by default.
2) Over merging of Shape3D nodes can work against the View
Frustum Culling optimization. Apps. developer need to
find a balance.- Chien Yang Java 3D, Sun Microsystems Inc.
Florin Herinean wrote:
For both Mark and Chris,
Yes, compile() may do that in some cases. However, from my very own experience, in many cases it fails to accurately detect what can be merged. Besides that, there are two specific cases that I want to explain:
1. the merging is completely governed by the permissions the user is adding to the scene elements. In most of the cases, the user simply assigns permissions by default, thus totaly defeating the compile() purpose - compile() works only if you don't set any permissions at all. 2. the merging is not done at geometry level, but at scene elements level. An example, let's consider a scene containing 100 spheres, each in it's own TransformGroup containing a different Transform3D. The compile() will *NOT* transform that into a *single* Geometry object, but *you* can do it !
I know that 2. is true, because at the very first stage of my project, I was relying too much on the compile() method. The scene graph was following the hierarchical model description, which was very convenient. However, I saw poor performance and a huge memory usage, besides the fact that compile()-ing or not didn't change anything visible in the performance.
Later on I've spend a lot of effort to analize the model I was importing, up to the level of individual triangles and merge everything that I can *before* even generating the Geometry objects. Yes, I've applyied the transforms directly to the vertexes of the triangles and moved the triangles one level up in the hierarchy. Combining that with factory objects to detect and reuse Geometry objects that was repeated, reuse Appearances and Appearances elements, so the overall result was an increase of performance in terms of fps to over 100% (double the fps) and a reduction in memory usage from 200-300 MB to less than 70 MB.
Cheers,
Florin
-----Original Message----- From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED] Behalf Of Mark McKay Sent: Mittwoch, 5. Mai 2004 21:46 To: [EMAIL PROTECTED] Subject: Re: [JAVA3D] the Need for Speed debate
Florin Herinean wrote:
here are my 2c:
1) carefully design your scene. Don't use TransformGroups if you don't plan to dynamically move the objects bellow. A static branch containing many TransformGroups is a waste of resources which results in poor performance and a high memory usage. Collapse whenever possible such static
branchgroups
to Shape3D's or, if possible to single geometries.
I thought compiling a scene would walk the scene graph and eliminate unnecessary Transform groups, and even go as far as to merge a static tree into a single Shape. Am I wrong in this?
Mark McKay -- http://www.kitfox.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".
=========================================================================== 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".
