On Thu, 2008-02-28 at 22:42 -0500, Sean Luke wrote:
> Hi Glen.  The default use of CubePortrayal3D has no need to modify  
> polygon attributes.  For example, PSO3DWithUI (particle swarm  
> optimization) works great with CubePortrayal3D as is.  This suggests  
> that your code must be doing something special to CubePortrayal3D  
> which is tickling Java3D's need to modify its polygon attributes.   
> Having it draw only as a wireframe maybe?  Adding gourad shading? Dunno.

I've created a SlabPortrayal3D inheriting from CubePortrayal3D that
basically just overrides the "verts" instance variable (with one
dimension scaled down so that it's much smaller than the others).

In the constructor for that class, I do the following:


public SlabPortrayal3D(java.awt.Color color, float scale) {
   super(appearanceForColor(color),false,false,scale);

   for(int i=0;i<scaledVerts.length;i++)
      scaledVerts[i] = verts[i]*scale;
}


I call super.getModel() implicitly since I don't override getModel() in
SlabPortrayal3D.  And CubePortrayal3D.getModel() calls:

   appearance.setPolygonAttributes(pa);

The thing I don't understand is why adding the
appearance.setCapability() calls to the SlabPortrayal3D constructor does
NOT prevent the exception but adding them to the CubePortrayal3D does.

I apologize for not being able to send the whole model because it's the
confidential property of my client.  If I can create a simple model that
exhibits the issue, I'll definitely send that.

> But this is perfectly fine to do -- you added the right  
> modification.  MASON doesn't have various attributes permissions  
> turned on by default because in some cases Java3D gets slower when  
> they're turned on; so we're conservative.  But if you find it helpful  
> we can add it to MASON for you.  But it'd be nice to suss out why  
> your code is requiring it just so to ponder over it.

_If_ I'm doing things right and it's just an extra feature of Java3D I'm
after, then it would be cool to be able to turn on/off various
capabilities before the object is "compiled" or goes "live".  But, I'm
afraid it would muddy up your clean class construction.  I suppose Yet
Another Constructor accepting capability bits would do it.  But, there
are the Appearance, the Shape3D, Texture, etc. bits ... I smell feature
creep. [grin]  So, it's probably best to just leave it as is
until/unless lots of users start having similar issues.

I probably shouldn't subclass from CubePortrayal3D at all.  But it was
convenient, since all I really need is to modify "verts".

Just treat my ranting as an FYI, for whatever it's worth.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com