PDA

View Full Version : Auto-Skin-Weight Approach


kogen
10-07-2009, 09:29 AM
Hi folks,

I've started to invest some time in a script, that is supposed to make a Max-rigger's life easier. It's an automatic skin weighter. Before you watch the video, I'd like to say that I'm still at the beginning and there definitely have to be some improvements. Nevertheless I'd like to show you the progress so far.

Autoweight(WIP) - Video (http://kogenspage.com/anims/aw0008_00.swf)

AsaMovshovitz
10-07-2009, 11:33 AM
Hi kogen,

that looks great very useful tool

Cheers,

Asa

PEN
10-07-2009, 11:57 AM
Nice approch, how is it determining which verts are weighted to which bones? You should be able to do a better job of smoothing the sections inbetween as well.

JHN
10-07-2009, 12:50 PM
Yes I'd like to know more too, seen a nice facerig for maya, that does a proper job on initial weigthing too, like weighting lips, upper lip not affecting the under lip for example.

-Johan

phoelix
10-07-2009, 01:24 PM
thats a nice aproach, i've always thought the skinning process should be more automatic,
keep it up!

kogen
10-07-2009, 02:45 PM
Hei guys,

thank you very much for your interest in the project.

@ Pen and Johan: The vertices are weighted in two steps:

1. Determine which points belong to a region (a region is defined as the area that is separated through n transition edges).
Theese points are weighted with the influence 1 for the bone that belongs to that region.

2. For every region there are still points that belong to the transition edges. So the next thing is that the algorithm looks for other regions that share those transition points. When such a transition area is found the average position of all the verts is taken to define a central point of that area. Afterwards the script compares if the distance from every point to the center point of the transition edge area is equal or less than a predefined distance). According to that distance the verts are weighted.

The problem with this way of calculating the weights is atm. that it all depends on the average position of the transition edge and a distance that I predefine.
So the next step would be to think about a more clever distance comparison. It would be nice as well if I wouldn't have to use the average position of the transition edge but... yeah I don't know yet. :)

labbejason
10-07-2009, 04:34 PM
Maybe have a spinner to use as a threshold to determine how much the weights overlap the transitional regions? This way you can control a bit of the blending instead of getting sharp spots. Really like your approach, btw. Looks like it's flexible :)

kogen
10-08-2009, 11:00 AM
Hei,

I've had an interesting idea while sleeping, so I had to give it a try this morning:
Obviously euclidian distances produce insufficient results. But when it comes to skin weighting you don't look at the euclidian distances but at edge distances.
I mean, nomally one would start to set the weights for two bones in a transition area and move on to all the points that are close to that area. For those neighbouring points one would normally use a value less than the value of the transition area and so on.

According to that idea the new distance calculation algorithm takes every transition edge area and calculates the edge-distance for every other point. For example the points next to the transition area have a distance of 1, the points next to them have an edge distance to the transition area of 2 and so on...
Here is an image to visualize all three skinning methods.
http://www.kogenspage.com/content/scripts/autoweight/aw_comparison.jpg

Number 3 produces quite smoother results than Number 2 now.

Labbejason: Yeah, there needs to be a spinner. The new edge distance can be changed by the user. At the moment I have an edge distance of 4 for the skinning. But I guess it's important to give the user a chance to vary it.
It seems flexible? Cool :) I'll try to keep it flexible.

nildoe
10-08-2009, 02:18 PM
As Mentioned..GREAT TOOL...

does the tool recognize also CAT bones? would be great if it did :)

Nildo

kogen
10-08-2009, 04:32 PM
Hi nildoe,

I'm not sure. Can you explain what are CAT-Bones?

I think I'll add a condition to find Bones via "BoneGeometry". Not sure neither, if that includes Biped. If it does that would make my life easier. Atm. you have to have the bones named as "Bone*" in the scene (indentical names are not possible yet). I hope to fix that issue tomorrow.

PEN
10-08-2009, 08:55 PM
I'm sure it wouldn't care what the bones are as you are working with Skin that can use anything in Max as a bone.

nildoe
10-09-2009, 09:08 AM
Hey Kogen...

Cat Bones you know from the CAT Toolkit plugin, like the Biped (Character Studio) but another animation Plugin, recently bought by autodesk and being distributed thru subscription customers as free.

http://download.autodesk.com/esd/3dsmax/cat-help-2010/files/WS7af5cac11814013a-37ebe48b11fde8bfe37-8000.htm

i asked especifically about CAT because in the Private message we exchanged u mentioned that u still have to have read Biped bones, so i thought that what PEN was suggesting was not valid.

Nildo

kogen
10-09-2009, 02:31 PM
PEN: You're definitely right. Anyways, I guess I have to make some decisions against that feature to use any object as bone. If you could use everything as bone, than the distance function wouldn't work properly. Atm. it calculates the nearest bone or bone geometry. When it calculates the nearest object it is possible, that other meshes like attachements for your character are found. So I guess there must be some restrictions.

Nildoe: I think I have to test it... or someone else who owns CAT if I stick to the BoneGeometry condition. maybe CAT bones are still stored as Bone geometry. :shrug:

labbejason
10-09-2009, 04:41 PM
You could always include a list of classes that the user chooses.

kogen
10-12-2009, 06:36 PM
Hei guys,

good news, the development is making some progress. The user is now able to use the script with bones and biped no matter how they are named ;)

I've taken out the geometric distance and added the edge distance as mentioned some days ago.

To cut a long story short, here is a little video, that shows how you can apply skin weights to a character using biped and Autoweight.

Autoweight - Biped video (http://www.kogenspage.com/anims/aw0015_00.swf)

nildoe
10-13-2009, 01:09 PM
Hey Kogen..

indeed is looking really nice...although i would have prefered to see a more "stressing video":)...having her making extreme poses to really see how good of a job your script did

keep up :)

if u need someone to test with CAT..lemme know ;)

Nildo

tarcus
10-13-2009, 02:43 PM
Hey,

i really like the approach you took for this and it looks all good and seems to be fast. But I would really like to see a strong and extreme pose to see how it does, since there is not a lot deformation in a walk-cycle :)

Cheers

kogen
10-13-2009, 07:15 PM
Hey guys,

allright, I see your point. I'm planning another video skinning a hand. And yeah, including some extreme poses of that girl, sounds like a good idea to show what the script can / can't.

Thanks for your remarks.

Steve Green
10-13-2009, 07:19 PM
Thats looking very, very good.

Cheers,

Steve

kogen
10-28-2009, 02:56 PM
Morning guys,

sorry for not posting any information since two weeks. I was a little occupied with some other stuff.
Since the last version I made the edge selection more comfortable. Over this I've added a "negative Edge Distance" making it possible to create smooth transitions in both directions of a transition border.

Here's a new video... (http://www.youtube.com/watch?v=H1Ye6uyuX4I) (Youtube)

nildoe
10-29-2009, 07:24 AM
Hey Kogen

VERY nice update :)

when u think it will be finished?

Nildo

hotknife
10-29-2009, 10:14 AM
That is looking great.

kogen
10-29-2009, 03:25 PM
Thanks a lot, guys.

Nildoe: I know you'd like to start immediately. Please, give me some time to tidy up the code and fix some minor issues. But I guess we're close to a stage where I won't be able to test it on my own. :)

kogen
11-01-2009, 07:51 PM
Allright, reached that point.
If there is someone who likes to fill out the laborious position of a tester, please send me a PM, and I try to get back to you soon.

CerberusC
11-03-2009, 02:09 AM
I'm doing right now a little demo of a real time videogame, i'll be doing a couple of characters, also i think i'll be doing some character animation in a few time so if you need some test i think i can provide you with some testing.

Cheers.

tarcus
11-04-2009, 09:39 AM
I would like to read into your code, so if you want to make it public I would appreciate that...

eek
11-04-2009, 03:00 PM
I would like to read into your code, so if you want to make it public I would appreciate that...

Same here - definately interested in this. Thinking about other ways you could do this, namely atlas mapping based approach or defining areas of soft, hard and sliding masses.
currently i tend to build lower poly versions, skin them and wrap the hires to them.

Polimeno
04-20-2010, 09:36 PM
Same here - definately interested in this. Thinking about other ways you could do this, namely atlas mapping based approach or defining areas of soft, hard and sliding masses.
currently i tend to build lower poly versions, skin them and wrap the hires to them.

Same here !

PEN
04-20-2010, 09:48 PM
Nice work, count me in for the code base as well if you are going to share.

zimOne
04-21-2010, 10:08 AM
ehi man, this tool's looking great.
it would be saving much time.
Are you willing to distribute it once finished? (eventually coded at least for max 2009/2010) I'm very interested on it.
I would love if final version will also be able to export/import correct vertex weighting, it would be very useful.
Good work

kogen
04-21-2010, 03:16 PM
A long, long time ago...

I'm sorry for keeping silence for so long but... I've been busy.
Nevertheless I knew I had to release the script one day so I'd like to do it today.
That's the actual state of the script. I hope it will work on your machines. Can be used theoretically (not tested yet) with Max 8, 9, 2009 and 2010.
The script won't work with CAT bones, they are pretty fancy, I know but tricky as well.

Maybe someone likes to add something. :)

You can get it from my page -> here (http://www.kogenspage.com/content/scripts/Aw0.02.zip).

Cheers "ko'gen".

doCHtor
05-23-2010, 09:03 PM
Great work and thanks for sharing. Any chance you will make it work with CAT one day?

Wheiraucher
10-17-2010, 09:52 PM
very nice script. But is it possible to redefine which bone belongs to which region? I have successfully initiated the mesh points and the bones plus regions have been found automatically, which is super cool. But two of the bones affect the wrong region. Bone2 should affect region1 and bone1 region2.

I tried to move the regions and/or bones in the lists to properly match my scene, but it obviously isn't possible. Is there a different approach that I should take? If not, maybe you could add the feature?

kogen
08-17-2011, 06:12 PM
Ooops and hei,

at first let me say that I'm sorry cause I haven't replied to lots of questions about the script cause I had absolutely no idea how to go on with it.
Dunno why but I took some old ideas and did a little bit of research on the net to develop new ones.
But one step after another:

@doCHtor: I know it's a big weakness that it doesn't work with CAT right now. I know about this problem but with the actual script "architecture" it will be horrible to include CAT-Bones.

@Wheiraucher: Yep I know this problem that's why I scripted kind of a XChange-function (that is not very user-friendly but it it's there. Just go to my page and download the actual version. There should be PDF in ZIP-file explaining how to do that.

But what's new, now?

I came to the point where I ran into problems with approaches that just take care of the mesh and read about a volume approach. Unfortunately it's necessary to voxelize the mesh which is not possible in 3DS Max (if you imagine something like in 3D Coat). But it's possible to create a rough volume approximation in finite time.
http://forums.cgsociety.org/attachment.php?attachmentid=163484&stc=1

So what you can see in the image is that approximation. I've created a 70 x 70 x 70 "Voxel-Grid" for the mesh which I named Igor. (First image, left) In the second image you can see the "voxel-areas" which I visualized just for that picture by creating cubes together with Igors geometry. The last image shows the "voxel-areas" without Igors geometry.
The whole creation took... 3 minutes which is quite long cause the runtime is O(n), since I have a triple loop. I guess I'll run into problems when I want to create a denser voxel-grid. Does anybody have an idea how to optimize the runtime?

I'm eager on working on that script-approach.

MatanH
08-18-2011, 08:10 AM
Hi kogen,
I had once tried to do the same thing as you do here, but had no time to finish it and later forgot about it. Any how I found an algorithm that can speed up the voxilization process.
It went something like this:


loop along the x bounding box edge using 'c' as the step size
loop through the y bounding box edge using the same step size
fire a ray from where you "stand" at the direction of the z axis
determine if you are inside the volume or outside the volume
if inside, go to where the ray hit, else, all voxels between where you stand and where the ray hit are occupied.
continue in that fashion until you get to the end of the bounding box.


to determine if you are inside or outside the volume I used this method (O(1)):
intersectRay only hits a mesh face only if it is fired on the side of the face that points in the direction of it's normal. So I fire one ray on the object, then I use a normal modifier to flip the normals of the object and fire another ray.
cases:

the first ray had a hit and the second didn't: you are outside the mesh.
the first ray missed and the second had a hit: you are inside the mesh.
both rays missed: you are outside the mesh.
both rays hit: if the first ray hit closer then the secons, you are outside, else you are inside.


P.S: you should choose the 4rd axis in the algorithm to be the longest.

Hope this helps..
M.

kogen
08-18-2011, 01:50 PM
Hei TzMtN,

yeah, I saw your approach when I was checking the forum if there was kind of voxel-technique in Max. :D

Actually my Script heads in your direction. I scan in every direction twice to see if I'm inside or outside the mesh with normals flipped on. That is all cool and actually I liked the idea to leave out an axis and only go with two axis like a 3D printer.
What frightens me with your approach is that I'd have to flip the normals for every region a ray hits. That would become an enormous runtime. :/
Or do I get something wrong?
Another approach I thought about was: Copying the mesh flippimg the normals and so having two meshes stick into eachother. Then you'd have to store all the points a ray hits and use kind of a recursive function to get all points in one ray-direction... my problem is, that Max crashed when I wanted to test more than 4 Points that had been hit :D

MatanH
08-18-2011, 02:42 PM
Another approach I thought about was: Copying the mesh flippimg the normals and so having two meshes stick into eachother. Then you'd have to store all the points a ray hits and use kind of a recursive function to get all points in one ray-direction... my problem is, that Max crashed when I wanted to test more than 4 Points that had been hit :D

Could you explain exactly what is your algorithm and / or post a code example?

kogen
08-18-2011, 03:13 PM
Of course, but since Max crashed I can only rewrite the pseudo-code from my imagination:

0. I've cloned the model, flipped all faces of the clone and attached it to the original.
1. I've created a recursive function saying: If ray hits a surface, take the actual hit-position and start this function again from the last hit-point... and so on. The recursion stops if the ray is undefined.
For a cylinder shoot in X direction this would lead to: First hit (outer hull), second hit (inner hull (flipped clone)), third hit (inner hull other side), fourth hit (outer hull (other side)), stop.
2. Now I found four points (where two points are identical) and theoretically I can now say where is inside and outside and fill the inside of the object with "voxel areas". I thought that this method might be cool if it comes to overlappings such as "If two feet are standing next to eachother". Cause so I'd find the first foot outside and the other side of it and then I'd find the second foot.

Was this clearer?

MatanH
08-18-2011, 03:28 PM
Yes it was.

My guess is that when you fire the ray from the point of the last hit, and because of precision reasons it is maybe possible that you hit the same surface again and thus entering an infinite loop. This will cause max to crash.
In order to avoid such a problem you could move a bit forward from the point of the last hit before firing the next ray. A recursive function by itself wouldn't cause max to crash, only if it leads to an infinite loop.
About flipping the normals. From your description it sounds like you are manually flipping every face using a loop. If this is the case, then you should try to use the normal modifier instead.
You said that when using my algorithm, the bottle neck was to flip the normals every time back and forth, you could instead make a duplicate of the original object without attaching them, and fire a ray on both of them. In some cases you can even avoid firing on both of them and determine your status with only one ray.

Hope this helps,
M.

kogen
08-21-2011, 08:31 AM
Allright I found the error, corrected it and came to the point where the voxelation isn't the real problem.

Actually voxeling the mesh was quite cool. It took the algortihm three minutes for splitting up every axis proportionally in at least 50 steps per axis. This was cool.
The real drama began, when I started searching for the shortest distance.
At first it seemed cool, cause since it's a grid every neighboring voxel has the same distance which meant that I wouldn't have to deal with complex Depth-Search-Algorithms which might slow down the system and use a lot of memory.
So I went directly to the Breadth-First-Search to expand the selection stepwise and so to find the voxel that contains the mesh-point that is the nearest neighbor to the voxel that contains the bone-point.
This was a desaster. Cause it takes the algorithm 20 seconds for a distance of 10 in a voxel grid with the extension: 31x 13 x 38. Imagining that this has to be calculated for every meshpoint with every bone-point leads to an enormous runtime even if I limit the max possible distance after the algorithm would have to stop. Sooo... programming it in C++ might perhaps solve the problem but I really ask myself if the basic problem isn't rather the approach of using a volume or the search for a shortest path.

doCHtor
08-21-2011, 08:39 AM
@doCHtor: I know it's a big weakness that it doesn't work with CAT right now. I know about this problem but with the actual script "architecture" it will be horrible to include CAT-Bones.
I see, and hope that one day you will include CAT (seems like it will be with us for some time). To be honest though, right now it's not a problem for me because I started to use 2 rig systems for my characters - CAT is for animation and max-bone based copy of the rig that's constraint to CAT bones is used for skinning.

Reading through the tech talk you and TzMtN are having (which is beyond my knowledge :) ), I would like to say that if the skinning would work great, then some long but sane times it would took to autoskin the mesh would be ok - still would save lot of boring work.

kogen
08-21-2011, 07:44 PM
:) You're right if we would be talking about "long" in the sense of "having an end" then this would work. But the problem with that approach was, that it allocated so much memory that your PC would have hung even before you'd have had any vertex skinned.

Buuuuuut I was pretty excited when I recognized that I assumed things in a wrong way: I thought that you'd have to calculate the shortest path from every bone-voxel to every Meshpoint solely. But that is impossible and I even would say "wrong". I guess one "just" has to calculate the shortest path in the voxel-grid from the bone-point to a n y other voxel which is no problem of finding a specific voxel but finding all voxels. This is still a bit expensive but takes less time.
At the moment calculating the shortest path to any voxel for one bone is around 25 seconds (Voxelgrid density: 56 x 23 x 68). I guess that can be speeded up if the user sets something like an exit value cause it makes no sense to calculate the shortest path for e.g. the voxels in the head if you want to skin the foot. :)

doCHtor
08-21-2011, 08:18 PM
Ok, I will be watching this thread with great interest :) .
Good luck.

TheGrak
08-24-2011, 09:58 PM
"Does anybody have an idea how to optimize the runtime?"

Instead of rayCasting, you could use an octree (http://en.wikipedia.org/wiki/Octree) or a bsp (http://en.wikipedia.org/wiki/Bsp_tree) tree to determine if you are in/outside of a mesh. Havaard and Denis had a great discussion with snippets here (http://forums.cgsociety.org/archive/index.php/t-988253.html). You might also consider a kd tree (http://en.wikipedia.org/wiki/Kd_tree)... or even a Rtree (http://en.wikipedia.org/wiki/R-tree).

marktsang
08-24-2011, 11:13 PM
hi,
about a year ago i wrote a plugin in max 2009 that does this as well as some other useful skinning stuff
i used octrees to accelerate
ill try dig it out and post some videos and benchmarks....as far as i remember it wasnt terrribly slow at a resonable grid density!

mark

kogen
08-25-2011, 09:01 AM
Hey Mister Gark, I've already thought about a bsp-tree but was a bit "scared" to implement it cause one of the conditions says "Cut through those polys where you get the least new polygons" which would mean that I would have to implement some kind of "determination feature" and so on. But there reamains still another question: What do you mean, when you're talking about having an octree without doing a raycast test? How do I determine if I'm inside the volume if I don't test whether I'm inside? :hmm:

@Mark: That sounds great! You should show us the script... now I ask myself if I really should go on with this one... :)

kogen
11-05-2011, 04:58 PM
Allright.

Finally I managed it. I'm about to release that little script shortly. If you're interested, please feel free to check out that video.

Autoweight 0.030 on Youtube. (http://www.youtube.com/watch?v=c33exYs68uk&feature=youtu.be)

-k.

doCHtor
11-05-2011, 05:24 PM
Looks fantastic. As I already said, I will be hoping for CAT support too.
Will this be a free script? If so, it will be encrypted or there is a chance for me to try to get it work on CAT?

kogen
11-05-2011, 06:00 PM
Heya,

of course it will be free. :)

Though it's not implemented yet, I strive for a CAT support. With the new "region-selection" instead of "loop-selection approach this might be possible. The only thing I need to know: Where do I switch on CAT-bones in Max? Basically I thought it is now fully integrated but maybe I need to download the plug-in first?

kogen
11-11-2011, 07:44 PM
Allright. So here we go with version 0.030.

If you are interested in the script, you can download it from my page in the stuff section (have to scroll down) Look here (http://www.kogenspage.com)

There is also a Youtube-Video (http://www.youtube.com/watch?v=SX35677xJRU) explaining every button and the workflow of the script.

-k

doCHtor
11-11-2011, 08:21 PM
Thanks for sharing, will try asap.

As for CAT, as far as I know, it's integrated at least in 2011 and 2012, not sure about older versions. You can find it in "Helpers/CAT Objects".

doCHtor
11-11-2011, 08:56 PM
A very quick attempt with CAT. Seems to work on my side, but really, this was really quick, will have to check it out better.

kogen
11-11-2011, 09:03 PM
Hehe you really want this implementation, do you :D

Actually I think we should implement it by using matrices of bones and maybe this changes the whole CAT-thing... I mean it maybe makes it easier... :)

doCHtor
11-11-2011, 09:11 PM
Hehe you really want this implementation, do you :D
Sure, are you surprised? You made the script so I guess you have your own issues with endless skinning :D.


Actually I think we should implement it by using matrices of bones and maybe this changes the whole CAT-thing... I mean it maybe makes it easier... :)
Not sure what you mean by this. You should know I'm more maxcript hacker then skilled maxscripter :). I added like 2 lines, so not sure what could make it easier then that.

kogen
11-12-2011, 08:11 AM
Heya,

when I was writing the matrix comment two hours later I had forgotten what I actually wanted to do... maybe that thought will come back later...
It was not that easy to include the CAT-system but it works now. The only problem is, that CAT has those Hub-sections that have to be included as bones too. So it happens that the script find the wrong regions after passing the Hub-Bones... to cut a long story short: It works with CAT but you might have to manually re-select the correct bones after that everything else (setting up the weights) was running normally during my tests. Thanks for the constant requests for that :)

Just download the archive again from Scriptspot or from my page and install it again, I just altered version 0.030 and didn't create a new one.

-k.

doCHtor
11-12-2011, 08:24 AM
Thanks, great job there.

Sorry to bother you, but for my own learning purposes, could you please explain why are you first collecting CATParent and it's all nodes:

if classOf obj == CATParent then
(
ArrBonesCAT = obj.CATRigNodes -- select reall ALL CAT-Parent.Controller Children
)
and then filter through them via:
for obj in ArrBonesCAT do
(
if classOf obj != CATBone and classOf obj != HubObject then
(
deleteItem ArrBonesCAT (findItem ArrBonesCAT obj)
)
)

What's the advantage of doing that compared to checking directly for CAT bone in the all scene objects:
if (classOf obj == CATBone or classOf obj == HubObject) then append ArrBones obj

Thanks

kogen
11-12-2011, 09:02 AM
Good question. :)

Actually when I was trying this I didn't recognize. There were HubObjects too. So I seemed to get the wrong hierachy.
To fix this, I used the Rootobject.CATRigNodes which gets you the complete hierachy. In the next step I just kick out the objects which are not CATBones or HubObjects.
It may work with your approach but I'm not sure if the hierachy stays correct.
In every case the method that is implemented now, stores the correct hierachy so we don't get in trouble with that.

doCHtor
11-12-2011, 09:04 AM
Oh, I didn't realize hierarchy is important.. doh :scream:

kogen
11-12-2011, 09:55 AM
Of course it is.

The easiest way to explain this is if you'd think of the way you'd normally skin a character. You wouldn't start with the pinky. You normally start with the pelvis or somewhere in this area and move on along the bone hierachy.

http://forums.cgsociety.org/attachment.php?attachmentid=165085&stc=1

To get more complex I've attached an image showing a schematic explanation what might happen.
In the first picture you can see four regions. Let's say the hierachy is like this: Blue -> Red -> Turquoise -> Green.
This results of the skin weighting is shown in #2 (yellow falloffs). Blue influences some points in red, red influences some points in green and turquois. Allright.
If we make the hierachy like this: Turquoise -> Blue -> Red -> Green than the result looks like #3. You can see that the falloff is now for Turquoise and blue in the red region which might be okay if it was symmetrical but since red is higher than green the falloff from red is influencing points in the green region which would look awkward when we imagine a symmetric character.

For me this seemed to work out but I agree with you, if there is another method of not taking the hierachy into account I'd use it grateful.

doCHtor
11-12-2011, 10:07 AM
So with this approach, hierarchy favours parent regions... I mean, parent region has it's weight + the blending is going into the child region, right?

Wouldn't it work if hierarchy as such is ignored and only pairs are used? What I mean by that is that there would be "equal partnership" between regions which would be associated with appropriate bone pair (again without caring for hierarchy, just pairs). Blending would then happen into both regions equally. But I have a feeling I don't understand some key idea here :)

kogen
11-12-2011, 10:57 AM
I have the impression that I did something like this before, but can't remember why I didn't include it. Should give it a try.

eek
11-12-2011, 07:12 PM
Nice, very nice - looks like you headed towards atlas skinning in the end.

http://www-evasion.imag.fr/Publications/2008/LHGT08/RR-6406.pdf

kogen
11-12-2011, 11:29 PM
Oh no, he found it out :D

Yeah, you're right. Basically I wanted to use the atlas - coloring method when I started back in 2009 but Max didn't support the "Face-Coloring"-Feature which was the reason why I dropped the idea. It all changed when they included it in Max 2010 which I just found out a couple of weeks ago ^^
Anyways I have an idea (just a rough one) how to find the regions automatically using an equal method as they describe when it comes to finding the regions by defining if a "border edge" of that region had been hit or had not. So I just left some interesting stuff to research for the next weeks.

Thanks Mr. eek. :)

eek
11-13-2011, 05:34 AM
Oh no, he found it out :D

Yeah, you're right. Basically I wanted to use the atlas - coloring method when I started back in 2009 but Max didn't support the "Face-Coloring"-Feature which was the reason why I dropped the idea. It all changed when they included it in Max 2010 which I just found out a couple of weeks ago ^^
Anyways I have an idea (just a rough one) how to find the regions automatically using an equal method as they describe when it comes to finding the regions by defining if a "border edge" of that region had been hit or had not. So I just left some interesting stuff to research for the next weeks.

Thanks Mr. eek. :)


Yep its pretty neat - I'd like to see regions assigned to multiple joints e.g. Upper leg, lower leg, knee faces assigned to both. Displaying the border verts would be neat and allowing there assignment too would be cool for joints used just for spreading deformation and not weighting a whole region.

Must look into this myself sometime.

kogen
11-13-2011, 05:41 PM
Oh I see what you mean. Cool ideas. I think some of them might be easy to implement, others might need some time especially cause I have to figure out how to make it all "flowing". The worst thing would be if the user would be slayn by thousands of menus.
So for today I added a little curve control to let the the user change the falloff type of their transitions took me a while to fight against the curve-control UI element but in the end it was okay.
I'm currently thinking about the possibility of storing a "transition-edge distance" for every bone individually.

kogen
11-14-2011, 12:53 PM
Just in case some of you downloaded it on Sunday, tested it with CAT and got pretty upset about the poor functionality... please donwload it again and try it once more. I've fixed the "CAT-bones-are found-in-weird-order"-bug.

-k.

kogen
12-31-2011, 08:28 AM
New year, new version Autoweight 0.055 is available.

http://www.scriptspot.com/files/aw0.055_0.png

Click here to go the scriptspot-page to donwload the current version. (http://www.scriptspot.com/3ds-max/scripts/autoweight-automatic-skinning-tool-for-3ds-max)

Click here to read about a couple of new features on scriptspot. (http://www.scriptspot.com/3ds-max/news/autoweight-0-055-is-out)

Click here to watch a new tutorial-video. :) (http://www.youtube.com/watch?v=x9H-QFXg_Bo)

Happy new year ko'gen

doCHtor
12-31-2011, 08:54 AM
Thanks for the nice present. Having mirror function is absolutely fantastic :)

edit: Would it be too much to ask for some next version to have a check box for mirror stuff to work on topology symmetry? What I mean is that often there are character's who's topology is symmetrical, but for some reason a mirror vertex or poly is in different distance from the mirror plane.

kogen
01-08-2012, 02:45 PM
Ahm... interesting question. Honestly, I have currently no idea how to implement such a topology method. Any suggestions?
What I could easily implement is a threshold value which would give you the opportunity to select a point if it's a bit displaced from its actual mirrored position. Another idea might be adding kind of offset like they have done on the skin-mirror tab to move the mirror plane manually which would also be pretty easy.

-k.

Kickflipkid687
01-08-2012, 03:23 PM
I don;t skin anything most of the time, but I think this script is still quite awesome.


As for doing the offset, that seems like the fastest/easiest fix to do, and if it doesn't work out, you can always do the harder approach if need be. :)

doCHtor
01-08-2012, 03:52 PM
What I could easily implement is a threshold value which would give you the opportunity to select a point if it's a bit displaced from its actual mirrored position. Another idea might be adding kind of offset like they have done on the skin-mirror tab to move the mirror plane manually which would also be pretty easy.
-k.
All those would help.


Ahm... interesting question. Honestly, I have currently no idea how to implement such a topology method. Any suggestions?
-k.
No idea, I'm only occasional scripter :)
But here is what I meant to exclude any confusion - mudbox symmetry (http://download.autodesk.com/us/mudbox/help2010/index.html?url=WS1a9193826455f5ff-6d855556117c4584e54-2888.htm,topicNumber=d0e11261), scroll down to the "Set a topological axis "/bull image :)

kogen
05-27-2012, 06:26 PM
Allright, so here we go with the latest version. Though the UI might look similar to the previous version I did some coding work to fix the improper "find-region-by-bones" algorithm. Not sure about your tests but mine have been quite satisfying so far. You may give it a try. :) (http://kogenspage.com/content/scripts/Aw0.058.zip)

ko'gen

johnwhile
05-28-2012, 11:46 AM
for a game a build a quick weight methods, the game need maximum 2 bone for each vertices. About your tool: if a skeleton exist can assign the best weight and apply a correct smoothing value into join ? Can i use your script with another script ?

/*
This script found all geometry with a Skin modifier and apply a best weight for each vertex.
In this version compute the best proximity with rigid weight (1.0), in next version i will
make also a no-rigid weight
*/

Struct BONESKINSTRUCT
(
iskin = 0,
mark = #{}, --vertex list assigned
smth = #{}, --vertex list that need a smooth value
pos = [0,0,0], --start of bone vector
end = #() -- all children pos
)

Struct FIND_VERTEX_WEIGHTS
(
nodes = #(),
smoothJoint = FALSE , -- is a beta
fn getDistanceFromBone tbone P &smth=
(
local A = tbone.pos
local AP = A-P
local endCount = tbone.end.count
if endCount > 0 then
(
local dist
for i=1 to endCount do
(
local into , bestDist
local B = tbone.end[i]
local AB = A-B
local BP = B-P
local outA = dot AB AP < 0
local outB = dot AB BP > 0
local distPB = length(BP)
local distPA = length(AP)
local distPAB = length(cross (AB) (AP))/length(AB)

bestDist = if outA and not outB then ( into = false ; distPB) -- out A -> get distance from point A
else if outB and not outA then (into = false ; distPB*1.01 )-- out B -> get distance from point B with a little penalty to assign
else ( into = (distPAB/distPB) > 0.5 or (distPAB/distPA) > 0.5 ; distPAB )-- in A and B -> get distance from line AB -- if is exactly near B prependicular vector == 1

if i==1 or bestDist < dist do (dist = bestDist ; smth = not into)
)
dist
)
else ( smth = false ; length AP)
),
fn setBestWeight =
(
clearlistener()
--progressStart "Finding Skeleton Weight"

progress1 = 100.0 / nodes.count
for h=1 to nodes.count do
(
progressOne = progress1*(h-1)
--progressUpdate progressOne
local obj = maxops.getnodebyhandle nodes[h]
format "\n# Finding best weight for obj:\"%\" #\n" obj.name
st = timeStamp()
local nVerts = obj.numverts

--------------------------------------------------
/* Get Bone informations */
--------------------------------------------------
local skinMod = obj.modifiers[#Skin]
if skinMod==undefined then continue
SetCommandPanelTaskMode mode:#modify
ModPanel.SetCurrentObject obj.skin
if ModPanel.GetCurrentObject() != obj.skin do (print "*** SHIT SKIN MODIFIER DON'T WOK ****" ; return undefined)

--max modify mode
--modPanel.setCurrentObject skinMod
local nBone = skinOps.GetNumberBones skinMod
local BoneSkin = #()
local BoneSkinHandle = #()
local BoneSequence = #()
BoneSkin.count = BoneSkinHandle.count = nBone
for b=1 to nBone do
(
local bnode = getnodebyname (skinOps.GetBoneName skinMod b 1)
BoneSkin[b] = BONESKINSTRUCT iskin:b pos:(bnode.pos) end:(for child in bnode.children collect child.pos)
BoneSkinHandle[b] = bnode.handle
)
format "> inizialize skin bone in % ms\n" (timeStamp()-st)
st = timeStamp()

--------------------------------------------------
/* Find nearest bone for each vertex */
--------------------------------------------------
progress2 = progress1/nVerts

local RigidVertex = #{}
for v=1 to nVerts do
(
--progressUpdate ((v-1)*progress2+progressOne)
--format "> Find nearest for v %\n" v
local vertex = getVert obj v
local nearest , mindist , needSmooth
for b=1 to nBone do
(
local smth = False
local dist = getDistanceFromBone BoneSkin[b] vertex &smth
if b==1 or dist <= mindist do (mindist = dist ; nearest = b ; needSmooth = smth)
RigidVertex[v] = needSmooth
)
BoneSkin[nearest].mark[v] = TRUE
)
for b=1 to nBone do for v in BoneSkin[b].mark do skinOps.ReplaceVertexWeights skinMod v #(b) #(1.0)

format "> get first proximity in % ms\n" (timeStamp()-st)
st = timeStamp()

if smoothJoint do
(
--------------------------------------------------------------------------
/* Find all valid joints es: join 0-1* , join 1-2 , joint 1-3 , joint 2-4
(2)--(4)
/
(0)---(1)---(3)
* : ha due figli, prendo una bisettrice come media tra i due */
--------------------------------------------------------------------------

local joints = #()
for b=1 to nBone do
(
first = maxops.getnodebyhandle BoneSkinHandle[b]
for second in first.children where (c = finditem BoneSkinHandle second.handle)>0 do append joints #(b,c)
)
for n=1 to joints.count do
(
local b1 = joints[n][1]
local b2 = joints[n][2]
local bone1 = maxops.getnodebyhandle BoneSkinHandle[b1]
local bone2 = maxops.getnodebyhandle BoneSkinHandle[b2]
format "Joint \"%\" <-> \"%\"\n" bone1.name bone2.name

face1 = meshop.getFacesUsingVert obj BoneSkin[b1].mark
face2 = meshop.getFacesUsingVert obj BoneSkin[b2].mark
smoothVerts = meshop.getVertsUsingFace obj (face1*face2)

local smth = false
if smoothVerts.numberset>0 then for v in smoothVerts do
(
local vertex = getVert obj v
local dist1 = getDistanceFromBone BoneSkin[b1] vertex &smth
local dist2 = getDistanceFromBone BoneSkin[b2] vertex &smth
local W = normalize [dist1,dist2]
skinOps.ReplaceVertexWeights skinMod v #(b1,b2) #(W.y,W.x)
)

)
--setVertSelection $Line004 selectV
format "> optimize joints in % ms\n" (timeStamp()-st)
)
)
--progressUpdate 100.0
progressEnd()
)
)

/* utilize */
--algo = FIND_VERTEX_WEIGHTS nodes:(for obj in geometry where obj.modifiers[#skin]!=undefined collect obj.handle) smoothJoint:TRUE
--algo.setBestWeight()
OK

kogen
05-28-2012, 12:16 PM
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.

kogen
09-25-2012, 09:10 PM
Hurray New version 0.060 (http://kogenspage.com/content/scripts/Aw0.060.zip)

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

Good night.

denisT
09-29-2012, 05:18 AM
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.

kogen
09-29-2012, 06:55 AM
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 (http://webee.technion.ac.il/%7Eayellet/Ps/0325_ayt.pdf) which is the foundation for automatic skinning. Or take a look at automatic skinning processes gotten from mesh animations (http://forums.cgsociety.org/Automatic%20Conversion%20of%20Mesh%20Animations%20into%20Skeleton-based%20Animations) 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.
(http://webee.technion.ac.il/%7Eayellet/Ps/0325_ayt.pdf)

martinez
09-29-2012, 09:54 PM
@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!

denisT
09-30-2012, 03:12 AM
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.

martinez
09-30-2012, 06:21 AM
@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().

kogen
09-30-2012, 07:19 AM
@ 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.

denisT
09-30-2012, 12:28 PM
@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.
Areas where the skin modifier can improve:
1. ... 6

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\ttime:% memory:% verts:%\n" (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\ttime:% memory:% verts:%\n" (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\ttime:% memory:% verts:%\n" (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\ttime:% memory:% verts:%\n" (timestamp() - t1) (m1 - heapfree) ss
)


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

martinez
09-30-2012, 06:28 PM
@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!

denisT
09-30-2012, 07:43 PM
I just tested a few of my tools with your updates. They went from 3.1 seconds to about 97ms.

~30 times faster. that's a good sample how the right tool can save a development time :).
but the function GetSkinVertexSelection which is only 8 lines on of c++ code takes nothing. i've called it on 20K skin and it gave me 0.3 ms.

kogen
09-30-2012, 09:25 PM
8 ms with method 4, 1154 ms with method 1. That's amazing.
Thanks a lot!
I'd be interested how you came about this exciting trick, Denis?

denisT
09-30-2012, 10:22 PM
I'd be interested how you came about this exciting trick?
I can't say how ... I kinda feel some trick in every max function, interface, plugin. I say myself: "It can't be so bad. There must be a catch in it." ;)

denisT
10-01-2012, 02:22 AM
8 ms with method 4, 1154 ms with method 1. That's amazing.
do you know about unwrap_uvw sub-object convert selection? it's slow. it's slow if you follow mxs help. there is a trick that makes it 10 times faster.
another sample... edit_normals modifier... SetNormal is very slow. but it can be ~20 times faster.
dig, dig, and dig deeper...

denisT
10-01-2012, 02:52 AM
the skinops interface... everyone knows that all its methods/functions work only if the Skin modifier is a current modifier panel object. Right?
funny. i've checked the skin related classes... there is no this limitation! probably the skinops developers invented it smoking a cool stuff.

lanimal
10-01-2012, 02:23 PM
In case of the skinops interface.
You use sdk functions to avoid the problem if i understand well.
Is it as fast to forbid ui refreshing? With hwnd stuffs?

denisT
10-01-2012, 03:04 PM
In case of the skinops interface.
You use sdk functions to avoid the problem if i understand well.
Is it as fast to forbid ui refreshing? With hwnd stuffs?
disabling redraw doesn't give you to much. almost all skinops interface edit functions send too many messages to the skin which causes every time the mesh recalculation. using sdk you can do a block of operations first and only after that notify the skin about changes. the difference is huge!
but my skin tools use skinops. i wrote only several key functions on c++/sdk. sometimes i distribute a tool without c++ plugins. so it has to work (mayby slower) but anyway.

lanimal
10-01-2012, 03:27 PM
Ok thanks for the answer.
It's perfectly clear now why skinops is so slow.
I'll stick to maxscript and disabling redraw since the C++/sdk is still a little too hard for me.

martinez
10-02-2012, 03:08 AM
@Kogen

Okay I used this tool all day skinning some very complex characters. I gotta say, using poly selection tools to "skin" makes it go much faster. The blending you are doing is awesome. I only hads to manually edit a few edge loops.

My only issues with the tool are UI related:

1. I had to modified the script to not use any image buttons. The icons were too similar and I kept clicking the wrong ones. Now the tool just says Set, Get, Mirror, ect..

2. I changed the setupBones function to get all the objects in a selection set named Bones. The autodetect kept picking up spline controllers and other objects. Many of my bones don't have nubs, and you formula removes bones with no children.

3. The "Pick" button wasn't replacing the bone assigned to the cluster.

4. I wish the cluster was assigned a bone when I clicked the Set button. I would just feel more in control.

5. I made the dotNet list box 2x the height. It felt very crowded with over 60 bones.

6. I wish there was a Move to Top and Move to Bottom buttons for the listbox.

Thanks again!

denisT
10-02-2012, 04:10 AM
I used this tool all day skinning some very complex characters. I gotta say, using poly selection tools to "skin" makes it go much faster.
my question for everyone who does do skinning. what selection features are you missing in the Skin modifier?

lanimal
10-02-2012, 08:37 AM
I don't skin every day but the basic component selection with convert beetween poly/edge/vertices are pretty much all you need.
Maybe mirror selection and selection by Id may be useful for isolating certain parts.
That's all i see but i'm not a full time rigger

MattRennie
10-02-2012, 08:42 AM
my question for everyone who does do skinning. what selection features are you missing in the Skin modifier?

I end up using skin or die as it has a much better floating ui for selecting bones. The default skin modifier listbox is far too small.

martinez
10-02-2012, 04:13 PM
I don't skin every day but the basic component selection with convert beetween poly/edge/vertices are pretty much all you need.
Maybe mirror selection and selection by Id may be useful for isolating certain parts.
That's all i see but i'm not a full time rigger

I agree that what you mention is important, but I don't think that's all you need.

What I need is all the poly selection tools available in Editable Poly. Select a component, shift select an adjacent component to get a loop (Vertex, edge, or face). There is an entire tab in the Graphite tools dedicated to subobject selection. I don't see why skin is limited to vertices and elements. The reason I'm excited for Kogen's tool is because it makes those selection tools available.

Again I'll compare to UV Mapping. When I UV map I'm only creating UVs for the vertices, yet all components are available to select. In general it would be nice if sub-object selection were unified in all the modifiers.

lanimal
10-03-2012, 08:49 AM
Originally Posted by martinez
Again I'll compare to UV Mapping. When I UV map I'm only creating UVs for the vertices, yet all components are available to select. In general it would be nice if sub-object selection were unified in all the modifiers.
Absolutely agree about unification, that's what i meant when talking about converting selection. Sorry if it wasn't clear ;)

rizki29
10-04-2012, 12:44 PM
i have problem with autoweight
http://imageshack.us/a/img832/5439/20121004203630.png
its always show when i want make a region how to fix it ?

kogen
10-12-2012, 10:18 PM
Have you tried version 0.061? Watching the code, I think you're ussing a version before that.

-k.

denisT
10-12-2012, 11:30 PM
you know how SetFaceColor slow is, doesn't you?

kogen
10-13-2012, 06:06 AM
Hi denis,

yes, now I know but by the time I've implemented it, I did not. I guess it will take some time to change all setface-orders properly as you suggested.
It's on my list.

DFiredman
10-17-2012, 10:30 AM
Nice, but,

I get this error when press "Skin weights" button:

"Runtime error: requested sub-object level out of range:1"

:shrug:

I use max11 and autoweight 061

DFiredman
10-17-2012, 01:04 PM
Nice, but,

I get this error when press "Skin weights" button:

"Runtime error: requested sub-object level out of range:1"

:shrug:

I use max11 and autoweight 061

martinez
10-17-2012, 09:09 PM
I've been using this quite a bit. I really like it. One feature that would be really nice is Import Regions from Object. Sometimes I forget to save the AWB file when I close the interface. The mesh still has all the regions I want colored by face, but the tool doesn't recognize them on re-open.

Alternatively, using okayToClose on the dialog with a prompt to save before closing might be useful.

rizki29
10-18-2012, 01:46 PM
it wont change to 0.61 still 0.52 after instal

CGTalk Moderation
10-18-2012, 01:46 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.