I used to develop my own “engine” and do all the openGL Stuff manually however I decided it’s time to play around with jMonkey
Unfortunately I experienced several issues:
The Vehicle Creator is completely useless. Neither can I use “test vehicle” (known problem according to google), nor are the bounding boxes correct (xy axis flipped?) and the created vehicle has completely misalgined wheels as well
So I decided to use the TestPhysicsCar and drive it through my moon-scene.
In general, it works quite well but sometimes it just drives under the visible terrain or gets suddenly hit. What’s wrong with that? Does anybody have a clue? It looks like RigidBodyControl is the wrong approach to give my terrain a colission?
-> I checked the SourceCode of the Vehicle Creator and would love to bugfix it. Is there a guideline on how to set up the environment to debug/code plugins?
Another thing I am curious about is Level Design: Compared to unity, jMonkey’s SceneComposer is weak.
I initially thought that One should design it’s map there as the compilation to .j3o increases speed. However I read that big chunks of a Model decreases speed again, so is the right way to level design the implementation of an own map format and level designer or are there maybe already set up user projects for that?
Bullets raycast vehicle is very performance oriented, this goes to its usability, it takes quite long to balance all the values perfectly.
-> What worked suprisingly well for me is, to add a large (2meter+) invisible wheel in the middle, with a very light suspension. That way the vehicle always has ground contact, and the chance of the 2m wheel getting trough the ground is low.
Using very large triangles in the terrain also increases the chance of physic gliches in general.
Many jme users probably are more code oriented.
Anyway having a large j3o only means its in memory at the same time. Within the scene a usefull spatial seperation should be no problem. Large models more mean like baking everything into one megamesh.
Approches so far seen by me:
-> Hardcode the level into the code, works great if you only have very limited amount
-> Use a Database where you store class to location logic, use j3o for models and load them depending on this
-> Use chunk logic, eg one j3o for each 16x16x16 meter bock (omit emty ones) as the player moves store and save them. (also seen this approach with database backend)
-> If your level is mostly static (like any fps) doing the whole level in like 3dmax or blender is also a possibility. Then only a few game specific things need to be configured, eg spawn points or such.
However will the vehicle flip over then? When driving over some “mountains”, a bit offroad stuff? (Or is 2m (diameter?) wheel small enough for that to work?)
As for the megamesh, you mean like “one shape for everything”?
I was thinking about a xml file which states the location of each model along with it’s name (in JME Terms it defines a Spatial). Then there is a routine “onLevelLoad(String levelName)” which then uses rootNode.getChild(“spatial_name”) to add the desired Controls. (A Database would also be possible, thank’s for the idea!)
The only question is whether to use some custom blender export, the upper approach without the xml file (which would be just the .j3o’s meshes) or a complete application with property settings for each spatial (like isCollidable). hmm
Thanks for your contribution so far, will check out the wheel
Oh for making the vehicle more offroad a good idea is to have the center of mass at non logic positions by offseting the vehicles mesh.
Basically my center of mass is like 10cm below ground level, resulting in a vehicle that can flip over, but in most cases by pure chance(from a players perspective) will come to rest in a drivable condition without feeling fake.
I can’t have my vehicles go too quickly currently because otherwise they end up flying in space.
I’m trying to avoid having the physics tick twice per frame because I fear it would slurp resources and make coding harder (due to multi-threading).
My vehicles length are longer than 2 meters, but they are quite flat. Do you think it’s worth a try adding that invisible wheel for me? Or maybe simply an invisible “antenna” would do the trick?
Since I use the ferrari model currently, and it’s center is at bottom of wheels height, I guess I won’t gain by making the center lower?
The ferrari is already quite good in terms of stability,
but the wheels have not enough room for offroad in my opinion.(here the invisible wheels help to prevent getting stuck on small bumps ect, also they of course improve overall grip.)
Thx for the info Empire Phoenix.
Yah, the ferrari is a wonder of stability (with decent parameters). Love how it never ends up on it’s back in my tubes, helped by gravity changes.
Don’t really need an additional wheel for grip since the vehicle parameters allow for total grip. Don’t have any stuck problems either due to the nature of my circuits.
My problem is really around being able to step up the speed of my vehicles without the flying circus happening :D. Being able to add half the max speed would be great.
Couple solutions I’m thinking about:
- multi-threaded physics engine with double ticks (trying to avoid it)
- trying with models with more height
- adding an invisible antenna
- upping the v-sync value (no idea if it’s doable or even makes sense)
- see if I can limit torque forces to a maximum (usually, the flying comes after my vehicle ended spiralling like hell). Probably would need to force a maximum linear velocity too. Basically, I limit the speed of my vehicles at the input level, but after collisions and stuff, they can start rotating and stuff like hell so need to see if I can limit it after the results calculations.
My in-game vehicle editor is nearly done. Apart from the pesky fact that I haven’t yet found a way of extracting the non-default technique parameters yet but that can wait.
so loopies you have it working and can even drive the ferrari top-down whilst I am unable to drive the “Basic” Vehicle on a straight track?
Btw: I added a new map, just a plain terrain. I can go 600km/h on there, but only with a small (0.5m? radius) middle wheel. It sometimes improves driving, however if it get’s to big and stuff I get into huge trouble.
As soon as I change the terrain, I get some really crazy issues, all the time. Like the stated driving under the floor (even with a huge (2m radius) middle wheel). It’s just like constantly driving down a straight layer.
Adding the Ferrari improves physics? How can that be? does the shape also effect the contact to the floor somewhat?
And the lower Mass Point is suggested in the official tutorial so I did it, however in free fall, my vehicle is not turning right. Having a Mass Point at “3m” (-3) gives me undrivability. I am currently at 0.8m as it improved over 1m? Why? Can’t I improve my vehicle using such stuff? I mean it weighs a 1400kg but behaves like well. A GoCart
@loopies: v-sync only means that the rendering process gets synchronized with the screen. This is only to fight flickering and stuff.
As for Multi-Threaded: Why would you want it to be multi-threaded? is your cpu already at 100% or your calc takes longer than 1/60?
If not, simply use bulletAppState.setInternalRate() or something, don’t know how it was called. It’s usually 60.
You could stop them from moving by getLinearVelocity and setLinearVelocity, but that could lead to some odd behavior. Rather try to Respawn the player then.
Good Luck Guys
Yah, the basics work very well for me here… while I’m a total idiot in everything related :D.
Have you tried with the following settings:
- vehicle size near real cars size
- vehicle weight near real cars weight
- a reasonable speed (force)
- a floor made of not too big triangles
- starting with the vehicle clearly over the ground?
- using a boxCollision
- building and attaching your vehicle via an appState to make sure it is built in the update loop.
Parameters such as frictionSlip and suspension params are important. Suspension values are linked to your vehicle weight. Try lowering your weight (or highering suspension params).
I found the following links enlightening:
The ferrari is very good because it has normal dimensions and a low gravity center. Also has good starting param values and weight in the examples (testFancy).
Only couac I find is that it’s looking backwards (front is the back).
I thought that v-sync was basically just setting a max fps. Was thinking the more fps, the less distance the vehicle travels between each physical tick but could clearly be totally wrong.
Multi-threaded physics because it’s the only way to have 2 physical ticks for one rendering tick… again meaning less distance before the physical tick.
I set my linear and so on velocities, but when the vehicles falls or bunks into stuff, bullet changes those values to represent the reacting… which is what I want… just want to keep those values in a range. I suspect bullet allows to do that… just haven’t checked it for a while now.
Good luck to you ^^.
@loopies: Well the thing is I used the boxCollision etc, all not from the FancyCar but from this one: https://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/test/jme3test/bullet/TestPhysicsCar.java (maybe it’s just my terrain that sucks, however I am simply using the default settings for the terrain).
I am building the vehicle in the onInitSimpleApp() should be equivalent to the update loop?
However I will check into your links and especially see what the FancyCar does to it, maybe it gets better with a complex model, you never know.
As for v-sync: It does limit your fps to the refresh rate of the display (50 or 60) however the bullet app state is indifferent. It uses an own 60 Hz clock and will simply interpolate on higher fps’.
Try to set
bulletAppState.getPhysicsSpace().setAccuracy(1f / 60f); and enhigher the value to 70 etc. This is what you want, more calculations per tick.
Btw: you could also in/decrease your vehicle and terrain size, maybe that also helps because your speed in units will change
EDIT: The car behaves semi-acceptable now and I also fixed the issue when disappearing under ground, it was not the suspension (however I also tried that out with 30G Gravity^^). I somehow rotated the whole level to some degree however the car did not care about this, it only took the heightmap mesh (is this usual?)