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.
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.
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.
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).
Which means that proper wheel shape is part of the answer to full physics train. This animation shows exaggerate idea of how it works:
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.
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.
We wanted to test it because of a game that we saw some days ago: Simple Planes
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.
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.
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. :rolleyes:
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.
Aye, that I have! I’ve just added functionality for the turret so I can limit both traverse and depression/elevation as well as a speed multiplier to slow it down. I’m not too worried about having the exact traverse speed just yet. I’ll be adding a speed limit later, since now it’s just multiplied by a low value, so you can move it fast if you move your mouse at lightning speeds.
Wouldn’t it be possible to achieve a temporary workaround for the torque issue using the same method you did for steering? IE, depending on the pitch of the tank tracks, you can assume it’s going uphill and the steeper it is - increase the extra power ratio, of course up to a certain limit so you can’t climb 90 degree slopes :rolleyes:
The easier solution should be to make mass of track lighter. There is a variable for that, try setting it to 100-200kg less.
Another thing to tweak is to make Rolling Friction Coefficient higher and higher Engine Power Coefficient, this way it should have enough power to get on slope, it will have a higher top speed because of the too, this is where higher Rolling Friction Coefficient should fix it.
I played around with the settings a bit and got it relatively good, I can climb the hill I made going on 2nd gear. I haven’t tried top speed yet, and the suspension might need some more tweaks. Turret rotation seems to not be accurately replicated for some reason, so will need to look at that.
But now I have the general functionality for a tank in place;
• Tank drives around and can get over*(or through :rolleyes:)* obstacles
Driven with a 360 pad*(One analog stick per track, one trigger per brake - allows for some smooth driving. Will need to tweak brake force as you can see though)*
• Tank is multi-crewed; so far only the driver and gunner
• Tank movement is replicated*(might need to tweak the replication values here)*
• Turret rotation is replicated over network(though seemingly not very accurate?)
• Turret can fire a crappy projectile for testing purposes*(will probably replace with raycasting)*
• Can limit the turret traverse and elevation as I please, as well as traverse speed
Still needs more tweaking and tinkering, some more features I’d like as well such as optics for the gunner. I’ve also made a sort of lobby system so other people can connect to my game via a server list(based on the shootout game) - I have yet to package it and try it with another person though.
Nice progress! I like how Tigers and Panthers have such a soft drive because of the amount of wheels on suspension. The other thing you could try to tweak is Mu coefficients of friction, try setting all of the to 25% higher, it gets much more grip this way.
Yesterday was working on the spline tracks. The easiest solution so far:
Move your tank into 0,0,0 of the world
Add Spline Mesh Actor
Spline mesh actor has only two control points, but you can copy/paste their coordinates and tangents right out of the properties.
Place control points of spline mesh actor where two of the track control points should be.
Tweak tangents until you get a proper curve and then just copy/paste tangent values into array.
Very cool stuff.
Nice physics, to drive around with.
Thank you, for your nice vehicle work.
Edit:
Very cool stuff, you are doing there
About stall: For that downloop spiral stuff. I thought about adding a rotating (mace) massobject with a constraint to the Hull.
When stall occurs, raise up spiral radius and or mass of object.
Very cool flystuff.
But I like this kind of simulations!
