Texture manipulation functions

A post on Torley Linden's blog made me think of something that would be needed if those kind of maps were to be done via the functions I suggested on another forum thread.

Functions to manipulate textures in ways we can't currently do.


llSetTextureParams() and llGetTextureParams() // Mirroring the functionality of llSetPrimitiveParams() and llGetTextureParams();


I suggest the following:

TEXTURE_COLOR_MODE (TEXTURE_COLOR_FULL or TEXTURE_COLOR_GREYSCALE - Lethe Naumova's film noir building in Help Island would've been completed much quicker if this option existed)

TEXTURE_FILTER (multiples choice of TEXTURE_SEPIA,float amount- 0 if off, TEXTURE_EMBOSS,float amount- 0 if off,TEXTURE_GAMMA, float amount - FALSE (is switching result from float to integer allowed ?) if off, TEXTURE_SATURATION, float amount- 0.5 default) etc etc.

I'd also like to see TEXTURE_BRIGHTNESS and TEXTURE_CONTRAST, since the only way to fake those currently is to fiddle with the color.

Thoughts and comments ?

Vote on Prop 1344

Hmmm.

How about llSetFilter(integer side, integer type, vector color, vector alpha, string texture); or llSetPrimitiveParams([PARAM_FILTER,integer side,integer type,vector color,vector alpha,string texture]);. Types would be (at least) FILTER_DARKEN,FILTER_MULTIPLY,and FILTER_BUMPMAP.

Existing color, bumpmap, and alpha settings could become special cases of these.

I would say that your description of llSetFilter() should be the same as your suggestion, minus the (string) texture bit.

that would make sense if the Asset server supported dynamic asset creation.

Supplying a texture manipulation function with a key should only be done if dynamic asset creation and asset garbage collection functions/systems are put in place.

I don't totally agree with putting the color and alpha into llSetFilter(). llSetTextureParams() (with the integer side thing), llSetFilter() no.

Basically, yes.
That was just an idea for an optimization, to reduce the number of bytes per prim over the wire on objects with filters set.Why? They're equivalent in functionality, and there's a case for either.

I'm basing my opinion on the structure of functions for prims:

prim functions.

the function of llSetAlpha() and llSetColour() for prims is only duplicated in the monolithic llSetPrimitiveParams() function.

Tinting textures can be done through llSetColor(), no need for duplication to llSetFilter(), only the color mode in llSetTextureParams() in combination with llSetColor()

Applying a color or alpha using a filter isn't the same as applying a color or alpha to the prim surface. You can actually lighten the texture, or decrease the alpha.

That is, applying a color or alpha would be duplicated with some combination of parameters, but other combinations using the same color or alpha would have different effects.