Client Side Color/Alpha Transition

Obtaining smooth color or alpha transitions on a large number of objects can be taxing. Many looped script calculations and server side updates are required. On top of that, they don't work reliably since v1.7. Rapid color changes often result in the object becoming transparent. (This is not a very reproducible bug. I have tested on half a dozen computers and also checked with other residents. Sometimes they see the object flashing when I don't and visa-versa. Reported the bug twice now.) Anyway... a far better way to do this would be to add a property to objects called transition speed. This would be a float representing the number of seconds required for a color or alpha change to take place. The details of the calculation can be handled client side reducing the number of updates required and reducing script loads. Again, I obviously don't know the details of your engine, but this should be simple enough, and would go a long way towards making SL more visually appealing. I noticed that when rezing an object, it fades in gradually, thus there is likely already some infrastructure in place to handle this.

This is a great idea Spank! Very well explained and thought out.

I would think rather than have it set as a property of the object, it might be better to have it implemented as a new LSL function instead. Modeling something similar to llSetTextureAnim, one could devise a function called, say, llSetAlphaAnim()

llSetAlphaAnim(float start, float stop, float rate);

Basically, the three parameters would inidicate the initial level of transparency, the final level of transparency, and the desired frame rate.

-----
Alternatively, is there any way you could use llSetAlphaAnim() to suit your purposes, by making multiple frames of varying alpha transparency on a single texture instead? In this way, you can have full control of the transparency of individual faces of a prim, or use SMOOTH to make the transparency appear in waves. Unless and until such a new function is created, this might be your next best alternative.

I fully support any operation which can be done almost entirely client side. Cutting down client server communication is a good thing(tm).

Make it more general...

llSetColorAnimation(integer flags, vector startColor, float startAlpha, vector endColor, float endAlpha, float seconds);

With the flags letting you specify whether the animation was smooth or stepped, looped or not, and bounced or not.

Many functions such as llSetTextureAnim actually set a property only you may not realize it. This runs client side which is why it can be so smooth. This is exactly what I'm suggesting. A property that would be handled client side (like llTargetOmega, llSetTexureAnim and llParticleSystem are) to provide smooth color or alpha transitions with only a single packet of server data sent. It doesn't require an equivalent in the object editor.

Tavis is actually right, you can do colour transitions using llSetTextureAnim() atm, it's particularly handy if you're only dealing with flat colours (ie no texture to the surface) as the frames only have to be a small size (probably only 1 pixel by 1 pixel come to think of it).

But specific functions for doing this without a texture would be nice too.

a similar issue is being discussed in a thread about moving non-physical objects smoothly.

I like SpankMe's transition property idea. It could be used to set the speed of llSetPos, llSetRot, llSetLocalRot, llSetAlpha, llSetColor, llSetScale and all their corresponding rules in llSetPrimitiveParams.

Within llSetPrimitiveParams it could also affect twist, shear, holesize, offset, revolutions, skew, cut, dimple etc etc.

As a discrete property, with its own llSetPrimitiveParams rule and/or llSet/GetTransistionSpeed functions, scripts could set it and rely on it for some truly awesome effects.

As an editable property in the build tool (assuming it is not overriden by the door script, for example) it would provide builders with a way of editing the speed at which their doors open and close, without having to understand or edit scripts. In objects that move, the builder could increase the time to simulate increased bulk in non-physical objects.

Although simple building is a good thing, I'm not sure encouraging builders to make doors without scripts is a good idea
The amount of doors out there that just open and close for anyone is quite disappointing actually, as many people buy houses hoping to be able to lock their doors. I know it's not a perfect security measure, but it's something most people want.

agreed - but what I meant wasn't doors without scripts.

I was thinking that the door prim/object still has a door script, with all its access control and ding-dong sounds etc etc, and an llSetRot (or pos, or holesize or whatever) that does the actual open and close.

What I was thinking was that if the builder gets to set the speed at which llSetRot works - he can drop the same door script into a small wooden door, as well as a massive steel city gate, but set in a higher transition time for the larger door.

Of course, like any other object property, scripts could change the value to whatever they want in cases where the scripter needs to override the builder.

I hope you mean separate transition properties for each operation, not just one global "all transitions take this long" flag.

I was thinking a separate flag for each type of transition... perhaps alpha and color could be the same flag, but flexibility is always nice. The idea of using texture animation for smooth fades just isn't practical for most textures.. it is a good idea though for situations when it will work. Just so you know... because of the way some graphics cards work, setting the texture size to one pixel isn't always a performance boost- it can actually hinder.

I don't think making doors easier for non-scripters to make is a bad thing. Besides.. if you want high function doors... just buy my Smart Doors, 49 functions! lol

Thanks for all the feedback on my idea.