I see. In essence the idea is to take a condition on model coordinates to define lighting. You don't need to go via a texture for that by the way - you could do it in the fragment shader directly, define a condition on coordinates there and just use a smoothstep function for the fading of the light, we pass the model coords into the fragment shader - that gives you much smoother boundaries.
It's the sort of effect which is relatively easy and cool to get to work for one particular use case but hard to generalize.
One problem is that model coordinates often don't form a continuous set (there's a short discussion in here)
http://www.science-and-fiction.org/rend ... lsl_3.htmlrather aircraft modelers have a different zero point for an instrument, a lever or a pedal as they have for the cockpit and use translations and rotations to move things around - which go into the transformation from model to eye space, i.e. happen after you define your lighting. Same is true for scale animations. Which is probably why your yellow light works for some elements but not for others. An aircraft 3d model has to be prepared for that kind of thing.
You could do it all in eye space, but then the location of your virtual light is not so easy to get hold of, the math gets ugly quickly.
If we'd like to generalize that, we'd need a host of additional parameters and conditions in the shader to take into account all possible positions, directions, cone angles, fade properties, colors and dim properties - fairly expensive.
The conceptual advantage over the existing lightmap would be that you can move the light around in model coordinate space relatively easily - just give uniform offsets, and it will illuminate something else in the cabin. However, as I understand aircraft interior lights are typically static, so you don't need that advantage.
The conceptual advantage of the classic lightmap defined over your base texture is that you can in principle (as I said) use a raytracer to compute it and hence get all shadows and reflections pre-computed correctly - in the static case, this wins out in my opinion.
So I think if you want to go down that road you've outlined, since you clearly understand what you're doing I recommend you use a modified copy of the fragment shader (residing with your airplane) called by your derived effect (warning - this is without warranty - changes to the rendering framework FG-side may or may not leave airplane-side shaders broken or inconsistent with the rest of the scene, I don't do maintenance on such copies and in general don't encourage them for that reason...).
- Code: Select all
varying vec3 rawpos;
is gl_vertex.xyz passed into the fragment shader, you can then use rawpos.xy as plane for your ad-hoc lightmap and do for instance
- Code: Select all
float r = length(rawpos.xy);
float light_factor = 1.0 - smoothstep(0.0, 1.0, r);
to draw a circle with fading boundaries without going through a texture and without getting the pixelization you incur when doing it in the vertex shader.
Or you could do it with a classic lightmap...
Hope that helps!