separate rigging/compositing

Discuss ideas for new features with other users. To submit feature requests to Smith Micro, please visit support.smithmicro.com

Moderators: Víctor Paredes, Belgarath, slowtiger

User avatar
Manu
Posts: 325
Joined: Tue Aug 03, 2004 10:11 pm
Contact:

separate rigging/compositing

Post by Manu »

I think I have mentioned this before, but not as a separate post.

I always felt that AS Pro should separate the rigging from the compositing part of a scene. At the moment, both these things live inside the Layers palette.

It's true that in most cases there is a lot of overlap in the logic the way things are composited and the way they're rigged, but this is about when things get a bit more complicated than that. For instance:

- Masking is awkward at the moment, lots of people struggle with it, and it's hard to see how you could make the controls for more straightforward in the current interface. Every time I find myself thinking of ways of improving the masking in AS, I always bump into that combined layer/rigging logic.

- Animatable layer ordering is great, but you can't animate a layer going outside a group. It's easy to see why, if layers started moving outside bone-groups, the whole thing would fall apart. Again, I can't help but feeling that this combined layer palette is the thing that's holding this feature a bit back.

I'm not going to dwell on for too long. It's just my gut-feeling that if those two things lived in their own world, it would really open up a lot of possibilities that most of us haven't even thought of.
User avatar
Víctor Paredes
Site Admin
Posts: 5646
Joined: Wed Jan 26, 2005 12:18 am
Location: Barcelona/Chile
Contact:

Post by Víctor Paredes »

I totally agree.
when Mike presented the new layer reordering feature I was a little disappointed.
it's useful, but for masking and rigging the new feature doesn't help too much.

things so simple as two guys giving a hug each other becomes a nightmare.

I think we just need a two different tabs in layer window. one for rigging and configure the project, and other to animate the layers order in time.
the characters hierarchy can't be limiting the animation.
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

I am trying to see this in my head, how does this sound...

Option 1:
A bone layer is not dependent on what is inside it. Each bone is "assigned" a layer (anywhere in the entire layer palette) AND how that layer is controlled (bound or flexible).

You could have the parts of two characters set up anyway you like and the parent skeleton for just that character would still work.

Or..

Option 2:
Animated layer order is not dependent on... anything. Any layer anywhere can be "moved" anywhere in the hierarchy. EDIT: The layer palette would not change. this would be a "separate" layer order for animation only. Layers controlled by bones would still be inside that bone layer but their "visual" order would be independent of the "rigging".

------

Option 1 might be done with a script. It would be tricky though.

Option 2 has to be a program feature. It couldn't be done with scripting. It might be as simple as changing z-depth so it works OUTSIDE of group layers. If you could do THAT it would be absolutely AMAZING.

Two characters in separate bone layers... change the z-depth of certain layers in each character and you can "mix" those characters to "interact" like a hug or embrace.

---------

p.s. In order for Mike/SM to consider a feature this big you need to explain it's process in detail. Write a tutorial as if the feature existed. Show exactly how it should work step by step so there is no fuzzy areas. Everything should be clearly stated.

I was working with Hash on their web based 3D viewer and made some offhand suggestions about features and Martin told me to write a "case study" and they would consider it. I wrote a couple of case studies that included "fake" screen grabs and step by step instructions.

It was amazing how clear the problems were when you had to write a "tutorial" for a non-existent feature. You get to a spot.. and suddenly you are stuck and have to start from the beginning and rethink things. For instance above I realizeed after writing the two options they are very similar. I also noticed that the second option was just like using z-depth except it works OUTSIDE of group layers.

Programming isn't like being an "artist" where you can make changes at any time with a brush stroke or the mouse... you need very detailed steps of how things should work.

If you create a case study like this it makes the programmers job "easier"... not easy... just easier.

-vern
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Post by Rhoel »

The alternative would be to have a virtual clone layer, which could be moved anywhere. on the layers, including nesting inside another group. The character would still be rigged and animated inside the bone/group layer, but a new virtual clone "token" is positioned higher in the stack to indicate the render order.

I'll need to mock up a screen grab to explain this better.

Rhoel
Genete
Posts: 3483
Joined: Tue Oct 17, 2006 3:27 pm
Location: España / Spain

Post by Genete »

I think that all that can be solved if you could weld points between layers. That would involve be able to select more than one layer at the same time.
The skeleton just move a non visual part (wireframe) and the visual part (remotely welded) move with the points of the skeleton. The visual part can be layer ordered inside a group folder etc.
Something close to Rhoel idea.
User avatar
Manu
Posts: 325
Joined: Tue Aug 03, 2004 10:11 pm
Contact:

Post by Manu »

heyvern wrote: Option 1:
A bone layer is not dependent on what is inside it. Each bone is "assigned" a layer (anywhere in the entire layer palette) AND how that layer is controlled (bound or flexible).

You could have the parts of two characters set up anyway you like and the parent skeleton for just that character would still work.
Well, I wasn't trying to be too specific about how this should be implemented, more like starting a dialogue and see how others feel about this.

But after I wrote this post I had roughly the same idea:

1. Keep rigs/skeletons as objects on heir own layer as it is now.

2. You can drop vector/bitmap layers inside them and they'll get rigged straightaway. In other words, exactly the way it is now (=backwards compatibility)

3. But you also have the option to assign any vector/bitmap layer(s) to that Bone layer via a drag and drop interface. You'd end up with all the vector/bitmap layers outside the bone layers of your project. Your could arrange your project so that all the Bone layers sit on top (they wouldn't show up at rendertime anyway) and all the vector/bitmap layers underneath where they can be moved up and down throughout an animation.
User avatar
Manu
Posts: 325
Joined: Tue Aug 03, 2004 10:11 pm
Contact:

Post by Manu »

Genete wrote:I think that all that can be solved if you could weld points between layers. That would involve be able to select more than one layer at the same time.
The skeleton just move a non visual part (wireframe) and the visual part (remotely welded) move with the points of the skeleton. The visual part can be layer ordered inside a group folder etc.
Something close to Rhoel idea.
That's pretty much how Animo 1.7 used to work. Fills and strokes (visual elements) would be living in their own palette where you could animate the layer order. Vectors and bones (construction elements) would have no business with layer ordering.

The only thing I would say is that this would be a very big departure of how things are done in AS at the moment. There is always legacy to deal with.
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Manu wrote:The only thing I would say is that this would be a very big departure of how things are done in AS at the moment. There is always legacy to deal with.
That is another issue with some of the more... complex solutions. In order for the programmer or distributor to get a return on the huge investment of adding a feature it needs to be balanced with how much work is involved and how long it would take.

I lean towards a simpler solution that doesn't require a total reworking of AS to achieve something close to what is desired. Having the ability to connect points across layers would basically... be a a total rewrite of the application. It would probably involve more changes and possible bugs than the end result is worth for selling the product.

You have to consider the amount of time and effort ($$$) required. If it will require a lot of work but isn't going to add a huge benefit to the program it isn't likely to be done.

If however it is something "simple" to do but adds tremendous benefits (z-depth outside of folders for instance) it has more potential.

Look at some of the main new features that Mike added "on his own":

Animated layer order
That could almost have been done using scripting. Changing layer order is a part of the program already. Just add a new channel to "store" those changes as keys.

Image Texture Bone warping
Once again, bone warping of image layers is already part of the program. This "simple" feature expands an existing feature in a different way. He didn't have to "reinvent the wheel" so to speak.

-------

I really like the idea of being able to use z-depth ordering OUTSIDE of folders. This would not be a perfect solution but in my humble opinion should be "easier" to add to AS than any of the other solutions and this would still be a killer new feature... a really powerful one (there are issues though with folders and masking I hadn't thought of before which could be a problem).

I also had thought of the "virtual layer" idea that Rhoel came up with as well. Two separate palettes, one for rigging one for animation. This would be one of those big tough programming challenges, requiring a new palette, "dual" time lines (does the rigging time line change during animation or is it ignored etc).

I kind of scratched that idea because it has the potential to be "confusing". Imagine if you are working on one palette by mistake or get them mixed up. Of course if it is implemented well it could work great.

p.s. I love this feature idea... I think you guys are correct that the rigging and animation are "mixed" and dependent on each other in a "bad" way and could be improved.

-vern
User avatar
Manu
Posts: 325
Joined: Tue Aug 03, 2004 10:11 pm
Contact:

Post by Manu »

I guess I'm thinking of added features, not replacement ones. If I find the time, I'll try and do a mock-up over the weekend. Unless someone can explain to me what a case-study involves.

So far I'm thinking of:

- Allowing for rigging outside the folder system

- Allowing for masking outside the folder system
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

A case study for a new feature in an application like this (based on my limited experience) is really just a tutorial.

You create a step by step tutorial of the feature you want:
1. Open the rigging layer palette.
2. Set up your layers and bone groups.
3. Open the Animation layer palette.
4. Create a proxy layer by clicking the "New Proxy Group Layer" button.
5. Drag layers from the Rigging Layer palette into the Proxy Group layer you just created...

etc... etc...
Fake screen grabs could be created to add to the visual explanation. This not only helps the programmer it can also help to create the best solution for what you want the new feature to do.

-vern
User avatar
synthsin75
Posts: 9935
Joined: Mon Jan 14, 2008 11:20 pm
Location: Oklahoma
Contact:

Post by synthsin75 »

While separate construction curves and fill/outlines sounds nice, I think that unifying the construction curve systems (i.e. vectors and bones) would be easier to implement. I'm working on a technique that would accomplish much of what you're looking for. With some tool improvements, I may have a feasible workaround. Once I have developed a few examples, I'll post it.
User avatar
Manu
Posts: 325
Joined: Tue Aug 03, 2004 10:11 pm
Contact:

Post by Manu »

Well, seeing how Mike has returned amongst the faithful, I thought it would be a good occasion to return to this topic. After all, I said I was going to make a mock-up. So here it finally is:

my idea of separating rigging from compositing (or layer-ordering)

I didn't look into masking.

I tried to stem my enthusiasm when describing my idea, every idea you have leads to a next one. But I tried to keep it focused on one aspect only.
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Great job Manu! It's easy to understand and makes sense. I couldn't see that in my head clearly without the pictures. I can almost imagine how this might work in the AS file format. There would be another property of the layer/mesh. A bone layer ID. It wouldn't even go beyond that really.

This new layer property would tell AS to use THAT bone layer to be the "parent" of the layer. Everything else would work the same. Of course this would still require major modification to the application but some of the scripting experiments with "mesh instancing" and transfering bone motion to layers outside of the bone layer has already done something similar.

-----

I have a question though about the process regarding layers inside a bone layer and assigned to a bone layer. You don't want this to happen "at the same time" right? That would be kind of cool but there could be conflicts with bone IDs.

-vern
User avatar
Manu
Posts: 325
Joined: Tue Aug 03, 2004 10:11 pm
Contact:

Post by Manu »

heyvern wrote:I have a question though about the process regarding layers inside a bone layer and assigned to a bone layer. You don't want this to happen "at the same time" right? That would be kind of cool but there could be conflicts with bone IDs.
Lots of 3D packages allow for several competing rigs to control the same mesh, often with a system of sliders that decides which rig has how much percentage influence over the mesh. Quite frankly, it gets very complex. Not very Moho-like.

I imagine that an artwork layer either:

- is the child of a bone-layer and behaves exactly the way it behaves at the moment. The assign tool I'm proposing doesn't work on them.

- sits outside the controlling bone-layer. In which case you just need to take a few extra steps to assign it to the controlling bone-layer.

On a more technical note. Don't bone ID's carry the ID of the layer as well? I have never looked at the innards of Moho so I'm just asking.

I have been playing with Applescript + Adobe Illustrator lately and to address a vector-shape on a given layer, I would have to write something like: shape 1 of layer 7 of document 1 of application "illustrator". So even though several layers will have a "shape 1" in them, they can still be told apart.
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Bone IDs are independent of the layer... or... well... the bones don't "care" what the layer is since you can't target bones in other layers. The layer ID is irrelevant to a bone.

For instance let's imagine you have two bone layers that have the same number of bones and you have a vector layer in one of those bone layers with points bound to specific bones.

Now if you drag that vector layer to the other bone layer the points remain bound to the same bones in the new layer. the bone IDs are the same for both layers even though it is a different bone layer.

However there is a "user element" with in AS scripting that represents a "unique" layer identification. This internal "layer ID" could be used somehow to uniquely identify a specific layer.

Actually, AS scripting "almost" has the ability to do this right now. I've just never had the patience to figure it out. It would involve a lot of tricky coding with matrices and blah blah blah... too much hassle.

The trick with your concept is that it works very well with the existing functionality of the program. If the SCRIPT INTERFACE in AS were just expanded so the bone influence of a layer NOT SELECTED could be "transfered" or applied to ANY other layer this it would be a piece of cake.

The script interface has a bone influence matrix... sort of. It is the points influenced by the bones in a bone layer. Right now it isn't very fun or easy to use, if however that bone layer "matrix" could be "grabbed" and applied to another layer this could be scripted. It might not even need to be a "new feature".

I keep saying, more script access would allow for more features that Mike doesn't have to be involved with.

-vern
Post Reply