Vehicle simulation

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
macaba
Posts: 2
Joined: Mon Oct 30, 2017 3:17 pm

Vehicle simulation

Post by macaba » Mon Oct 30, 2017 3:28 pm

Hello all!

I'm new to BEPUphysics but otherwise an experienced C# developer. I've downloaded bepuphysics1 from GitHub, compiled it and had some fun with the demos.

As with any library like this, half the challenge is in knowing where to find useful resources to help me get started so I hope any responses to this post will give me a good starting point.

The challenge:
I want to simulate the physics of an aircraft tug; to drive it around an airport, hook up to a 747 and push it out from the stand.
I've got the visuals all sorted - a tug in an airport with some 747's, but no simulation for the tug.

This is what a tug looks like.

Does any car/truck sample code exist that I can use as a starting point for this?

Thanks,
Mark

macaba
Posts: 2
Joined: Mon Oct 30, 2017 3:17 pm

Re: Vehicle simulation

Post by macaba » Mon Oct 30, 2017 4:13 pm

I've just spotted this post:
https://forum.bepuentertainment.com/vie ... 0047#p9962

That's probably enough to get me started :)

mcmonkey
Posts: 92
Joined: Fri Apr 17, 2015 11:42 pm

Re: Vehicle simulation

Post by mcmonkey » Tue Oct 31, 2017 4:59 am

Hello there! If you discover a good way to achieve what you've described, I'd be curious in what direction you tweaked things.
A small vehicle (a tug car) pulling on a massive vehicle (a 747) will in an initial simulation inevitably cause things to start tearing apart as the physics engine struggles to keep up with incredible forces.

The system will generally still work (BEPUphysics is good at keeping things working!) but if you render physical parts accurate to their physical locations, you'll generally see parts start to drag away from where they belong when under too much load. I'm sure there's a solution for this, but I haven't experimented too far in that direction.

(Though I imagine now that I've said the above, Norbo's going to pop in and tell us exactly how to fix that to near-perfect levels, and then continue with exactly how BEPUphysics2 is going to make it easier to achieve even better results, all while running faster too :P)

Norbo
Site Admin
Posts: 4529
Joined: Tue Jul 04, 2006 4:45 am

Re: Vehicle simulation

Post by Norbo » Tue Oct 31, 2017 6:36 pm

Norbo's going to pop in and tell us exactly how to fix that to near-perfect levels
8)

Provided that the attachment points of the tow bar are the main masses of the tug and the plane, and provided that the tow bar is simulated as a single constraint, I wouldn't expect any significant issues. Tugs aren't particularly lightweight vehicles, and the accelerations involved are pretty small.

You might get into a little more trouble if you have an intermediate physical body representing the tow bar. If its mass is too low, you could get into mass ratio related issues- or it might be fine. If it's not fine, it would tend to manifest as instability when the constraint rigidity is too high. If an intermediate body is required, one trick (other than increasing solver iteration count, increasing tow bar mass, or decreasing simulation time step) is to have a 'cheat' constraint that still directly connects the tug and plane. That way, the low mass tow bar wouldn't be a bottleneck in propagating impulses.

(The same sort of cheat can help ropes a lot too- rather than having a chain of bodies which are only connected to their immediate neighbors, you could add distance limits between the start and end, and maybe also between every five links or whatever reaches your desired level of stability. Since the mass ratio problem is effectively an impulse propagation bottleneck, adding those cheat constraints can give impulses a more efficient path and significantly improve stability.)
and then continue with exactly how BEPUphysics2 is going to make it easier to achieve even better results, all while running faster too
I have considered implementing dedicated subsolvers for marked constraint graphs- this would be similar to what some engines call 'articulations'. Such solvers aren't used across the board since they tend to be far more expensive and/or can have limited applicability and nasty corner cases that require fallbacks, but targeted usage can be really powerful.

That said, I wouldn't expect to see such subsolvers implemented for at least another year, if ever. The initial v2 release won't include them, and the fundamental solver type (PGS/SI) is the same, so mass ratio concerns still exist. It probably will, however, ship with slightly more robust combo constraints, like individually block solved sliders. This is a special case of the subsolver idea, but it won't be quite as powerful since the scope is so narrow.

That also said, when it comes to physics simulation, quality and performance are sort of the same thing. A simulation that takes 16ms per frame in v1 might take less than 2ms in v2, which gives you some headroom for, say, doing way more substeps or increasing the solver iteration count.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest