How to make projectiles

Ok, so I have been fiddling for a while

I want to make bullet-like projectiles: so kinetics are out, because they would bounce off other rigidbodycontrol objects rather than going through them (like bullets would)

I tried ghost controls and it works great, I can remove projectiles when they leave the region and the collisions register nicely (if i use a box collision rather than a sphere) however the collision registers the ghost control not the spatial it is attached to (the examples show this behaviour too)
BUT unlike the controls that extend BaseControl it has no getSpatial() or spatial to retrieve the spatial using the control and the ghost control cannot hold any user information the way a spatial can and it cant be extended (the clone functions are not extensible by the looks of it)
So i can get collisions but i cant do anything with them
Unless I make a map of <control, spatial> and run into a bunch of issues keeping the map current with the scenegraph

Or i can do it without the physics system and shoot off rays for who knows how many projectiles every single bleeding tick, generating millions of unneeded intersections/collisions and get the closest and keep track of them so that after the projectile passes through a mesh i can retrieve the previously closest spatial and apply effects just to have access to the information about the projectile that the ghost control cant supply.

I really hope there is a better way.

You can also do raycasts in Bullet directly. It’s gonna be way faster than any ghost collider.

Still, doing it in the scene graph isn’t that bad either, providing you override some of the collideWith methods and add some broadphase checks.

You could extend GhostControl to implement a getSpatial() method for it. The spatial field already exists, so cloning wouldn’t be affected.

Has your issue been resolved? A curious monkey wants to know!

1 Like

Havent really looked at it :frowning: had work to do … unfortunately.

I’m busy trying to work this out:

I’m sure i read that jme uses BiH … meaning mesh collision is faster because there is only 1 interval to test most of the time, while a ray shoots through a huge number of intervals so u practically have to test against all objects, not to mention a ray will give false positives and require storing old results. So i need to find my incorrect perceptions and correct them.

Then i guess i will need to start the ray 1sec of travel behind the projectile so the desired collision isn’t ignored and eliminate the rest. Removing the ghost control and pulling the projectiles out of the physics system would be a good side effect. Even though i’ll still use a physics tick listener because the extrapolation of position of the rigid bodies that are firing the projectiles cause them to shoot in strange directions when source and target are tooo close.

1 Like

I assume you’re aware that there are 2 collision-detection systems in jMonkeyEngine. There’s one in the jme3-core library that operates on meshes in the scene graph used for visualization; it’s optimized for picking objects from a camera viewport. There’s another in the jme3-bullet library (also implemented in jme3-jbullet) that operates on physics shapes in physics space. Both use the Bounding Interval Hierarchy (BIH) algorithm for detections involving meshes. jme3-bullet also uses algorithms besides BIH.

When people say that jMonkeyEngine uses BIH, they’re likely referring to jme3-core. The BIH algorithm in jme3-bullet is infrequently used because jme3-bullet includes non-mesh primitive shapes for spheres, capsules, and so on. As you probably know, these primitive shapes are usually more efficient than meshes. When no mesh shapes are present, jme3-bullet doesn’t use BIH.

I think @MoffKalast was pointing out that in jme3-bullet you can detect physics objects along a path using a raycast in physics space. Raycasts in jMonkeyEngine don’t have to be performed against a scene graph, and detection in physics space doesn’t have to use a collision shape. Does that make sense?