Limitations of Animated Sculpties?

By the way, does anyone know if there is (going to be) an oblong map exporter for AC3D? Oblongs are much more amenable to the one-prim animation technique.

Ok, that I'm following, I think. I've made little animated movies before to put inside TVs I'd sculpted, which basically requires the same principle. I'd put all the frames in one texture and let the script run through them.

I don't understand what you mean by "using subset of the 1024 quads, defined by the sculpt map, to make the nth shape for each frame" and "where each panel is transparent except for the part of the map that falls on the quads of the nth shape in the map". Err what do you mean by nth by the way?

Yeah, that's a better name

You could always use Blender to bake your oblongs. I've added .obj support to the "Import - Second Life Sculptie" routine in 0.9.x, as long as the UV map is correct it automatically assigns the correct image size for the bake.

0, 1, 2, 3, 4, .... n

so n could be 0, 1, 2 all the way up to how ever many frames there are.

So say * is a 3 frame sculptie. 0 \ 1 | and 2 /

so we see a spinning bar as n goes 0, 1, 2

It can be more complicated than that, as you aren't limited to nice even frames. You can define exactly which modelling faces show for each frame by the transparency. So for something like a balloon that the avatar can blow up, you might use less faces for the uninflated balloon than you do for the last frame when it's full size. The neck of the balloon could even be the same faces across all the frames.

Hmm ok, now I get it I think. I got the animation part, because I've done that before like I said, but I didn't understand why you were involving transparency.

But for example, when only the top part of a sculpt is moving during an animation, you could input one complete sculptmap in the larger 'sculptmap texture' you're making and for the following frames only make the part that's moving visible? So there's less stuff reloading?

But the basic principle is flipping through sculptmaps that you put in one big texture right? (Sorry if I'm sounding daft here, but I still don't really see why it has to be more complicated than that.)

Yes. The alpha channel of the texture for a basic 4 frame one prim animated sculptie (maybe that's a bit long a name ) would look like this:

With the visible squares being the sculptmaps of the individual 'frames'? Why do they have to be cascading? Why can't they just be next to and below each other in rows and columns?

Yes

I used a 4 x 1 layout so it's clear what's happening. I could have used a 2 x 2 if that's what you mean.

Of course this technique does have some impact on lag due to the extra texture space needed. I'm on a portable so texture lag is noticable to me, often before other types. So like most cool stuff in SL, use with moderation

Yep, that's what I mean. Just found it confusing, cuz I thought it had to be like that for some reason. I have a little script to set the rows and columns, which is how I did the TV anims (20 frames: 5 rows, 4 columns). Just wasn't sure if that was all there is to it for sculpt animation, as it appeared more complicated from your explanation.

Thanks for clarifying

And indeed best to not go crazy with it I suppose, though it would be tempting. Considering a sculptmap is 64x64 pixels and the maximum SL texture size 1024x1024, you could in theory do a LOT of frames.

Just to see if we are all talking about the same thing, tell me if this is wrong ....

It is not the sculpt map itself that is animated (alas this would be much better but is not implemented), but the texture that is applied to the surface of the sculpt defined by the map. The arrangement of transparency in successive frames of the animated texture hides different parts of the surface (by making them transparent) as each frame is applied. Appropriately arranged, this gives the impression that some or all of the sculpty surface is moving.

I still don't see what transparency has to do with it.

As far as I understand it, you just put your sculpt maps in one big texture, in different rows and columns, and then use a script to run through them. (You tell the script how many rows and columns there are, so it can 'find' the different sculpt maps/frames.)

This technique is used for simple texture animation as well. You put the frames of your movie next to and below one another and use the script to run through them. (I animated the little TV in my signature this way.)

I presume you are talking about llSetTextureAnim here? That can only be used to animate the surface-applied texture, not the sculpt map. If that's wrong, and you have some other way, I would be very interested in seeing the script. The ability to use an equivalent function for the sculpt map, say llSetSculptAnim, would be highly desirable. I don't really know why it isn't there, as all the code would be the same except for the destination of the smaller bitmaps. My guess is that it's a performance issue, as the sculpty triangle list (what gets passed to opengl) would have to be completely regenerated from the new map for each new frame. That is a costly process that would be very laggy.

I'm not a scripter, and I haven't tried it, but from Domino's explanation that's what it sounded like, animating sculpts using that function? I was totally confused by the initial explanations to be honest. That's why I specifically asked if the 'frames' in his example texture were sculpt maps and if the technique meant flipping through them and the answer was yes?

I don't understand your explanation either. You're saying it's the texture on the sculpt that's being animated?

Yes. That confused me, which is why I asked for confirmation or refutatuion of my description.Exactly. I know this works ... the transparent part of each frame hides the parts if the sculpt that you don't want in that step of the animation.

The problem with replacing the whole sculpt map for each frame, whether by an llSetTextureAnim method (which can't be done (yet?)), or by fetching a different texture, is that the list of triangles, that defines the sculpted surface and is passed to opengl, has to be completely regenerated for each frame = slow and laggy.

With this method, the sculpt map does not change and the efficient client-only animation of the surface texture from frames extracted from a single large texture is fast and low-lag once the two textures have been loaded. The disadvantage is that the animation is not synchronous for all observers (like things rotated with llTargetOmega).

Ok, so an animated texture. And the different frames are different shadow maps of the sculpt as it looked animated in your 3D program? Would that really make a sculpt look animated, if its shape doesn't change?

And why make them partly transparent? If I take my example of a ball being squeezed, I don't see how adding transparency to the textures is going to help the animation. And doesn't that mean you would have to use really low resolution textures as well?

I don't know how to explain this better. I am sending you a very crude example.

Nothing to do with what anything looks like in a modelling program.

No partial transparency.

There are some completely opaque areas and some completely transparent. The surface of the sculpty is only visible where it has non-transparent texture applied to it. The transparent areas in each frame act as a masks to select which areas of the sculpty surface are hidden in each frame ... where there's opaque texture, they are visible with that texture on. Where there is transparency they are completely invisible. So you only see part of the sculpty in each frame. If the selectively visualised parts are set up appropriately, this provides the illusion of movement.

Limited resolution is indeed a problem, as with all sculpties unless the texture can be repeated.

Thanks for the sample

I see what you mean now. That sculpt is constructed in a way that, when you make certain parts transparent, you're kind of peeling off layers one by one. I was imagining just a regular sculpt, which is why the transparency made little sense to me. I've never constructed anything like that.

This is not something you could do for any kind of sculpt then, I imagine. Also, I'm not the most tech savvy sculptor. I wouldn't really know where to begin with making the right texture areas transparent.

Thanks again for being so patient and showing me what you meant. I couldn't visualize what you were saying, but it makes sense now that I've seen the sculpt. I probably won't be able to use this method, since I'll need at least a dozen or more frames at a decent resolution, but the principle is very nifty.

Sorry for any confusion, I was answering in the context of the thread, and my blocks.blend that I mentioned as an example. That has 16 separate sculpties with the UV maps all aligned across a single sculpt map - so I took the multiple sculpties on one big texture comment a different way.

Maybe it should be said, that "the 16 separate sculpties" are indeed one single sculpty which "appears" to be 16 individual objects. I have just updated my "2 in 1" video tutorial to show the basics of the used technique.

http://blog.machinimatrix.org/2009/08/14/2-in-1-multiple-objects-with-one-single-sculpty/ And i hope that this can help a bit for clearification ...

/me shrugs



Looks like 16 separate sculpties with the UV maps all aligned across a single sculpt map to me.

Isn't this totally missleading? Whatever you call it, it is made out of one single mesh of connected vertices. Even if it appears to be a set of separated objects it is not! After you bake your sculptmap you will no longer have separated meshes but one single mesh conforming to the specifications of a sculpty:

"A sculpty is a bended plane of n*m connected Quads where n*m <= 1024"

(Yes i know, in reality it is made out of triangles and the above statement is probably not a clean unambigeous definition.)

If you introduce the notation "multiple sculpties in one single sculptmap" than in my opinion this leads to complete missunderstanding and confusion about what a sculpty is. I may be wrong again here, but at least i am now massively confused

Just for clearification please: Should i rename my video from "2 objects out of one sculpty" to "2 sculpties out of one sculptmap" ?

In the context of this thread I don't think it's misleading at all. I created blocks.blend by starting with a single sculptie, which I duplicated and aligned along a larger sculpt map. There's no connecting lines between the blocks either in 3D space or on the UV map.

Sure it ends up as one sculptie, but at that point in the modelling it is what it is, 16 separate sculpties that will be baked to a single map to make one sculptie. Which then could be turned into 16 separate animation frames via transparency when it's displayed.

I think we've all been a bit unclear with our wording in this thread. The confusion for me started with Domino's link, which I couldn't really follow since I was dropped right in the middle. (And I also don't use Blender, so I couldn't look at the models.)

I don't think it's a good idea to be using the term 'sculpties' when referring to models within a 3D program. Certainly for me, knowing 3D only as far as SL goes, that term is meant for SL sculpted prims. Within a 3D program I would call them objects, NURBS primitives... 'Sculpties' is the only term used for SL sculpted prims, so I would reserve it just for there to avoid confusion.

Eventually we all came to the same realization, but I think we could've worded it better (including myself)



Like I explained above, I would definitely NOT do that. As far as SL is concerned that's 1 sculpted prim, 2 objects/shapes.

I can see how anyone not familiar with how Primstar 0.9.x works could be confused by my description. I've put a lot of effort into making it as flexible as possible, so things like combining multiple sculpties into one sculpt map, or baking one mesh to multiple sculpt maps are all possible.

A Blender object can be one or more sculpties, trying to use another term is just going to confuse matters. The distinction for me is in sculptie and sculpt map. Normally that's a one to one relationship, but Primstar lets you vary the equation by editing the UV layouts. That's all I did. I took 16 sculpties and arranged the UV layouts to bake to a single sculpt map. So it's the bake process that combines them. If then imported the sculpt map, I'd get a single sculptie with a continuous mesh and UV Layout.

Calling them something else just means that the inherent information about the UV map the sculptie term conveys is lost and I'd be dealing with far more people who thought any old mesh or shape could be baked to a sculpt map.

This statement does not imply that regular primstar users would not be confused I always thought that i would count as a regular primstar user myself but (although no longer confused by now) i am still very much concerned about your terminology.

So is it then possible with blender to create 16 low-facecount sculpties individually, each of them with its own UV-map and then combine these individual objects into one large sculptmap ? For instance would it be possible to create one torus-sculpty, duplicate it in blender, rotate the copy and then merge both objects into one sculptmap ? How would the process of "combine them into one sculptmap" look alike ? It would be a fascinating alternative to how i am doing it right now

Ok, now i understand why you came to the notation of "several sculpties into one sculptmap". But i still have the feeling that you are focussing on the technical details of the creation process here and not at the functional details of the end result:

For me the term "sculpty" is very much related to the 3D environment and less related to the creation process. Its inworld properties are clearly:

- it only needs one prim
- it only has one texture
- all contained items are strongly coupled to each other (they only can translate/rotate/scale in full synchronisation)

So my simplistic descriptive definition is something like:



Wouldn't that be a sufficient and less confusing statement ?