I am working on creating my own character control and am wondering what the best way to go about this is. The control will need to be able to react to the environment in a bit more interactive method than I believe the character control can (i.e. running on walls, changing the up axis to non-coordinate axes and the like).
Right now I have been looking into mimicking the way the current character control works but I’m running into trouble trying to use some jbullet techniques such as CollisionWorld.ConvexResultCallback. For some reason I cannot figure out the way to use it from the source code.
Anybody have advice, either on how to learn jbullet or another direction I can take to do this.
Ok, I think I’m giving up on using the jbullet stuff because I read somewhere it will not work after jme moves to a new bullet library or something. Instead of trying to learn jbullet from source I’m just going to use jme3 classes.
Is there any already implemented method of picking, like you can with the Ray class, but using a shape such as a capsule shape? Basically a Ray with a shape, rather than just being a line?
If not does anyone have advice about creating one? I have a basic understanding of linear algebra but I’m betting it would be no small task.
Yeah, theres physicsSpace.rayTest(raystartWorldCoord, rayendWorldCoord) (yeah it has an end and thats no ray then but who am I to tell them to rename their methods? ;)) and physicsSpace.sweepTest(collisionShape, start, end); and this is in fact what you should probably use to do your character collision. The bullet character uses a combination of sweep test and ghost object afaik but as you say the api to access this collision data isn’t exposed in jme’s api so you cannot do it exactly that way which is arguably also not ideal, theres been a lot of suggestions on character improvements and imo its probably always best to bake your own based on your needs.
1 Like
Thanks for the quick simple reply, the physicsSpace.sweepTest is exactly what I am after.
Now that I am underway with the sweep tests I am running into a few issues.
Issue 1: Accuracy
As is mentioned here the javadoc says that the sweep distance needs to be >0.4f and normen says it is actually quite a bit smaller. Normally normen’s word is the final one in my book but when I run my code, the collision is not read (consistently) unless the distance is >0.4f. Anyone know how to increase the accuracy or maybe have an idea of what I am doing wrong?
Issue 2:Data
I would like to draw more information from the sweep test such as the location of the collision or the distance from the inital transform that it occurs. Essentially it would be nice to have the list of CollisionResult like the com.jme3.math.Ray class gives when using spatial.collidesWith(ray,results) but I don’t know that the sweep algorithm even allows for such a thing to be compiled. Any tips?
Issue 3:Processing (kinda)
More or a query than an issue: How computationally heavy is the sweep test? Is it unrealistic to try and run 4 or 5 per frame and still get a decent framerate?
You do get a list of PhysicsSweepTestResults returned, you can use the hitFraction value to determine on what distance of the given sweep length the collision happened. E.g. when the hitFraction is 0.5 and you sweeped from 0,0,0 to 0,6,0 then the hit position was at 0,3,0.
2 Likes
Beautiful, that solves them. Still missing the floor once in a while but I’ll play with the code for a bit and if I can’t figure it out I’ll get a detailed post out.
Thanks normen for your answers and work on jme in general.
1 Like
@wabashton said:
Still missing the floor once in a while but I'll play with the code for a bit and if I can't figure it out I'll get a detailed post out.
Probably adding a downwards ray for terrain following to the mix won't hurt, also for other functionality like jumping etc. The bullet raycast vehicle uses one ray per wheel as the name suggests but some people use sweep tests with capsules instead from what I heard so I guess you should be fine with reasonable use. Also try to use the physicsTick to optimize the amount of checks. However mind that you should use the application queue if you want to modify scene objects from the tick callback as it might run in parallel to rendering (reading values should be fine), best only modify values that are not related to the spatial, material, effects etc.
Edit: Instead of using the app queue you can also simply apply won data in the update() call of the Control that you might create for this purpose.
@normen said:
You do get a list of PhysicsSweepTestResults returned, you can use the hitFraction value to determine on what distance of the given sweep length the collision happened. E.g. when the hitFraction is 0.5 and you sweeped from 0,0,0 to 0,6,0 then the hit position was at 0,3,0.
Thankfully google found this post or I would've been stumped in finding where the physics ray intersected the terrain :) This should be in the javadoc. In what way can I help out getting it there? Submit a patch in this forum?
1 Like
@jmaasing said:
Thankfully google found this post or I would've been stumped in finding where the physics ray intersected the terrain :) This should be in the javadoc. In what way can I help out getting it there? Submit a patch in this forum?
Yeah a patch would be best, thank you very much! I think the whole sweep and ray stuff isn't really javadoc'd as I added it quite late and in the native version its even a contribution that isn't really checked yet..