Whether that is true or not shouldn’t be the case here. I respect the Igors assessment of the time required to complete Richard’s request provided that my observations of the problem with weight maps are accurate within EI’s current system. Can we please get a developer to officially respond on the weight map situation based off the information I provided in my link posted above? Why would this be difficult to fix? What does it entail? I think after 3 or 4 years of reporting this problem for correction its time.
Users shouldn’t vote on UP strength/weight map tools that do not fix the problem. It would simply be a waste of resources and I’d rather put energy into something more productive.
It is, of course, a great idea to do this - better access to the current tools. I like it.
The idea is fresh, the first I heard of it was this week, thus many questions need to be answered.
What exactly are we visualising? How do we do it? What would it look like (a direct copy of Maya? is this suitable for EI?)? Does anything else need to change before we do this?
Strength maps vs Weight maps?
All this needs to be resolved before any development time is put into it. Weeks of learning, discussion and experimentation is required before this turns into a ‘concrete’ feature. Essentially, it needs designing. The core Beta testers do this kind of thing all the time, as without this ‘design document’ the programmers have to hit a moving target..
Mock ups, workflows etc. Let’s get to work,
My very best,
Ian
Thanks for the opportunity to simply discuss the weight/strength map issue. First off, I want to clarify a few things.
1. My position for animation support is not purely directed at CA. I’m all in favor of any tools that help the advancement of the animation discipline. Modeling and Rendering are obviously fully covered. But I believe that in order to be effective, EI needs a well rounded, balanced system to sell. This includes animation. If the weight map process proves to be too extensive, alternate animation tools should appear on the ballot.
2. I’m all in favor of the larger master plan of Tesla, advanced render capabilities in Camera, and the scheduled non-voted v8 upgrade path being put forth by management. I do not want to appear as stonewalling anything or being unreasonable.
3. Alot of my focus is being directed for the sake of several lost EIAS pro animators who left the package out of frustration because of new features consistantly surplanting bug fixes and workflow problems that have gone unanswered for years. If the concept of the User Pack is to continue in future upgrades, we must find ways to represent all disciplines in the election process and ensure less “populated” disciplines and historical topics are fully recognized. I know you know this, and I believe your current UP list is trying to represent this.
4. I acknowledge that resources are limited.
5. I acknowledge the developers’ assessments as to how long potential fixes may take and will respect those estimates.
6. Try to remember that while appealing to the broader user base through this election is a commendable gesture, we must always remember that the needs of the pro users should drive the feature list. (And I think that’s being addresed in the non UP features) My statement isn’t to judge anyone’s skill level or to suggest that members of the advisory board, EITG and beta team don’t have that in mind. I believe they do. Its just a statement that mearly reflects the concept that is recognized by the CG industry as a whole.
It has been pretty thoroughly defined that Animator utilizes a two part initial bind weight map to strength map system. There is an initial bind that is fine tuned by a grayscale strength map that alters the weighting values of the initial bind. But the strength map isnt the actual solution itself. Thus the confusion. A number of users have requested the ability to see and directly manipulate the initial bind through a “Paint weights tool” and thus eliminate the concept of separate strength maps.
Questions:
Why are we using a two part system? Are there limitations to EI’s skinner that requires a two part system? How does it actually work for clarity’s sake.
How difficult is it to visualize the initial bind or the results of a combined solution?
Is it possible to paint and directly modify the initial bind’s weight map rather than using a separate strength map modifier?
What is the technique being utilized by the current strength map system that could cause problems experienced by users like loss of binding on potential vertices?
How often does the skinner reaverage the solution? Each time the weight map is turned on or off? Is it possible for it to recalculate a slightly different solution each time they are turned on/off thus resulting in unusual vertex fluxuations?
Here’s a quick mock up of a single bone in a potential chain. We have EI’s initial bind for bone two. Then we have an EIAS strength map overlaying the initial bind. Since we know that all the vertices must add up to a value of 1 based off the number of bones set in the Bone Max setting, we must ask ourselves:
1. What does the initial bind look like for each bone?
2. How exactly does the strength map affect the initial bind? Right now white retains the initial bind values while black removes initial bind values.
3. What happens if more than one map is applied to a bone? How are those strength maps “differenced” to obtain a total overlay that is then applied to the initial bind for that bone?
4. If black removes values from the averaged initial bind, where do those values go? They must be moved to other influences described in the Bone Max setting. Thus bones 1 and 3 take on values removed from bone 2.
5. Now that those values from bone 2 are being added into bone 1 and/or 3, what does that look like? How is the user supposed to make an informed decision without seeing the new modified initial binds for bones 1 & 3? He can’t because he doesn’t have visual access the newly reaveraged results. The problem cascades everytime the user adds a new strength map.
6. If all is working well, we should see the vertices update as each new strength map is applied, however while seeing the vertices move is a good indicator, access to the combined weight map is needed to potentially ensure everything is correct. There are other potential checks and balances that can help an artist make sure specifc vertices are locked and don’t move when ever the solution is reaverage, but we don’t have those tools. We also can’t “insure” that everything needing to be fully on or fully off is possible just through the painting paradigm. Its easy to miss a 2% or 5% patch of gray in a sea of vertices.
7. Smoothing tools can help blend the vertex values across the combined solution. We would want to ensure that we’re blurring these values properly.
Yes.. it is what Maya does...but Maya shows the combined end result in a real time visual feedback as it is being painted without using separate strength maps. Maya will not permit you to just “paint” a strength map that’s not associated with any particular influence because strength maps don’t exist in maya. Only weight maps do. Thus the user knows exactly what he’s going to get as its painted where in EI you can not see the combined end result.
This presents the following problems:
1. Inability to lock or hold specific values from being reaveraged when the user doesn’t want them too.
2. Inability to visually inspect the final weight map for potential patches of unwanted influence.
3. Confusion from the user expecting to just paint areas of influence when in reality he’s only altering an unseen one.
4. No spreadsheet of values to see vertice averages across the entire solution.
5. No way to prune out minor values that can’t been seen visually.
As a result, users typically have to generate a strength map for every bone manually which takes time. If the combined result was immediately accessible and paintable… workflow would be improved.
In all fairness, there actually could be BENEFITS to EI’s 2 part system if we could just visualize the final solution.
Benefits are:
1. Having a list of strength maps that are selectable to be turned on and off at will. (As currently implemented)
2. Single strength maps could be applied to more than one bone. (Though that can get confusing and I’m not sure if that’s supported or desired)
3. Photoshop like transfer modes could be applied to the various strength map layers before combining to the intitial bind.
But all of these benefits are somewhat wasted if we can’t see the end results everytime the solution is reaveraged.
We don’t want to enter in debates in this thread. Let us just post some tech explanations - all this “initial bind” etc can be very confused.
As you know, every bone has an influence (how it does affect vertices). This influence exists always and dependent on bone’s strength, falloff etc. The influence can be modified by strength map. All this is same (in principle) in any skinizer, but it can be SHOWN in very different ways, for example:
- show applied map only (as it’s now)
- show initial bone’s influence
- show combined (influence affected by map)
Yes, it’s possible to paint a “combined” one, but it absolute does NOT mean we change the initial bone’s influence (it’s controlled by bone’s strength etc). We still paint weight map. It’s possible also to put the map “behind scene” and show user only “combined” results.
How it’s effective/intuitive? Don’t know, every way has “pro” and “cons”. For example “paint combined” should have no effect at places where initial influence = 0 (enough to confuse user). “Paint combined” will be automatically changed if, say, bone’s strength is changed. IMO a direct strength map visualization (as it’s now) is necessary anyway.
And another one: all this is pretty simple for one (single) bone. With 2 and more bones the situation becomes much more complex. For example you can see “well-painted” place that.. almost has no effect. Just because another one bone has much more weight here. If we add another one mode (like “show relative influence") - it will have its own probs/negatives too.
So, summary:
- first off, it’s always EITG solution what features should be added and when. We can say our opinion only - same as everyone
- technical implementation can be more or less complex (here is not a place to discuss this). The real prob is what effect can be expected from the implementation and how users REALLY need this. Because now it’s like “a bunch of legends”, not a real feature with limitations (that are always unavoidable).
Debate based on unnecessary emotionalism will get us no where. However, allow me to point out just a few things.
Users have been reporting problems with the workflow EI utilizes to handle strength maps for years. Because of its convoluted approach, using bones and weights have been a trial and there has been a migration of these kinds of artists away from EIAS because of it. Failure to address the problem doesn’t make it go away. Every major artist that uses or has used EI to rig and skin geometry has complained. Even Matt as acknowledged that the current system was not designed effectively and that it has been debated about for the past 3 to 4 years. Its time to stop this nonsense and address the issue. Artists also mention problems with loosing vertices from the bind, unreliable results, inability to visualize the combined solution, and a lack of the proper tools to ensure a successful, intuitive and consistant binding methodology. This is NOT a bunch of legends.
What’s sad is EIAS doesn’t really need a huge injection of new infrastructure technologies to make this process better or even more so..just to make it reliable. Only a few small steps taken could ensure EIAS could effectively rig and skin a character without issues. EIAS may have started out as a hard surface animation package only, but it doesn’t have to stay that way. What it needs is the experience of users to identify a methodolgy that works. From what I can tell, they’ve been doing that...so why can’t we get a resolution to this problem?
I have pointed out clear and necessary tools required to improve the skinning process that address the limitations of the existing toolset. We understand that the initial bind is the solution. We also understand that strength maps offer the ability to modify the existing initial bind. But there are no means to allow artists to accurately ensure a total binding solution created under the existitng EI system is accurate and or reliable. Skinning, in any package, is challenging. In order to know if a solution works, you turn to the artists who have experience in rigging multiple characters and ask, “is it working?” Clearly, the consensus is “No”. But if you think this is “a bunch of legends” then its obvious that you’ve already past judgement on the problem and you’re dismissing what several talented people are telling you.
1. Allow the user to paint on the combined solution if he wishes to. Visualization of the combined solution is critical.
2. Provide grayscale sampling tools to readout values within the weight map.
3. Provide smoothing and flooding tools to better average out weights in localized or global areas.
4. Provide mirroring tools to reflect the painting solution symmetrically on the X or Y axis.
5. Provide a “Hold Weights” tool to lock weighting solutions on a per bone basis to prevent changes in the weights for that bone when the solution is re-averaged.
6. Provide a pruning function to re-average visually indistinguishable gray areas and minor values out of the solution.
7. Create a spreadsheet tool that displays the weighting values of every vertice in the skinned geometry and allow users to assign values to bones numerically.
8. Permit load, save, copy and transfer functions of strength maps to other rigs and skins within EI.
9. Provide importing/exporting functions to save complete weighting solutions, in user defined resolution values, to disk.
None of these things should require any infrastructure changes to the EI framework.
