Further development of the Advanced Vehicles project

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).

4 Likes

“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:

  • One that jumps out at me is “multiple tracks/maps/environments”—currently the Vehicle Playground is the only one.
  • I’d also like to augment the keyboard shortcuts with GUI buttons for things like “start engine” and “sound horn”. Friendlier to users that way.
  • More camera views would be nice to have. For instance there’s currently no way to see behind you.
  • Moving obstacles, such as deer or other vehicles, would add interest.

What features do you think should be added?

2 Likes

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)?

1 Like

Yeah public is okay by me.

Honestly im not picky about what we add, but im hesitant to add heaps of not vehicle things.

2 Likes

Hi @Murph9, I’m the +1 @sgold mentioned. :smiley: 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.

2 Likes

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.

2 Likes

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:

  • a core library, offering vehicle physics with all the parameters, car loading, etc.
  • a samples library (based on core), that offers sample cars, a playground map, GUI, horns, break marks, maybe even a demo app and all the other fancy stuff that people might want to use when setting up a project without wanting to go the whole way of implementing it customized for their game

… 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! :slight_smile:

6 Likes

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:

  • unrealistic tire friction
  • unrealistic engine power at high speed
  • no gears
  • wheels lack momentum
  • terrain normals not interpolated
  • tires have zero width
  • suspension lacks hard limits
  • wheels don’t spin while airborne
  • power is applied to the chassis, not the wheels

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:

  • integrated into an existing physics library (such as Minie or jme3-bullet) or
  • packaged as one or more separate libraries.

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!

5 Likes

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:

  • wheels lack momentum (assuming you mean suspension) the wheels have rotational inertia though
  • tires have zero width (can be fixed with a capsule physics ray cast)

My model also has as features:

  • doesn’t use bullet vehicles (+/-) so its all java
  • sway bars
  • torque curve engines
  • combined Pacejka of long/lat (Traction Curve Merge)
  • some speed hacks to prevent weird jittering, but Pacejka is not really designed for slow speeds

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.

1 Like

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. :slight_smile:

5 Likes

I’ve begun working in my own fork of jme-vehicles repo: GitHub - stephengold/jme-vehicles: A tech demo for jMonkeyEngine vehicles.

6 Likes

very good news for us :slight_smile: your products quality is top

1 Like

I’d appreciate some advice on how to debug this issue.

2 Likes

Never happened to me. I’ll try to reproduce

2 Likes

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.

1 Like

I’m still stuck on issue 1, which might be an Engine issue.

1 Like

I’ve created a JmonkeyStore page for this project:

5 Likes