Comments on: More Aircraft RFCs – Landing Lights https:/2008/12/more-aircraft-rfcs-landing-lights/ Developer resources for the X-Plane flight simulator Tue, 01 Feb 2011 18:52:23 +0000 hourly 1 https://wordpress.org/?v=6.6.1 By: Anonymous https:/2008/12/more-aircraft-rfcs-landing-lights/#comment-867 Thu, 18 Dec 2008 18:09:00 +0000 http://www.x-plane.com/dev_blog/?p=267#comment-867 Hi Ben,
Any chance you could elaborate a little on the use of datarefs to manipulate custom lights? I checked the obj8 specs but couldn’t quite make out how it works.

Thanks /Nils

]]>
By: Benjamin Supnik https:/2008/12/more-aircraft-rfcs-landing-lights/#comment-868 Thu, 18 Dec 2008 13:21:00 +0000 http://www.x-plane.com/dev_blog/?p=267#comment-868 sim/graphics/animation/lights/airplane/landing_light in your dataref, alpha is interpretted as an index and RGB is ignored.) <br /><br />This technique would be what you want - a high level interface described in modeling terms, no code.<br /><br />2. Lower level, any plugin can also provide datarefs with these types of functionality..if I don't think of the algorithm, maybe someone else will - they can add them too.<br /><br />3. And of course, a specific plugin for a specific plane can contain an algorithm that is very heavily tailored to that plane. <br /><br />I hope that made some sense...the main points are:<br />- Lights are built on top of the plugin system.<br />- Anyone (x-plane or plugin) can provide the code algorithms.<br />- The code algorithm can remap the custom light params from low to high level.<br /><br />Finally re: plugins - I agree that authors are not programmers and probably won't become programmers (but both case 1 and 2 do not require programming). <br /><br />I do not agree about the breakability of plugins, and thus I do not agree that plugins should not be the foundation of lights because they are breakable.<br /><br />Final note to any programmers reading this: I realize there are two useful datarefs missing - I will put them on my 930 todo list!<br /><br />* Some named lights are custom lights inside, and some are hardware accelerated, mapped directly to pixel shaders.]]> It’s not that those properties don’t exist – it’s that custom lights provide a lower level interface than those properties. Those properties must be simulated and mapped to the actual graphics interface, which is what the custom dataref system provides.

That mapping happens through a dataref. So there must be some code doing that mapping.

The code can come from X-Plane, or it can come from a plugin.

Consider how the airport landing light works: the named light is internally implemented as a custom light*. That custom light in turn uses a dataref provided by X-Plane.

That dataref transforms the light alpha property to the landing light index (e.g. light 0, light 1, etc.) and also directly queries the aircraft for how right the light is. Finally the dataref does the math to make the light get dimmer when off-angle.

(Remember: all datarefs are really code in a plugin…x-plane can act like a plugin too.)

This scheme can be replicated in planes in basically three ways:

1. LR can provide datarefs that provide useful mappings – these REDEFINE the meanings of the light params to provide a higher level abstraction.

(Note that when you use sim/graphics/animation/lights/airplane/landing_light in your dataref, alpha is interpretted as an index and RGB is ignored.)

This technique would be what you want – a high level interface described in modeling terms, no code.

2. Lower level, any plugin can also provide datarefs with these types of functionality..if I don’t think of the algorithm, maybe someone else will – they can add them too.

3. And of course, a specific plugin for a specific plane can contain an algorithm that is very heavily tailored to that plane.

I hope that made some sense…the main points are:
– Lights are built on top of the plugin system.
– Anyone (x-plane or plugin) can provide the code algorithms.
– The code algorithm can remap the custom light params from low to high level.

Finally re: plugins – I agree that authors are not programmers and probably won’t become programmers (but both case 1 and 2 do not require programming).

I do not agree about the breakability of plugins, and thus I do not agree that plugins should not be the foundation of lights because they are breakable.

Final note to any programmers reading this: I realize there are two useful datarefs missing – I will put them on my 930 todo list!

* Some named lights are custom lights inside, and some are hardware accelerated, mapped directly to pixel shaders.

]]>
By: Anonymous https:/2008/12/more-aircraft-rfcs-landing-lights/#comment-869 Thu, 18 Dec 2008 11:59:00 +0000 http://www.x-plane.com/dev_blog/?p=267#comment-869 Indeed Custom Lights are useful but they appear to be missing some key user definable elements, namely:

Vertical beam width
Horizontal beam width
Heading x&z;
Some form of focus to define visibility over distance, and hence ability to combine or define the appearance out of the focal beam. (airport beacon-esque properties?)
Always on or day night

Most of the above would be welcome on many named lights too. (tail and port/starboard nav lights).

Add to the above check boxes to define Global illumination abilities in whatever from becomes deemed acceptable.

Plugins are for most an investment in time leaning to code beyond acceptable… easily broken and easily able to break XP… When a script compiler with the ease of use of Automator arrives I'm sure they will take off. Personally I avoid all plugins except from the most trusted authors, through experience of the mess they can create.

Named lights:

Formation lights. blue, white, and Electroluminescent(EL) panels

Directional taxi lights (yellow and green) for custom taxiway use such as helicopter hover taxi ways.

Ground vehicle beacons red yellow and blue (we define when to hide them).

I'm sure there are many more.

]]>
By: Benjamin Supnik https:/2008/12/more-aircraft-rfcs-landing-lights/#comment-870 Wed, 17 Dec 2008 20:15:00 +0000 http://www.x-plane.com/dev_blog/?p=267#comment-870 Anon — some of these customizations are possible now via a combination of:

– Show/hide animation to tie the light to the on-off switch and
– Custom lights interacting with the existing animation datarefs for special behaviors. (You tune the look using textures.)

This second technique is a little bit complex because the datarefs are, um, under-documented.

Of course with a plugin quite literally ANYTHING is possible, because the plugin can adjust all lighting parameters.

Finally, if there are fairly standard (but not available) lights, e.g. a lighting strobe pattern or light used in a wide variety of aircraft, feature-suggest it to me, and maybe I can make a “named light” for it. This would give you an easy way to attach the lights – having a wide list of named lights is not a problem!

]]>
By: Anonymous https:/2008/12/more-aircraft-rfcs-landing-lights/#comment-871 Wed, 17 Dec 2008 16:03:00 +0000 http://www.x-plane.com/dev_blog/?p=267#comment-871 Steps towards control are always welcome. So far however in respects to 3D objets on acf’s and lights, a need to better customisation of halo size, direction of view, LOD, and colour of the other navigation lights and scenery lights in general, would seem desirable?

I’m not entirely clear as to what is possible…

I’m thinking vintage nav lights, formation lights, narrow beam tail lights, Xenon search lights, yellow beacons, Light houses, naval navigation marker lights, user controlled brightness on taxi lights, custom airport lights, and the list goes on…

]]>