From: Alex Bowden
Sent: Thursday, September 07, 2000 6:52 AM
> I'm trying to get my brain around the use and intent of the 3D library
used with J3D.
Be careful. Have a friend sit with you the first couple of times.
> I'm used to 4x4 transformation matrices to give general real world
transforms of 3D > co-ordinates which are generally used with a 3D
homogeneous point or vector
> definition (x, y, z, 1.0)
The sensible homogeneous representation of Point4* is (x, y, z, 1.0) and of
Vector4* (x, y, z, 0.0). This way Point4* + Vector4* is a Point4*,
Vector4* + Vector4* is a Vector4*, Point4* - Point4* is a Vector4*, all
sensible outcomes. The result of Point4* + Point4* doesn't make sense
mathematically (w=2.0), nor does it make sense geometrically.
This was hotly debated here a few summers ago, and I think the strict
constructionists who thought this homogeneity should be the organizing
principle of the API lost. This representation is certainly expressed, just
not featured. Look at Appendix A in the API Specification. The
constructors for Point4* set w=1.0, the constructors for Vector4* set w=0,
and the new-to-1.2 conversions from *3* make the corresponding sets.
> or more generally (xw, yw, zw, w). A simple 3D matrix won't, for example,
> perform a rotation about an arbitrary vector which does NOT pass through
the
> origin.
If I understand your complaint, neither will a Matrix4*. You'll always have
to translate to the center of rotation first. Methods that offer to do it
in one operation are just wrappers for the translate * rotate.
> The Transform3D object clearly can do this and almost certainly converts
> Point3f and Vector3f to Point4f and Vector4f by adding 1.0 for w.
Partly true. See above. Point4*s transform to Point4*s (w=1.0), Vector4*s
transform to Vector4*s (w=0.0).
> But Point4f and Vector4f don't generally seem to function as homogeneous
> points and vectors - e.g. add() adds the w components rather than
> dividing by them first - i.e. they are being used as (x, y, z, w)
The structure of vecmath *uses* the transformation and combination
properties of the homogeneous Point4* and Vector4*, but it doesn't *enforce*
the geometric restrictions. This is a consequence of vecmath's basic object
model, and, IMHO, is a mistake of the highest order. For example you can
freely add() two Point4*s by virtue of their inheritance from Tuple4*, but
you're on your own dealing with the meaningless result. Same with the the
constructors and set()s that take float[] arguments.
> This seems
> a - inefficient (you have to keep swapping between 3f and 4f entities
> to perform basic operations
In practice, this might be less of a problem than you imagine. I think that
most users deal with the higher order structures (TransformGroup, Geometry,
Shape3D, etc.), which skin over the basic ugliness below. The people who
built those classes fully understood whatever theoretical shortcomings
vecmath might have (if it has any), and worked around them.
> b - verbose
Maybe same response here.
> c - functionally limiting. Real homogeneous usage solves so many
> pathological issues (e.g. letting curve control points go off to infinity
> in a particular direction while still correctly obeying
transformations.....)
> so its generally nicer to write the whole application in homogeneous3D
I prefer to think that the higher level operations cover for most of it. By
the time that you're stacking up TransformGroups and Shape3Ds on a scene
graph, you can forget about the object structure of vecmath, as long as the
part of it you're using delivers the correct result.
> So, am I misunderstanding the Point4f and Vector4f or are there
> proper homogeneous equivalents available somewhere else?
I think that you're understanding the basic conflicts, but I think that it's
a losing enterprise to look for propriety. Relax. Deal with
TransformGroups, BrabchGroups, and Shape3Ds and build great content.
Sorry I couldn't help much, but it felt good to rant.
Fred Klingener
Brock Engineering
===========================================================================
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".
