Project Universal Cars for Orbiter (UCFO) Development Thread

[Buck Rogers]

but the better solution would have been not posting at all in that moment.

How often have I thought that...

Germans have less inhibitations on using profanity

Yes, I think the problem is that coloquial english is often more than profane, but you'd never hear it on the news etc. I've taught business english and 3 things stuck out as nearly impossible to teach; prepositions, how to pronounce "th", and when, and how to use profane language.
All good, out in the open, cleared up. Hopefully Matias can make head from tail to solve the animation.

 

[Thunder Chicken]

I apologize for using implicit profanity here, that was inadequate and nothing to be proud of. It happened in a lot of stress, but the better solution would have been not posting at all in that moment.

Some things aren't conveyed or understood well in text. Being told to RTFM reads more aggressively than I believe you meant. You also caught me before I was fully caffeinated as well, which never is a good thing.

Onward!

Back to the point - I was trying to convey how I managed to get the wheel animations to work. There may well be an improved way, but I think if they can recover the functionality of my Lua script in C++ and understand that, then we all (module and script developers) can modify and build improvements on that. There is a lot going on in my script with all the models so it would be rather helpful to see if it can be more or less perfectly replicated in a compiled module.

 

[Matias Saibene]

Dear brothers and sisters:
Let's calm down for the sake of the cause, our beloved simulator.

I'm going to continue investigating this issue, seeing if it can be solved with programming instead of having to edit the 3D model.

Thank you all for your responses. I'm going to study them carefully.
I also found this, which I believe was written by @martins himself.

Having two rotation animations applied to the same mesh groups will lead to undefined results.
Whenever SetAnimation() is called for one of the animations, the vertices of the affected groups are rotated: x' = R1 x, where x are the current vertex positions and x' the transformed ones. If you call a second rotation, the new rotation is added to the result of the previous rotation: x'' = R2 x' = R2 R1 x. If the two rotations are coming from the same animation, the effect is as expected. In particular, the rotations commute: R1 R2 x = R2 R1 x. If the rotations are coming from different animations, this is no longer the case. This means that the end result depends on the order in which the rotations were supplied.

I don't know why but this reminds me of the three-body problem.

 

[Thunder Chicken]

Having two rotation animations applied to the same mesh groups will lead to undefined results.
Whenever SetAnimation() is called for one of the animations, the vertices of the affected groups are rotated: x' = R1 x, where x are the current vertex positions and x' the transformed ones. If you call a second rotation, the new rotation is added to the result of the previous rotation: x'' = R2 x' = R2 R1 x. If the two rotations are coming from the same animation, the effect is as expected. In particular, the rotations commute: R1 R2 x = R2 R1 x. If the rotations are coming from different animations, this is no longer the case. This means that the end result depends on the order in which the rotations were supplied.

This is true. Our case is even more complex as there is a translation also added to the mix. This is why we DON'T apply the separate animations to the same mesh groups, but link the animations in a parent-child cascade that only moves the visible mesh groups through all the transformations in the last child.

• The parent1 animation defines the steering rotation of the wheel (rotate left or right). This is applied to an invisible dummy mesh group as we just want the rotation transformation.
• The parent2 animation defines the wheel travel (translate up or down) and is a child of parent1. This is also applied to an invisible dummy mesh group as we just want the translation transformation.
• The final animation defines the wheel rotation about its axis, which is a child of parent2, which is a child of parent1. It is only this last animation that moves the visible wheel mesh groups through all three transformations.

You should be able to define the animation transformations in any order (i.e. put the wheel rotation as parent1, steering rotation as parent2, etc..) and so long as they are linked in this parent-child cascade and the visible mesh groups are only moved in the last child the motion should be correct. The parent-child linking should permit commuting of the transformations as they are rotating and translating the mesh group local coordinate system.

 

[Urwumpe]

I am not even sure, if the order really doesn't matter. The order also defines the outcome of the animation. As such, I would recommend you to use the following order:

1. Wheel travel
2. Steering rotation
3. Wheel rotation

This way, you don't need the implicit assumption that the axis of steering rotation is parallel to the direction of wheel travel. (And of course, this assumes still a very simple model).

 

[Thunder Chicken]

I am not even sure, if the order really doesn't matter. The order also defines the outcome of the animation. As such, I would recommend you to use the following order:

1. Wheel travel
2. Steering rotation
3. Wheel rotation

This way, you don't need the implicit assumption that the axis of steering rotation is parallel to the direction of wheel travel. (And of course, this assumes still a very simple model).

The order does not matter so long as the parent-child linking is established. You are transforming the mesh group coordinate system, not just the vertices. The vertices are just along for the ride, so to speak. This is why it is necessary to not transform the visible mesh vertices until the end of the parent-child chain.

The order does matter if you transform the vertices once, then transform them again using the same coordinate system.

 

[Urwumpe]

The order does not matter so long as the parent-child linking is established. You are transforming the mesh group coordinate system, not just the vertices. The vertices are just along for the ride, so to speak. This is why it is necessary to not transform the visible mesh vertices until the end of the parent-child chain.

The order does matter if you transform the vertices once, then transform them again using the same coordinate system.

I think you either use a language that I can't fully understand (not impossible at all) or have a different understanding of affine transformations (which should be highely unlikely).

Of course, the reference vectors of the child animations are transformed during parent-child animations too. If you apply multiple animations without parent-child relations on the same meshgroup, any further animations act weird, that are not using the neutral vector of the previous animations, if it exists at all.

 

[Thunder Chicken]

Of course, the reference vectors of the child animations are transformed during parent-child animations too.

That's the critical distinction. The reference vector defines the coordinate system used for a given transformation. If you link a series of parent-child animations/transformations, they transform the coordinate system as well. If you provide the target mesh groups at the end of the series, it basically relocates the mesh group into the final transformed coordinate system. The x, y, z coordinates of the mesh vertices would be identical to those in the mesh file, but they are located in the final transformed coordinate system, not in vessel coordinates.

If you apply multiple animations without parent-child relations on the same meshgroup, any further animations act weird, that are not using the neutral vector of the previous animations, if it exists at all.

Exactly.

It's easy enough to test - you can just go into my VW Thing code and change the order of one of the front wheel's parent animations and compare it to the other wheel. The order makes no difference if you do the parent-child linking because you are also transforming the coordinate systems.

 

[Thunder Chicken]

One thing that I did discover is that the initial state of the animations does affect the behavior of even the parent-child animations. For example, if you define an animation like this:

anim_right_front_wheel_rotation = vi:create_animation(0)

This basically says that the item to be animated is in its neutral state in the mesh vessel coordinates.

But if you define the animation like this:

anim_right_front_wheel_steer = vi:create_animation(0.5)

This basically says that the item to be animated is not in its neutral state in the mesh vessel coordinates. This seems to affect the orientation of the local coordinate system being transformed, and you get some wonky behavior even with parent-child linking as you are adding a spurious "transformation" when the animation is created like this.

I think the fix would be to set the animation state to 0 for all animations on creation, and then define the range of the animation around 0, then the parent-child linking should behave as expected (and order still shouldn't matter). I did some quick testing and this seems to be so, but I need to look harder at this.

 

[Thunder Chicken]

Yep, that seems to be the issue.

When creating the animations, anything that goes into the parent-child chain of animations needs to have its state initialized to 0 for the reference vectors in the transformations to behave as expected. I suppose that makes sense, because the first transformation starts with the mesh vertices in vessel coordinates.

Once this is done, the order of the animations in the parent-child chain does not matter, so long as they are parent-child linked and aren't just sequential.

 

[Matias Saibene]

After a long time away from this module/project, I finally picked it up again.

I ran into a lot of problems implementing three animations on a wheel. So, to escape development hell and move forward with other aspects, I decided to only implement the wheel rotation.

I'm releasing a version (alpha or beta, I'm not even sure) for you to test. So far, the problem I've encountered is that in the Windows scenarios, the cars are launched off Earth. So I have to fix that. Therefore, the scenarios don't work on Windows, but they work perfectly on Linux.

I haven't finished writing the documentation yet, but when you add a UCFO vehicle to the scenario, on-screen help is displayed.

Releases here: https://github.com/MatiasSaibene/UniversalCarsForOrbiter/releases/tag/2025

 

[JMW]

Therefore, the scenarios don't work on Windows, but they work perfectly on Linux.

I'm getting ctd on launch, is that what you expect on windows, or should it start but throw the car into space?

OK, so it's meant for 2024 I was trying it on 2016.
On a very quick test --
Not getting any interstellar launching. Stays firm on the runway.... (Windows 10)
Steering needs a bit of work tho. Wanders left/right.
But nice little addon

 

[Matias Saibene]

I'm getting ctd on launch, is that what you expect on windows, or should it start but throw the car into space?

OK, so it's meant for 2024 I was trying it on 2016.
Not getting any interstellar launching. Stays firm on the runway.... (Windows 10)
Steering needs a bit of work tho. Wanders left/right.
But nice little addon

Thank you very much for trying it. And yes it is true, a lot of work still needs to be done, namely:

-Improve handling.
-Add more animations.
-Add more car models.
-Test UACS support more extensively.
-And even more.

I'm really glad it works correctly on Windows 10, apparently TouchdownPoints are a bit glitchy on Windows 11. I'll have to find out.
I have to organize myself better with the free time I have available since I have several projects in progress (Orbiter and outside of Orbiter as well) and I don't want to keep the community waiting for a long time.

Again, thank you very much for trying it!

 

[N_Molson]

I'm really glad it works correctly on Windows 10, apparently TouchdownPoints are a bit glitchy on Windows 11. I'll have to find out.

Are you sure it is not a problem related to the suspension parameters ? These are very touchy, and you need values that make sense from the physics standpoint (it is, after all, a simulator). Else, yes, stuff like interstellar launching may happen.

 

[Matias Saibene]

Are you sure it is not a problem related to the suspension parameters ? These are very touchy, and you need values that make sense from the physics standpoint (it is, after all, a simulator). Else, yes, stuff like interstellar launching may happen.

As far as I remember, I adapted the Touchdown Points calculation system from @Thunder Chicken VW Thing. It worked fine in Lua, but it might be different in C++.

 

[Thunder Chicken]

As far as I remember, I adapted the Touchdown Points calculation system from @Thunder Chicken VW Thing. It worked fine in Lua, but it might be different in C++.

I would hope that there is nothing algorithmically different between Lua and C++ that would cause these problems.

It is more or less a standard spring/damper model. If the stiffness is too high and the damping too low it is possible to get a natural frequency that is faster than the integrator timestep, which can lead to numerical instabilities. I generally tried to ensure something close to critical damping to avoid this for the main wheels.