WYSIWYG lights using Blender's UI for spill, custom, param lights

[danklaue]

Suggest using Blender's spot lights for this. Those parameters can be exported and translated for X-Plane's lighting usage.

For instance, -"spot shape" (in Blender) can be translated for X-Plane's spill lights, as the cone size and angle of the spill. It could also be used in X-Plane's custom lights for custom lights' W value (Width). -"Energy" (in Blender) can be translated into X-Plane's spill lights, as size parameter, or for Custom lights for the halo size. -Directionality is integrated in Blender's spot lights... it would just have to be translated to the OBJ8 lighting direction format. -An X-Plane override to attach it to brightness ratio dataref. -Translate the RGB values of the spot light for use in X-Plane.

-Leave current infrastructure as is, for backward compatibility, but use spot lights for "new" export capabilities.

[bsupnik]

Ondrej -- we should come up with some specs for this at some point; light integration -is- something that would really bring modeling forward. One of the tricky things is how Blender can know how a light works; my thinking is that we (LR) could provide more useful annotations in lights.txt so that Blender can correctly translate a named or param light, just like Blender (2.49) can use DataRefs.txt to manage animations.

[jeiting]

From what I can tell this is untouched? The exporter has basic support for param lights but you need to place one light per param and setting the spill color is not supported. I'll probably come to lights soon on the model I'm working on and maybe I'll pick this up to make my life easier.

[bsupnik]

We are planning WYSIWYG light editing including spill as the next major feature once 3-4 is finished. 3-4 will include v11 attribute support and bug fixes for animation and attributes.

[danklaue]

Up until recently, one of the parameters that controlled directionality for the "custom lights" in Blender 2.7 was the RGB value of the light in Blender. E.g. to have a custom light with a custom png billboard shine in a particular direction, let's say "forward", one would have to see the exported .obj have something like this in it:

LIGHT_CUSTOM -0.00000031 0.33022034 -0.66518688 0 0 1 1 2 0 0.5 0.5 1 sim/graphics/animation/lights/airplane_navigation_light_dir

where the "0 0 1" after the positional coordinates, according to the documentation represent RGB values (tinting of the halo texture) but actually in practice represent a directionality of the light... in this case, a light shining straight back, with not too much "focus" to the light.

If one would want this same halo to be visible from the front, one would have to change the "0 0 1" to "0 0 -1", or, if you want the cone where that halo is visible to be tighter, you'd increase the value of the last number in the negative direction , like "0 0 -7".

This used to be doable via Blender's RGB control sliders. But a recent version of Blender discontinued support to enter negative values into the RGB slots, so now the exported .obj files have to be hacked, in order to affect directionality of custom light billboards.

Now, I'm sure this'll be addressed once lights are re-vamped. Just wanted to make Ben and Ted aware of this.

[tngreene]

Up until recently, one of the parameters that controlled directionality for the "custom lights" in Blender 2.7 was the RGB value of the light in Blender...

For reference, this was resolved in #316

[tngreene]

This was brought up again in #312. The ideas brought up so far

OBJ Light Concept	Blender UI Mapping
X, Y, Z	Light Location
DX, DY, DZ	Light Spot
RGB	Light Color Picker
A	Since A is just a dimmer, not real transparency, people can just use the color picker and we always set this to 1
S, SIZE	Light Energy. It is available regardless of Lamp Type

Some common elements from lights.txt

PARAM	Blender UI Mapping
BRIGHT(see helipad_flood_sp)	Light Size again? Radius?
THROW (see heli_3_col_beacon)	?
WIDTH (see helipad_flood_sp)	?
W (aka Width)	Synonym, see above
FOCUS	?

Elements that have no Blender Mapping. The good news is that this won't actually be many (so far)

• FREQ | New property to be shown
• PHASE | New property to be shown
• DREF | New property to be shown
• INDEX | New property or it could be parsed directly from the use of DREF. I like this much better because it matches what we do with datarefs in other places like animations

Concerns

• After we pick a bunch of stuff to re-use it WONT end up being WYSIWYG because the properties with names that make sense won't line up with how X-Plane does things, or, if we start with the visual and pick the properties that make it happen, the abstractions will make even less sense or it will be impossible to map Blender's lighting model to our own.
• Any lights that are inconsistent with using Blender data
• Billboards, commonly represented with a point light, will not have the Spot Shape properties necessary
• Unnatural mappings - where Blender's Power doesn't mean brightness, but Blender's Radius does
• Some light tricks, like setting whatever makes WIDTH happen to 1.0 or 100% of whatever we pick makes it omni-directional, don't make sense

The good news is that lights don't get added often so we probably don't have to worry about having a billion new properties like how manip has them.

Either some guarantees are made about names in lights.txt and some REALLY good choices are made for a subset of common light parts, or we stick with just the basics - XYZ from location, RGB from a color picker, A is autoset to 1, DX, DY, DZ from the rotation.

The manual override for this will be going back to the old param light type.

[tngreene]

There is another issue with WYSIWYG - Blender doesn't render things the same as X-Plane. We could be making a promise we can't keep.

What You See Is Probably The Type Of Thing You'll Get :/

[tngreene]

There is also Blender 2.8 to think about. Looking casually at it now, the some of the labels and options are different between the two. I vote to move this feature to after the transition has been made.

[arb65912]

"I vote to move this feature to after the transition has been made." I think since all the hype in now on Blender 2.8 , there is a good chance it will became a standard for many so personally I would like to see transition first.

[tngreene]

Merged! 0fb061421ab269fc8

Prepare ye masses, for this awesome feature will soon be upon you in beta.2!