Is downwash the vortex produced by the wings that slows the aircraft when lifting? Isn’t that just dependent on the aspect ratio of the wings? High aspect ratio means low induced drag. Or is it something different?
Right now I have induced drag + interference drag on my aircraft, I wonder if that’s enough drag or is there any other significant drag out there?
Regarding skin drag. On wing surface it should be already “baked” into your curves. For other parts of airplane - fuselage/engines/nosels/landing gear and etc. check this:
Search in google for “INTRODUCTION TO AERONAUTICS: A DESIGN PERSPECTIVECHAPTER 4: WINGS AND AIRPLANES” first link will be a word document. On page 35 of this document you will see Parasitic Drag chapter and example of it’s calculation for real airplane. Would be cool to make an editor in UE4 for drag components, so you could place basic shapes in BP and select drag coefficients from catalog. But don’t really have time to do this.
Downwash is a bit more involved. Empirical method states that wings of perfect ellipse form, have lowest downwash effect. In practice, not only pure aspect ratio, but form of the tip of the wing, tapper, proportion of width of tip and base, all this have significant effect on downwash. There is “aspect ratio” approximation to all of them, but it doesn’t combine well when multiple alterations are involved, nor it’s accurate enough for what I want to achieve.
In my case, wing is constructed out of segments of different airfoils, and accurate downwash can be achieved computationally in pre-processing, as in this example:
but math there is a bit beyond my grasp to get it running over the weekend. I’ll come back to it some later time.
Very nice work ! This looks amazing ! :eek:
Привет. Хорошая работа. Можешь обновить до 4.14?
Updated plugin to 4.14.1, the Content part is still on 4.13, going to finish some work before upgrading to latest stable.
Update on progress
When constraint based model for simulating suspension of the tank failed (miserably in some areas and wasn’t flexible enough in others), I started looking for other algorithm. Sweep based model with shaped colliders was rather obvious and works quite well.
This model is very similar to doing a raytrace for each wheel for calculating suspension. The core difference is that instead of using a ray or sphere trace for all wheels, front and back wheels use shaped collider which approximates contact of the track with the ground:
I’ve decided to give a try to a more complex model, where track would approximate behavior of the real one. There are quite a few implementations, including simulating track as a connected chain of rigid bodies - real deal. I might give a try at some point but not now.
Just to make it clear, the algorithm that I want to describe is not final and not planned to be used for more than a few tanks at the same time. We are not looking only at visual behavior of the track either, we want it to have an effect on tank’s mobility too. Tanks are capable of driving over large obstacle not only because of powerful engine but the fact that road wheels never have to “attack” obstacle in a sharp angle. For comparison with the wheeled vehicle:
Green points (main) are allowed to move only vertically in local space of the tank, so that they can follow wheels. There are multiple forces that effect them:
Yellow points (middle) are effected by the same force when they are not in contact with obstacle. During contact with obstacles these point can move not only vertically but horizontally. This is schematics of how contact with obstacle is detected:
this is how it looks like in the engine, without smooth tangents on the spline:
Unfortunately, while this approach with using “middle” points was an optimization, it has some issue which I can’t solve right now. Mainly there are situations where tracks start to jitter as middle point keeps jumping between free and collision states. Today I’ve tried replacing middle points with a several regular main points and results where better than I’ve expected. Work continues, there are still couple of things I have to try here and there before deciding on final approach.
Capture of the WIP results:
Long time since I last read this thread, I’m glad to see you’re still actively working on this - you’ve made some really impressive progress since. Keep it up 
Thank you!
The plan is to have multiple implementations for tracks:
Updated repo to 4.14. Didn’t test vigorously but it compiles and doesn’t throw errors. Cleaned up the main level a bit (there were half broken tanks slowing down everything).
I’m planning on converting MMT Content into c++ project, right now it has to be done every-time when you want to compile executable and I’m getting tired of making a copy of the project for this every-time. Judging by this thread:
we won’t get content only projects with custom c++ plugins anytime soon, so I might cut out this hassle of converting it.
Hello, !
I am working on “Our Ghosts of War” (link here) and I want to use this kit to implement vehicles. Right now, I am focusing on tanks. I have set up a model of the Tiger I and physics are working great. Before integrating this into the project I have been testing performance and noticed that placing several of my tanks (10 in my case) has a significant drop on the FPS so I tried doing some optimisations, which you might be interested in. I managed to double the FPS, which sounds good but I wish I could further improve it. My tank is set up nearly the same as the M113 with the only differences being: 1. three additional wheels on each side 2. spline tracks were replaced with a skinned posable mesh whose bones are aligned with the wheels and moved up to make the tracks follow the wheels 3. the tracks movement is animated using UV animations. For debugging, I have added afunctionality which causes the tank to keep driving forward, so it does not go to sleep while debugging. All optimisations were run separetly for better analysis.
The simplest optimisation which works but yields only minimal improvements: For both tick functions, the main tick and the substepping tick function, I added added the option to configure that some ticks are simply skipped. For instance, I tried several configurations in which every 2nd, 3rd, etc up to 8th tick are skipped. Setting it too low causes the simulation too look jerky but setting it too high will hardly yield any performance boosts. Empircally I determined that without loss of the simulation quality skipping every 5th tick is fine. However, it turns out this hardly saves much performance, as might have been expected: With 10 tanks, it went from ~18 FPS to ~21 FPS so a rather small improvement but it still works.
A second improvement is in the main tick: there are several animation functions which only need to be run when the client is close-by to a tank. I set a configurable property that ensures the animation functions AnimateWheels, AnimateTreadsMaterial, AnimateTreadsSpline, etc. are run only if the client (in both standalone and networked games) is close-by, say 50 meters. This made the FPS go up from ~18 FPS to around ~36 FPS when the client went a little away. I think this optimisation is quite useful as usually at around 50 meters distance it is quite difficult to see the wheels spin anyways; after some gameplay testing I can confirm this: you do not notice it at all so the quality is not harmed in any way. So it seens a good idea to do distance based animations.
A third optimisation I tried is quite similar to the second approach; it works with occlusion culling. Before executing animations, it determines whether a tank is actually visible to the client. If it is not, we need not bother playing the animations. This yields a significant boost similar to the one in the second approach, optimally performing when you can only see your own tank. The performace then increases to ~35 FPS, again with 10 tanks. So it appears this optimisation is also a good idea.
The profiler has also told me that CheckWheelCollision and ApplyDriveForceAndGetFrictionForceOnSide are quite more expensive that the other ones all together. Reason for this is because those functions are run multiple times for every wheel and suspension. I tried minimising calling those functions using distance culling again. However, this yields quite funny behaviour. If I spawn my tank far away from them (>50 meters which is the configured culling value) my FPS is 120 for my tank on its own (awesome!), however if I drive to the other tanks they yield to simulate: the wheels are stuck in the floor. Once I ram them, they start to drive around until I exit the 50 meter sphere and they yield doing their phyiscs again. Now I admit what I tried was very adhoc and I have not tried all options yet, nor have I shared my setup with you yet, but maybe you have an idea to prevent those expensive function calls?
Also, do you have any other ideas to optimise vehicles both on client and on server? In our current game, their may be up to 100 tanks which are concurrently active, which would be quite expensive for the server. Of course, the server never has to run those animations and some of the physics code but it appears as soon as I do not run one of the physics functions handling movement, the tanks starting behaving in a weird manner. What are you plans for performance updates to the project?
As a side, I will continue on working on these optimisations and add them to the project as I have the time to do so.
Skipping ticks on physics simulation can lead to very bad results. It depends heavily on the landscape you are driving over - when landscape is smooth (like in War Thunder), you might not experience any major issues, but if tanks is going fast and encounters large obstacle during skipped tick, next tick can create much larger suspension force, effecting stability of the tank. I would rather skip some of the calculations when you believe they are not necessary, more on this later.
That is a good approach, I would setup some animation and skeletal mesh LODs together with this, to cut down some of the performance at closer ranges. I was looking at tank in Red Orchestra 1/2, which is made in older versions of Unreal Engines. It looks like devs change materials and complexity of the tread mesh at distance + animation is updated less frequently.
These functions contain the core of movement simulation, they run on every tick and every physics sub-step. If you skip them, tank will fail to drive over the landscape as no suspension of friction forces (traction is part of it) will be generated. It should be possible to improve performance of these functions, but this is BP implementation - there is a limit to how fast it can run. New model that I’m working on has the most math heavy components implemented in c++. Moving friction component to c++ gave about x2.3 times boost in performance. Moving communication between components and the rest of the calculation into c++ should provide even better results.
What can be done here is some sort of check on rate of change of the form of the landscape, so if tank is keep driving in then flat field, some of the calculations can be skipped all together or can be done only on first wheel. The rest of the wheels would provide just the same force (in local space of the tank) as on previous frame. So if tank is driving forward and suspension force on the front roadwheels is not changing significantly, then the rest of the forces won’t change significantly.
Another approach is similar, by comparing landscape in front of the tank on previous and current frame, decide if all wheels are needed and if not then drive it only on front and backward wheels, as if it would be a car. This would require adjusting stiffness of the springs which can be done with small adjustment in the code - there are some pre-calculations done in constructor.
I’m not planning on touching code of A_Tracked_Vehicle. That implementation was made largely for studying the subject and uses similar approach to PhysX N-Wheeled Vehicle. For having something like a 100 tanks in the same scene, I would start with Nvidia’s implementation, but I doubt that it can support that many with a reasonable performance. People did report that they could have 20+ tanks in the same scene without heavy performance impact.
For this project (Machinery Modelling Toolkit) I want to have something more modular than what Physx team have build and what I have build in Tracked Vehicle project. Having more detailed simulation would be nice too, but I don’t think it would have a better performance than Physx’s implementation. So it would be going more in the direction of having more features and modular design, rather than maximum possible performance. I don’t think it’s possible to have a generic model, that would be flexible in usage (in terms of what kind of vehicle you can build) and have a better performance than specialized implementations.
I don’t know what kind of performance I will get with new c++ implementation, it will be faster but I don’t think it will be 10x faster, perhaps with optimizations that you’ve tried in regards to culling and animations it will get over the 10x. So far only few components are moved to c++.
There are multiple prototypes that new c++ components but they are broken, each in their own way. One prototype, is using physics constraints for suspension and it’s a dead end in terms of stability, getting it to work exactly as it should and quite costly performance wise. Second prototype uses AnimBP for suspension animation but it uses BP code to trace suspension against the ground, which leads to quite a performance hit but more stable and predictable than constraints implementation. Finally the latest prototype, is based on second prototype and extended with track simulation. Last two are being moved to c++ in a form of a single component per tracks, instead of 50+ as it was before. It’s quite some work to do and I have no idea when this will be finished.
I thought you guys where using this thing:
as I would recommend Physx implementation of N-Wheeled Vehicle for best performance. So far I’ve heard only good things when it comes to how much performance they need.
I’m still here 
You mentioned somewhere , something about having to copy the project in order to be able to create an executable. Is this correct?
I cannot seem to build the project… I keep getting an error.
I still need to update to 4.14 , my progress has been a bit slow… mainly because the amount of things I need to do to get everything up and running is a bit overwhelming to do alone… and it’s hard keeping myself motivated to move on sometimes.
I’ve written a document with everything I want and need for a first proof of concept. I have a lot of ingredients ready, but adding all of them and making them work together is just… well… again… an overwhelming amount of work.
Hi there, glad to hear from you!
So the situation with 3-rd party plugins is following - if you have a content only project (only BP code) and want to add a 3-rd party plugin (which is not Substance, or other plugins endorsed by Epic) then you will have to turn your project into c++ project, in order to be able to package it. It’s easier than it sounds, but has a number of side effects, such as some complications when making game for IOS or Android. You can read more about this issue here:
So far, I was keeping MMT Content as content only project, so you can open it with just an editor and play with it. But you can’t package it, because of custom c++ plugin - MMT Plugin. When you want to compile/package your project, you need to have Visual Studio installed and add a single dummy c++ class into your project. This process is irreversible as far as I know. So in my case, to get executable of MMT Content, I would just clone it and then turn into c++ project by adding a single c++ class from UE4 editor.
I wonder what wold happen if I turn MMT Content master branch into c++ project. Would it be possible for people without Visual Studio installed to open it in editor? - I’ll check on this.
I’m afraid we have to scrap constraint based setup for tank suspension. I wasn’t able to get rid of jittering and overall we are rather limited in how constraints can be tuned. On top of that, they are performance heavy, in my last tests, about 30% of the frame time is spend on synchronizing positions of the rigid bodies and with constraint based setup we use quite a few rigid bodies just for suspension alone.
New approach is to animate suspension using AnimationBP (which hopefully supports culling and LODs) and calculate suspension using sweeps, sphere traces or ray traces.
If you focus on other features for now, I’ll help you with setting up new system for suspension and traction when I’m done with it.
Could someone WITHOUT Visual Studio installed, please test this for me:
Just try to open it in UE4 Editor and package executable.
This is c++ version of MMT Content with compiled dlls included. Normally, “Binaries” folder is excluded from source repo, but if you can open this project and able to package it then we have a win-win situation. At least for Win64 it could work out of the box.
I’m fine with that I’m not a big fan of constraints anyway 
too much hastle to setup.
Just a simple spring would be fine just like in the a_trackedvehicle blueprint.
The most important thing is what you wrote on the previous page… the sprocket at the front and part of the track between the sprocket and the first wheel should be able to help you over an obstacle. Nobody will see that I’m not using a real torsionbar suspension setup 
I cannot test the zip, I have visual studio installed.
No problem at all! My good friend helped me to test it yesterday:
I’ll convert MMT Content into c++ project then, on my side it will greatly speed-up development process, on users side nothing is changing.
Just for the fun of it… decided to put on my oculus Rift… since UE4 has support for it out of the box.
Guess what… Driving a Tiger with your head from the Cupola is serious Fun in VR! I might make VR an option for controlling the tiger.
I did this a while ago in unity with the tiger, but driving from the commander position made me really sick. Now it does not… how weird… maybe better suspension this time 
I need to throw in the interior, I think it would be epic to drive this thing from the driver perspective in VR.
Sounds fun 
Not sure if this is because of suspension. If you see more chassis from driver position it can help to relief nauseous feeling.
no it was not because of the suspension I’m sure it was the camera. I remember in unity the camera was “connected” to the tank chassis, so your view rocked and moved when the tank moved.
The camera rotation in UE4 are disconnected from whatever the chassis is doing. But it is good to know that this works and you do not get sick as it opens possibilities for a vr mode.
