Related to this: WIP: Advanced Vehicles - #24 by sgold
I can help (although not heaps). My game has some features that project could be missing, although my cars are more ‘serious’: GitHub - Murph9/RallyGame: Simple 3d rally game, because 3d is a good place to start.
Willing to discuss whatever (i am on discord just barely open it ever).
“Discourse, not Discord” could be my motto, so choosing venue should not be an issue between us.
Perhaps we should kick things off by making a list of the features that the “jme3-vehicles” project lacks:
What features do you think should be added?
There’s at least one other person interested in working on Advanced Vehicles. I haven’t found a way to add them to this discussion without making the topic public.
Would you be OK with that (making this topic public)?
Yeah public is okay by me.
Honestly im not picky about what we add, but im hesitant to add heaps of not vehicle things.
Hi @Murph9, I’m the +1 @sgold mentioned. 
My time two work on this will be quite limited until about 2 weeks from now, at which point I expect I’ll be able to spend some time on this.
My hope is to use the work here to augment Minie’s vehicles and see if there’s anything useful I can contribute to the vehicle model or API.
One question I have off the bat is whether the focus is on the project as a demo or as a library for advanced vehicle models on top of the physics engine. My primary interest is on using it as a library in my project, but I’m happy to help out with “demo only” tasks as well.
I had the idea that it was a library but totally happy with demo stuff as well - i guess we do need it for people to use it.
I’m okay with figuring out what its for before we start, ill have to sit down and actually read the code first too.
My reasoning for contributing is ive already done a lot of this work before in my stuff and feel like i can help for the physics stuff the best.
I would be highly interested in a good library for vehicles - I spent tons of time back in the day trying to get nice car physics in jME, but they never really felt the way that I would’ve liked them to. For me, the absolute (wish) focus of this project would be a good API for the physics, with tons of tweakable values. Stuff like GUI, maps, horn sounds, break marks on the ground sure are nice-to-have, but I see this more as an additional feature, that is nowhere near as important as the actual physics.
I most likely won’t have time to support this topic code-wise, but my suggestion would be to maybe split the library into two parts:
… with the focus obviously being to provide a good extensible core. I saw Jay doing quite a bit of research on this topic (math and physics wise) and it makes sense, that his implementation might be better than the one we had in the past. I think with his work as a base, there is a high chance to come up with a great addition to jME, so it would be unfortunate if all this fresh motivation was spent on fancy demo stuff that isn’t correlated to the actual physics, which in my opinion is worth way more. But don’t get me wrong, any addition is great, I just wanted to highlight where my personal interest in this library would be.
In any case, however you decide and on whatever you work in this project - Good luck! 
I encourage interested persons to study the source code. I need to do that, too!
The simplified vehicle physics model provided by Bullet has significant limitations:
For more details see:
James overcame the first limitation (using the Pacejka friction model). To overcome the rest, it’ll probably be necessary to model vehicles in greater detail, using rigid bodies and constraints. I’ve done some preliminary work in this area, and I’m interested in seeing how far we can get.
I think jme-vehicles would provide a good testbed for developing such detailed vehicle models. Depending what emerges from such efforts, the reusable parts could either be:
Whatever happens with the library idea, I think it’s important to continue providing a demo application. For many developers, an sample application (one they can execute and tinker with) is just as important as documentation!
Ive got nearly all of the those dot points with the stuff in these 2 files:
Look at RayCarPowered and RayCar
I know that they are 100% not usable as a general jme library as is. And also the amount of configuration they need is large: Normal.yaml
I’d rather someone didn’t go through the pain of figuring some of this physics stuff out.
The only dot points i don’t have is:
My model also has as features:
Now as much as that sounds like a pitch to use my library, its not, but its a good starting point to take bits out and work with them. Because simulation speed is a bit of a problem.
And yes a demo application is 100% required, but id rather have a working vehicle thing first. The jme3 fancy car demo is how i originally learnt how the jme vehicles worked.
I’m grateful to you for doing all that development work and making the results visible to us.
Jme-vehicles has a BSD 3-clause license, just like JMonkeyEngine. I don’t see a license in your RallyGame repo. Would it be okay for me or Daniel to copy some of your code from RallyGame into the Jme-vehicles project?
Yeah I allow it.
I’ve begun working in my own fork of jme-vehicles repo: GitHub - stephengold/jme-vehicles: A tech demo for jMonkeyEngine vehicles.
very good news for us your products quality is top
I’d appreciate some advice on how to debug this issue.
Never happened to me. I’ll try to reproduce
Remember to enable assertions.
I’ve forked a copy of @sgold’s repository and am beginning to get acquainted with the code. I’m most interested in the mathematical model - seeing if there are model or API improvements to be made. If anyone would like a second pair of eyes on an issue let me know.
I’m still stuck on issue 1, which might be an Engine issue.
I’ve created a JmonkeyStore page for this project: