Hi! 
I have a short (and at least for you guys) simple question. Like everyone else here ;), I want to simulate/model a simple wheel. But searching this forum for a proper physical representation, I always end up with the BoundingSphere (which is no option for me), generatePhysicsGeometry(true) (which maybe too expensive during simulation as I need a lot of wheels… it does triangle-accurate approximation, right?) and the use of a PhysicsCylinder (which seems to be pretty inaccurate, as it only has 10 sides… or is there a way to change this???).
This leads me to my question: What is the difference between PhysicsCylinder and a (hypothetical) BoundingCylinder, for example? In some posts here it is described as alternative to the missing (?) BoundingCylinder, but why two types of physical representation? Or am I getting something wrong? (I think so^^)
And more questions: Is there still the need for an implementation of the BoundingCylinder? Or is there any other way to model a wheel? (I suppose so, as everyone who posted a similar question/problem seemed to be satisfied… though I can't find anything fitting my needs :()
Thanks in advance for any kind of response/answer/enlightment! 
First of all I'd suggest using jbullet-jme instead of jmePhyiscs as jmePhysics is not maintained anymore.
Second, you will always have to discern between the physics collision shape and the jme shape that you see, they are not interconnected only that the physics shape might get derived from the jme shape (bounding shape/mesh). In jbullet-jme I'd suggest using either the built-in vehicles or cylinder collision shapes for the wheels and hinge joints for the connections.
Hope this helps,
Normen
Hi Normen, thanks for your response (fast as usual ;))!
First of all I'd suggest using jbullet-jme instead of jmePhyiscs as jmePhysics is not maintained anymore.
I noticed that, and branched my project several weeks ago, but wasn't able to produce as good results as I did with jmePhysics2 (Suppose it's my fault, I hadn't have the time to convert my physics entirely, must have missed something). Furthermore, I'm under kind of time pressure (who isn't... ;)), and at the moment it seems more opportune to stick with jmePhysics than changing my whole project (> 7k loc)...
Second, you will always have to discern between the physics collision shape and the jme shape that you *see*
I'm aware of that, and as you mention it, I suppose I mixed it up... and let me guess, I mixed the debug-visualization of the PhysicalCylinder (debugShape with 10 sides) with its physical representation? But how does collision detection work then? :?
As I understand that, BoundingVolumes are used for culling etc, and can be used to generate physics geometries from it (generatePhysicsGeometry(false)). And as I'm in lack of a BoundingCylinder, setting the Physical part of my wheel directly using PhysicsNode.createCylinder(String) hopefully solves all my problems...?
jmePhysics simply has bugs in ODEJava that start surfacing sooner or later, I did not find any workaround as they seem to be completely random crashes somehow related to collision… so I still suggest using something else for production games.
Physics engines work mathematically, not with objects/surfaces. So in effect spheres are real spheres with "infinitely" exact curves.
The way physics implementations work is completely separate from the rest of the OpenGl displaying. So the physics space can be created even without any opengl objects, just by defining the collision shapes in it. And they would bounce off each other etc. as long as the physics space gets updated.
Now the opengl (visual) objects are updated each frame by the position of the physics object in the physics space so that it looks like they are moving according to the physics. I dont exactly know how jmePhysics handles collisionshapes internally but in jbullet-jme the PhysicsNode, its collision shape and child spatial are handled completely separately.
The culling etc. works on the opengl side of things, so even when an object is culled it will still bounce into other physics objects, just that its not rendered.
Cheers,
Normen
Physics engines work mathematically, not with objects/surfaces. So in effect spheres are real spheres with "infinitely" exact curves.
The way physics implementations work is completely separate from the rest of the OpenGl displaying.
Thank you a lot for this explanation, that made things clear to be!!! :)
jmePhysics simply has bugs in ODEJava that start surfacing sooner or later, I did not find any workaround as they seem to be completely random crashes *somehow* related to collision.. so I still suggest using something else for production games.
I read that, and sure will switch, but not now (due to time pressure) :wink:
So I will use a PhysicsCylinder cylinder = PhysicsNode.createCylinder(String) for now, and averything should be fine.
Thanks again, Normen! :)