Problem exporting airplane_generic_sp lights

[kucoman]

Hi.
I am finding an unexpected situation while exporting lights with:
Build with Blender 2.79 (sub 0) (build b'5bd8ac9abfa'). Exported with XPlane2Blender 3.5.0-rc.1+40.20181016150257

The same lamp object with same parameters is exported with different rotation if the type of light is changed from airplane_landing_sp to airplane_generic_sp. In the first case the result is what would be expected, but in the second case the light is rotated in an unexpected way.

Attached are the Blender file and the result OBJ file.

Am I missing something?
Or maybe is one of those work in progress issues related to lights?

test-lights.zip

[tngreene]

I deleted this long response about how airplane_generic_sp and airplane_landing_sp were different because I was actually wrong. The difference came from a bug that got fixed

Good news! Upon some very careful debugging, I've come to realize that there is a problem with the implementation of this feature! airplane_generic_sp shouldn't be getting autocorrected at all! Thank you for bring this up, it is very useful. Some details of how to work around it may follow.

Github saves the old content, but, I won't stand by it and disown it and figure it might not be better to have it up to save confusion.

In the time between now and that qouted reply I had also forgotten that named lights and param lights don't use the light's RGB color. Only Custom, and the old Default and some of the deprecated lights use that. Sorry future readers!

[kucoman]

I see. I had missed this piece of information.
I have been going around this for a while and I am still getting strange results. This is what I get when exporting a duplicated lamp just changing the R G B values in the parameter box.

ANIM_begin
ANIM_rotate -0.62537205 0.76327485 -0.16223861 129.04283687 129.04283687
LIGHT_PARAM airplane_generic_sp -0.99277997 -6.74318123 -5.78887177 1 1 1 0 400 0.85
ANIM_end

ANIM_begin
ANIM_rotate 0.1740277 0.96322191 -0.2047385 129.30851871 129.30851871
LIGHT_PARAM airplane_generic_sp -7.13129663 -4.14505482 -3.45402288 1 0 1 0 400 0.85
ANIM_end

As expected, according to what is explained above, direction of the rotation vector changes. But the color values are changed too (not reset to [1,1,1]), while W parameter is not affected, which I understand is not expected.

It might be my lack of experience with this.
Can you give me a hint on what I am doing wrong?
Thanks!

test-lights-02.zip

[tngreene]

You'll have to forgive me, you might be the first person to ask about this since it was developed.

In the .blend file you gave me, you have "generic_light_sp.003" using the light airplane_generic_sp and "landing_light_sp.001" also using the light airplane_generic_sp. Is this a mistake or just some poorly chosen names or something else? In addition the color is the same for both of them.

[kucoman]

You are right. The naming is not relevant to this problem and was overlooked when recycling the previous file as an example. They are intended to be of the same type (airplane_generic_sp) to make the comparison effective.

About the color, if you mean the color of the Blender lamp, then it is the same. In the explanation you posted above I interpreted "RGB" values as the values of R G B in the parameter's field (XPlaneLampSettings.params)

Following the indications at
https://developer.x-plane.com/article/airplane-parameterized-light-guide/

And interpreting the signature of that field as:
airplane_generic_sp R G B INDEX SIZE W

The behavior that I am observing is that changing thos R G B values, the color of the light changes, but also the direction baked by the script.

Is this the expected result in this case?

[tngreene]

Good news! Upon some very careful debugging, I've come to realize that there is a problem with the implementation of this feature! airplane_generic_sp shouldn't be getting autocorrected at all! Thank you for bring this up, it is very useful. Some details of how to work around it may follow.

[tngreene]

Using this build, I think the bug is fixed.
io_xplane2blender_3_5_0-dev_0-47_20190221191339.zip tell me what you think

[kucoman]

I run the export of the latest test case, using the provided link version, with identical results.
See attached obj:
test-lights-02-with-fix.zip

I have found other light names that present what could be the same problem. I have not made a test-case for each and every one of them, but found unexpected results of similar type.

These types are exported with unexpected baked rotations:

• airplane_generic_sp
• airplane_strobe_dir
• airplane_nav_left_size
• airplane_nav_right_size
• airplane_nav_tail_size

This type had issues with the size of the cone:

• airplane_landing_core. Size of vector should control the cone angle, but unexpected results are obtained.

[tngreene]

I'm surprised you're saying generic_sp is still having issues. I really thought that that build I linked fixed it. If that is having trouble, is landing_sp also having trouble?

I'm also surprised by all these lights you've listed. To be clear, none of them have _sw callbacks (including airplane_generic_sp as of several days ago in the build above)

I guess I should also ask what you mean by unexpected (basic question I know). The point of the feature is that where you point the light in Blender is where the light will be pointing in X-Plane no matter. Period.

Can you post a side by screenshot of Blender and the result in X-Plane?

[kucoman]

I'm surprised you're saying generic_sp is still having issues. I really thought that that build I linked fixed it. If that is having trouble, is landing_sp also having trouble?

airplane_landing_sp is working fine. That is why I was confused in the first report. But you clarified that they were different, so my last question was comparing the airplane_generic_sp with itself, just changing the RGB parameters. As can be seen in the attached obj, exported with 3.5.0-dev, the baked rotations differ.
I am still unsure if this is something I am doing wrong, or a normal behavior.

I'm also surprised by all these lights you've listed. To be clear, none of them have _sw callbacks (including airplane_generic_sp as of several days ago in the build above)

I understand I need to provide some specifics. I was hoping the airplane_generic_sp case would clarify something before going into detail. These cases are even harder to test, because with the spills at least you can see the projection of the light, which with the billboards you cannot.

I guess I should also ask what you mean by unexpected (basic question I know). The point of the feature is that where you point the light in Blender is where the light will be pointing in X-Plane no matter. Period.

Where I speak about the rotation of the lights, unexpected means the baked rotation does not match the correct rotation as seen in the blender lamp.
In the specific test-case, that identical lamps are exported with different rotations just by changing RGB parameters.

Can you post a side by screenshot of Blender and the result in X-Plane?

Here a visual example:
The setup, based on one of the taxi lights:

The expected result:

Changing the type to generic_sp, maintaining the rest of the parameters. Rotation changes:

Changing the RGB values from 1 1 1 to 0 1 1. Color and rotation change:

All this done with the last version: 3.5.0-dev

Any ideas?

[tngreene]

Can you share the last line of the OBJ being used in those screenshots?

[kucoman]

Sure. Here:

Build with Blender 2.79 (sub 0) (build b'5bd8ac9abfa'). Exported with XPlane2Blender 3.5.0-dev.0+47.20190221191339

Attached is the obj itself, for the last case:
MD-11-exterior-19.obj.zip

It only has two lights:

• An airplane_nav_sp which is working fine. (Edit: not seen in the screenshots)
• An airplane_generic_sp which is the problematic.

By the way, thanks for taking the time to look into this. I know that lights+rotation problems is always a nasty combination...

[tngreene]

I've tried so summarize this bug so far here:

Problem 1

Set up: 2 airplane_generic_sp lights, rotation = (90, 0, 90), colors = (Blue, Red)
Are they baked the same for me? Yes

Set up: 2 airplane_generic_sp lights, rotation = (78, 0, 0), colors = (Green, Purple)
Are they baked the same for me? Yes

Problem 2

Set up: 2 airplane_landing_sp lights, rotation = (90, 0, 90), colors = (Blue, Red)
Are they baked the same for me? Yes

Set up: 2 airplane_landing_sp lights, rotation = (78, 0, 0), colors = (Blue, Red)
Are they baked the same for me? Yes

Problem 3

When comparing the lights from Problem 2 and 3, do they have the same baked rotation? Yes

Problem 4

So, as it turns out, you have helped discover some bugs in XPlane2Blender and problems in X-Plane! Thank you! It turns out several software callbacks were being applied when they shouldn't. After yet another pass of what is applicable, and what isn't, here are some answers about the specific lights you asked about.

• airplane_strobe_dir?

airplane_strobe_dir is completely brain dead stupid - Ben Supnik

When Laminar Research Artists use this they set RGB to 0 0 0 and aim the light with X Y Z. RGB can be used for aiming under specific and stupid circumstances that aren't worth mentioning.

• airplane_nav_left_size, airplane_nav_right_size, airplane_nav_tail_size, airplane_landing_core?
  We have been auto-correcting this when we shouldn't have. Try it with this new build

io_xplane2blender_3_5_0-dev_0-41_20190325184329.zip

[kucoman]

I'll try that link.
But just to be on the same page, when you say:

colors = (Blue, Red)

Do you mean the color of the blender lamp, or the RGB components in the "Parameters" box?
Or in other words, can you share the relevant info of the lamp to compare with mine?

Thanks.

[tngreene]

Good catch. I mean (I made a blue colored lamp and a red colored lamp using the Parameters box). As has been said, the parameters lights only get their coloration from RGB parameters or the contents of the lights.txt file.

[kucoman]

Thanks for looking into this.
This last version nails it. I have exported all the problematic lights successfully, except for one case. It is however a very minor problem, as it only affects the nav billboards, and is easily worked around by setting the cone to 360º, which is the typical configuration for this effect anyway.

I'll leave my observations here in case they are helpful:
The thing is I am still having an issue with the airplane_nav_left_size / airplane_nav_right_size lights. I have attached a test case, but in short: these named lights are exported with different results, with only changing the type from one to the other.
test-lights-03.zip

In this case, the ANIM_rotate command is baked with the same results, as expected, but some of the parameters, which I understand are interpreted as the direction vector XYZ by X-Plane, are exported with differences:

LIGHT_PARAM airplane_nav_left_size -11.52632523 0.04237811 -47.38787079 5 0.99
LIGHT_PARAM airplane_nav_right_size -47.25687408 0.04237285 -11.99319649 5 0.99

The result of this is that lights modeled in Blender with the same direction, are oriented differently in X-Plane. However, I am still not sure if this is a problem of the exported data or a problem of how X-Plane is interpreting it.

Any thoughts?

[tngreene]

So glad it was solved.

airplane_nav_left/right_size always points left or right. The FOCUS parameter changes when you start seeing the light, only from directly to the side or a little forward or backward. It isn't a real rotation, however. Only a visible effect. That's why you're unable to aim them like this.

See "Navigation Positional Lights" at Airplane Parameterized Light Guide for more details