[sldev] Alpha Blending Settings Included in Texture Metadata

[Ricky]

Maybe this should be handled at the applied surface, instead of at the
texture?  If done at the prim surface, then it can be applied by object
designers using old textures.  Textures would not have to be re-uploaded
just to contain the new new information.  Existing objects would remain as
they are, and new objects can choose to keep the old (and default) value, or
select one of the new options.

This might, or might not, be relate-able to
http://jira.secondlife.com/browse/VWR-7689 "Selectable blending modes for
the texture color"  This JIRA entry is about the color information, but I do
not know how close the underlying data-structures and code are.

Just an idea or two,
Ricky
aka Cron Stardust.

On Thu, Jan 15, 2009 at 8:50 PM, nivardus <nivardus at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090115/38485a14/attachment.htm