Ellery Chan wrote:
>
> Is there an easy way to override the appearance for a large portion of a
> scene graph, say to toggle texturing or wireframe/solid rendering? Or
> do I have to enable all the ALLOW_*_WRITE flags on the Appearance
> objects of all my Shape3Ds and recursively traverse the scene graph to
> change an attribute? Or can Shape3Ds share an Appearance object by
> reference, so I need only modify one?
Ah... welcome to one of the Great Mysteries of Java 3D. Based on
empirical data collected over many moons of watching this email list, I
do believe that the common appearance node thing will work. However, you
may have the severly limiting factor that a single appearance generally
means a single colour for every single object (you need a separate
appearance for each texture you want to use or different Material
config).
Basically what you need to do is:
- enable the writing capability in the PolygonAttributes
- enable ALLOW_POLYGON_ATTRIBUTES_WRITE
- Keep a reference to the PolygonAttributes _and_ it's parent
Appearance node
- When swapping, set the capability in the Attrib class, then call
appearance.setPolygonAttributes() with same.
However, due to the complete lack of specification (one of my pet
topics!), there is another possiblity, but simply setting the mode in
the polygon attributes, it will automatically pick up this for the next
rendering pass.
To me this seems rather silly, but is another one of these problems
where the J3D team seem to assume that you know everything there is to
know about the internal implementation and don't tell you anything.
Here's the basic wording problem:
A TransformGroup node uses a Transform3D class to deal with it's
transformation attributes. To set a new set of transformation
attributes, you first set the value in the Transform3D (even if it is
the same reference to what you orginally created). Next you then
TransformGroup.setTransform(Transform3D) with the appropriate capability
set. The wording from the Javadoc is:
"Sets the transform component of this TransformGroup to the value of the
passed transform"
For the various Appearance/Attribute combinations the wording is less
than clear. You need a capability bit set in order to change anything at
the attribute level. For example, to change between wire/solid you use
PolygonAttributes.setPolygonMode(..). Here the wording is:
"Sets the polygon rasterization mode for this appearance component
object."
Now in isolation, this would appear to be fine because the wording is
very similar to the TransformGroup stuff. You would assume that setting
the value would mean that it is automatically picked up next time
through.
The problem is, does the parent Appearance class get copied like the
Transform3D does, or does it get referenced. Let's look at the set
method doc:
"Sets the polygonAttributes object to the specified object. Setting it
to null will result in default attribute usage."
Here does "set" refer to a reference to the original object or does it
mean "make an internal copy of it"? If it is the former, then the
terminology is contradictory to that used for TransformGroup where "set"
== "copy". If it is the later, then the assumed behaviour is the same as
TransformGroup - even though you change the values in the Attribute
class, they are not picked up until the next time that you
setAttributeClass(). Following from this, what is the point of having
capability bits on the Attribute object when you will need to set values
in it and then copy that across. Seems contradictory to me again.
If I was producing my own implementation of Java3D, I would have
absolutely no idea what I am supposed to do for correct behaviour. It
would be a flip of the coin to decide one way or the other - at least
without reference to the Sun implementation by trial and error.
--
Justin Couch Author, Java Hacker
Snr Software Engineer [EMAIL PROTECTED]
ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------
===========================================================================
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".
