[OPEN-SOURCE] Machinery Modelling Toolkit

[BoredEngineer]

Been tweaking a bit and playing around with implementing functionality for the turret. It's a very simple testing setup, I added a boolean variable to A_Tracked_Vehicle called TurretLock so I can change whether my 360 pad's input goes to the throttle or turret. So far it rotates along yaw and the barrel pitches but I haven't added any limitations yet. I also added a basic fire function but as you can see the force applied is a bit funky(Used your MMT Ad Force at Location). I made a socket for the muzzle location and I'm using it as a location for the force. I'm still trying to figure out how to properly apply the force for realistic-ish recoil.

Sorry for hijacking your thread with all my updates

https://streamable.com/gyzd

Still some performance tweaks to do, but I might continue that later. I think I'll look into some multiplayer replication now and see if I can get the turret rotation to sync. After that some model tweaks as the turret model isn't particularly accurate when it comes to the gun mantlet(model probably wasn't intended to be used for games).

I also found a bunch of awesome cutaway pictures, so I might try and model a basic interior for the tank(I'm a terrible 3d artist, so it'd be the most basic of shapes). This really makes me regret selling my Oculus Rift DK2 a bit over a year ago.

No worries at all. I'm actually glad that you are posting here - it's nice to see how people are using MMT and what kind of issues they have with it.

For the recoil try regular AddImpulseAtLocation in the direction reverse to the muzzle socket forward vector. Something like GetForwardVector(muzzle_socket) * (-1) * RecoilStrenght would be the impulse vector itself.
MMT functions have to be called from MMTPhysicsUpdate event and this makes them not very suitable for the input driven events. Add impulse will work just fine and better suited for this kind of behavior.
Btw, I'm not sure if recoil should originate from the muzzle, perhaps it should be somewhere between the breach and middle of the barrel.

[TiagoTiago]

I'm still quite new to all of this, so please forgive me if this turns out to be a dumb idea.



What if each bogie (or whole wagon for the ones connected rigidly to their wheels), were positionally constrained to two objects that are being moved along the spline (two to provide the direction), and the wagons constrained to their bogies, and the distance between the pairs of objects running on the tracks being calculated to account of slack between the wagons?


And then you can even make derailments possible by making the bogie-splinerider constraint breakable.



To move the splineriders, first calculate how much the powered bogies/wagons move, then iteratively calculate the distance between each pair of splineriders, and if it is bellow or above the slack, add a "force" (not physically, but used in the calculations to move the splineriders) that propagates in both directions; and keep iterating till no pair of pair of splineriders are beyond the slack.


edit: not sure if it is clear; so I'll point it out explicitly. You will need to simulate the inertia of the wagons in the calculations for the movement of the splineriders, not just blindly change their positions

[BoredEngineer]

I'm still quite new to all of this, so please forgive me if this turns out to be a dumb idea.



What if each bogie (or whole wagon for the ones connected rigidly to their wheels), were positionally constrained to two objects that are being moved along the spline (two to provide the direction), and the wagons constrained to their bogies, and the distance between the pairs of objects running on the tracks being calculated to account of slack between the wagons?


And then you can even make derailments possible by making the bogie-splinerider constraint breakable.



To move the splineriders, first calculate how much the powered bogies/wagons move, then iteratively calculate the distance between each pair of splineriders, and if it is bellow or above the slack, add a "force" (not physically, but used in the calculations to move the splineriders) that propagates in both directions; and keep iterating till no pair of pair of splineriders are beyond the slack.


edit: not sure if it is clear; so I'll point it out explicitly. You will need to simulate the inertia of the wagons in the calculations for the movement of the splineriders, not just blindly change their positions

Yeah, I see what you mean. Someone was asking about movement of the train along the spline about a year ago on the forum. At the point I thought about geometrical solution, this was the illustration:

The whole idea was about finding two points on the spline where bogies will be at some point in time. For example you can integrate position of the first bogie and then find a second one as intersection point of the spline and circle with diameter of distance between bogies. It's doable but I didn't do the math for it.
What you suggest is to place a physics constraint on each bogie, connecting them to the train, so that they can rotate to some degree but stay connected to the train. Then on each step estimate where bogie will be on the track in t+1 time and apply a "correction" force sideways, which will push bogie and subsequently wheels back to the "proper" path. Some torque would be necessary to rotate bogies along the spline too.
I mean this is really the choice of solving it as kinematic system or physics system. In kinematic we have to calculate position, rotation and velocity for each element, which is doable geometrically but won't allow much of physics interaction with the rest of the objects in level. I would prefer physics one, just not sure where one would start from. Wheels can be driven along the spline by a simple spring system, which should be enough to align them along Y axis of the track. But in curves, wheel on one needs to have a smaller speed than wheel on the other side (just as in cars and this is why we have differential). Difference is speed on side will lead to a specific angle of the bogie. Or we have to calculate angle of the bogie in one way and alignment of the wheels along Y axis of the rail separately.

[TiagoTiago]

I think on most trains the wheels on both sides rotate at the same speed, but their profile makes it so it behaves sorta like a CVT, making the outer wheels touch the tracks on the point where they (the wheels) are wider; making it so, as long as all the shapes and stuff are calculated right, they self-steer back into a centered position mostly aligned with the direction of the tracks.


I'm no train expert though.

[Freakazoid!]

I think on most trains the wheels on both sides rotate at the same speed, but their profile makes it so it behaves sorta like a CVT, making the outer wheels touch the tracks on the point where they (the wheels) are wider; making it so, as long as all the shapes and stuff are calculated right, they self-steer back into a centered position mostly aligned with the direction of the tracks.


I'm no train expert though.

A difference in speed doesn't really make any sense. All wheels go (unless some sort of brake is applied) the same speed as the rest of them. The only factor that may slow wheels down is physical weight, but then all the wheels on said car would be affect and not just one. Also I had to look up what you meant by boggies/bogie because I didn't understand what that was referring to. Then I saw that it was the UK term for the car trucks (as they are called trucks in the USA), and I understood a lot better. xD

I was talking to a friend of mine about how you would accomplish this (in Unity 3D mainly) and I thought that instead of having one single Spline to follow, you would have two. One for each rail (and then one that is the rail ties, but that is more of a visual thing then a functional thing). So instead of forcing the objects to following a single Spline (that right now causes the trains wheels to look like they aren't even on the rail at curve sections), you have the wheels following two Splines. I know this is a game engine, but in real like a train can't just run on one track (unless you are talking about a Monorail or MagLev train, which is a whole thing on it's own) and are following two different rails. How would this change the whole formula/problem solving process? Would it make thing more difficult? Or easier?

Also if we used different Splines for each rail, there would have to be a system in place to make it so the user/developer could place both Splines at the same time (creating proper distance between the tracks and nice looking/functioning curve sections). I think even a editable spline/rail distance option would be nice, allowing for the use of Narrow Gauge track to be placed (instead of only standard gauge).

What do you all think about this idea?

[Cristineltr]

Here is a simple explanation on how the trains go around bends https://youtu.be/Wqwq1Lx0w64?t=4m34s

It has to do with the shape of the wheel

[BoredEngineer]

Here is a simple explanation on how the trains go around bends https://youtu.be/Wqwq1Lx0w64?t=4m34s

It has to do with the shape of the wheel

Which means that proper wheel shape is part of the answer to full physics train. This animation shows exaggerate idea of how it works:
https://www.youtube.com/watch?v=agd8B-31bjE
But real train wheels are much thinner and I'm not even sure we have enough numerical precision to implement this effect naively. I was planning to do something similar for motorcycle tires as rounded tires is what allows them to steer by tilting. Have to look at this later, so far it looks a bit like an overkill just to keep wheel meshes away from clipping a rail But I like this kind of simulations!

[Freakazoid!]

Which means that proper wheel shape is part of the answer to full physics train. This animation shows exaggerate idea of how it works:
https://www.youtube.com/watch?v=agd8B-31bjE
But real train wheels are much thinner and I'm not even sure we have enough numerical precision to implement this effect naively. I was planning to do something similar for motorcycle tires as rounded tires is what allows them to steer by tilting. Have to look at this later, so far it looks a bit like an overkill just to keep wheel meshes away from clipping a rail But I like this kind of simulations!

Awww. That's a bummer. I was hoping that someone would be able to work on this system. Well, hopefully it sparks your interest later and maybe we can get some great looking and functioning trains.

[BlueBudgie]

We looked around in other engines for physics games and found this.
MMT + 2 years fiddling = http://store.steampowered.com/app/397340/?l=german

It is done in Unity.

[spiez]

I've tried your toolkit, works perfectly. Your work on aerodynamics on blueprint is really nice! Keep up the good work!

[BlueBudgie]

Our main man set up a framework yesterday where you can move parts around and 'construct' your vehicle and then fly it like this. Your can move the four 'thrusters' around with the mouse by clicking oh them and putting them in all possible places.
The download link has the feature test version of our physics based flying game in it. We use this 'guinea pig' version to prototype new things (nothing is modeled there). Gamepad required.
https://drive.google.com/file/d/0B_g...ew?usp=sharing

We wanted to test it because of a game that we saw some days ago: Simple Planes
http://store.steampowered.com/app/397340/?l=german

This should also work with MMT.

[BoredEngineer]

Our main man set up a framework yesterday where you can move parts around and 'construct' your vehicle and then fly it like this. Your can move the four 'thrusters' around with the mouse by clicking oh them and putting them in all possible places.
The download link has the feature test version of our physics based flying game in it. We use this 'guinea pig' version to prototype new things (nothing is modeled there). Gamepad required.
https://drive.google.com/file/d/0B_g...ew?usp=sharing

We wanted to test it because of a game that we saw some days ago: Simple Planes
http://store.steampowered.com/app/397340/?l=german

This should also work with MMT.

In principal it's possible as long as you can "automate" wiring of the components with current approach. For example, when you add a wing section in real-time, aerofoil component needs to know about the mesh component it will be attached too. The "easier" way to build such constructor is to move some code to c++ and make a component which will have both the visual/physics mesh and logic which drives it.

[BoredEngineer]

A sneak peak on the next update:


Now I'm using a different method for simulating friction and both sprocket and idler can participate in traction. In previous model only points under the roadwheels could contribute to traction. Another big change is that suspension is not limited to a single vertical or angular spring. You can have pretty much any kind of suspension setup now as long as road wheels can be made as meshes with collision.

[Dealman]

That sounds awesome, I can't wait!

Been getting some help on the UE4 AnswerHub and have now got this; https://streamable.com/dskb

I had some issues getting the turret aiming to work since the mouse inputs inside A_Tracked_Vehicle are set to consume input, once I disabled that it worked like a charm in case anyone else runs into a similar issue. So now some final tweaks as I kinda messed the performance up and it doesn't like going uphill at all anymore. And some speed and aiming restrictions to the turret.

[BoredEngineer]

That sounds awesome, I can't wait!

Been getting some help on the UE4 AnswerHub and have now got this; https://streamable.com/dskb

I had some issues getting the turret aiming to work since the mouse inputs inside A_Tracked_Vehicle are set to consume input, once I disabled that it worked like a charm in case anyone else runs into a similar issue. So now some final tweaks as I kinda messed the performance up and it doesn't like going uphill at all anymore. And some speed and aiming restrictions to the turret.

Cool! So you got it working in multiplayer?
One problem you can encounter when going uphill is that there is too much friction which pushes tracks the other way. This is the issue with the model itself. Tanks needs to have much larger rolling friction in contact with the ground and mechanical friction of the thread elements. Which means we would need a more powerful engine output but things should even out. Right now if you just add more torque from the engine it might drive too fast on the flat.
I'll solve this problem in the new model.