Hi,

yes you can use the script with another script.
And yes, the automatic region-finding mode of the script is able to find the closest point to the current bone by iterating about all bones and all points and finding the closest distance. I think I could make this even better by using the geodesic distance on a volume base as I proposed earlier in this thread but using euclideean distance does the trick for now as well.

-k.

Hurray New version 0.060

There are a couple of new features like import / export for regions and custom bone objects may be used…

Good night.

the interesting story. i wrote three different ‘auto skin’ tools. no one was needed by a user! do you think i am a bad coder? hopefully no… there is something wrong in ‘auto-skin’ approach.

Hei denis,

I’m sorry for your auto-skin tools and thus your question seems to be rethorical, I’d like to add that I don’t think you’re a bad coder . But I’d like to contest that there is something wrong with the auto-skin process in general (I think you have spoken generally). As calculation power grows time consuming algorithms for calculating skin-weights automatically become faster and get more attractive to script-stuff as well. Besides that there are many very interesting mesh-decomposition technologies out there that have recently been researched like this article of Sagi Katz and Ayellet Tal which is the foundation for automatic skinning. Or take a look at automatic skinning processes gotten from mesh animations this is all pretty interesting and very promising. Stating that there was something wrong with an automatic skinning process seems to be unprecise in my oppinion. Maybe the currently used algorithms still need to be reworked, but I’m confident that this problem might be solved in the near future.

Speaking of “Autoweight” I can’t tell if anybody uses it in a professional environment (at least I know some people who seem to use it for personal projects). And yeah using automatic region detection in Aw has some downsides, cause you still might have to tweak them manually. But that’s a matter of the algorithm. Speaking for my personal process the script has speed it up because the terrible “skin painting” could be reduced and this was the overall goal.
Having the script calculate each region correctly automatically is just the icing of the cake and something to invent in the future.

So I hope you know I don’t feel offended and I even like to discuss this topic with you. Who knows maybe we can come up with an uber-tool for skinning if we throw our brain power together

-k.

@kogen,

I tried to use this script on a more complex scene than what you show in your tutorial video. There’s a few features I think that would help make things better/easier.

(BTW, I’m not giving you tasks, I’m just suggesting changes.)

1. Let the user specify a set of bones to use. Like most rigs, mine has a lot of bones and controllers linked to my skeleton that shouldn’t be used in the skin modifier. This could be as simple as only using the bones in that already exist in the Skin Modifier.

2. If manually creating clusters and auto calculating them were undo-able that would be very helpful.

3. A combine cluster operation. If I select one face from cluster A and one face from cluster B, I press a button to combine both clusters. This would be helpful after using auto calculate clusters.

Thanks for the tool!

i’m in the character rigging business more than 16 years. i’ve skinned in my life … hmm… a lot!

what is an average 3d character today? generally it’s a human kind game quality character about of 8-10k polys. right?

any pro can skin this guy for about 3-5 hours. i’m talking about good and final quality. right?

ok.
how the time by tasks is distributed? let’s show it for 4 hours full time case:

20-30 mins for draft skin (rigid)

20-30 mins to blend joints

1 hour for the shoulders and pelvis area

2 hours for the face

right?
(of course these numbers are not for the cinematic quality. for cinematic you have to add more time for hands and face skinning)

the question is? by using any ‘auto-skin’ approach how much time can we save? what step can be optimized? i see that the best ‘auto-skin’ tool cannot save more than 20 mins. and we can get some saving only at two first steps.

please correct if i’m wrong.

i want to emphasize that i’m talking about any ‘auto-skin’ tools including three ones that i wrote.

@denisT,

You are correct about auto-skin methods not being able to save much time for a pro, but there is a lot of room for improvement for skinning workflows inside of 3ds Max. When I saw Kogen’s tool I knew right off the bat that it wasn’t a one click solution, but what I saw was the next generation of skinning tools.

Maybe when this tool reaches v1.0 a non-pro can skin the same complex character in 3 or 4 hours. The curve editor changed the way we animate, pelt mapping changed the way we UV, polyboost/zbrush changed the way we model, and something is going to change the way we skin.

Areas where the skin modifier can improve: (Not necessarily for Kogen’s tool to solve.)

1. Selection tools for the skin modifier are poor when compared to Editable Poly and Unwrap UVW.

2. Why not let me hide geometry inside of the Skin Modifier, instead of jumping back and forth between Editable Poly and Skin. Hiding geometry is a great way to narrow the focus of what you are working on.

3. Envelopes in skin are limited to capsule shapes. I can see how this was for performance reasons in 1999, but these days my computer’s got 8 hyper-threaded cores. For this reason, I never use envelopes/cross-section, and I only weight verts directly.

4. The mirror tool is pretty good, but I’d like for it to allow me to set mirrored pairs of bones when it fails to auto-detect them. Also, it would be nice if it could mirror the center line intelligently.

5. It would be nice to have a few “oops” tools. Like swapping bone weights for the currently selected verts. (I accidentally weighted my jaw to the tongue, no problem I’ll use the swap tool.) Or I need to remove a bone let me choose a bone to give the bone weighting. (I often end up removing the twist bones to save on the joint count.)

6. Blender has a “Keep Volume” checkbox, I think it’s duel quaternion skinning, but Max needs whatever Blender is doing. It won’t work in many game engine (CryEngine does), but it saves a lot of time from creating joint angle deformers on cinematic models.

7. SkinOps needs a getSelectedVertices() function. I have script tools that take care of most of these problems, but they are all very slow because I have to loop through each vert and ask isVertSelected().

@ denisT:
What you’re saying sounds totally right. From this standpoint I’m not able to add anything because the time schedules seem to be pretty fixed.
But what I could say is that we’re still at “3 to 5 hours for a pro”. This is still very much for something that is just an unloved part in CG as UV-mapping is. And when we’re speaking about spending time for 3 to 5 hours for unloved stuff there should always be some room for improvements. Maybe one day nobody needs to care about skinning anymore because it can be calculated within a couple of seconds correctly. This would be the day when I say: Well nothing to invent here, let’s move to something different. And that is the cool thing about beeing an IT guy: You discover problems and start flying around that bunch of problems thinking about solutions. And from time to time somebody (I’m not speaking about me, just to make that clear) finds a really awesome solution to change things (like Aly Katz) for example or think about Mr. Ed Catmull that has tremendously changed our whole CG-world.
What I want to say is that if nobody starts something, there won’t be something another one can build a foundation upon maybe your skinning tools could have been a great start for somebody else to start his improved tool.

@ rmartinez:
Totally agree with your last posting, especially point 7 was shocking when I discovered that this is the only way to do it.
These are pretty cool ideas: But I think in the current version there already is something similar to what you’ve pointed out:

1. You can select a proper hierachy of custom bones and use them for auto-calculation. Of course you still can’t select a bone group but that shouldn’t be too difficult to implement. Great idea.

2. Undo, yeah, why not, cool.

3. This is already possible: If you have two or more regions, select one poly or the whole region, click on “get region” and then on “set region”. Should work.

I really appreciate this discussion.

-k.

I’m absolutely agree with you. A lot of things might be improved and has to be improved in the skin modifier. And after the adding these features the skinning workflow might be dramatically speed up. After disappointing in all my ‘auto-skin’ tools I’ve focused on Skin Tool that extends the Skin Modifier. This tool really saves the time and specially helps beginners. I can’t share the tool but I can show how it looks (see attachment) :).

7. It’s very silly that skinops doesn’t have a get-vertex-selection function. But there is a trick how to collect all selected vertices fast enough:

 -- make a skin (~10K verts)
 delete objects
 sp = converttopoly (geosphere name:"mesh" segs:32 isselected:on)
 max modify mode
 sk = Skin()
 modpanel.addmodtoselection sk
 skinops.addBone sp.skin (box name:"bone") 1
 
 seed 0
 vv = #{}
 for v=1 to skinops.getNumberVertices sp.skin where (random 0 1) == 0 do append vv v
 skinops.selectVertices sp.skin vv
 subobjectlevel = 1
 	
 -- test #1
 (
 	ss = #{}
 	m1 = heapfree
 	t1 = timestamp()
 	for v=1 to (skinops.getNumberVertices sp.skin) where (skinops.isVertexSelected sp.skin v) == 1 do append ss v
 	format "test1	time:% memory:% verts:%
" (timestamp() - t1) (m1 - heapfree) ss
 )	
 -- test #2
 (
 	ss = #{}
 	m1 = heapfree
 	t1 = timestamp()
 	for v=1 to (skinops.getNumberVertices sp.modifiers[#skin]) where (skinops.isVertexSelected sp.modifiers[#skin] v) == 1 do append ss v
 	format "test2	time:% memory:% verts:%
" (timestamp() - t1) (m1 - heapfree) ss
 )
 -- test #3
 (
 	ss = #{}
 	m1 = heapfree
 	t1 = timestamp()
 	for v=1 to (skinops.getNumberVertices sk) where (skinops.isVertexSelected sk v) == 1 do append ss v
 	format "test3	time:% memory:% verts:%
" (timestamp() - t1) (m1 - heapfree) ss
 )
 -- test #4
 (
 	ss = #{}
 	isVertexSelected = skinops.isVertexSelected 
 	count = skinops.getNumberVertices sk
 	m1 = heapfree
 	t1 = timestamp()
 	for v=1 to count where (isVertexSelected sk v) == 1 do append ss v
 	format "test4	time:% memory:% verts:%
" (timestamp() - t1) (m1 - heapfree) ss
 )	
 

what method do you use?
is #4 still slow for you?

@denisT,

Of course I’m using #1, and I’m not even using a bitArray. In my defense my skin tools were some of the first tools I had ever written. I don’t know why I never bothered to go back and update them. But even if I had, I didn’t know, until now, that saving a struct’s function inside a variable was faster than calling the struct.

I just tested a few of my tools with your updates. They went from 3.1 seconds to about 97ms.

THANKS!

@kogen,

Thanks for taking my feedback!