- We have to allow access without breaking old planes.
- There will be two distinct cases due to very different hardware.
One option (not really discussed in the RFC) is to do nothing at all. Basically I hit upon this during some routine refactoring of the shaders. The whole issue can be deferred indefinitely.
Why wait? Well, I don't believe that an incremental increase in the number of landing light halos is the future. Our end goal must be some kind of truly global illumination, hopefully without a fixed lighting budget. It may not make sense to add a bunch of complexity to the aircraft SDK only to have all of those limit become unnecessary cruft a short time later.
(I think I can hear the airport designers typing "why do the airplane designers get four lights and we get none? Give us a light or two!" My answer is: because of the fixed budget problem. We can allocate a fixed budget of lights to the user's aircraft because it is first in line - we know we either have the lights or we don't. As soon as we start putting global lights in the scenery, we have to deal with the case where we run out of global lights. For scenery I definitely want to wait on a scheme that isn't insanely resource limited!)
Programmers: yes - Dx10 hardware can do a hell of a lot more than 4 global lights. Heck - it can do a hell of a lot period! For example, it can do deferred rendering, or light pre-rendering. A true global lighting solution might not have anything to do with "let's add more global lights a few at a time."
5 comments:
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...
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!
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.
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.
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
Post a Comment