[opensource-dev] Mutli-layer images (RFC)

Ricky kf6kjg at gmail.com
Sun Apr 11 23:00:45 PDT 2010

I'm not sure one way or the other on the idea, but a solution to
problem 3 is relatively easy: Just bake the layers together before
sending down to the client.  That way the rendering system wouldn't
have to change and all clients would see it as-is.  Only the owner
would need know about the layers, and then only when editing.

Cron Stardust

On Sun, Apr 11, 2010 at 8:43 PM, Robert Martin <robertltux at gmail.com> wrote:
> With all this talk over changing how clothes work i was thinking
> Why don't we code for Multi-layer images? Leave the clothing layers as
> numbered but include support for having multiple layers in a texture.
> an example of how it could work (and yes it would be very complicated
> so we may need to target 2.4 or so)
> allow for a total of 6 layers numbered 0-5 and expose to the inworld
> editor numbering from 1 (layer 0 would be a special use layer)
> as an example a shirt
> layer 5 a slogan or other image
> layer 4 a somewhat cleaner image
> layer 3 long sleeves
> layer 2 short sleeves
> layer 1 the base shirt
> layer 0 uploaders copyright data and labels for the upper layers (with
> age ratings)
> in the in-world editor allow for folks to turn off any of layers 5 4
> or 3 (assumes that the avatar is set for adult access)
> advatanges
> 1 this would allow for a huge number of new products
> 2 the control layer could be used to add in a needed flag for "Full
> perms does/does not mean export to other grids"
> 3 this would enable folks a to have a simple way to "watermark" textures
> questions/problems
> 1 this would require both changes to the server and the client
> 2 how many layers should we have??
> 3 fall back to "legacy" clients
> 4 encoding for the control layer (or is this even a sane approach??)
> --
> Robert L Martin
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

More information about the opensource-dev mailing list