> From: Justin Couch <[EMAIL PROTECTED]>
... specific stuff about setting polygon attributes ...
> 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.
The spec is a bit unclear about this aspect of J3D. Let me see if I can clear
it up a bit.
> 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"
This seems fairly concrete: the TransformGroup does not keep a reference to the
Transform3D which was used for setTransform(). Instead, the contents of the
Transform3D are copied to an internal transform in the TransformGroup.
> 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.
The Attribute objects use references to the objects used for the setXXX()
methods. The difference between TransformGroup.setTransform() and
Appearance.setXXX() should be made more clear.
The key is that PolygonAttributes extends NodeComponent which implies that the
object used to set the polygon attributes would become part of the scene graph.
On the other hand, Transform3D extends Object, which implies that a Transform3D
is not part of the scene graph, but is instead a "container". Not very clear, I
know.
The spec should make this more explicit: methods which set() using a
NodeComponent create a reference to the NodeComponent in the scene graph, while
methods which set() using objects which are not NodeComponents set the value by
copying the contents of the object.
> 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.
Actually, if you were implementing Java3D this differences in the classes would
be the clue you would need. The NodeComponent superclasses are what allow the
implementation to keep the scene graph in "sync". Transform3D's don't have any
kind of infrastructure for propigating changes, so it would be difficult to keep
track of changes to the transforms without polling the Transform3D objects.
Doug Gehringer
Sun Microsystems
===========================================================================
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".
