Airplane PhysX Wheels

[DSabre 2332]

This thread originated when I was trying to save my addons when they all had stopped working after the TacOps update.

 

Now in hindsight I want to share some examples and ideas about physX for aircraft, especially for tail drag setup.

Feel free to share insights in this thread.

 

The TacOps update of November 2017 changed the ground handling of airplaneX simulation. This probably happened accidently while BI was trying to improve tank movement. Anyway, since then aircraft set up in the traditional way (Arma 2 style) and with airplaneX enabled may start to jump and blow up on the runway. This usually happens at ground speeds exceeding 50 km/h (even on VRs flat surfaces).

 

Before this update the mix of physX and old wheel config worked just fine. In some aspects that system was superior to the new physX wheel setup. It was possible to <damage hide> parts of the gear like a wheel so you had to land on two wheels and balance the plane, actually simulate belly landings and things like that. Some of my Secret Weapons mod planes do work this way still. The IL-2  for instance looses a wheel after some damage and can belly crash land. I have no idea why it still works and never managed to reproduce that setup.

Now the following are some of my personal observations concerning airplaneX and physX wheels. Not pretending to understand what is really going on. Just some observations after doing this to a few dozen aircraft.

 

First some basics:

Spoiler

 

Aircraft do not have the same implementation level as cars:

Diag.exe supports "Suspension" mode for cars.

Dampers are shown.

 

 

Does not work for aircraft. No dampers visible.

Interesting fact: Engine rpm only works on the ground.

The wheels are treated as if they were powered wheels on a car.

This has important implications.

 

There is also no handbrake for aircraft.

The brake works as follows:

Brake power 1.0 applies while thrust = 0.

Thrust > 0 = Brake power 0.0.

 

 

Once airborne physX engine rpm is 0.
 

A tail drag aircraft may have the "engine rpm" running at high values when resting.

Even when actual thrust is zero, physX thrust reads as 1.00 (100%).

That also may happen when the engine is off.

Any way you may get a Perpetuum Mobile. The plane will move without engine power.

 

 

Compare with another tail drag mod aircraft. Here rpm is 0 while resting

 

Engine RPM while moving

 

in flight

 

stopped and engine running

 

 

 

 

The major issue with physX and tail drag setup seems to be to make it stop moving when engine is off and the plane is idle.

 

 

 

 

 

 

General setup / Tricycle gear setup (http://en.wikipedia.org/wiki/Tricycle_landing_gear)

Spoiler

 

 

Resolution LOD (Tricycle)

Wheels and animations here are purely visual and irrelevant to the behaviour of the plane.

Keep in mind that the virtual physx damper only has one axis of movement.

Dampers with hinges or complex dampers with many parts will have to be made in a way so they sort of match.

 

GEO LOD (Tricycle)

Geo lod wheels seem to help with placing the aircraft in the editor and collision with other objects. Some of my aircraft don't have any and work just fine.

Sometimes I assign the named selection  ofthe wheels in geo lod after the actual wheels, sometimes after the damper, sometimes I have none or assign no named selection. All seem to have slightly different effects.

 

Remember to always update changes to your geo lod with >Structure-Topology-Find Components< or it wont have any effect.

Not sure about properties, for instance if property autocenter = 0 has any effect.

If you intend to use BIs buzzard cannon, have the total weight set above 5000 units or you plane will fly backwards from the recoil.

 

Apart from that total mass is only used for collision with other planes or trucks on the ground.

It does improve maneouverability (higher mass, higher manoueverability, yes it is contrary to common sense). Perhaps an option to simulate load changes via setMass.

- I use the same weight for all of my aircraft mostly. Otherwise you will have to redo damper settings over and over again, if you happen to make more than 1 aircraft.

I assign specific characteristics rather by changing aileron and elevator sensitivity.

 

GEO PHYSX LOD (Tricycle)

Copy of geo lod, no need for wheels. Seems to be irrelevant for collisions between vehicles.

Quite probably only needed for collision detection with thrown physX objects like grenades.

- I would suggest not using till everything else works.

 

LANDCONTACT LOD (Tricycle)

I would suggest trying without this first till your plane work (even if it throws an error in diag.exe).

You can still add more layers of confusion and problems by adding this later.

Seems to help with placing in editor (tail drag may have its tail floating till the engine is turned on if missing this). 

You can name the points after the dampers, the gear or have no name attached at all. All have slightly different effects

-Can sometimes prevent rolling off for taildraggers. Some planes work without this LOD in the p3d at all.

 

MEMORY LOD (Tricycle)

the wheel_center and wheel_rim points do not animate properly. They are either there (gear extended) or hidden (gear retracted).

There is some upwards/downwards movement when gear is retracted/extended but I am not sure which rules that follows.

They may follow the bone you reference in the class wheels (?). All damping happens in relation to these points by using the damper vector and droop and compression values.

This will also enable you to use 3d models with pre folded gear though. Just place the wheel points where the gear would be if extended and reverse your visible animations to make it match.

 

 

 

 

 

 

Differences for Tail draggers (https://en.wikipedia.org/wiki/Conventional_landing_gear):

Spoiler

 

Start off by making the two front wheels the steering wheels with steering = 1;  in class wheels (thanks to Reyhard for this idea).

Tail wheel should not be a steering wheel! Balancing the damper settings between front wheels and tail wheel is quite important.

 

GEO LOD (tail drag)

Geo Lod wheels are not really necessary. My setups sometimes have geometry wheels for better placement in the Editor. That is the only effect I am certain of.

If your plane rolls away on its own - move GoC opposite the direction of the movement and try again (again try to name the selection after wheels, dampers or nothing at all).

Another thing that can sometimes help the tail draggers is to move the landcontact point of the tail wheel up into the wheel position. Sometimes a bit to the front of it. That seems to act as a kind of brake (see above the insights from diag.exe).

 

A tail dragger takes off at about 20-30 km/h less than a tricycle if everything is equal otherwise. The game engine obviously interprets it as some kind of high AoA.

Sometimes if your plane can not take off, it makes sense to tilt the whole setup - playing around with envelope or thrust is probably easier though. Bad damper values can also act as a brake.

 

 

 

 

 

Setting up class wheels:

Spoiler

 

First of all: lower and UPPER case do matter! It may work in buldozer but not ingame if you mix (see TeTeTs post).

Make sure you use the same case for all names in config and model.cfg.

 

some further reading:

https://community.bistudio.com/wiki/Arma_3:_CfgVehicles_Plane_class_config_reference

https://community.bistudio.com/wiki/Arma_3:_Cars_Config_Guidelines

https://community.bistudio.com/wiki/Arma_3:_Vehicle_Handling_Configuration

Keep in mind that many of the aspets in these guidelines do not affect aircraft (gearbox, brakes, ...).

 

Of course it makes sense to use https://community.bistudio.com/wiki/diag_mergeConfigFile for this part.

 

Depending on tail drag or tricycle assign steering.

Tail drag:  steering = 1;   for both front wheels,  steering = 0; for the tail wheel

 

Make a spreasheet to calculate your damping ratio (dampingRatio = springDamperRate / (2 * sqrt(springStrength * sprungMass)))
Play around with setting it slightly higher or lower than 1.

 

MaxCompression and MaxDroop have a very strong influence. Start with small values.

Same for longitudinalStiffnessPerUnitGravity. BrakeTorques do not seem to do anything. See above.

 

 

 

 

 

Final Thoughts:

For a standard tricycle gear plane all of this is not entirely bad. It does not add anything much except a lot of work and maybe some nicer damper animations. You lose the option to damage the gear functionally or to belly land though.

 

For a taildragger you could try the old Arma2 setup without this and use the old system first and see if you can make it work.

For slow planes (Biplanes/Ultralights etc) just stick to the old way and forget about class Wheels.

The bumping/exploding effect usually happens above 50km/h so may not be relevant to you! (examples for this are my An-2, Ultralight, and every plane in my Flying Circus and Flying Machines addons)

 

Hints:

Spoiler

 

change of mass:

With commands and adding cargo we can affect the weight of a physX enabled plane.

Tail draggers will roll away when GoC changes due to the additional cargo weight! Try loading something into you tail dragger with box loader or use vehicle player setmass ...  from console to test this.

 

Mass change will change control sensitivity in flight (more mass = very much more agile - yes, that is not a typo! So if anyone wants to simulate the plane becoming easier to handle after dropping something, raise the mass.

 

If you start a new plane with physX my recommendation is to start from bottom up. Forget about landcontact lod, complicated animations, geo lod wheels or damper setup.

Make the absolute minimum work first, then move upwards. The basics are the wheel_center and wheel_rim memory points and your class Wheels.

Then add layers of complexity as needed. That way you won't spend days adjusting something that isn't even the cause of an issue you may encounter.

 

 

 

Thanks to TeTeT and Reyhard for some great suggestions!

Edited March 18, 2021 by DSabre
some new insights

[xxgetbuck123 945]

Looks interesting. May I ask what the actual challenge is?

 

I'm guessing its getting a working setup that doesnt get thrown across the map? 

[DSabre 2332]

Yes, the challenge is to make a plane that does not explode when trying to taxi or take off/land at speeds exceeding 50 km/h.

For a tricycle that can be done, but for a tail dragger it's a real nightmare.

 

We have a first entry too. TeTeTe3 was so kind to make a pretty decent setup for both. The tail dragger is a little bumpy still but both are far better than anything I could do.

I will provide a link sometime I get around to it. Right now physX got me so fed up again I need a break from it.

 

 

[reyhard 2082]

Have you tried to configure two front wheels as rotating one? It will be fake, indeed, but I guess nobody will notice that without PhysX diagnostic.

[DSabre 2332]

Hi Reyhard, thx for dropping by!

I did something similar, making a fake invisible front wheel. Thinking about it now that was a really silly idea.

All kinds of issues arose from not having the thing leveled out.The taildragger becomes tilted upon spawn naturally. The tail dropping to the ground. That seemed to cause all kinds of weird behaviour.

A funny find is that the taildragger in the above example takes off at about 20-30 km/h less, with the exact same flight model setup! Angle of attack does exist in Arma.

 

 

But I really did not think of what you suggest. That sounds like a really good idea. Will let you know.

 

[eggbeast 3684]

not sure i see the solution to rear wheel steering yet - great work btw - this really needs sorting out

[DSabre 2332]

Looks pretty good so far. Tried Reyhards suggestion. Having slight issues adjusting CoG as it has extreme effects on making the plane move on its own.

looks quite promising though. Thank you!

[reyhard 2082]

Glad to hear that ;) I've used that trick on An-2 and it works decently so far. You can try it in RHS (or any other plane - all of them should have PhysX by now) and see how it works. I've also added engineMOI parameter to adjust how fast is plane able to accelerate on runway.

One thing that is very important is to match maxDrop & compression values  with what is model.cfg, so land contact points are moving correctly. I can give those models a shot during a weekend and leave them here if you want to see how it could be done.

[DSabre 2332]

thank you. that is very helpful. I made an update with a link in the first post.

A lot is lacking. I accidentally used my ill configured base as start instead of Tetete3s update. I added some of the values by hand. The result is quite ok though, judging from it's behaviour.

 

I found out that landcontact is not necessary for a flat tricycle gear setup. (you can even remove the wheels in geo lod...not sure what putting them there is good for...)

It helps a plane like the tail dragger though. It prevents the rolling away! (does not seem to be related)

 

Yes please feel free to play around with it! I will add a link for anyone interested then in first post.

[scotg 204]

Kind of on a side note, but I think it's very relevant: None of your visible geometry have to have the same names as your virtual components. I found this useful when aligning the dampers/pistons and their stabilizers, the little elbows that keep the gears from turning out of position. Instead of using a translation animation approach in the model.cfg animations, use a rotation for your damper part - just like you would for those elbows.

 

In the skeleton section make the damper a child of the lower stabilizer elbow.

"damper_guide" ,"", //To provide something to inherit in animations. Might be redundant. 
"gear_1"	,"",  // The front gear mast, which lowers for landing. Connected to the root
"gear_1_2"	,"gear_1", // The first arm of the elbow, connected to the gear mast
"gear_1_3"	,"gear_1_2", // The second gear arm, its axis is the elbow joint. Connected to first arm
"gear_1_damper"	,"gear_1_3", //* The piston that goes in to and out of the gear mast. Connected to 2nd gear arm
"gear_1_caster"	,"gear_1_damper", //* Don't forget the steering on the front wheel.Connected to the piston. 
"visWheel_1"	,"gear_1_caster", //* The visible wheel; turns at virtual wheel's rate. Connected last.

// Steering can go before or after the three parts of the elbow assembly, but never within.
//* These have corresponding virtual components, and for this set up should be named differently. 

If your elbow parts are the same length, rotate the first elbow and the damper the same radian value, and rotate the middle (where it actually looks like an elbow) the negative of twice that amount. The goal is to nullify the difference. The piston will stay in its sleeve, and the joints will all stay "connected."

			class damper_guide_move ///again: this class might be redundant...
			{
				type="translation";
				source="Damper_1_source";
				selection="damper_guide";
				axis="basic_damper_destruct_axis"; //This is in a lot of vanilla vehicles
//				sourceAddress = clamp;// (default) ///these are in here, but why?
				minValue = 0.0;
				maxValue = 1;
				offset0 = 1;
				offset1 = -1;
				animPeriod = 0.0;
				initPhase = 0.0;
//				memory = true;//(default assumed)
			};
			
			class gear_1_stabil_1_rot: damper_guide_move ///...but we'll inherit from it anyway
			{
				type="rotation";
				source="Damper_1_source";///if inheriting from damper_guide_move, this might be redundant
				selection="gear_1_2";
				axis="gear_1_2_axis";
				minValue = 0.0; 		///redundant
				maxValue = 1;			///redundant
				angle0 = -0.0;
				angle1 = 1.0472;//rad 60; //Use also for Damper rotation when both elbow sections are equidistant. 
				animPeriod = 0.0;		///redundant
				initPhase = 0.0;		///redundant
//				memory = true;//(default assumed)
			};
			class gear_1_stabil_2_rot: gear_1_stabil_1_rot
			{
				selection="gear_1_3";
				axis="gear_1_3_axis";
				angle0 = 0.0;
				angle1 = -2.0944;//rad -120.0; //nullifies sum of angle changes for gear_1_2 and gear_1_damper
			};
			
			class gear_1_damper_rot: gear_1_stabil_1_rot //inherits most of gear_1_2 values
			{
				selection="gear_1_damper";
				axis="gear_1_damper_axis";
			};

It can still be done for landing gear stabilizers of different lengths, but it would require a little more math, knowing the lengths of the arms in the elbow, and thus knowing the initial and terminal angles. I believe the elbow angle should still be the negative of the sum of the other two angles. An example of this setup is in the A-10's Main Gear (rear). Despite the focus, the difference is clear here, too. What I did for my A-10 was I measured the angles in 3DSMax, at both extremes. I don't have actual specs on A-10 suspension stabilizer lengths, so I could fudge with it a little. Just make sure your angles add up to 180 in each position/phase, since it's technically a triangle. EDIT: After going back to look at my model rig, I remembered that the A-10 main suspension wasn't as simple as this. I had to set up an IK Arm Solver in 3DSMax, keyframe the damper going between its motion range extremes, and jot down the angles at both extremes. The problem arises with this one because the 2 axes of the elbow closest to the piston are not parallel to the piston. There probably is a mathematical way to sort it out, but it in this case it was easier for me to have the beginning and ending angles and then plug that data into the model.cfg. If you are having problems with a piece rotating the wrong way, then you can either A) try using the negative of whatever value you used, or keep the value but instead B) scale the axis to -1,1,1 in Object Builder MemLOD (if it's not on the X coordinate then  use -1,-1,-1).

I think I covered everything about this. The result should be a nice, connected, fluid motion on the suspension parts when dampering, whereas before it was misaligned or broken.

[scotg 204]

Forgive me for the double post, but I wanted to distinguish these next thoughts from the previous one. Since that post was a little in-depth, I didn't want this to get glossed over.

1.) Let me impart some wisdom to you guys about case sensitivity. It was a major source of my problems which led to a bunch of unnecessary anguish and repeated trials. Even if you read an official statement somewhere claiming that a parameter is case insensitive, forget that noise and just stick to your principles. Always practice case sensitivity, and hunt down and assimilate rogue letters if you are pasting from someone else's script. For me, it was a 'w' where I needed a 'W' for Wheel_*. The W is sneaky for me, especially in the Courier-esque fonts that Notepad++ uses.

2.) This one is really more of a question, but first a brief outline of my trial and error process:

• Start up A3, play-test, observe, shut down A3
• Make changes to config.cpp, model.cfg, and/or [model].p3d
• Compile in Addon Builder. If it fails without good explanation, compile in pboProject (free version) for better output. On successful compile in AB (needed for including .rtm files), move on.
• Repeat process

It can be quite time-consuming, especially with all the load times. I feel like there should be a way to make changes in Eden to save time, and then use that data to make the changes permanent in the config (where most of the alterations take place). This would save time from all the load screens, not to mention how it would cut down on all the anguish over waiting, anticipating, and lingering disappointment accumulated between changes and results. I ran across this page: https://community.bistudio.com/wiki/Mission_Editor:_Debug_Console_(Arma_3). It seems to cover more about configuring for servers, but it does say changes can be made on the fly. It just doesn't specify what kind of changes - changes to an .sqf, .cpp, .cfg, or what? It seems to also be a fairly new feature, in the scheme of things. My question is: Has anyone used Eden's Debug Console to do fast edits to their config.cpp settings? Can it be done?

 

Edit: This question, though maybe not presented in the most efficient thread, is super important to anyone who has spent time tweaking airplane suspension. Thus, this is a good place for it. 

Edited September 11, 2018 by scotg

[TeTeT 1523]

6 hours ago, scotg said:

...

It can be quite time-consuming, especially with all the load times. I feel like there should be a way to make changes in Eden to save time, and then use that data to make the changes permanent in the config (where most of the alterations take place). This would save time from all the load screens, not to mention how it would cut down on all the anguish over waiting, anticipating, and lingering disappointment accumulated between changes and results. I ran across this page: https://community.bistudio.com/wiki/Mission_Editor:_Debug_Console_(Arma_3). It seems to cover more about configuring for servers, but it does say changes can be made on the fly. It just doesn't specify what kind of changes - changes to an .sqf, .cpp, .cfg, or what? It seems to also be a fairly new feature, in the scheme of things. My question is: Has anyone used Eden's Debug Console to do fast edits to their config.cpp settings? Can it be done?

 

 

The debug console can only use SQF to manipulate the game engine. What you're probably looking for is the diagnostic exe of the dev build: https://community.bistudio.com/wiki/Arma_3_Diagnostics_Exe

 

Of interest there is this command: https://community.bistudio.com/wiki/diag_mergeConfigFile

 

With help of diag_mergeConfigFile you can change and add values to an existing config from within the debug console. I have to admit that I rarely use it, but for all those detailed small adjustments on class wheel config values, it should be a real timer saver.

 

As converting your default game to dev build is not such a great idea, BI has published the game updater, that takes care of that for you: https://community.bistudio.com/wiki/Game_Updater

 

On your point 1), just discovered this case sensitivity when the wheels of a plane would refuse to roll in the game, with the wheels rolling perfectly in buldozer...

 

[reyhard 2082]

Just a note about devbranch - you can switch to devbranch, copy paste diag.exe somewhere, switch back to stable and use diag.exe along stable. As TeTeT mentioned, diag_mergeConfigFile should be your friend - you can merge config and i.e. respawn vehicle again to apply changes.

[scotg 204]

So now I'm trying to figure out how to use the diag_mergeConfigFile command. I did what @reyhard and @TeTeT said, esp. reyhard's advice about keeping a copy of the .exe before switching back to stable.

Based on the example here: https://community.bistudio.com/wiki/diag_mergeConfigFile, I replaced it with my plane's path:  diag_mergeConfigFile ["P:\gijoe\vhx_plane\cobra_firebat\config.cpp"]. Got an error message saying it was missing a ';' so I tried placing it at the end. Nothing. For unknown reason I tried placing it before the path. I would never have thought of that except for that one moment of randomness, but it did something. Started up scenario, and it didn't let me enter the plane. Weird. I didn't delete plane entry point; all I did was bump the spring strength up to to a ridiculous number, for the sake of testing the config merge. I'm guessing the missing ';' wasn't supposed to be where I put it, after all. For grits and shins, I shut down game and compiled with pboProject, but noisy output just gave me missing sound file warnings (i.e.: for sure no missing ';' in the config).

 

I think you guys are right about this saving me loads of time; I just need to figure it out first.

[Dedmen 2714]

15 hours ago, scotg said:

message saying it was missing a ';' so I tried placing it at the end. Nothing.

Semicolon at last line of script isn't needed. Look closely at where exactly the error messages hows it's missing.
Missing semicolon at:
diag_mergeConfigFile |#|["P:\gijoe\vhx_plane\cobra_firebat\config.cpp"]
Means that the script command doesn't exist.

[scotg 204]

2 hours ago, Dedmen said:

Means that the script command doesn't exist.

Thanks, @Dedmen. So the |#| indicates where the semicolon goes? I did try putting it ahead of the file path, too. It did something. It didn't do anything right, but it did something.

[.kju 3245]

you are not using the diag.exe

[scotg 204]

You're right. That must have been reyhard's shorthand for arma3diag_x64.exe. Diag.exe doesn't exist even in dev branch mode.

[scotg 204]

On 1/9/2018 at 11:34 AM, DSabre said:

The TacOps update of November 2017 forces us to use wheel.cfg

This is confusing. @DSabre mentions wheel.cfg a few times throughout his first post, but I am not sure what wheel.cfg is. He has also mentioned it in other threads, if I recall correctly, and he has brought it up with me in private messages. Unless someone else knows what he's referring to, we may not be sure what this is until if/when he gets back into working on airplaneX stuff. It is taxing on one's sanity, especially if they feel like they're doing it alone. Getting this even just close to being right is a thing that really separates the big-team mod developers from individual, talented mod'ers.

[DSabre 2332]

sorry that was me being up late.

what I meant is class wheels : )

 

sorry about that - and thanks for putting your thoughts and observations here

[scotg 204]

Ah, ok. It's class wheels in the config.cpp. That I do have. Things are still a bit wonky, so if I start to think I'm missing something it'll haunt me.

[DSabre 2332]

I fixed some mistakes in my first post.

Another thing I just observed while updating my navy planes to work better with the carriers:

 

I copy/pasted my taildragger A6M Zero setup into my SBD Dauntless, TBF Avenger, Aichi Val and the Nakajima Kate, adjusting wheel positions to match the model.

That worked mostly well. When I put it in the Avenger and Val they would just roll all over the place though.

I played around for hours moving CoG here and there. Nothing helped. Again the frustration....of fixing things that had worked well before...

 

This is what finally helped:

simply moving the landcontact of the tail wheel up into the wheel position. I believe that acts as some kind of brake.

 

What caused the rolling off compared to the other aircraft was the position of Tail wheel in relation to the front gear.

Not sure what to make of it. But then taildraggers are not properly supported anyway and all of this is some kind of hack : )

 

 

 

 

 

 

 

Overlay of memory, geo lod and landcontact lod items in an edit lod (I use this to align and then copy/paste into the respective layer):

The physx mem wheel points are where you would expect them to be.

The LC points are a bit to the front of the wheel and a bit above the actual contact.

 

Note that I use wheel_l,r and c (left, center, right) instead of wheel_1,2 and 3.

I never know which is the left or center wheel with the stupid numbers.

 

Both geo lod wheels and memory lod wheels are smaller than the actual resolution lod wheel. That's my way of preventing the model from visually floating over the ground.

You could of course set up all dampers and animations and things precisly - but with over 100 aircraft I just do not have the time for this nonsense. Considering they all used to work just fine before last winter.

 

 

 

Incase someone is interested, some more details:
 

 

Spoiler

https://www.dropbox.com/s/7uezqgnpsqqjqvf/avenger physx setup.p3d?dl=0

(link to the geo lod, mem lod and lc lod setup)

 

 

CoG is between the 2 wing mass points. total mass my standard of 1500 units.

   

 

 

 

 

 

class Wheels {
            
            class Wheel_c {
        
                steering = 0; //thanks reyhard!, tail dragger hack
                
                boneName = "wheel_c";  // linked for visual display of droop and compression?
                center = "wheel_c_center";
                boundary = "wheel_c_rim";
                suspForceAppPointOffset = "wheel_c_center";
                tireForceAppPointOffset = "wheel_c_center";
                                    
                width = 0.2;
                mass = 10;
                MOI = 1;
                
                dampingRate = 0.1; // 0.1
                dampingRateDamaged = 10;
                dampingRateDestroyed = 1000;
                maxBrakeTorque = 100;   // put a million in here... no effect at all
                maxHandBrakeTorque = 100; // same, no effect..
                suspTravelDirection[] = {0, -1, 0};  // this gentlemen, is the actual physx dampers movement direction. in relation to your center and boundary wheel points I believe.

                
                maxCompression = 0.01; // how far the virtual damper can compress
                maxDroop = 0.01;        // how far the virtual damper moves down without load, I think. Some say we have to make the axis in mem lod the exact length? This does not make sense to me. that is like a conflicting definition
                longitudinalStiffnessPerUnitGravity = 1000;  // all these values are from trial and error. the formulas did not do it for me
                latStiffX = 2;
                latStiffY = 3;
                frictionVsSlipGraph[] = {{0, 1}, {0.5, 1}, {1, 1}};
            
                //sprungMass = 500;  // all these values are from trial and error. the formulas did not do it for me
                //    springStrength = 5000;  // all these values are from trial and error. the formulas did not do it for me
                //springDamperRate = 6000; // all these values are from trial and error. the formulas did not do it for me
                
                sprungMass = 700; //all these values are from trial and error. the formulas did not do it for me
                springStrength = 4000; //all these values are from trial and error. the formulas did not do it for me
                springDamperRate = 5000; //all these values are from trial and error. the formulas did not do it for me
                
            };
            
            class Wheel_l : Wheel_c {
                MOI = 0.1;  // 0.1
                steering = 1; //thanks reyhard! tail dragger hack
                maxCompression = 0.01; // 0.01
                maxDroop = 0.01;        // 0.01
                maxHandBrakeTorque = 0;
                maxBrakeTorque = 0;
                boneName = "wheel_l";
                side = "left";
                center = "wheel_l_center";
                boundary = "wheel_l_rim";
                suspForceAppPointOffset = "wheel_l_center";
                tireForceAppPointOffset = "Wheel_l_center";
            };
            
            class Wheel_r : Wheel_l {
                
                boneName = "wheel_r";
                side = "right";
                center = "wheel_r_center";
                boundary = "wheel_r_rim";
                suspForceAppPointOffset = "wheel_r_center";
                tireForceAppPointOffset = "wheel_r_center";
            };
        };
   

 

[scotg 204]

1 hour ago, DSabre said:

Note that I use wheel_l,r and c (left, center, right) instead of wheel_1,2 and 3.

I never know which is the left or center wheel with the stupid numbers.

I always assumed, for planes anyway, that the order is front to back, left to right. So in a tricycle plane wheel_1 would be the front wheel, wheel_2 would be the left main wheel, and then wheel_3 is the right main. In taildragger layout I would think wheel_1 is left main, wheel_2 right main, and wheel_3 is the rear wheel. That's my assumption, but since I haven't tried making a taildragger it has little merit.

Any idea how many wheels total per plane are supported in A3?
Tanks are something like 10 ground wheels per side, and I think cars are 8 in total... or at least I haven't seen anything more than 8.

[DSabre 2332]

I would suggest to model 3 wheels max with physX and animate any surplus wheels only in res lod. That should save a lot of work

So I have no idea how many would be in theory possible..

... maybe, just maybe I will try on the An-22, just to see what happens : )

 

Edited October 4, 2018 by DSabre
never say never

[scotg 204]

On 10/4/2018 at 1:09 PM, DSabre said:

I would suggest to model 3 wheels max with physX and animate any surplus wheels only in res lod. That should save a lot of work

So I have no idea how many would be in theory possible..

... maybe, just maybe I will try on the An-22, just to see what happens : )

 

I was re-reading this thread to see if there were any further developments, and because I reached out to you in a PM. That aside for this thread, I haven't been around much since using the Discord server more. I'm curious if you ever did the An-22, or any other plane with multi-wheel gear. Some larger aircraft have 8 wheels per main gear. The ones on the back end would teeter totter the entire wheel assembly before the gear suspension compresses on landing. Simply put, the way a (tricycle) plane lands on its main gear first and then sets down on its front gear, the row of wheels on one gear would behave the same way. On bigger planes, not showing this behavior would be ugly.