People using Primitive derived objects may be interested in the following.
I recently downloaded and installed the latest release of J3D (1.1.1) and to
my dismay several things broke relating to Primitives.
Our applet uses Box and Sphere primitives extensively. Unfortunately
primitives no longer have APPEARANCE_READ and APPEARANCE_WRITE set by
default. I.e.: User in the field installs the latest release of J3D from Sun
and our application no longer runs.
To set these attributes use the Primitive.ENABLE_APPEARANCE_MODIFY flag.
I.e.
(pre 1.1.1)
Box( 0.5f, 0.5f, 0.5f, null );
(in 1.1.1)
Box( 0.5f, 0.5f, 0.5f, Primitive.GENERATE_NORMALS |
Primitive.ENABLE_APPEARANCE_MODIFY, null );
Even worse, GeometryArray.processQuadStrips has been modified to return a
TriangleStripArray instead of a QuadStripArray (why?). This has the effect
of causing all Box objects when rendered as wireframe to show the line
separating the 2 triangles that compose each face. Some optimisation...! Not
very good.
Interestingly GeometryArray.processQuads has NOT been modified.
We are now faced (because of an *undocumented* change in 1.1.1) with having
to write our own Box primitive (when I thought we were code complete), that
uses a QuadStripArray like the old implementation did.
I appreciate that the utils package comes with lots of disclaimers, but
these sort of undocumented and flawed changes will quickly alienate
developers... It makes me wonder whether 1.1.2, or subsequent release, will
break anymore of our code once it is in use in the field.
I believe that the implementation of Primitive and the derived classes is
essentially flawed, and that people should seriously consider rolling there
own over using the built in Primitives. IMHO Primitive should be derived
from Shape3D and also contain an array of Shape3D objects (or a Group if Sun
insists).
You would have though that key to the design of Primitive would be the
ability to use a Primitive everywhere you had a Shape3D and vice-a-versa...
Looking at the differences in the implementations of the Primitives also got
me looking at the (much vaunted) cached geometry implementation. Crude and
inefficient are the two words that spring to mind...
How's this for extensible OO design (from Primitive.java):
static Hashtable geomCache = new Hashtable();
protected GeomBuffer getCachedGeometry(int kind, float a, float b, float
c,
int d, int e, int flags)
{
String key = new String(kind+strfloat(a)+strfloat(b)+
strfloat(c)+d+e+flags);
Object cache = geomCache.get(key);
return((GeomBuffer) cache);
}
So, every time you create a primitive you do:
4 int -> string conversions
3 float -> string conversions
create (and hence GC) a String object
do a *synchronized* HashTable lookup
...all based on 7 arbitrary parameters!
What happens when a primitive is written that can't be uniquely described
using 4 ints and 3 floats I don't know!
In summary, Sun broke our code, and I'm pissed off. Based on the quality of
the implementation of Primitive, and some of the excellent engineers at Sun,
I would say that the Primitive implementation will probably get a major
overhaul for the next big release.
I would suggest that if you would like your code to remain compilable for
1.2 you stay away from Primitive derived objects and roll your own compound
Shape3D classes until Sun get their act together.
Daniel Selman
(having a bad day)
Tornado Labs Ltd.
Email: [EMAIL PROTECTED]
Web: http://www.tornadolabs.com
Phone: +44 (0131) 343 2513
Fax: +44 07070 800 483
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
