Request for top 10 Anime Studio Pro Version 6 Features

[DK]

This idea was bought up in another thread but would be a fantastic tool to incorporate in the next version of AS if possible:

Imagine a tool or set of tools that could spear through all the layers of a character and manipulate the points directly rather than having to open up all Switch layers and sub folders to tweek .... Very time saving.

Cheers
D.K

[GCharb]

Hello all.

Okay, made a small Wink presentation which I hope will shed some light on what I have in mind for that "Tweak Tool"

Tweaktool.zip 806 kb

GC

[Genete]

Making accessible all the layers (and its vectors shapes) to the root folder would allow to do the "tweak tool". So you need something kind of tool that can select shapes, points and bones and manipulate all them in one single tool.

1) Make all the layers/shapes/points/bones accessible to the root folder
2) One single tool for shapes, points and bones.

Yes I want that too.

-G

[Víctor Paredes]

1. Fix arm/leg flexations. Absolutely number one, número uno, note that there are TONS of workarounds on this site about this very thing, meaning it's not done right. But the bottom line is we ALL want a limb to maintain volume as it's bent, and it should be possible to do this without jumping through hoops.

3D programs allow you to define cross sections -- I don't know why something similar couldn't be attempted, where you define the sections of the limb as the two bones change angles. But we need this more than we need almost anything else.

I never tought this... you are right, this would avoid a lot of work, and doesn't seem to be very hard to implement.

[heyvern]

1. Fix arm/leg flexations. Absolutely number one, número uno, note that there are TONS of workarounds on this site about this very thing, meaning it's not done right. But the bottom line is we ALL want a limb to maintain volume as it's bent, and it should be possible to do this without jumping through hoops.

3D programs allow you to define cross sections -- I don't know why something similar couldn't be attempted, where you define the sections of the limb as the two bones change angles. But we need this more than we need almost anything else.

I don't know exactly how this can be "fixed". What would the "fix" be? What's broken? I don't understand the "cross section" part. I only ask so that Mike can understand better a possible proposed solution. I don't know of any real "fix" for this in any 3D software. You still have to create the solutions yourself using existing tools in the application to change the volume of the shape as the bone bends. We need to come up with a good description of this new feature so Mike knows what needs to be done. I can guarantee you he is more likely to look at a feature request that is well defined.

I've tried to come up with possible "new feature" solutions:

One thought that might work is something that Animation Master has. "Poses" that are "activated" when a bone reaches a certain angle. For instance if the bone passes a certain max angle the points move a specific distance to maintain volume.

Another issue is the "pivot" point deformation. If there were a way to link bone rotation to the point curve value so that those inner bends get more "pointy". This has been my focus on my own bone constraint solutions. This might fall into some kind of bone constraint feature.

Maybe an option that can be clicked on a bone to "expand" the "base" of the bone a certain amount to increase the volume of that section of the bone.

Yes, this is a needed "fix" but there is no clear direction or solution that can be programmed like magic. It needs a clears solution as to what should happen. every joint is different. Not every joint needs this fix so it can't be "automatic". It also needs to vary in amount for different shapes and types of characters.

-vern

[chucky]

Re :Fix arm/leg flexations,
Is what you are a after a solver or expression feature ,something like :
if forearm rotates then elbow fan bone lengthens by x amount per radian?

This could be added to the constraints menu perhaps ,
bone rotation controls bone length.

This kind of feature could add automatic muscle bulge and such.


Add a lag offset with positive or negative values and you've got some real magic,

I might even hang some dynamic jiggle bones off that rig just to be a smart arse, yeehaa.

[Dodgy]

Lightwave has a joint bulge control which bulges points closer to the joint away from the joint when it bends, thus controlling the thickness of the bulge. It's scalable so you can increase or decrease it to suit.

[synthsin75]

Yeah, Chucky's example of cross-constraints is the solution I'd want. That would provide solutions to much more than one problem. Rotation controls scale, rotation controls translation, translation controls rotation, translation controls scale, scale controls rotation, and scale controls translation.

Some of those already exist with parenting, multi-bone rig, or script. But it would be much more flexible as an actual feature.

[jeff]

My first wish is for a proper implementation of motion curves – something that has been discussed several times over the years. The default curves that the program at present offers always try to smooth actions, which is not always what an animator wants.

The second wish is for far greater control over timing. For example, I would like to grab all the timelines associated with one character or element and nudge them back or forwards in time without having to tediously pick through all the related timelines looking for the keys that need to be altered. This would also apply to the sound time line.

Lastly - a generalisation and hopefully a wish that is not unrealisable: as far as is possible, it would be a major step forward if every single element were able to generate key frames and be alterable over time. Some are now handled this way (line thickness for instance) but others aren't, such as animated noise values and centres of rotation.

Looking way beyond the next release, (I'm thinking years), I'd love to see the program evolve beyond its cut-out roots and adopt the aim of eventually becoming an all-round 2D animation program – something that would rival Toon Boom, After Effects, Celaction, the late Animo, TVPaint and so on. And, yes, I would be prepared to pay far more for a version of the program that becomes a universal 2D (2.5D?) animation tool. I think there is agreement in this forum that AS can look Flash right in the eye without flinching. I am sure it has the potential, given time, to go a lot further and square up to other animation software!

Jeff G.

[mkelley]

Yep, Chucky's got it -- that will work (and add a lot of functionality).

Vern, you've got a definite blind spot when it comes to this, and I'm not sure why. There are all KINDS of things that are "automated" in AS, and making this possible is not only desirable but *highly* desirable, as witnessed by the dozens and dozens of threads on this topic (I'd guess offhand it's one of the most asked questions about AS).

You can't automate art, but you sure can automate basic deformations, and AS does start that process. But like with any 3D program I've ever used (and I've used them all) deformations need to be far more controllable than they are now. That's all I'm asking.

[heyvern]

Yep, Chucky's got it -- that will work (and add a lot of functionality).

Vern, you've got a definite blind spot when it comes to this, and I'm not sure why. There are all KINDS of things that are "automated" in AS, and making this possible is not only desirable but *highly* desirable, as witnessed by the dozens and dozens of threads on this topic (I'd guess offhand it's one of the most asked questions about AS).

You can't automate art, but you sure can automate basic deformations, and AS does start that process. But like with any 3D program I've ever used (and I've used them all) deformations need to be far more controllable than they are now. That's all I'm asking.

I agree with you 100%. I understand the issue and I don't have a "blind spot" . I could say the same about everyone asking for new features. Thee is a blind spot as to how these features get created. I know what the problem is with joint volume but there are a bazillion possible solutions. I want the feature as well but without a description of a solution Mike has to "make one up" or spend effort to come up with the steps needed and it might not be the best one. It will be more work if he doesn't know the steps to make it work in AS.

------

For instance the rotation/length constraint solution that Chucky illustrated.

That's a very general bone constraint feature that has absolutely nothing to do with maintaining volume in a joint. It could be used for dozens of different things, like head rotations. Also that length change bone bulge effect can be done right now easily using rotation constraints and rotation limits. So why create a complex new feature when the same thing can be done now with the existing tools?

Better yet, what about a new feature to give bones scaling on the X axis? Wouldn't that be better? Two of my feature requests are very simple, X scaling on bones and key framed constraints. With those two (and script access) then a joint that maintains volume is very easy to do. With X scaling and adjusting bone size you could do the volume solution with one bone.

However having a joint/volume solution IN the application and simple to use would be 100% better. That TOO is one of my requests, open up the script interface so we can add "global" features that don't require layer scripts. A feature that has an impact beyond the update.

Or the joint "bulge" feature mentioned for Lightwave? How would that work in AS? How would the program know which points to "bulge"? Do you select them and click a button? Is it based on some sort of "envelope" on the bone like the strength but different? Would this be a special tool?

You need to do more than say "it works like that feature in Lightwave". It's like the joke we have over at Animation Master forum... the "Make Dragon Button". That joke has been around for years.

--------

If a program has a feature it had to be "designed" ahead of time. The programmer doesn't type code "on the fly" to get that result. The programmer has to know EXACTLY what is going to happen from step 1 to step 2. You don't make it up as you go along. You have to have a process defined in ADVANCE of creating the feature. Any process has to be adapted to the existing code.

The more explanation and description for a feature the better. My only suggestion was to do more than say "fix joint bending to maintain volume". It's way too vague.

Someone could spend weeks/months creating detailed descriptions of how all of these feature requests would work in the application. they are all fantastic suggestions but some are very vague in functionality. When the request is vague or too general, it isn't going to entice Mike to do all the work needed.

One of my goals is to come up with relatively small "simple" feature requests that fit into existing categories and are simple to explain; lua, bone constraints, etc. These simple features are key to creating these other more complicated features. So if there IS a rotation/length bone constraint I know in my head I can create a joint that maintains volume.

-----------

I want to hear the steps of these features as they might be done now using scripting or done better later using improvements to scripting.

Remember one thing, Once this new version is out don't expect any more new features for a very long time. The more small simple scripting, interface access and bone constraint features Mike adds to AS the more features people like me can create later. Some you guys may not have even thought of. Would you rather have one new feature that does one thing or a new feature that has the potential to do a dozen things?

------

I'm not suggesting these features aren't good or needed, I'm merely suggesting that you give a possible description of how the feature works.

-vern

[mkelley]

Better yet, what about a new feature to give bones scaling on the X axis? Wouldn't that be better? Two of my feature requests are very simple, X scaling on bones and key framed constraints. With those two (and script access) then a joint that maintains volume is very easy to do. With X scaling and adjusting bone size you could do the volume solution with one bone.

However having a joint/volume solution IN the application and simple to use would be 100% better. That TOO is one of my requests, open up the script interface so we can add "global" features that don't require layer scripts. A feature that has an impact beyond the update.

I'm not sure how bone X scaling (which I want as well) could handle the bulge issue as elegantly as the one shown by Chucky -- because the volume at the joint wouldn't be handled with one bone (unless you're saying X scaling at either end of the bone -- I do like that but so far Mike hasn't given us anything other than symmetrical bone scaling).

I'm not sure we agree or disagree when it comes to providing Mike with "solutions" as to how things should be implemented. People seem to understand pretty well what is meant by "maintain joint volume" and thus how it's actually implemented doesn't matter all that much. Could I tell Mike the math on how to do this? Unlikely. And does that discount the fact that Mike himself may have better ideas on how to do this than I ever could? Extremely likely.

If I were programming it I'd probably do something with sliding the vertices along either side of a joint up along and away from the joint, with the user specifying exactly how small the section at that joint could deform. That's what I meant by specifying cross-sections (which we do in 3D applications). For any given joint you have the ability to tell the app how close together the vertices on either side can collapse and if this is done along all the joints then the sliding of the vertices between these joints "bulges" upward. So I guess what I'm saying is that I would provide a "joint" functionality that "knows" some things (such things could be specified, like bone strength, via a visual slider, or perhaps typed in as bone constraints and other parameters are typed in).

This kind of attribute (a "joint" attribute) does exist in *some* 3D programs. It requires two or more bones and, as you would imagine, is always one less than the number of bones in any solution or rig (three bones, two joints). A joint can "know" the angle of the bones which comprises it, and can do things dependent upon that angle, which I guess is exposed to your programming and thus can do different things in scripts and such.

But I'm no graphics programmer -- that's merely the way I'd approach it and I don't know that suggesting it actually helps Mike or merely confuses the issue.

[heyvern]

I'm not sure how bone X scaling (which I want as well) could handle the bulge issue as elegantly as the one shown by Chucky -- because the volume at the joint wouldn't be handled with one bone (unless you're saying X scaling at either end of the bone -- I do like that but so far Mike hasn't given us anything other than symmetrical bone scaling).

The X/Y scaled bone could be "offset" from the bending bone. This would allow for moving points "up" and "out" from the joint as you describe.

People seem to understand pretty well what is meant by "maintain joint volume" and thus how it's actually implemented doesn't matter all that much.

That IS my point. Everyone has a different idea as to how this should work but some might not understand it. Mike would have to create that solution. Invent it from scratch.

But I'm no graphics programmer -- that's merely the way I'd approach it and I don't know that suggesting it actually helps Mike or merely confuses the issue.

You are not a programmer. Neither am I. But you DO know how to use a program like AS. You push the buttons, you select menus etc. You don't have to know how to program to explain how you want a feature to work.

Those who create tutorials don't understand how the program was created but we know the steps involved to create a file or show how a feature is used. All that is needed is a clear description of how a NEW feature would be implemented.

You have already come up with several ways to do this. Which one is the best one? If WE come up with a clear solution without actually programming it then Mike has something to go on for implementing it.

-vern

[mkelley]

The X/Y scaled bone could be "offset" from the bending bone. This would allow for moving points "up" and "out" from the joint as you describe.-vern

Yes, but you suggested this could be done with one bone and that's not true -- what you really meant to say was this could be done with one additional bone.

And even that's not true -- how does that bone "know" how to scale? Right now with your bone rig (that three bone "thingee" at the bone joint) you can automagically get the volume deformation by typing in a whole lot of value and assigning vertices. I don't want to have to do this in any way shape or form. Or to run a script that does this. Or to say this another way -- I can already do this. IOW, I don't want a solution that's as complicated as what I already have to do. I want something simple enough to be able to tell my wife how to do it <g>.

Which is why I think that specifying volumes in some manner is likely the easiest solution... but that may not be the best by far. And while it's certain there is something to be said in requesting very specific features implemented in very specific ways, as a programmer (which I am, but not a graphics one) I do know that it's not always best that my users tell me how something should be implemented, but rather *what* they want me to implement.

IOW -- a programmer really does know best at times, and I suspect that Mike not only understands the request to maintain joint volume but has some perfectly good ideas on how to do it that us specifying some other ways is not a Good Thing. We might tell him how to do it in such a manner it will keep him from doing it far better and easier, just in order to (supposedly) make us happy.

So -- I'm sticking with my original request. If Mike does need more details about it (maintaining joint volume) then I'm sure he can ask you/me/us and we'll be glad to provide them. But I have a huge hunch he's *way* ahead of us in all of this (he must have been reading this forum for quite some time and seen all these requests for proper joint deformation a long, long time ago).

[heyvern]

The X/Y scaled bone could be "offset" from the bending bone. This would allow for moving points "up" and "out" from the joint as you describe.-vern

Yes, but you suggested this could be done with one bone and that's not true -- what you really meant to say was this could be done with one additional bone.

Don't split hairs! I'm thinking out loud here. If you want the feature come up with the process. Supposing mike had already gone down that road you described and THEN realized it wouldn't work? That's my point. Without a clear path for the programmer it is twice as hard.

Check out this really fantastic description of a new feature that Manu did a while back:
http://www.funnylittlemen.co.uk/as_feat ... rom_layer/

From this topic/discussion:
viewtopic.php?t=10938

That is EXACTLY what I'm talking about. It doesn't have to be complex. It just needs to show the logical steps so a programmer can recreate it. Many applications are designed by creating "fake" point and click "movies" that just simulate the process before any major programming is done.

This information is what I received from the creator of Animation Master, Martin Hash. The original programmer. I asked for "vague" features for something and he said;

"do a case study Vern. Create a tutorial for the features as if they existed."

He is very vocal about users begging for new features... like the "Create Dragon" button. They don't know what's involved. The more input we give up front the more likely the feature will be implemented.

Best advice I ever got. I believe they actually used part of my case study to implement those features. All I did was create fake screen grabs of the dialog boxes and settings to check. What happened when you clicked that button or entered values in a text box. It is of incredible value to programmers to see what the USERS WANT and how they expect it to work.

If you like I will do a case study for this feature and post it so you can see how this works.

-vern