[SOLVED]CapsuleCollisionShape not correctly added to spatial

So I’ve been playing around with jme3 for about a week now( I’m very much enjoying this engine :smile: ) and I’ve been making all kinds of little prototype game thingys. Anyways basically I’ve noticed an inconsistency with the way CapsuleCollisionShape is located in terms of the spatial it’s connected to. So i created a 3d character with it’s origin at the center and bottom of the mesh( As the help files say) and thats all peachy. But when i add a capsule collision shape to my spatial it is centered around the origin of my model( which is at the bottom of the mesh), and so i end up with a floating character?? I got around this by adding a second un-rended spatial translated slightly above so that the visible model sits at the correct spot, but this seems like a bodgy work around. Is there a better way to fix this, or should i just reset my characters origin to the actual center in blender?

Here is an image to make things very clear :smile:
P.S(The second smaller mesh is a ghostcontrol for non kinetic collisions )

Attach the model to a node, move the character down and attach the control to the node.

Haha should of thought of that, it’s much simpler! Thanks though. I’m surprised there’s no method for translating the capsulecollisionshape without the use of an extra node.

I guess there is one but not in the constructor.
I’d use BetterCharacterControl for that anyway and it also adds a Capsule but adds the posibility to walk around.

Note: The GhostControl should be LARGER than your Capsule or else the physics will prevent it from being hit. It wont be ever hit.

What do you mean adds the possibility to walk around? that npc walks,attacks and dies just fine :smile:. I will have a look at better charactercontrol though. And that ghostcontrol is for detecting bullets, which i haven’t added to the physics space and so they go straight through the characterControl.

Well CharacterControl/BetterCharacterControl adds methods to make the npc jump, walk and such, all the work you’d have with a raw CapsuleCollisionShape.

Oh then it’s fine, but usually you use a bigger radius.
Keep in mind: When you don’t add bullets to the physics space they can go through walls. If you’d add them you’d even have some cool bounciness.

Or do it with a ray trace (as I do)

Yeah, using actual physics objects for bullets is not a good idea. Do it using rays.

@Darkchaos yeah it’s a good point about bullets going through walls and stuff. This was just a test with an open landscape, and so i wasn’t really thinking about that sort of thing, just collisions with entities.

@normen Yeah i was going to use rays but i figured rays are instantaneous and i thought it would be cool to have the delay between bullet leaving gun and bullet hitting target. Although in hindsight, considering the speed of the bullet, to actually enjoy that feature, you would have to be standing fairly far away from your target, probably further than my map can reach. Ill definitely look at the ray approach next time i try something like this.

Thanks for all the replies btw, lots of new stuff to consider :smile:

Just do multiple ray tests over time…

Yeah, that’s what I thought too.
Instead of: gun--------------------------------------------------------------->target (instant ray)
Do this: gun—>------>------>------->----->------>----->------>----->target (ray segments)

A bullet’s speed is quite low for some weapons, e.g. pistols (around 300 m/s).
It is a bit faster for sniper rifles (1000 m/s) and for modern tanks (around 2000 m/s).
So if you simulate a pistol and have 300 fps then each frame is one meter closer to the target…

(For people from US and UK: one meter is circa 3 feet (circa 1 yard).)

Well, here m/s is a nice unit even in US because it nicely maps to JME’s units.

300 m/s at 60 FPS is a 5 meter ray stepping at 5 meters per frame. It would also take just over 3 seconds to reach the default far plane.

300 m/s seems a little low, though.

Or you just do the complete ray every time and check where the ray hit and if the bullet would be at that location already/still. The ray test gives you a value from 0-1 where the ray hit relative to its length afaik.

Would that be accurate? Someone could step into the ray path after the bullet has been shot (e.g. a martial arts close combat enemy steps before player - then intersects, but bullet is behind him already). But if ray always gives all targets one could simply foreach all hits. But might be performance killer to make long ray instead of short ones (if I would code a physics engine it would have octree or grid during broad phase).

There would be the possibility to do this for bullets that will never have the chance to hit anything but static background: just calculate the time until impact, set a timer, update visuals for the impact (e.g. particles of dust flying up). Might give good performance.

For the pistol speed - ok, it’s 340 m/s (roughly mach 1): Projectile - Wikipedia
Note, this speed is directly at the muzzle and will get slower rapidly due to air resistance.

A hint to @Kix: ballistics (science of bullet kinetics) is complex (gravity, rifleman velocity, etc.)

Haha thanks for all the fantastic replies. This whole ‘test game’ i built was actually more about sorting out my asset pipeline( Blender ----> Ogre ----> jme3), as getting the animations and materials to work correctly took a bit of messing about. But once i got that sorted out i just started playing around with some stuff. I never had any intention on making the most accurate fps ever created :smile:.

@Ogli I’m actually quite aware of ballistics, I’m just about to go and sit my physics exam! Like i said all this stuff is super awesome, but seeing as how im not using mesh accurate collision shapes for bullet ‘collision’ putting in that amount of realism isn’t necessary, as the final collisions are not that accurate :smile: