The big glider project

[D-ECHO]

is there anything in the K6, which makes it not working in 2019.1.1?

last line of log file

47.81 [INFO]:flight /build/flightgear-e1iPVb/flightgear-2019.1.1/src/FDM/JSBSim/JSBSim.cxx:249: aero does not exist (you may have mis-typed the name).

That's strange. I'm using flightgear next, but this should not cause JSBSim to fail like this.

[Ysop]

No problem. Maybe I have to wait, until 2019.1.2 is ready (for Ubuntu) and make a nice clean new installation with that.
No reason to put time into single-user-problems.

[D-ECHO]

During further tests with the new shader, I noticed that it breaks rotate animations, because under high load, e.g. the ailerons now rotate around a wrong pointed. Is this something that just has to be accepted or do you by chance know any fix? On that note, can animation coordinates be adjusted run-time?

[Thorsten]

The rotations are part of the matrix stack that is applied after the vertex shader does its job. So theoretically you can construct a matrix that compensates for the vertex displacement inside the vertex shader and multiply that on top of the stack, that would fix the rotation.

In practice, computing that matrix may be... challenging.

It may in fact be easier to dispense with the rotation animation and give the shader the ability to do a rotation after the displacement has been computed.

But basically you have re-discovered the reason why a wingflex shader isn't more widely in use

On that note, can animation coordinates be adjusted run-time?

At least some of them can, but I'm not sure axis definitions fall under that heading.

[D-ECHO]

mh.... that sounds complicated, and I didn't know of this limitation before

I am afraid I am not capable of doing this at the moment.

[wlbragg]

I take it it is a small defect in the aileron and flap rotations or is really noticeable?

I suppose a wing such as the DaSH has that has no control surfaced won't be affected?

[D-ECHO]

With no moving parts there should be no problems. The defect unfortunately is pretty huge

[erik]

The rotations are part of the matrix stack that is applied after the vertex shader does its job. So theoretically you can construct a matrix that compensates for the vertex displacement inside the vertex shader and multiply that on top of the stack, that would fix the rotation.

In practice, computing that matrix may be... challenging.

After thinking about this, and if I'm understanding this correctly, you should move the object to the intersection of the circle centered at the original rotation point with the circle centered at the translated rotation point, both with a radius of the distance between them:


If the object is translated after flexing then the object would rotate neatly in place again.
In theory this would only be necessary for the up-down axis.

Erik

[Thorsten]

Sounds plausible enough (not sure if there can be hidden surprises...)

[erik]

I thought of a couple:

• It only gives you the solution for a 60 degree rotation (since it's an equal sided triangle).
• this only works for an aircraft aligned rotational vector.
• Since the wing rotates around the center-line of the aircraft you'll need to compensate for left-side displacement also.

You'll need the following additional steps:

1. Do it for the side (left-right axis) too
2. multiply the translation vector with the inverse rotation vector
3. rotate the translation vector another (60-angle) degrees using the rotation vector

Erik

[D-ECHO]

Your ideas sound very good but both undersranding and implementing this is above my capability, Im sorry.

[erik]

What I'm mostly wondering is whether all information is available to the shaders:
rotation point and rotation vector of the individual objects.

I've not messed with shaders that much myself.

Erik

[Thorsten]

What I'm mostly wondering is whether all information is available to the shaders:
rotation point and rotation vector of the individual objects.

No, it's not, because from the point of view of the shader it's all in the matrix stack, already multiplied and you can't undo that. You'd have to give the info of the animation parameters separately to the shader as uniforms (i.e. change the effect to pass more parameters).

Then you could do the required math, but I's not really fun.

As I said, it might be easier to not do the rotation as animation but inside the shader - that is in principle straightforward (and would require the same info - rotation origin, axis and angle).

[erik]

Ok clear. Then I agree with you.

Erik

[D-ECHO]

I am trying to implement the rotation inside the shader. Can someone confirm that this formular (from wikipedia https://de.wikipedia.org/wiki/Drehmatrix (de)) needs to be implemented therefor or whether there is a simpler way?