@NiN Oh trust me I understand. It makes me rather curious to know what it happening under the hood. I am halfway tempted to write an reader for the binary so just see all the information and how its laid out. I am thinking that the M3 format might read them as bones but they may not start out in life that way. They may just be packing them in as bones for the sake of size. Those Helpers may be points to help zero out the rotations of bones.
I am using the SC2 GE as my baseline since that is the reader/viewer that Blizz has provided. I have some auto rig scripts for max that I have to work on today, but I will see about kicking around the bones and such this weekend.
Or I may just write a Binary reader for the M3 format so I can see what it says in the file. I really want to see every last bit in that file and then decrypt that.
Unfuntuntely there is of course no one at Blizz that can give us the right information. However I can certianly gleen information based on what was not done or left behind. via naming and such.
You are going to have no end of issues with the Ultralisk. This is primarily due to the fact it has a bad name in the Bone heirarchy. You can see it in the SC2 GE (Star Craft 2 Galaxy Editor). If you turn on View Bones. You will see the ~DUP~ as a duplicated Name for its Tail. I have already Bugged this with Bliz on their Forums.
There are a number of models with Bad names. So the problem may not be entirely on you NiN. It may be on Blizzard's side for sending out bad models to begin with.
The ghost model has some issues with its heirachy to begin with as well. One of the key tip offs is that Dummy01 and such should be coming in as a DummyHelper and not a Bone. I am fairly sure that the Ref_* objects should all be Point Helpers (setup as Boxes) it looks like they are all being duplicated at the moment and made bones.
you can do something like the following
-- Existing Object
/*
* objExists() - Given an object name, with or w/o $, this tells if it exists or not.
* Returns true on exists, false otherwise.
*/
fn objExists objname =
(
name="";
if (objname[1] == "$") then -- already have $ in it?
name = objname;
else
name = ("$"+objname);
ret = execute(name+" != undefined");
return (ret);
)
to check to see if a name matches.
resulting in something like this
if (objExists("$"+"Ref_*")) then
(
print "Do something here"
)
I use this bit with more precision since I know the naming convention that I use in my own companies Rigs.
Last Gmax that I am aware was based on Max 5. As of Max 6 there were some changes to core script parts. The bone creation is much different in Max 6 and higher. There are also other max script changes as well. Which is one of the reasons you will see on most scripts that saw good for Max 6.0 and Higher.
You cna get a trail verision of Max, and if you have a student .edu email address you should be able to get a student version of Max. In most cases if you can get a your hands on a student ID you can get a student /Educational Verision of most any software fairly inexpensively. This is a much better route then dredging through the dark places on the internet for other methods.
<<reply 98589>>
Nin I would have responded earlier but I have work to do every so often =)
Oh don't even get me started on Max's rotation Matrix.
Really next time I am at Siggraph or GDC I am going to beat someone with a stick. A lot.
Some of the issues look to be coming from parenting. That is what I am starting out with at least. Why start there.
Glad you asked.
If you know the parent and the child of a bone it becomes a trival task in auto bone creation.
you get do the following:
[code]<br>
This is taken from Mike Comets Auto Rigger for Max 6 and Above. <br>
My Notes on this: <br>
-- ptToe and ptAnkle in the Auto Rigger are the locations of points that later become bones. <br>
-- since you are basically auto generating the bones on the fly you can do basically the same thing. <br>
-- Create points first for location, placement and parenting then Replace those with Bones.</p>
<p>vec = ptToe.pos - ptAnkle.pos -- get nice vector to determine Z up<br>
vec = cross [0,0,1] vec; -- now make vec more on side not front/back</p>
<p> bUL = BoneSys.createBone ptLeg.pos ptKnee.pos vec; -- upper leg<br>
<a href="http://bUL.name" rel="nofollow">bUL.name</a> = (prefix+"_upperLeg_"+LR+"_BN"); <br>
boneSetup bUL true mixColor:sideColor;<br>
bLL = BoneSys.createBone ptKnee.pos ptAnkle.pos vec; -- lower leg<br>
<a href="http://bLL.name" rel="nofollow">bLL.name</a> = (prefix+"_lowerLeg_"+LR+"_BN");<br>
boneSetup bLL true mixColor:sideColor;<br>
bFT = BoneSys.createBone ptAnkle.pos ptBall.pos vec; -- foot<br>
<a href="http://bFT.name" rel="nofollow">bFT.name</a> = (prefix+"_foot_"+LR+"_BN");<br>
boneSetup bFT true mixColor:sideColor;<br>
bTO = BoneSys.createBone ptBall.pos ptToe.pos vec; -- toe<br>
<a href="http://bTO.name" rel="nofollow">bTO.name</a> = (prefix+"_toe_"+LR+"_BN");<br>
boneSetup bTO true mixColor:sideColor;</p>
<p>[/code]
This of course is just a sample. My intial thought on this is to Create an Array matrix to record the parent child relationships
This way I can create everything cleanly. This should remove the gimbal locks of most everything. BTW I HATE max rotations.
At the moment I am trudging through the 2000+ lines of script for the Importer. Looking primarily at the bones. It doesn't appear to be creating the bones quite right. It's close but just a hair off. Going to see what I can re-script on my end and work out. Its a great script, btw.
One thing I also noticed is that the exporter is not handling point helpers correctly, or not at all. I have not looked over that piece just yet. Just started looking at the Importer to beging with. This should be a fairly easy solve, but I will know more once I start working through it.
Mike Coment has some nice code in relation to auto-generating bones. I am going to use that as a basis. At least that is the thought at the moment.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
@NiN Oh trust me I understand. It makes me rather curious to know what it happening under the hood. I am halfway tempted to write an reader for the binary so just see all the information and how its laid out. I am thinking that the M3 format might read them as bones but they may not start out in life that way. They may just be packing them in as bones for the sake of size. Those Helpers may be points to help zero out the rotations of bones.
I am using the SC2 GE as my baseline since that is the reader/viewer that Blizz has provided. I have some auto rig scripts for max that I have to work on today, but I will see about kicking around the bones and such this weekend.
Or I may just write a Binary reader for the M3 format so I can see what it says in the file. I really want to see every last bit in that file and then decrypt that.
Unfuntuntely there is of course no one at Blizz that can give us the right information. However I can certianly gleen information based on what was not done or left behind. via naming and such.
You are going to have no end of issues with the Ultralisk. This is primarily due to the fact it has a bad name in the Bone heirarchy. You can see it in the SC2 GE (Star Craft 2 Galaxy Editor). If you turn on View Bones. You will see the ~DUP~ as a duplicated Name for its Tail. I have already Bugged this with Bliz on their Forums.
There are a number of models with Bad names. So the problem may not be entirely on you NiN. It may be on Blizzard's side for sending out bad models to begin with.
The ghost model has some issues with its heirachy to begin with as well. One of the key tip offs is that Dummy01 and such should be coming in as a DummyHelper and not a Bone. I am fairly sure that the Ref_* objects should all be Point Helpers (setup as Boxes) it looks like they are all being duplicated at the moment and made bones.
you can do something like the following
-- Existing Object
/*
* objExists() - Given an object name, with or w/o $, this tells if it exists or not.
* Returns true on exists, false otherwise.
*/
fn objExists objname =
(
name="";
if (objname[1] == "$") then -- already have $ in it?
name = objname;
else
name = ("$"+objname);
ret = execute(name+" != undefined");
return (ret);
)
to check to see if a name matches.
resulting in something like this
if (objExists("$"+"Ref_*")) then
(
print "Do something here"
)
I use this bit with more precision since I know the naming convention that I use in my own companies Rigs.
Last Gmax that I am aware was based on Max 5. As of Max 6 there were some changes to core script parts. The bone creation is much different in Max 6 and higher. There are also other max script changes as well. Which is one of the reasons you will see on most scripts that saw good for Max 6.0 and Higher.
You cna get a trail verision of Max, and if you have a student .edu email address you should be able to get a student version of Max. In most cases if you can get a your hands on a student ID you can get a student /Educational Verision of most any software fairly inexpensively. This is a much better route then dredging through the dark places on the internet for other methods.
<<reply 98589>>
Nin I would have responded earlier but I have work to do every so often =)
Oh don't even get me started on Max's rotation Matrix.
Really next time I am at Siggraph or GDC I am going to beat someone with a stick. A lot.
Some of the issues look to be coming from parenting. That is what I am starting out with at least. Why start there.
Glad you asked.
If you know the parent and the child of a bone it becomes a trival task in auto bone creation.
you get do the following:
[code]<br> This is taken from Mike Comets Auto Rigger for Max 6 and Above. <br> My Notes on this: <br> -- ptToe and ptAnkle in the Auto Rigger are the locations of points that later become bones. <br> -- since you are basically auto generating the bones on the fly you can do basically the same thing. <br> -- Create points first for location, placement and parenting then Replace those with Bones.</p> <p>vec = ptToe.pos - ptAnkle.pos -- get nice vector to determine Z up<br> vec = cross [0,0,1] vec; -- now make vec more on side not front/back</p> <p> bUL = BoneSys.createBone ptLeg.pos ptKnee.pos vec; -- upper leg<br> <a href="http://bUL.name" rel="nofollow">bUL.name</a> = (prefix+"_upperLeg_"+LR+"_BN"); <br> boneSetup bUL true mixColor:sideColor;<br> bLL = BoneSys.createBone ptKnee.pos ptAnkle.pos vec; -- lower leg<br> <a href="http://bLL.name" rel="nofollow">bLL.name</a> = (prefix+"_lowerLeg_"+LR+"_BN");<br> boneSetup bLL true mixColor:sideColor;<br> bFT = BoneSys.createBone ptAnkle.pos ptBall.pos vec; -- foot<br> <a href="http://bFT.name" rel="nofollow">bFT.name</a> = (prefix+"_foot_"+LR+"_BN");<br> boneSetup bFT true mixColor:sideColor;<br> bTO = BoneSys.createBone ptBall.pos ptToe.pos vec; -- toe<br> <a href="http://bTO.name" rel="nofollow">bTO.name</a> = (prefix+"_toe_"+LR+"_BN");<br> boneSetup bTO true mixColor:sideColor;</p> <p>[/code]
This of course is just a sample. My intial thought on this is to Create an Array matrix to record the parent child relationships
This way I can create everything cleanly. This should remove the gimbal locks of most everything. BTW I HATE max rotations.
At the moment I am trudging through the 2000+ lines of script for the Importer. Looking primarily at the bones. It doesn't appear to be creating the bones quite right. It's close but just a hair off. Going to see what I can re-script on my end and work out. Its a great script, btw.
One thing I also noticed is that the exporter is not handling point helpers correctly, or not at all. I have not looked over that piece just yet. Just started looking at the Importer to beging with. This should be a fairly easy solve, but I will know more once I start working through it.
Mike Coment has some nice code in relation to auto-generating bones. I am going to use that as a basis. At least that is the thought at the moment.