Not an issue, looking for opinions/options on

Troubleshooting physics
1

Hiyas,



I’m working on a project in jme3 and was not happy with the way the current collision detection was implemented (actually… I also had no need for any advanced physics and really didn’t care for how the movement of a physics node was implemented as well), so I wrote a simple collision detection system using rays and very simple physics for gravity only (as it is all I am concerned with for the type of game I am working on.



My primary issue with the implemented collision detection system and why I chose to not use it:



The way it works presently is: Collision happens and then the physics node reacts to the collision



The way I wanted it to work was: Collision is evaluated prior to happening and then stopped before it happens.



Now, the way I implemented collision detection was to use rays to evaluated absolute X, absolute Z, the player nodes relative Z and then Y–all depending on rotation and movement. (i.e. no need to check if their head has collided with the ceiling if they are not jumping… however I always need to check if they are falling… unless on the upswing of jumping, etc)



It takes a total of 4 rays per pass, per object that implements a movable class I wrote to evaluate collision properly.



Sooooo… here it my questions:


  1. What are the performance issues with ray collision as compared to mesh collision?
  2. collidesWith (on a geometry) method seems to be a potential resource drain… Is it? (though, the physics node was not working when I decided to take this approach).



    Hope this makes sense… and thanks in advance for your insight!
2

There is also the geometry based collision detection in jME3 thats not physics based, I guess you are aware of thatedit: err… Actually you are :slight_smile:

Did you try the latest improvements in the bullet implementation? With controls you can now use GhostControls and kinematic RigidBodys basically as if they were just a boundingvolume of a spatial, also the character was improved in the latest nightly. But basically performance of the geometry collision system should be quite good if you want to use that.

3

Yes… question 2 was talking about both options. Sorry for not clarifying this. The info I am looking for is:



What is the performance difference between ray collision and geometry collision? Is there a reason geom collision would be preferred… taking into consideration performance issues?



It seems to me, that comparing ray to geometry would be far less processor intensive than evaluating geometry to geometry. Is this the case? (I do understand that ray to geom is not as thorough as geom to geom, but… in my case… the margin of error is acceptable, IF there is no glaring reason why ray to geom is a bad idea)



Thanks!

4

You can only collide boundingvolume vs geometry and ofc its more cpu intensive than ray collision, yes.

5

Thanks so much… and I will be playing around with the new & improved jbullet!