Cross-fading images?

Hello,

my client wants an image viewer with crossfading, so I wonder if there are any experiences with this kind of thing here in the forum?

My thought is to create two overlapping prims, but will there be issues? I was told that the SL viewer shows artefacts if prims overlap, or ist that only a problem if they overlap 100% identically? (Ie if I had a smaller prim inside of a bigger prim, it might not be a problem?)

Maybe the prims should be 1 pixel apart, but would that still look ok?

If they are not apart, is there a way to tell whose prims texture will show on top? Ie maybe root prim shows first or something like that?

Many thanks in advance for any pointers!

Regards,


Fractality

Yeah you don't want two surfaces at exactly the same place, the textures will flash in an unpredictable manner; even an extremely small amount of offset can be problematic since the viewer loses very fine distinctions if viewed from a distance, and things start flashing again. And no it doesn't matter if one of the prims is smaller than the other; it's all about the position of the surfaces you're looking at.

What I'd do is offset one "in front of" the other by a small amount, and surround the whole thing with a frame of some type that sticks out substantially further. I bet you wouldn't even notice the small difference between the display surfaces in that case. Then you can control the crossfading by adjusting the alpha of the "front" prim, and only switch the texture on the "back" prim when it's fully obscured anyway - and only switch the texture on the "front" prim when it's at 100% alpha.

I hope that makes sense It's one of those things that's simple to visualize but not so simple to explain without a diagram.

Thanks, that was really helpful!

There are actually two different artifacts that could bite you here. One, which Anti described, is "z-flicker" and occurs when two overlapping surfaces are at (or almost at) the exact same depth in the viewer. This generates that "flashing" effect.

The other is the "alpha-sorting problem" which affects only partially transparent textures, and again arises when they overlap--but the surfaces can be very widely separated, as long as their textures both contain an alpha channel (and seemingly to a much lesser extent, transparency imposed on fully-opaque textures, as with llSetAlpha()). This generates an even weirder effect, where the rear texture will pop on top of the front one and persist until the cam moves.

If the images being cross-faded do not themselves contain an alpha channel, you may never encounter the latter problem at all, but if they ever do, you'll know what's happening. Not aware of any remedy for it, though, if it does occur.

Again thank you for the information. I wonder if it would be a sufficiently nice effect to only fade out the picture in front. That is for image switch I think about the following algorithm:

1. set current picture to front and set front Alpha-Channel to 100% (or 0%, whichever is "not transparent".
2. set next picture to "back" pane
3. start fading out picture in front.

That way only one picture would have an Alpha-Channel assigned. No remedy if the pictures themselves have an Alpha-Channel, but still.

That sounds like exactly the right approach.

I was thinking of suggesting to use just one prim, painting one of the pictures on the inside of a hollow cube, and the other on one face of the outside. But it's tricky to align the texture on that inside surface (it also has to be "flipped", and when you rescale the object, it will misalign... so unless prim-count is a major consideration, not worth the hassle.

To take that one iteration further, do you then move the two prims to physically swap them, or do you set the 'hopefully loaded' rear texture up to the front as it is now the 'current' image instead of the next. The SL viewer has a tendency to lose resolution and blur textures if anything changes, and this may lead to wierd behavior? Curious myself as I've been wondering how to do this also.

Well, I wouldn't move the prims at all, just fade in and out that front image with successive calls to llSetAlpha(), advancing the rear image while the front image was fully opaque and advancing the front image when it's fully transparent. I'm guessing that if the fade-in is slow enough, the viewer should have time to load the gradually-appearing texture while the "fuzziness" isn't very apparent, either because the loading texture is mostly alpha, or because it's masked by another texture that's mostly opaque.

If that doesn't work, there's a trick of painting the next-to-be-loaded texture on a fully transparent surface somewhere in view, to force the viewer to load it without (yet) showing it.

Yeah that does sound like it would work. I'm going to try this as well as I don't like the grey temporary state when changing photos in my viewer either.

I went ahead and implemented this and I've run into an odd issue. I have 2 different objects that I had slideshows in, so needed slight variation but the gist of it is that it worked fine in a simple picture rotater, I used linkMessages to send the images from the root prim to the child (the one fading in and out) containing the key, then locally setting texture to that key (I realize there are other ways probably to do this using setParams calls on a link number). It worked, despite the textures not existing in the linked object. I tried something similar on another device and it always failed to set the texture, as if the key was invalid.

I guess my question is,
a) can you use the key in an object not containing the texture
b) since it worked once.. I wonder if that was the object having 'once contained' those same textures and remembering the keys??

Wierd anyways.

The fade does look much better now though!

Actually, UUIDs for textures can be used anywhere, the texture doesn't have to be or have ever been in the object, you can just copy the asset ID from your Inventory and paste it into a script (or send it by llEmail() to a prim far, far away: that's usually how network vendors get their product pictures). So, something else is going wrong (my guess would be: something embarrassing like a script set not Running or just gone missing from a child prim).

Nothing to do with the trouble, but perhaps an aid in simplifying things for easier debugging: As you suspect, there is another way to set the texture of a linked prim besides sending it a link message, and it's a fairly recent addition to LSL: llSetLinkTexture(). It's kinda convenient to have everything in one script, in the root prim (as long as things don't get unlinked and relinked in the wrong order).

actually.. I don't have UUID's as its a dynamic photo list. What I was using was keys as in getInventoryKey() type keys.

Sorry for confusion: key is the same thing as UUID. If you have full perms on a texture, you can get the UUID (key) from the item in Inventory with Right-Click | Copy Asset UUID... that'll be the same as what you'll get when you call getInventoryKey() on that texture in an object's Inventory. The point being that you never actually have to copy the texture into anything if you don't want to, you can just use that key or UUID in a script. (Now... just in case this could be the snag: a call to llGetInventoryKey() won't work if the named item isn't in the object's inventory at the time of the call.)

interesting, the code is actually set so that the root object grabs the key, then linkmessages it to the front prim (also handles fading in/out via messages), which takes the key and sets its texture based on it. Thats where it doesn't work. Its hard to debug because getNameFromKey doesn't work on textures (so I read) so it always shows "". It is extremely odd primarily because one object I built works, and the other object doesn't! I cannot spot the mistakes because the code is a little different (the second object has some textures of its own, so it has to do a little skipping around to make sure it doesn't display its utility stuff as user photos).

haha, I had the tint set to black. DUH, works great now.