How many users must find SUCCESS ELSEWHERE?
One here ready to go................... if this is not fixed soon.

Hi Paul,
Lets calm down and give time to the developers and pros to find the best solution. FInally evryone is working with a goal in mind. Lets keep the good vibe. Pressure is not an option. Theres is nothing better to work knowing what you do is enjoyable and will get to work for all the artist as a whole.

Paul use the tool that better suits your needs.
Igors is great to hear your enthusiasm about Animator keep the good feeling.

I got a question for the Igors, why when i hit the duplicate command as i want many copies of the same surface but i want to have them animated at a different time in my animation, why is it that i loose my Bind?

I havent tried using bones as deformers.

Thanks,
Edgard

Almost done with my mock ups. Should be up on the site today.

Hello Everyone,

So here are some mockups of potential changes to the weight mapping toolset. I tried to maintain the existing 2 step approach by including both the original “Strength” map system and by introducing an alternative combined “Weight” map system. I will admit that by having both it could potentially cause confusion without significant explanation. However, one should realize that existing “Strength” maps are still utilized by various plug-ins and tools outside of the skinning solution. So removing them could potentially present problems. Discussion on how to address this is needed.

SKIN EDITOR: The new SKIN EDITOR has been expanded to consolidate menu items and to put both automatic and manual weighting solutions in a single interface. Tools in the new SKIN EDITOR include:

Binding Globals: These tools influence the entire initial automatic solution for the entire hierarchy.

1. Weight Minimum (Same as before)
2. Falloff Powers (Same as before)
3. Bone Maximum (Same as before)
4. Maintain Max Bone: Used to limit the maximum number of bones that can obtain weighting data per vertex.
5. Skin Tab: This lists all objects in your scene that are currently skinned. Single click displays bones to the right in the bone tab, while double clicking opens the Object Editor for that particular skinned object.
6. Bone Tab: This lists all bones in the solution for any 1 particular skinned object. Blue spheres activate/deactivate the bone from the weighting solution while double clicking on the bone name opens the bone info window.

Manual Control: These tools help the user refine the automatic solution numerically, prune weights, and reset the solution. Alterations with these tools would automatically be updated visually in the display when showing the weight map.

1. Prune Weights: Removes weight values below the threshold and redistributes values throughout the solution.
2. Reset Weights to Default: Resets all weighting values back to automatic defaults stripping out manual changes and any strength maps assigned within the solution.
3. Vertex Weighting Editor: This tool shows every vertice within the skinned object and the weighting value for every bone influencing the solution. Users can use this tool to manually assign weight values to any number of vertices numerically.

--------------

Object Info Window: The Strength/Weight tab in the Object Info window has been expanded to support the original Strength Mapping system and the new combined Weight Mapping tools.

1. View As Strength/Weight buttons: The user must select how he wishes to view the solution. The Strength option uses the original separate strength map paradigm and allows the user to see these paint maps separately before they are “combined” into the solution. I recommend that all “Strength” maps appear in shades of gray only when painting. While weight maps can appear in grays or colorized based off the color of the bone driving that weight. Clicking the Weight button grays out the strength map options and presents only weight tools for consideration.

2. Strength Tools: Same as before with the addition of copy, paste, load and save. The list window to the right of the Strength tools will only show the specific strength maps like before but should now be identified accordingly with the user supplied name plus the words “Strength” following after. An example would be: Left Elbow (Strength). Blue spheres activate and deactivate Strength maps when in that mode.

3. When viewing as “Weight”, the strength tools are grayed out so not to confuse users. Now all bones within the solution will be accessible with their initial bind visible to the user. The center list window now shows ALL the appropriate influences as named in the project window. An example would be Bone1 (Weight). This name appends a “- S” to the name to signify if there is a strength map affecting that portion of the bind. To the right red dots appear that “HOLDS” the solution. If activated, a “- Hold” appears next to the name and those weights can no longer be altered by the re-averaging system. The tricky part here is if the user is working in “Weight” mode, and he paints changes to the combined solution, a “strength” map should automatically be generated and be listed when if the user switches back over to Show AS: Strength. This does lend to confusion and may need working out.

4. Export Weights: Opens a new interface with various options to define and export out weights accordingly. Options should include user definable resolution and what type of file format the user wants to save the weights out as. Exporting weights should have the option to export one or all the weights defined by the user.

5. Import Weights: Imports weights and reassigns them to the bones based off naming convention.

6. Mirror Weights: This tool needs to be defined because mirroring weights is dependent on having identical bones on the opposite side of the symmetry to associate with. Without bone mirroring, mirror weights could get tricky.

-----------------

Bone Info and Paint Tools in next post.

Bone Info Window:

Not much has changed with this window. However, a few things should be pointed out. These tools currently modify the larger “automatic” initial solution by altering bones individually on the local level. Whenever changes on the local level are done, they should be automatically viewable when using “Show As: Weights” is being used.

The bone action tab currently seems to invert the include/exclude functions and should be checked for a bug.

The Strength/Weight tab would simply list maps associated with the bone and could be double clicked for viewing.

---------------

The Paint Tool:

The new paint tool has been expanded to include:

1. A Currently Painting Identifier field to show what the user is currently accessing. Strength or Weight.

2. Changing colors affects weights only. Weight colors are based off bone color. If user wants to change colors, he can do so here or within the bone info window. Weight maps should have the option to be seen as grays or colorized based off bone color. Strength Maps however should always be seen as grays.

3. An eye dropper has been added to sample values.

4. The Feather feature now has a value that can be added to determine how great of feather is applied.

5. Replace / Smooth buttons determines what “mode” the paint tool is working in. Replace for painting values, smooth for blurring and smoothing values.

6. Flood button has been added to flood out the current painted solution. It spreads out and grows with each consecutive click.

7. Show wireframe has been moved to this window. Turns on / off wireframe while painting.

8. Process Skin while painting remains as like the original tool.

I will admit that by trying to permit both the Strength map and Weight map paradigms we’re looking at more work. Its harder to keep track of two separate systems rather than just combining them into one. (Which I feel works better) ... However, because of the dependence of plugins that use the Strength Map functions, they just can’t be simply eliminated. Perhaps, for just the skinning tools, the concept of strength maps should just be excluded from the user’s choice of options and just go with direct editing of the combined solution only.

Other potential issues.

EI as opposed to Maya, doesn’t seem to prevent alteration to the “Falloff powers” or other global binding or local bone settings after the bind. There might be a need to toggle certain tools as active or deactivated depending on what the user wants to adjust post the initial binding. Having the “Reset Weights to Default” option button could completely restore the solution back to its initial state if the user wants to. But there are two trains of thought depending on whether you’re using “Strength Maps” or “Weight Maps”.

With strength maps, the automatic/global initial bind is always active, always alterable and is adjusted by the presence of a strength map to move values around through out the solution. But turning strength maps on or off always restores the initial bind because its always active and ever present and ever re-evaluating.

And alternative approach may be to consider having a “locking option” of the initial bind state after an object is first skinned (and thus deactivating global falloff powers and so forth from that point on) and only using the skinning engine to “re-average” the solution through painting weights, numeric entry or by using the local tools found in the bone info window. This might have the added benefit of potentially stabilizing the weighting solution. The Maintain Bone Max option could potentially provide some of that capability by limiting the number of bones used at any one time to evaluate the individual vertices within the solution.  The point of this is because when a user starts painting weights to alter the solution, any alteration of the global binding settings would likely erradicate any custom values previously painted.

Hello Everyone,

Based off my last post, I’ve got another potential idea on how to address the dual strength / weight map issue. What if we offered two binding solutions rather than opting for a “Show As: Strength/Weight” selection button in the Object Info Window’s “Strength/Weight” tab? Currently when someone in EI binds bones to a skin, there is an underlying, active binding solution that is constantly “on”. It is globally modified by the settings in the current skin editor and locally on each bone in the Bone Info window’s “Special” tab. To modify that “active” initial bind, outside of the global and local tools, the user must use a strength map to fine tune the solution. Potential problems can occur when one alters any of the global or local settings after Strength Maps have been painted. The new falloffs, or range limits, may not produce a desireable solution so the user is forced to either repaint the strength map or get rid of it all together.

Typically, a user should set his global and local binding settings and then NEVER alter them again if he plans to use Strength Maps. But sometimes that’s unavoidable. The current methodology can be confusing and it doesn’t allow the user to see the combined solution. (The initial bind + the strength maps). Consideration to at least view the combined solution would be good in this mode just for visual inspection. Additionally an “active” binding solution doesn’t really give the user the ability to utilize a manually entered binding solution with the numeric spreadsheet or to prune values under a certain threashold because the intitial bind isn’t capable of being changed in that manner.

So, as suggested previously, perhaps there should be a second type of binding called “Inactive Binding” or perhaps a tool to “convert” to inactive binding. Inactive binding would take the calculated initial bind based off the global and local bone binding settings, freeze them, and then deactive those settings to prevent further large scale changes. Now each bone possesses its own seperate weight map and each of those maps are visable in the Object Info window.  From that point on, the only way to modify an “inactive” bind would be through the numeric spreadsheet editor, the prune weights tool, or the paint weights tool. The paint weights tool would then redistribute/reaverage the values of the bind based on direct weight painting rather than strength maps. When in “inactive bind” mode, strength maps would not exist. Their tools would be grayed out in the “object info” window. If a user wanted to reset an inactive bind, he would use the “Reset Weights to Default” and the redistributed weights would return to their original positions before painting took place. The “Maintain Max Bone” tool would still work in this mode and the Hold Weights tool would also function.

So instead of trying to make the two methodolgies cooperate with one another, perhaps its just best to keep them separated and turn on and off certain tools based off which type of binding one chooses to use. This would allow EI to still have access to the older “strength map” system for legacy projects and plugins and incorporate a new solution that is more intuitive.

Hi All

We see enough typical situation: this thread is over-burden, too many themes in one thread. Thus no way to discuss something productively. Ideally it would be create a small sub-forum (like for Soonica) just to emit small threads there. For example, like “spreadshit editor”, “bone influence visualize”, “strength maps vs weight maps” etc.

Ian, Phil, is it possible?

You said “spreadshit”.

BTW, Paul.

EIAS still pays my bills. Not Maya per se. Maya I use to assist EI. I have had only one fully Maya CA job for PUMA. The golf.puma.com

Still reviewing the extensive detail info you submitted Brian. Very well done.

Just a few notes without going into details of specific feature.

1. I am very happy to seen SpreadSheet for verts. One stray vert can be fix quickly. Also excluding bones by zeroing out weights. A slider should also be included to “interactively” hone stray verts and not just input from keystrokes.

Igors mentioned that a slider can be used instead of “Power of”. Maybe the slider can be carried into the “SpreadSheet”.

2. More importantly Brian, you bring up a valid issue about the plug-in needing strength maps namely Placer Deposit. I used PD for the first time to make the quills on the Puma Porcupine into geometry instead of hair. For a $99 plug in, it was invaluable. However, the reason why I did the Puma Porcupine in Maya instead of EI was because EIAS skinning wasn’t strong enough. Not that EI couldn’t do the Porcupine with FBX skinning from Maya, EI could have. Problem was I had a few unmerged edges in the character modeling. Though it was my fault, Maya could handle the rips in the geometry and EI couldn’t compensate for faulty (fast) modeling.  If the skinning system in Animator was sturdier it would have completed the job just fine.

My point is, unless EI skin system is better plugs like PD won’t be very functional for furry, or hairy characters. The skinning has to have priority over the plugs.

I agree that there should be two paradigms for binding but it would be more work for coders and could be redundant.
If given a choice I would prefer to see plugs take advantage one weight map paradigm/Bind setup that works.

Create Bone>Add bone to skin with Bind>Edit Initial weight maps>plugs use this map instead of strength map with no bone.

3. It is important to keep in mind that those Skin SpreadSheet, Weight Maps and Bone fall off are all separate option, they all work to one cause. They are not components on to themselves. I don’t know if separating topics is better for code developers but viewing, and editing all the options together is the ideal workflow for skinning. All options should be visible and accessible to the user/operator at one time.

(Still can’t get MacPro to pull up EITG. Taking a little longer to work on MacBookPro)

Hi Alonzo,

To be fair, Maya will tear apart a skin just as easily if edges aren’t properly merged in the geometry. Even the slightest difference in weight on vertices occupying the same space will separate if not merged, and for EIAS the only way to ensure verts and edges are merged would be in a modeling application not Animator (unless “Mesh” were to one day be integrated). Anytime you build a segmented character rather than a single skinned character you’re gonna have to address this problem. Its particularly critical in areas where the neckline and the body meet. No wonder so many characters hide the neckline under a collar or some other piece of clothing.

I agree that finding the “correct” skinning methodology is more important, but we do have to consider that given the limited participation we’ve seen from the plugin vendors, having some kind of legacy throw back to keeping strength maps available shouldn’t be dismissed. There has to be at least 5 plugins or so that use strength maps if not more. Here’s the thing though, just because we work towards creating a new skinning system doesn’t mean that strength maps couldn’t still be accessible for those legacy plugs and project files that use them. Strength Maps being used to just “direct” the placement of placer deposit objects don’t need to do anything to affect the skinning solution as long as a user doesn’t attach the strength map to a bone. The new skinning solution should be capable of doing its thing and to allow an “old school” strength map to dictate the placement of placer objects without interfering with the skinner.

I further more agree that all these tools do need to work in concert. But the first hurdle to get over is to address methodology. Items like direct weight manipulation, pruning, and numeric input would likely not work under the current EI methodology because the underlying active initial bind is always “on”. If someone changes a Falloff setting, any manually entered data would probably be re-averaged for the new falloff and the numeric data would be lost. This is why I’m suggesting a “conversion” process that converts the “legacy” system over to the new system. Once converted, all the manual weight mapping tools activate and we proceed as expected. The skin averager then only re-evaluates the solution when painted, pruned, or numerically changed. And maybe one day, if EI were to get influence objects, those could be included too.

Reset Weight to Default would return the solution back to the original bind...and if the user needs to go back to an active bind, using the legacy system, he would just have to detach and reattach the skin with an active bind.

I’m against causing any redevelopment or updates for current plugin which utilizes strength maps for their output.

I agree that

1. One system must be established and agreed upon inorder to move forward into development asap. It’s a paramount first step.
2. The system should create as little “disturbance” to current plugs and development while achieving a better skin system.
3.  if possible, it would be better to maintain legacy Strength maps for vendors while not creating more or redundant work for Skinning developers or end users.
4. Using the old strength map system as before for plugin (5) then using a “conversion function” to a visible 1 map to bone skinning systtem with color synced, auto-map and respective bone labeling. This “conversion button” effectively “shuts off” the constant initial bind strength map system to use the automated one bone/one map “Weight map” system would be the best solution to kill two birds with one stone, Strength vs Weight maps.

So ultimately if this this can be achieved by host app developers the conflict between initial bind and strength maps obstructing or only modifying geometry would RESOLVE nonreponsive vertices editing issue for users. Then converting the initial bind maps into a “visible, re-averaging, bind” will resolve ambiguously painting weight maps blindly.

BTW, it’s clear that the unmerged edge at the connecting arm pit was my fault. Missed a stitch

Paralumino - 21 August 2008 12:08 PM

Hi Alonzo,
... Anytime you build a segmented character rather than a single skinned character you’re gonna have to address this problem. Its particularly critical in areas where the neckline and the body meet. No wonder so many characters hide the neckline under a collar or some other piece of clothing.

Whatever happened to the much touted ‘Council of Twelve’ the body of experts established to guide the EIAS development program?  Set up presumably to act as a buffer between the programing/development coalface and the extended (if not extensive) userbase.
Not nearly enough attention is paid to the issue of bad SDS modeling technique and topology. Nearly every tearing problem can be overcome if the model topology (SDS cage) is well designed to conform with ‘anatomical structure’ of the character design. (assuming the ‘broken’ weightmap issue has been addressed)
Ultimately the use of weightmaps for controlling ‘creasing’ and unwanted bone influence interference, is an imprecise, sledgehammer method (like any deformation lattice), but its necessary nonetheless.
(Because more sophisticated model posing controls, such as keyframe cage editing in EIAS or better still a Hash AM ‘Smartskin’ like toolset is currently impossible).
Skinning in EIAS is simple and effective, the default influences should display as a greyscale weightmap, this should be editable. The need for additional maps needs to be catered for in a consistent manner.
Strengthmaps should be isolated from the skinning interface.
I am a character modeler, out of touch for a while now, so experienced character animators like Fred Kuentz and Richard Morley may wish to modify my comment.
Its important that char anim professionals are consulted in such matters as this, self appointed experts and hobbyists can easily distort the real picture, confusing management and programers alike.
Programers exposed to such a confusing array of of user opinion in a public forum are bound to end up with a lot of irrelevant and confusing information.

Tasybear,

I’d completely agree with you. Not enough effort is given to modeling issues when preparing a character for animation. Too often people will build a model expecting it to deform perfectly but more than not, they’re left using the ole “sledgehammer” to knock vertices back into place with a weight map. I like the idea of exploring other avenues of geometry manipulation in EIAS like cage editing and SmartSkins. They could be very beneficial when Tesla arrives. However, we do need an “old school” weight mapping system that works and is intuitive.

I’m gonna wipe the slate clean again because the Igors feel this thread has gotten too overwhelmed with high concepts and ideas. I also feel we may be arguing symmantics. So why don’t we just start with the basics?

What is a weight map?

Well by my definition, a weight map is a grayscale map that defines the areas of influence of a bone to the vertices of geometry “skinned” to that bone. As the bone moves, it deforms or alters the positions of those vertices dependent on the amount of influence or “weight” that is being exerted on the skin. White areas on a weight map represent attraction influence to the bone where black areas do not. A range of grays provide a level of percentage of influence a bone has on the position of the vertices.

How is a weight map created?

Depending on what application you’re using determines if the answer to this question gets tricky. Initially, a weight map is generated through an application’s skinning or binding tools. I like to use the term binding “globals” because they determine the “conditions” of the bind at the immediate point of skinning. Sometimes I’ll also call this the “initial” bind. Typically, after the initial bind is complete, most applications will convert the intitial bind state into a series of weight maps which correspond to each individual influence found within the skeletal hierarchy. One bone = 1 weight map.

Does this process happen with EI?

No. It does not. EI will not convert the intitial bind into a visable, editable state of 1 bone to 1 weight map.  Instead, EI chooses to retain the bind in an “active” state and “fine tunes” the bind through an EI strength map.

How does EI’s binding globals work?

EI’s binding globals include: Weight Min, Falloff Powers, and Bone Max. These 3 settings alter the bind across the entire skeleton. Additional refinements can be made on a “local” level by altering special deformer values in the bone “Special” tab. These tools will alter the initial bind on a per bone basis. Within the solution of the intitial bind, all the vertices are averaged across the hierarchy’s bones based on the Bone Max setting. A bone max setting of 5 means that five bones will be used to average the position of a vertice during a deformation in relationship of the vertice’s distance from these bones. Closer bones derive more influence where more distant bones exert less influence. While this process is identical to the processes being used in other applications, EI will not convert the bind into a visable 1 bone to 1 map solution.

So what does EI do instead?

EI implements a Strength Map, which is essentially an exclusion map. The Strength Map tells EI where to remove or reduce influence away from the bone so the geometry deforms less. This is the exact same process being used in other applications, but the difference is EI elects to show the user the area being painted for exclusion rather than showing the user the combined exclusion map and the intitial bind together. The result is the EI user must think in terms of excluding influence or negative space, where most other applications show the weight influence in positive space. This exclusion methodology can become confusing to the user the more and more bones that are introduced into solution’s hierarchy. To accomplish a “positive” strength painting methodology in EI, the user must create a strength map for every bone in the hierarchy and remove all influence of the initial bind by filling the Strength Map with black. He must then paint back in areas where he wishes to reassert influence. This is time consuming and impractical.

Are strength maps and weight maps the same thing?

Again, this is a matter of symmantics. Technicallly, one could say that strength maps and weight maps are the same thing IF one does not consider the initial bind a form of weight map itself. For some, the initial bind is simply a constant calculation of the binding globals while a weight map is the device used to redistribute the weighting values within the solution. Personally I always think of a weight map as being the COMBINED data of both the initial bind and the exclusion map TOGETHER, not SEPARATELY. Strength maps by themselves are meaningless without being combined with the intitial bind.

So which method should we use?

I believe most users who do any kind of skinning prefer seeing the binding solution as a series of grayscale images that combine the exclusion map that is painted by the user along with the intitial bind to form a “positive” representation of the weight map for every bone/influence in the hierarchy.

Should we get rid of EI Strength maps?

No. Because EI Strength Maps still allow the user to define areas on geometry for use with various plugins. But for skinning purposes, an option to see the combined solution rather than just the exclusion map is needed for the best workflow.

What about your other ideas about weight pruning, spreadsheets, and “bypassing” the bind state?

Means to manually alter the bind state through these tools are still important to obtain, but not until we make a decision to support the 1 bone to 1 combined weight map methodology. EI should also consider the binding process as a tool that is executed rather than a state that must be constantly “on”. If users want to change binding globals they can do so, but not without being asked first.