Are you using the latest build from CVS?  I committed fixes for both of these issues a while ago...

http://192.18.37.44/forums/index.php?topic=7822.0
http://192.18.37.44/forums/index.php?topic=7094.0

Yes.

polygonAttributes.setCullFace(PolygonAttributes.CULL_BACK);

This issue was recently resolved.  Try grabbing the latest CVS.

Yes!  I just updated from CVS and can now adjust the tex coord generation planes!  Thanks Will and Matthais!

The Sphere was just an example.  I can generate texture coordinates for an arbitrary object just fine.  In general, I want to change the orientation of a texture relative to an object (which wouldn't really matter for a Sphere anyway).  I just realized that I can use the texture transform.  I'll try that  It is curious that changing the tex coord generation planes doesn't seem to have any effect though.

I'm having trouble getting the planes in TexCoordGeneration to have an effect on the actual texture coordinate generation.  I am generating 2D tex coords for a sphere, and have tried many combination of S and T planes, but the resulting tex coords do not seem to vary as a function of the planes.  Has anyone else had a similar experience?  I don't see any problems in the JOGL code...

When will the next release be?  It seems like new users are much more likely to download an official version than the CVS.

Just add AWT listeners to your canvas.  You'll want to add the events to a queue so that they can be handled synchronously with the rendering thread.

<bump>

Yes... isn't the collide package being removed from the xith core soon?

Just wondering: why does collide2(int o1, int o2) use ints instead of longs?  Geom.getId().getSwigCPtr() returns a long, so an explicit cast is needed (which worries me because we are chopping the high-order bits off of the pointer).  Is this a problem?

Looking at the C++ code:

It looks like the only difference between nearCallback and nearCallback2 is that nearCallback2 recurses into sub-spaces.  So should we be using nearCalback2 for spaceCollide?

Is anyone using category and collide bits?  They don't seem to have any effect... The ODE guide is a little opaque as to whether the bits are used directly by ODE or whether they needs to be tested in a nearCallback method.

No problem.  Glad to hear it's working!

I actually do allow modification of the COM during runtime.  In my experience, both a Body's position and a GeomTransform's offset can be adjusted between collision and step calls.  Modifying a GeomTransform's offset seems to work pretty well, but modifying a Body's position causes discontinuities (understandably).  So long story short, it works if you occasionally need to make an adjustment, but not if you to constantly vary your COM (why would you want to do this anyway?).

What are the semantics of dContactApprox0?  I don't see it in the ODE user's guide...

I have modified all of my code to get COMs working.  Here's the strategy:

Add the COM to each Body's position when I initially position it.

Attach the Geom using a GeomTransform that is offset by the negation of the COM.

It's working great!  A total hack and I wish Body.setMassParameters worked in ODE, but it's working great

Are you using the latest CVS?

That's basically the approach I'm using now... the only problem is that I have to render using an orthographic projection to avoid perspective distortions between camera locations.  Is there a way to do this without moving the camera?

So using your code, how would one get a BufferedImage from the TextureCanvasPeer or RenderTexture?  I have been unsuccessful in doing this

Try grabbing the latest odejava from CVS.  I just now committed a change that improves TriMesh performance.

The ODE user's guide says:

// as long as dReal == floats
dGeomTriMeshDataBuildSingle (TriMeshData,
       // Vertices
       Bodies[BodyIndex].VertexPositions,
       3*sizeof(dReal), (int) numVertices,
       // Faces
       Bodies[BodyIndex].TriangleIndices,
       (int) NumTriangles, 3*sizeof(unsigned int),
       // Normals
       Bodies[BodyIndex].FaceNormals);

So yes, I agree that the call wants the vertex count and not the number of vertex coordinates.  I'll commit this change as soon as I post this.

Also, I'm not aware of a Java equivalent to sizeof... any ideas?

Edit:
Thanks for debugging this, irrisor.

I committed the change and TriMeshs seem to be working really well.

Ok... got it working on a different computer.  I'm not sure what the problem was, or why it was crashing when I resized the viewer   I am noticing another weirdness though.  I want to attach the texture canvas to the same View that the standard canvas is attached to so that I can do high-res captures.  When I attach both canvases to the same View, my machine grinds to a halt (memory leak?).  This does not seem to be an issue if I use two separate Views.

From the ODE user's guide:

Other spaces that are contained within the colliding space are not treated specially, i.e. they are not recursed into. The callback function may be passed these contained spaces as one or both geom arguments.

So it seems that sub-spaces are not automatically handled by ODE.  I think this would be a useful feature (I'd use it), so maybe we can think of a way to build it into odejava.  Looking at the odejava code, it looks like this change would have to go into the native libraries.

I get the following exception when I create a Window containing a Canvas3D attached to a View that also has a TextureCanvas attached to it:

Exception in thread "AWT-EventQueue-0" net.java.games.jogl.GLException: pbuffer
creation error: wglCreatePbufferARB() failed: tried 8 pixel formats, last error
was: (Unknown error code 0)
       at net.java.games.jogl.impl.windows.WindowsPbufferGLContext.createPbuffe
r(WindowsPbufferGLContext.java:304)
       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent
(WindowsOnscreenGLContext.java:135)
       at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:246)
       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(Wi
ndowsOnscreenGLContext.java:76)
       at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas
.java:228)
       at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:125)
       at java.awt.Component.setBounds(Unknown Source)
       at java.awt.BorderLayout.layoutContainer(Unknown Source)
       at java.awt.Container.layout(Unknown Source)
       at java.awt.Container.doLayout(Unknown Source)
       at java.awt.Container.validateTree(Unknown Source)
       at java.awt.Container.validateTree(Unknown Source)
       at java.awt.Container.validateTree(Unknown Source)
       at java.awt.Container.validateTree(Unknown Source)
       at java.awt.Container.validate(Unknown Source)
       at java.awt.Window.pack(Unknown Source)
       at jdm.viewer.DinoMorphViewer.<init>(DinoMorphViewer.java:67)
       at jdm.DinoMorph.startNewViewer(DinoMorph.java:192)
       at jdm.gui.DinoMenuBar$8.actionPerformed(DinoMenuBar.java:369)
       at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
       at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
       at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
       at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
       at javax.swing.AbstractButton.doClick(Unknown Source)
       at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
       at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown
Source)
       at java.awt.Component.processMouseEvent(Unknown Source)
       at javax.swing.JComponent.processMouseEvent(Unknown Source)
       at java.awt.Component.processEvent(Unknown Source)
       at java.awt.Container.processEvent(Unknown Source)
       at java.awt.Component.dispatchEventImpl(Unknown Source)
       at java.awt.Container.dispatchEventImpl(Unknown Source)
       at java.awt.Component.dispatchEvent(Unknown Source)
       at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
       at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
       at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
       at java.awt.Container.dispatchEventImpl(Unknown Source)
       at java.awt.Window.dispatchEventImpl(Unknown Source)
       at java.awt.Component.dispatchEvent(Unknown Source)
       at java.awt.EventQueue.dispatchEvent(Unknown Source)
       at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)

       at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
       at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
       at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
       at java.awt.EventDispatchThread.run(Unknown Source)

Any ideas?

Yes... Coincidently, I have just today needed to render a high-res screen capture for the first time since porting to Xith3D from Java3D (9 months ago or so).  This was possible in Java3D, so I hope that it makes it into the CVS soon.  The high-res image is for a magazine cover and the article may mention Xith (I'll post details as they become more clear and official).  For now I'll try reconfiguring hardware in hopes of getting a screen resolution higher than 1600x1200 or try the render-to-texture .jar posted by Niwak.

Yes. I use dContactApprox1.

+1!  I would really like to use this feature soon!  Is it close to being added to CVS?

I added the methods, along with getMass, getCenterOfMass, and getInertiaTensor methods.

SetBoxMass() (and its' Sphere counterpart) use dimensions and density to determine inertial parameters.  setBoxMassTotal (and setSphereMassTotal) use dimensions and the total mass to determine inertial parameters.