Limitations of Animated Sculpties?

This is not something I urgently need, but I've been wondering about this for a long time and thought I'd ask.

How smooth can animated sculpties be made? Is there a limitation to how many 'frames' you can use? I personally only own a bird that has one animated sculpt. The movement doesn't look that smooth, but it's sufficient for that particular item. Apart that, I've seen animation on other sculpted animals, but again it didn't look very fluid. I also saw (though only on video) these bouncing breasts that, from a technical point of view, looked very impressive. I'm just wondering if this means it's dependent on how many 'frames' the creator is willing to upload? (On the other hand, the breasts were a much simpler shape than the animals, so maybe that's a factor as well.)

I have this project in mind that I might want to make sometime, but it would be greatly helped by the use of animated sculpted prims. Your thoughts on the subject would be much appreciated

Iv'e made a lot of sculpted, animated curtains among other things.

I have used just 5 or 6 images for a curtain pair. I mirror the second curtain to literally halve the number of images needed.
Using <1 second between "frames".
Always, on the first run, 5 balls pass by. Second run, 5 messy sculpts or maybe one or two that are still balls.

By the third or fourth run, the first and last have fully rezzed and another run before all have fully rezzed.

If I go away and do something else. The above is repeated. It's completely annoying.

For a visitor who drops in, it is repeated for them. It's a mess for a couple of runs uless you sit on each frame until it's fully loaded before moving to the next. That can take 30 seconds for each sculpt sometimes for some people. Some even longer.

The way around this is to have every sculpt image visible and loaded from the get-go.

I do it with a prism, cut so when flattened, 5 faces can be viewed at once. I turn transparency to 95% and stick it somewhere that the visitors' viewer will "see" and load before the sculpt anim is run. SO, when the anim is run, it runs smoothly and everybody is none-the-wiser.

So for a flowing sculpted animation, 25 images are needed for every second. But it's not guaranteed as the viewer can throw away parts at any time. You can just turn you cam away for a few seconds and back.

For the creator it always works fantastic because they have watched, and loaded it many times. For the casual visitor/viewer, their mileage will vary depending on network speed and machine age/configuration.

It is certainly possible too, to use a movie file via media settings but this is limiting.
There are other ways as well if you run servers. But the viewer will dispose of images in the cache. It doesn't keep everything.

Thanks for your input

I guess it wouldn't be wise then to do something with more than 1 fps. If I ever go forward with that project, I'll just have to test and see what is feasible. I wish flexi sculpted prims would be part of the main viewer already. Those would eliminate the need for animated sculpts in at least a few cases.

I try to stay away from animated sculpties, it is a very bad trend. I'd only use it for mission critical effects, but never for casual stuff like creatures. They have an adverse effect on simulators, it is quite similiar actually to a few techniques that griefers use to lag down sims, constantly refreshing a prim shape. I once did a stress test in a full sim with a 5x5 grid of animated rippling-water sculpties and brought it down to 0.8~ time dilation quickly.

I didn't realize it was such a strain on simulators
Something else I'll need to test I suppose. If it really is that bad, I won't use it.

actually i've come up with a way of creating a smooth sculpted animation that does not lag at all since it is client side
and once it loads it stays loaded

I guess some of us are curious to know the trick
Would you mind to give us a hint ?

Image each block was a different shape: http://dominodesigns.info/node/89 to make the animation frames. Then use transparency on the texture to only show 1 block at a time.

Ahhh of course. I imagine that'd become a bit messy when using tons of frames, but it's better than rezzing the sculpts each time.

yes, this is how it is done So far i've only expeirmented with 16 frames.

This implies that the visible shape has got only a fraction of the available faces. Assuming each frame contains the same amount of faces, that would give me a resolution of approximately 1024/n faces per frame (for n different frames)... Is that correct ?

Yes

i'm not sure what you mean by a fraction of the faces.

As i understand the technique, at any time part of the sculpty is hidden. So not all of the sculpty-faces are visible. Thus the visible sculpty uses only a fraction of the available faces. I asked this because i was not entirely sure if i understood the technique, but i guess now i do

i still don't understand as i see the whole sculpt when one frame is visible

Ok, then i either have not understood it at all, or you make it different from what Domino described, as he allready wrote, that his solution would only show a part of the sculptmesh at any time (since the use of alpha-transparency effectively hides faces).

But when you can see the whole mesh (1024 faces) in every frame, then you are not hiding faces and alpha-transparency is not the trick you use, or you use a not so apparent trick... And now i am totally confused

That's not what Domino means either, I think.

The way it works is: an animation consists of different frames. For example when you squeeze a ball, frame 1 is the ball perfectly round, last frame is the ball squished. To animate sculpties in SL, you have to upload different sculpts which represent the object at different frames. However, to go through these frames in-world, you would have to have the sculpts load one after another, over and over, to simulate animation. What Hikaru (and I think Domino as well) is suggesting is keeping all the sculpts/different frames rezzed, but making them visible one by one. This reduces the lag caused by constantly re-rezzing sculpts.

Sculpts don't have faces in-world by the way. They are essentially distorted spheres and are treated like that for texturing as well.

To be precise, they have just one 'face' as far as texturing is concerned*, but they have 2048 triangular 'faces' that define their shape (at highest LOD)(have a look in wireframe mode). The angles between these can be acute, but the shading assumes they are smooth, which leads to shading artefacts on anglar sculpties unless this is explicitly avoided (see Gaia's link below).

*in the sense of the 'face' parameter to llSetTexture ... that is to say there is only one distinct 'face' so that only one texture can be applied, stretched (with possible repeats) over the whole sculpted surface.

If a sculpty has got only one face concerning texturing then how does vertex lighting work in SL ? I have been looking at that recently and it appears to me that there are as many texture faces as there are shape faces. I.e. 2048 triangles as you said...

http://blog.machinimatrix.org/sidenode-on-vertex-lighting-in-sl/

Please can you explain in a little more detail, how that all relates to each other ?

So now i understand that there is a small difference between what Domino suggests and what you suggest:

Your and Hikaru's technique is to place n sculpts (at one location), make all but one invisible and then flip through the stack by replacing the alpha textures with the visible textures periodically.

Domino's technique would essentially do the same, but use only one single sculpt and using a fraction of the vertices on each frame...

Domino's technique would be for ultimate efficiency where lag is concerned and smoothness is top priority as it is entirely client-side and doesn't involve many repeated llSetLinkAlpha calls.

Anya/Hikarus' technique is most suitable if coordination/synchronization is required with other animated prims and/or agents.

Although llSetTextureAnim can be well synchronized just as well if done correctly.

By "...as far as texturing..." I mean the number of faces in the sense understood of the "face" parameter of llSetTexture...where, for example, a cube has six faces each of which can have a different texture, but a sculpty has only one. I will edit the post to clarify that. Thanks for the excellent link, by the way, which explains the technique for dealing with the shading problem.

I don't mind it being called "Domino's technique" in this thread for clarity, but it's not something I came up with. I don't know who first used this method, but anyone trying to come up with a technique to fit that description should end up at the same place. There's only a couple of "client side" effects to choose from after all

That's where the miscommunication started for me in this thread, as I consider a 'face' to be a side of a regular SL prim.

I'm confused then about Domino's technique though
How can you animate a sculpt by only showing part of it at any given time? Animation means the sculpt changes, so I don't understand how you can animate by using only one sculpt shape.

You use a subset of the 1024 quads, defined by the sculpt map, to make the nth shape for each frame. With a normal texture, you see the shapes all on top of each other. Then you make a large texture, consisting of n panels for n frames, where each panel is transparent except for the part of the map that falls on the quads of the nth shape in the map. When you apply llSetTextureAnim, it scans through the the panels so that for each scan frame only one of the piled-up shapes is non-transparent. (It works. I tried it after reading the idea here). The key is understanding that the sculpt map is also the UV map for the sculpt, defining what part of the texture is applies to which parts of the surface.