I'm working on a patch that would essentially add image blending options to a texture's JPEG2000 metadata. Specifically, I'd like textures to carry their own alpha blending information: to switch between blending and masking (like linden trees, so that it'd be possible for residents to make transparent textures that sort correctly.) This would essentially be an implementation of this jira issue: http://jira.secondlife.com/browse/VWR-6713 Qarl Linden even mentioned in a comment that there is even a LL internal jira entry for the same thing.
I'd like some input as to whether to include a simple boolean value that'd be toggled during texture upload (Uploader can pick to have a texture rendered with default settings, or masked with 0.5 alpha reject settings), or adding more texture parameters for greater flexibility (Resident picks from a selection of blend types, alpha comparison functions and correlating values) I tend to lean in favor of allowing the deeper functionality to be usable, so someone could play around with his textures' alpha reject settings, seeing the more opaque areas stay while the more transparent ones are cut away. But are there any risks I'm unaware of? How kosher would including the blending value's native types into LLImageJ2CImpl (llimagejp2c.h) and it's child classes be? (Including llrender.h) Or should that be done at a higher level like at LLImageJ2C::encode()? Datatypes in question: LLRender::eBlendType LLRender::eCompareFunc F32 value for above alpha rejection compare function Any feedback/suggestions/warnings about the idea would be appreciated. Toodles, Gonta Maltz
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
