Jean,
Switch :
I would break the performance cost into 3 parts, ie. memory cost,
rendering cost, and update cost. Here you've mentioned the following scene
setups :
A) SW B) G
/ ... \ / ... \
/ \ / \
SubGraph_0 SubGraph_N SW_0 SW_N
| |
SubGraph_0 SubGraph_N
Let's look at the costs for each of the setup.
Memory cost : The cost of (A) is lesser than (B), as it requires lesser
nodes to setup.
Rendering cost : In j3d1.2.1, (A) and (B) are the same. We cached the states
of Switch node.
Update cost : This is a bit tricky. Depending on the percentage of children
change over the total number of children. (B) can be cheaper if the number of
changed SW nodes/frame is small compare to the total number of SW nodes
under the same Group.
BranchGroup :
In general, the of cost of BG, both speed and memory, is small compare
to other j3d nodes. Setting capabilities bit may affect scene compilation,
hence rendering and update speed may suffer.
But, ALLOW_DETACH shouldn't cause significant performance impact.
TransformGroup:
TransformGroup node (w/ the ALLOW_TRANSFORM_READ and ALLOW_TRANSFORM_WRITE
capabilities set) can be expenseive. It will prevent j3d from flatening
the scene, hence increase memory, rendering and update costs.
We've greatly reduced the cost of doing chained TG update in j3d1.2.1, and
will continue to do so in the coming j3d1.3. But there is always the
additional cost of handling chained TG vs. single TG update. If user can
easily do the composition manually and set it to a single TG, by all
means go for it. :-)
- Chien Yang
Java 3D Team.
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> Importance: Normal
> Date: Thu, 3 May 2001 12:53:18 -0400
> From: Jean Laleuf <[EMAIL PROTECTED]>
> Subject: [JAVA3D] Performance hit of various nodes
> To: [EMAIL PROTECTED]
>
> Hi everyone,
>
> Does anyone know what the cost is (in memory use and execution speed) for
> various types of nodes? I'm particularly interested in the following:
>
> Switch:
> How does the performance of 1 Switch w/ multiple children using the switch's
> childMask compare to the performance of having 1 Switch per child? Is there
> a significant impact on memory use with the second approach? How much? How
> about execution speed? I would assume there's an appreciable hit, but I'd
> like to get a better idea of how much.
>
> BranchGroup:
> What is the speed & memory impact of inserting a BranchGroup (w/ these
> capabilities set: ALLOW_CHILDREN_READ, ALLOW_CHILDREN_WRITE,
> ALLOW_CHILDREN_EXTEND, ALLOW_DETACH) into a scenegraph? For example,
> BranchGroup(root)->TransformGroup->Shape3D VS.
> BranchGroup(root)->TransformGroup->BranchGroup->Shape3D: what is the impact
> of the added BranchGroup? Also, what is the impact of enabling the various
> capabilities I listed above? Does enabling ALLOW_DETACH impact performance
> significantly? If so, why? What about the others?
>
> TransformGroup:
> What is the cost per TransformGroup node (w/ the ALLOW_TRANSFORM_READ and
> ALLOW_TRANSFORM_WRITE capabilities set) added to a scenegraph? I'm trying to
> answer the following question:
> When building a scenegraph to achieve a given composite transform, is it
> more efficient to use a chain of TransformGroup nodes rather than a single
> TransformGroup for which you perform the transform composition manually?
> The first approach is conceptually simpler, but I would expect the second to
> be more efficient. This may not be true, however, if j3d performs any
> optimizations for the first case (such as caching intermediate composite
> transforms and reusing them when only one of the nodes in the chain is
> updated). Bear in mind that for each TransformGroup in the chain,
> ALLOW_TRANSFORM_READ and ALLOW_TRANSFORM_WRITE have been set (I assume that
> compile() will compress chains of TransformGroups for which these
> capabilities have not been cleared).
>
> Thanks a lot,
> -Jean Laleuf
> ([EMAIL PROTECTED])
>
> ===========================================================================
> 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".
