Hey all.
I am trying to migrate my project from v3.0 to v3.1.
I noticed that com.jme3.bullet.collision.shapes.CollisionShape does not have the cShape variable anymore that I used to create procedural collision shapes. Instead there is an objectId that I guess reference the physics object.
Is there another way to set a custom com.bulletphysics.collision.shapes.CollisionShape?
Thank you in advance for your support!
3.1 uses native bullet so there is no com.bulletphysics, as the javadoc says you were never supposed to use getCShape in user code… What exactly are you trying to do?
@normen I am trying to create a procedural collision shape for terrain surface (planet) and the above described method worked in 3.0…
You already said that, I also said that it doesn’t work in native bullet. So what are you trying to do?
@normen, i don’t get your question, I already said what I am trying, twice, as you stated.
So, sorry to bother you and thanks.
I am asking what exactly you’re doing or intend to do. Like HOW you create your collision shape, what its purpose is (its exact purpose, not “its a collision shape for a planet” - duh), what the needed properties are, what the data is that its generated from etc. So I could point you to a way to do it without using com.bulletphysics classes (or native code in the case of native bullet).
Anyway, you can simply use jbullet instead of native bullet and use your old code if you want to.
@normen, the collision shape I was using is generated based on the height data used to generate the procedural terrain (noise based). The result was a com.bulletphysics.collision.shapes.CollisionShape inserted directly into a custom shape extending com.jme3.bullet.collision.shapes.CollisionShape. This was used normally in a physics space together with other rigid bodies created normally in jme3. Naturally, when switching to native bullet, all the objects work properly since on jme side nothing changed as far as creating normal objects, except that the com.jme3.bullet.collision.shapes.CollisionShape does not has the cShape variable anymore, which I used to set the procedural shape.
Hope this clarifies a bit and sorry if I was/am still unclear in explaining.
I will explore using jbullet. Thanks again.
That still doesn’t tell me what that shape is doing and why it has to be custom instead of made of existing collision shapes but anyway, I guess you’ll be using jbullet until it gets deprecated.
Basically because as far as I understand the HeightfieldCollisionShape has to be centered in the world origin. I use it for planets terrain that are not centered. Also, as far as I understand is not applicable to a sphere inflated cube, as I generate the terrain mesh. Please correct me if I am wrong.
No the object its assigned to doesn’t have to be in the world center. And I don’t know exactly what you mean by “sphere inflated cube” but the actual visual position of the object on the surface is more of a rendering thing than physics. I.e. if the object was in the middle of the height field you could render it “higher” than on the edges to simulate a curvature.
Anyway, just go to the project settings and add jme3-jbullet instead of jme3-bullet for now.
Yep. Regarding jbullet vs native all is clear. I will look into the other options as well as suggested. Thanks all for the ideas and comments!
Thanks all for your support, I switched to generating mesh collision shapes directly on needed terrain quads instead for the whole object which also speeds things a little. And I don’t have to use jbullet anymore. Thanks again.