Also, I hope the direction you are going (shaders lighting) will continue to be exploited to further improve the environmental lighting model. Small changes in the lighting model can have huge effects on the realism of the scene.

It’s fixed? I disagree! Since you can animate moving parts, pre-baked lighting may not be adequate for the 3-d cockpit. I have seen a number of autopilot dash boards done in complete 3-d (that is, every knob is 3-d).

Computationally more expensive: maybe…but it’s not using the same resource. 2-d lighting in its current design uses the CPU, something we don’t have a lot of (and spend a bit of in a high-batch-count object like a 3-d cockpit). Per-pixel lighting uses shaders, which would otherwise be unused if we use a trivially simple 3-d lighting and pre-bake everything.

Finally, I come back to the issue of textures…a lighting system that only lets the author affect the panel tex is very limiting (and encourages the author to make HUGE panel textures, which is very expensive). And doing 2-d lighting calcs on the object texture would add another big cost.

The trend in graphics hardware is to deliver more and more pixel power – CPUs aren’t growing as fast, nor is bus bandwidth…in this context I think it makes sense to use shaders to shade a 3-d cockpit.

/ben

We expect the 3-d panel to start to support more and more real 3-d lighting – this is already partly possible in that you can get directional lighting on ALL surfaces (including the panel texture) using ATTR_cockpit_region.

As we add more features to this, we won’t want to allow both 2-d lighting baked in and 3-d lighting, taking a hardware hit with both features; authors will be expected to light 3-d cockpits only using 3-d lights.

From a practical perspective, I don’t think this kind of feature will be that useful for 3-d cockpits in that I’ve seen quite a few where the panel tex and obj tex are heavily intermixed – with these effects only on the panel tex, they’d be applied unevenly to geometry.