The Igors recently raised a very valid question.

“Why do we want to see the Initial Bind of the skin, as a visualized weight map”?

The answer is because visualizing the bind is the first step in fixing binding issues, including; errant vertices, bones influencing incorrect geometry (left thigh affecting right leg), pinching, etc.

The effect of incorrect binding is visible without the map (call it weight or strength). Just move your bones and watch the mesh tear or stretch. (See Alonzo’s recent video).

The key then, is how to fix it. The current methodology is to see the bone influence via a graphic, the weight map, and manually correct it by painting in our own desired influence.

But is this the only way to go?

The Igors have offered an idea to select areas of the mesh (vertices) that are bound in ways we do not want, then adjust the influence that they feel with a slider tool.

This idea has possibilities, but also some potential difficulties. Brian has pointed out that vertex selection is not capable within EI at this time. Also, current strength mapping is per bone, and the vertices sort themselves out by way of the painted influence.

Painted Influence maps are the modern way of addressing mesh tearing and pinching. The older way of creating “hold bones” was not effective enough.

However, this new idea, for a vertex influence tool, might be worth pursuing.

What are everyone’s thoughts?

I’m open to exploration on any new technologies & techniques, however I just want to point out that standard weight maps are implemented by nearly every 3D package out there. As long as any new technology can ultimately generate an easily editable weighting solution, and provide an exportable weight map that properly defines influence for every bone in the hierarchy, I’m interested. However a dependable weight painting system is still an important tool to have. Its considered an industry standard and we all know industry standards are both a blessing and a curse.

There are some tools for another 3D package that I like to use out there that implements a “novel” approach to dealing with unwanted binding issues called vertex exclusion sets. The user just basically highlights the offending vertices and the potential influence/joint causing the problem and tells the weighting solution to ignore or exclude these vertices from that portion of the bind. Its all well and good, but ultimately it becomes an issue of managing these exclusion sets and users must have the proper plugin installed to edit them and it all becomes a very customized solution. The point I’m trying to make is even though this technology is available, I still wind up going back to the weight painting system to really see and alter the fine details.

Right now, EI still remains a bit of an “island” on the input/output front. FBX import has opened some doors, but its not a complete solution. Solid & reliable geometry importing & exporting of objs, 3ds, and dxf files is critical along with the addition of FBX exporting capabilities out of Animator. I mention this not as another thing to point out about what’s “wrong” or “bad” with EIAS (as certain people so commonly like to accuse me of), but rather to ensure that we’re thinking ahead. If we ever want to adopt FBX exporting capabilities, standardized weight maps are a crucial part of that system. Any new system we adopt must be capable of generating weight maps for every bone in the solution. It would be nice to simply and dynamically edit them too.

I’m all for innovation...but I’m not for any potential tool that further isolates EI from the rest of the 3D community.

Another question I would have about this “slider” system would be to ask:

What kind of methodology for the initial bind would we adopt for this to operate properly? An “Always On” style initial bind or an “Event” style initial bind? Or would it be entirely and fully dynamic like Tasybear is suggesting?

Oh and just one more:

If the user selects a cluster of vertices and uses the slider to increase or decrease their influence, will there be some kind of “falloff” available to adjacent vertices? Right now with the painting paradigm that’s easy to accomplish by using a blur paint tool to smooth out the influence.... how would this new system address falloff & smoothing?

Edit: A nice painting system could also support a pressure sensitive device too.. which would be very nice to have. But the slider system? I just fear it might not seem intuitive.

Hi, Kurt, All

Actually we are not happy with how CA sub-forum is going on. It looks like “CA tools” = only one thing: “wmap painting, initial bind” etc. With only one idea in fact: “do it as it’s in maya” We’ve nothing against wmaps. we’ve nothing against “do copy” (this job is easier). But we don’t think it’s an ultimate/primary thing. IMO the workflow at vertices/facets level (that EI never had), mesh editing and other themes are at least same important.

Igors - 30 August 2008 08:02 AM

Hi, Kurt, All

Actually we are not happy with how CA sub-forum is going on. It looks like “CA tools” = only one thing: “wmap painting, initial bind” etc.

Hi Igors,

The only reason why weight maps are the forefront of these conversations is because it was only weight maps that were on the Brown UP feature list for voting.

If you want to talk about more than weighting tools and weighting issues… there’s nothing wrong with that. I just figured none of those things were even up for discussion.

Hello all,

Since everyone seems to be talking about weighting and mapping etc.. etc.. I thought I would bring up another option that seems to be forgotten.
I agree that painted maps are the “industry standard”, however, there are other weighting options that are far more elegant. In fact, EIAS already utilizes another form of weighting: deform regions. Not that they don’t have their limitations, but I do find them to have many benefits over the standard skinning setup. Bones deformers are not implemented the same way as most deforms in that they only have one region for all bones, but I still pretty much use bones deformers on any rig with any complexity. They have many benefits over painted maps in that they are not tied explicitly to geometry, they are non-destructive, their effect can be inherited, so you can layer deforms from cage resolution upward and you can use sim-cloth with them to add muscle jiggle and fat effects. (You can get subdiv and gnome export for free doing this on a single skinned rig, by the way). You can, of course, use painted maps in conjunction with them anyway, so you don’t really lose anything except ease of setup. 

The biggest changes that I would love to see regarding deformers:
allow multiple regions for bones rather than a single region
the ability to animate /control region falloff
the ability to have painted maps work in conjunction with all deformers to isolate specific deform areas
have regions that are not just boxes, but spheres with inner and outer falloff zones
have some way to visualize which verts are being controlled by a region. (such as a color change or highlight)
bring the controls for the regions into world space so you don’t have to pop back into the deform editor all the time.

In other packages this type of weighting is known as “field weighting” and it is a dream to work with. Since you can animate the regions as well as the deforms that effect them you can create very complex rigs.

Of course, I know very little about how the program works “under the hood” so I have no idea how difficult this would be to implement. It just seems to me that since regions have already been in the program since the beginning that there may be some underlying power there that hasn’t been brought to it’s full capacity.

that’s my two cents.

Hello Brian, Hello Igors,

as Alonzo (and others) have mentioned previously, Character Animation is more than just specific tools. There are features (tools) and also work flow issues which allow certain things to be achieved quickly and efficiently. Take Set Driven Keys. You can almost achieve the same thing in EI with Xpressions, but you have to be a math whiz to normalize the range. In Maya you just set an upper and lower key and you’re done. You can also go into your Driven Key’s graph and adjust it’s curve. Something you can’t do with Xpressions unless you are extremely gifted with equations.

There are also Custom Attributes which can be added to any object, Clusters, Smart Skins. Lots of work flow and features that are useful for control rigs on Mechanical objects, set pieces, effects, and more.

However, this particular thread was specifically about comparing a Paint Map work flow with the Selection/Slider Influence work flow.

Brian - I agree with you that implementing corrections and improvements to the current Influence Mapping work flow would be best. Most users are familiar with this style, it is intuitive, it plays well with other packages via FBX, and per the Igors, is easier to implement.

For the Igors - I really like your idea. Do I prefer the Slider Tool for influence over Paint? No. I feel that a Painted Map makes users more comfortable, and will become a feature in EI before the Slider Tool (which is harder to create). I do however, encourage you to experiment with this idea as time allows. Also, even though a user may ultimately be able to select vertices and adjust the influence with a slider, your code should still allow for exporting of a weight map. This will allow compatibility with solutions in other packages (FBX).

As far as other Character Tools - well this sub forum has room for many, many threads. Let’s hear everyone’s ideas!

Thanks.

Igors - 30 August 2008 08:02 AM

We’ve nothing against wmaps… But we don’t think it’s an ultimate/primary thing. IMO the workflow at vertices/facets level (that EI never had), mesh editing and other themes are at least same important.

Hi All,

IMO, any character animation that utilizes a skeletal bone hierarchy and kinematic systems to move around a character requires a stable weighting/binding solution. That unquestionably is the most important thing. Without a good bind of skin to bones, nothing takes place. Everything works towards achieving a perfect bind.  Are weight maps the best means of doing this? Maybe, maybe not. Given Animator’s current implementation of technology, the use of weight maps is the most logical method to providing Animator with a system that works without overhauling various core infrastructure issues. This isn’t about “copying” Maya. Its about getting a system inside Animator that works. Since we have the underpinnings of a weight mapping type system already in place, lets focus on making it work in an intuitive way.

Of course it would be nice to have a mesh editing system within Animator that gives component level access to the object’s CV’s inside the application. I’ve been preaching that for years now...and even had some plugins, at one point, that were beginning to address that situation.  But someone wisefully decided to discontinue them along with any other mesh editing ideas I had for them.

It would also be nice to address some of Tasybear’s ideas of cage editing inside Animator too...and that would be a smart thing to look into once Tesla is fully part of the picture. But we must consider the possibility of Tesla becoming more than modeling package one day.

Weight mapping, whether you may think of it as an “old/outmoded” system or not, is still embraced by every other application out there. Its a universal method that’s proven and allows for the exchange of information cross platforms thanks to things like FBX.

I petitioned for other CA type tools on the UP ballot but was pretty much overruled. I’m just thankful EITG was willing to address the weight mapping issue by putting it on the ballot...and if I recall, that’s what won the vote.

Hi Randall,

Using deformations, like lattices for instance, in conjuntion with weight mapping when skinning is a very common practice. As long as you have a solid deformation order established as to what deforms what first, tying it in with weight mapping works pretty well. Some of the very feature suggestions you’ve listed for deformations I’ve requested too. But what is the current state of the deformation engine/code in EI? I don’t know. Is it easier to enhance deformations to do all these things or fix weight mapping? My guess is weight mapping is the more “cost effective” call not to mention its usually falls before deformers when rigging a character.

In a typical workflow, one would build a deformation friendly mesh first, build some morph targets for base level facial animation if required, create a skeleton, check the joint rotation orders, insert kinematic systems, bind the mesh to the skeleton, tweak the weighting solution via weight maps, and then introduce additional deformers to even further refine the behavior of vertices.

Creating an entire animation rig with deformers only is possible but I personally wouldn’t recommend it.

But having nice falloff capabilities on a multi-regioned deformation… that does have potential.

Igors - 30 August 2008 08:02 AM

Hi, Kurt, All

Actually we are not happy with how CA sub-forum is going on. It looks like “CA tools” = only one thing: “wmap painting, initial bind” etc. With only one idea in fact: “do it as it’s in maya” We’ve nothing against wmaps. we’ve nothing against “do copy” (this job is easier). But we don’t think it’s an ultimate/primary thing. IMO the workflow at vertices/facets level (that EI never had), mesh editing and other themes are at least same important.

Hey Igors,

I hope my message here will he bridge the gap between your dissappointment of how the forums are proceeding and the dissappointment between the animators who become so disgusted with EITG failure to fix the problem they switch to Maya, C4D or LW.

It’s not that Animators doen’t care about all the other creative ways to approach the problem. We are sure some inventive was of making EI weight maps different is very possible but also endless.

The problem is that as long as we focus on anything other getting weight maps functional...we DON"T HAVE A CHARACTER ANIMATION TOOL WITH EIAS.

So although we like the idea of many different options, we just want a fast reliable conventional weight maps so we can WORK AGAIN. Maybe make superheros again...or flying elephants. Now we have NOTHING. Not even a properly weighted cylinder. Something is better than nothing. We are only asking for something that works. Maya, C4D, LW, Blender and Hash. ...works. We only need our wmps to be like their wmps.

Maybe we can come up with Unique Creative Weights once we at least have a working CA Skinning System again.

Why can’t we just do simple weight maps and get it over with?

Hello Brian,

I agree that skinning/weight mapping is probably closer to a solution than updating the deformers. That was actually what I was trying to find out..it may possibly be that deformations are more deeply a part of EIAS than the skinning engine is.  If that’s the case, it may be easier to implement changes in that framework.

As for using deformers for rigging -bones really are just another type of deformer, they just seem to be hooked up differently. I use a proprietary package every day that doesn’t use weight mapping, nor does it allow for the creation or direct cv level manipulation of geometry, but it does have incredible rigging tools based on field weighting in conjunction with geometry groups (I suppose you could consider that mapping of a type).  We can change a model dramatically at vertex level and not break the rigging. Very handy. And the ability to animate regions of influence is extremely helpful in complex rigging situations.  The only off the shelf package I know of that supports this style of rigging would be Messiah, but I’ve never played very much with it.

The only reason I’m bringing any of this up is that I think we need to make certain that we don’t go so far down one road that we ignore other possibilities that may be closer at hand.

Hi Randall,

It sounds like a very intriguing proprietary package you have there. It would be interesting to see how things like that could be addressed in the future. Perhaps that could be the very method that sets Tesla apart from the pack if Tesla adopts animation features...say 2 or 3 years from now.  But what do we do until then?

I believe in the long term road map Brad is trying to establish for EITG. Get Tesla on board, make sure it out models the competition, continue to modernize Camera so it can stand eye to eye against any other renderer out there, and then provide Tesla with the means to talk to Camera. This creates a great new avenue to re-introduce the “new” EI family to the world and create a new “Brand”.  But where does this leave us with the animation aspects of the system? Well, it leaves us waiting...and you know.. that’s ok to some degree provided we just don’t totally dismiss animation all together.

Right now, our animation capabilities are stuck in the late 1990’s. By addressing the weight mapping issue properly, we’re simply attempting to bring us up to speed where we should have been around 2003. It would be a mistake to completely overhaul Animator right now and let Tesla and Camera slide. For a while there I didn’t believe that, and I actively pushed for Animator’s development over anything else. But I believe that creating a new “brand” and avenue for EITG into the 3D community is important. That can most easily be accomplished (in EITG’s case) with Tesla and Camera than with Animator. But this doesn’t mean we just dismiss animation.

Its my belief that animation tools are more critical to the story telling process over anything else, BUT, you really need everything working together to have an effective solution that sells. Today, the marketplace addresses that concern and provides us with a plethera of modeling and rendering applications out there. But they are add-ons or complementary specialty applications that assist to expand a core app. The market place only has a few minor examples of animation devoted applications. Messiah, Hash, and Motionbuilder. But none of them are foundational applications.

The core apps that are succeeding out there are those that can really animate and have a well integrated total pipeline.  These apps can tap into these other specialty applications because the CG community LOVES integration. We want to be able to find ways to get our data anywhere it needs to go....EASILY. I will admit that other applications can be successful in ‘modeling’ only or even ‘rendering’ only worlds if they want to be considered a speciality application, but EITG hasn’t positioned itself that way. I believe EITG wants EIAS (or whatever) to be a core app to compete against the C4D’s, LWs, Mayas, Maxs, and XSIs of the world.

So what do we do until its animation’s day in the sun over in EITG land? Well, we effectively improve existing animation systems so we can still have a reasonable animation presence. This is not a waste of time or money. It promotes the idea that EITG can provide a complete solution. Dynamic weight painting and effective, intuitive skinning tools are probably the most important missing element from Animator to emphasize that EIAS can provide a reasonably capable animation system...especially with the advent of FBX.

AVTPro - 30 August 2008 08:34 PM

I hope my message here will he bridge the gap between

Aha, “same song” we heard many times.

- When Ian asks for bug projects - silence. But it’s repeated and repeated that EI should “fix” something. Fix.. what??

- When it’s proposed to formulate new skinizer ideas/functionality - we see/hear nothing concrete yet but only some long considerations

- When we finally asked directly “let’s copy it from maya”? - we hear no answer again

So what do you want? Where are your constructive propositions? Or your goal is only to talk and talk “how bad EI is”? Looks like this.

Hi, Randall

Randall - 30 August 2008 05:39 PM

The biggest changes that I would love to see regarding deformers:
allow multiple regions for bones rather than a single region
the ability to animate /control region falloff
the ability to have painted maps work in conjunction with all deformers to isolate specific deform areas
have regions that are not just boxes, but spheres with inner and outer falloff zones
have some way to visualize which verts are being controlled by a region. (such as a color change or highlight)
bring the controls for the regions into world space so you don’t have to pop back into the deform editor all the time.

In other packages this type of weighting is known as “field weighting” and it is a dream to work with. Since you can animate the regions as well as the deforms that effect them you can create very complex rigs.

It’s a “classic” theme. Or, at least - very old. It’s not a secret that “Deform region” (cube) is a very rough tool. Normally (in other apps) user selects vertices, effect’s spread and applies an action (deform for example) to selection. Of course, wmap can be used in a role of selector - although it’s less elegant. Note also that “bad EI wmaps” are very suitable to do this.

So “why it’s not done yet”? Because this thing (same as many others) requires “mesh” - enhanced polygon model data representation that EI has not. More intellectual operations (like selective deforms) need to know more than actual EI data can not provide. For example: what vertices are around this one? what facets this vertex belongs to? what is a painted value on surface (not only in vertex)? And so on.

In other words, interested/usable things need a some fundament/basement first.

Hello Igors,

Would you like a more expansive CA tool list? Ok...here ya go.

1. Bone Mirroring Tools with bone renaming capabilities.
2. Event based binding with auto weight map generation per bone.
3. Dynamic, real time weight painting. (no more non-dynamic strength maps...except for legacy plugin support)
4. A Smooth paint tool to blend weights where ever the user indicates.
5. Weight Mirroring Tools.
6. Joint orientation tools.
7. Lock Influence tool to prevent weights from being redistributed into a specific influence when painting.
8. Flooding tool.
9. Eye dropper tool to sample weighting values.
10. Fix the process painting while skinning bug in v7 so we can see the mesh update while re-distributing weights.
11. Load/Save/Copy/Paste/Export/Import of weight maps.
12. Recalculate or update weights button.
13. Check out the weight min setting. This is supposed to act like an “envelope” setting but I believe it is not working as expected. ***
14. Weight Pruning.
15. Set/Go to bind pose.
16. FBX export
17. Fix bone action tab. Include/Exclude tool is flopped.

*** I’ll send up a screenshot

Potential other ideas:
1. Numeric weighting tools / Spreadsheet
2. Improved morphing tools as suggested in other threads
3. Spline IK
4. Soft Region Deformers
5. Geometry as influence
6. FK/IK switching
7. Set Driven Key
8. Vertex Caching
9. Character Sets for multi-keying
10. Improved function curve editor
11. Truncate animation paths
12. Onion Skinning
13. Cage Editing & Wrap deformers

Since you indicated the possibility to actually select vertices how about:
1. Lattices
2. Clusters

How much more do you want me to go on? The top list alone just deals with skinning (except for bone mirroring, joint orientation tools & FBX exporting). Users have been providing you with plenty of great feedback.