Wednesday, April 22, 2009

ATTR_light_level vs. Generic Instruments

Propsman caught something: modifying the value of a batch of ATTR_light_level tris comparable [performance-wise] with toggling the state of a backlit generic instrument? Instinct tells me that you must have the latter more streamlined than the former, but maybe not?
He is right: in the current implementation, ATTR_light_level is probably a bit more expensive than using generic instruments. This may not be true in the future though.
  • The generic instrument code is pretty tight.
  • Right now ATTR_light_level sometimes has to adjust shaders, which can be expensive.
  • In the future, ATTR_light_level has the potential to be very heavily optimized, while the generic instrument code will always be CPU based.
But to put it in perspective, all instrument drawing is slow compared to scenery drawing - in the scenery world we draw 50,000 triangles of identical OpenGL state in a row, and modern cards do that very, very well.  In the panel, we have to put in a lot of CPU time to figure out how to draw each quad or tri-strip.  Fortunately you probably don't have 50,000 individually programmed flashing lights in your panel.  Heck - there's "only" 3608 datarefs published by the sim.

Perhaps other questions are important when picking ATTR_light_level vs. panel texture:
  • Which is more useful: to be able to have several variant images and variant images that are not "lights" (this is only possible by generics) or the ability to vary the light level gradually and not just have on or off (this is only possible with ATTR_light_level)?
  • Which is simpler to author given the rest of the panel?
In other words, it's all pretty "slow", but fortunately "slow" isn't that slow.  If your light has to blink, you may want to pick what looks best and is straightforward to author.


Anonymous said...

Something that currently reduces the usefulness of attr_light_level is that there are issues with _LIT textures and semi-transparency, such as white edges and completely transparent LIT_textures being drawed as opaque white. Atleast there used to be in 9.21 - forgive me, I havent had the time to experiment in 9.30.

Anyway, this poses a problem if your cockpit gauges have semi-transparent textures for glass surfaces or shadows behind needles etc.

Otherwise it's a very attractive feature for us who like all-obj panels.


Benjamin Supnik said...

Nils - 99% of the time, white edges are due to having white under the transparent part of the texture, which is a defect of Photoshop. If you find white edges AFTER fixing this, send me an OBJ that demonstrates the bug.

Anonymous said...

I've sent you an e-mail. Thanks!