detbear Posted November 14, 2012 Posted November 14, 2012 I imported an obj into A:M(via the .obj importer) which converted it into a Hash model. Then I imported it a second time in the same way using the same process. The results are two separate models in AM that are exactly the same. However, when I click on the same cp on both models, I notice that the cps are not named the same thing. You can see this by clicking a cp, then right clicking, then choosing"Edit CP weights"..... Each model has a different CP # for the same cp. Something like "CP# 296183" and "CP# 495742" Anyway to get those numbers the same so that I can make a mesh action that will effect both models the same? I would really appreciate any input you guys have for me on this. William Quote
Hash Fellow robcat2075 Posted November 14, 2012 Hash Fellow Posted November 14, 2012 Anyway to get those numbers the same so that I can make a mesh action that will effect both models the same? Technically possible idea... If every CP were attached to its own bone , that set of bones could be dragged into another model and the other model's CPs attached to the bones. An Action that worked on bones would work on either. Quote
detbear Posted November 14, 2012 Author Posted November 14, 2012 Anyway to get those numbers the same so that I can make a mesh action that will effect both models the same? Technically possible idea... If every CP were attached to its own bone , that set of bones could be dragged into another model and the other model's CPs attached to the bones. An Action that worked on bones would work on either. Exactly!!!!!!.........That's why months back I requested a function tool that you could snap a bone to a cp.....REMEMBER!! basically select a bone, right click on it.......then have a "Snap to cp location" then click on the cp that you want the bone to go to. It wouldn't be attached to the cp.....but rather translated to the X,Y, Z coordinates of the cp. Then the bone could translate the cp to the right local. But that is a future idea. I'm wondering how to do this now. William Quote
Hash Fellow robcat2075 Posted November 14, 2012 Hash Fellow Posted November 14, 2012 Anyway to get Exactly!!!!!!.........That's why months back I requested a function tool that you could snap a bone to a cp.....REMEMBER!! basically select a bone, right click on it.......then have a "Snap to cp location" then click on the cp that you want the bone to go to. It wouldn't be attached to the cp.....but rather translated to the X,Y, Z coordinates of the cp. Then the bone could translate the cp to the right local. Now, i THINK...you can... -in a pose, "Group" constrain a bone to a named group, even a group with one CP. (you'll have to zero the offsets manually) -put that model in a chor and turn the pose on, causing the bone to move to that group -export that model from the chor as a new model with the pose alteration baked in the bone placement -reload that new model with altered bone placement how close does that get you? Quote
Gerry Posted November 14, 2012 Posted November 14, 2012 Can you not import the model just once, then duplicate it? Are the cp names still different when you do it that way? Quote
John Bigboote Posted November 14, 2012 Posted November 14, 2012 Can you not import the model just once, then duplicate it? Are the cp names still different when you do it that way? That's what I was thinking too... or do a 'save-as'. Quote
detbear Posted November 15, 2012 Author Posted November 15, 2012 Hey guys, Unfortunately I have to import more than one version of the model. It is a model already rigged in another app. I'm attempting to utilize the morph bends in the joints. So I am importing the T-pose model and the same model with joint bends. my hope is to transpose the joint bend cp positions onto the T-pose versions in a pose or other keyed way. Because the cp count is high, I want to transpose the cps in the "bent" joint version to the t-pose version. But since the Cps switch names(although they are the same)....... a translation "muscle" key doesn't work. Hee hee eeeeek!!!! I know....I'm nuts William Quote
Gerry Posted November 15, 2012 Posted November 15, 2012 Yikes, well good luck with it anyway! Hope it's not too painful. Quote
detbear Posted November 15, 2012 Author Posted November 15, 2012 So with a heavy mesh model.....is there a way to place a bone at each cp without having to do each by hand? Quote
Hash Fellow robcat2075 Posted November 15, 2012 Hash Fellow Posted November 15, 2012 Have you solved the problem of getting the morph shapes from the other Polygon app into A:M? Even to the heavy mesh version? If you don't have that I'm not sure what the rest of this will get you. Quote
detbear Posted November 15, 2012 Author Posted November 15, 2012 One possible resolution would depend on how hard it will be to get a bone created and positioned to each cp of the tpose model. Quote
Hash Fellow robcat2075 Posted November 15, 2012 Hash Fellow Posted November 15, 2012 I know of no way to automatically place many bone like that at once. If this is a pressing business need I'd suggest hiring a file format guru who can engineer a more direct translation of the morph-target info to an A:M pose. I presume the morph targets are similar to A:M muscle poses in that they are translations of a point in XYZ space to a new point in XYZ space. Quote
Admin Rodney Posted November 16, 2012 Admin Posted November 16, 2012 I'll guess that there is a way to do this by creating a plugin (SDK type programming) but you might also be able to do a brute force method (for instance I could see a basic proof of concept being created via MS Excel). The following is the area of interest in any particular Model file: <SPLINE> 262273 0 1 0 0 0 . . 393217 0 3 -5 0 0 . . </SPLINE> <PATCHES> </PATCHES> <NORMALS> </NORMALS> <ATTRS> </ATTRS> </MESH> <BONES> <SEGMENT> Name=Bone1 <NONSKINNEDCPS> 3 </NONSKINNEDCPS> BoneColor=255 0 0 255 Start=-5 0 0 End=-5 0.5 -5 Rotate=-0.497406 0.502581 0.497406 0.50258 Length=0.483963 </SEGMENT> <SEGMENT> Name=Bone3 <NONSKINNEDCPS> 1 </NONSKINNEDCPS> BoneColor=255 0 0 255 End=0.00740465 0.408511 -4.87063e-008 Rotate=-0.495449 0.50451 0.495448 0.50451 Length=0.408578 </SEGMENT> </BONES> Basically, for every instance between the tag inside a tag: <SPLINE> 262273 0 1 0 0 0 . . 393217 0 3 -5 3.72529e-009 0 . . </SPLINE> You would have to create an equivalent Bone in a tag: Name=BonedCP1 1 BoneColor=255 0 0 255 End=0 0.5 -5 Rotate=-0.495449 0.50451 0.495448 0.50451 Length=0.408578 and <SEGMENT> Name=BonedCP3 <NONSKINNEDCPS> 3 </NONSKINNEDCPS> BoneColor=255 0 0 255 Start=-5 0 0 End=-5 0.5 -5 Rotate=-0.5 0.5 0.5 0.5 Length=0.5 </SEGMENT> Note1: In this case I manually deleted a CP (CP#2) and therefore because it doesn't exist... no Bone would need to be created for it. Note2: Apparently a Bone at location 0,0,0 doesn't need a Start point indicated, so if all your Bones are stacked at 0,0,0 then that's one less thing you'd have to code. You can initially assign a set number to those areas that aren't of particular interest to you such as: BoneColor End Rotate Length I can see where the End value might be problematic if you leave that one alone but you could just take the Start value and add a specific number (say 5?) to that. Incrementing the BoneColor slightly upward with each Bone created would let you know at a glance which Bones were created first by their assigned color. The Line Item of specific interest then is the designated Start location of the Bone Segment: At any rate... For Spline3 we'd get (roughly): 393217 0 3 -5 0 0 . . ...you would generate a Bone (We'll call it BonedCP3 so that we know who it belongs to): <SEGMENT> Name=BonedCP3 <NONSKINNEDCPS> 3 <<Most Important </NONSKINNEDCPS> BoneColor=255 0 0 255 Start=-5 0 0 <<Most Important End=-5 0.5 -5 Rotate=-0.5 0.5 0.5 0.5 Length=0.5 </SEGMENT> There are some things I'm not quite accounting for here (I'm rounding numbers for instance) but that is the general direction you'd have to go if you were brute forcing the creation of one Bone per each Control Point. Something that could be tested: How does A:M deal with incomplete Bone information? If for instance you just created the framework for the Bone and Assigned it to the CP would A:M fill in the rest of the information automagically? I'll wager it would. DISCLAIMER/WARNING: Manually coding an A:M File is one of the surest ways to crash A:M. Make sure you save your files before testing any model or project file you've manipulated manually in a text editor. Quote
Admin Rodney Posted November 16, 2012 Admin Posted November 16, 2012 I think the issue with: Something like "CP# 296183" and "CP# 495742" Is that the CP number is assigned based on the spline that it belongs to. If the importer doesn't create the same splines in the exact same order with every import then the CP#s will be a different number. Because the importer has to make decisions (some of which may be random?) this will assign different CP#s throughout. Edit: I would say that it is possible to 'break' an importer to where it always makes the exact same decisions (i.e when it encounters Problem A always perform Solution A no matter what the other variables are) but surely that would result in a less than optimal import. We'd have to get a look at the importer code itself to understand what variables it considers in making the decisions on what process to execute at each decision point. It does seem to me that some optimization could be gained by reducing variation (i.e. limit any random decisionmaking to the absolute minimum possible... or leave those variable to the user to decide) but I have no idea what thresholds exists that constrain the decision making of the import code. Added: The SDK has information on the makeup of CPs: spline := "CPs=" %cpCount = int eoln [cp]%cpCount /* cp flags are interpreted as follows: enum ECPFlags { kSmooth = 1, kClosed = 4 }; The different flags are or'd together. */ cp := %flags = int %weld = int %number = int eoln if (%weld == 0) { float float float eoln // cp's x y z coordinates } else { int eoln // this cp has no x y z, rather it is welded here } %alpha1 = float if (not end of line) { float float eoln // read gamma1 and magnitude1 } else { skip to next line } %alpha2 = float if (not end of line) { float float eoln // read gamma2 and magnitude2 } else { skip to next line } int := [0...9]+ This is really old stuff and only posted here as representational of what is going on. I believe it's from circa v8 file format. Quote
detbear Posted November 16, 2012 Author Posted November 16, 2012 Hey Rodney. Wow...that is very fascinating. I think that a programmer who knew much more about the nuts and bolts of it could really make that happen. ALSO...... Those numbers for each cp show up when you RIGHT CLICK a cp and choose "Edit weights." At that point, the number/ name of the cp appears in the top left box of the weighting window. It's a number that normally looks something like this: CP# 253629 Quote
Admin Rodney Posted November 16, 2012 Admin Posted November 16, 2012 ALSO...... Those numbers for each cp show up when you RIGHT CLICK a cp and choose "Edit weights." At that point, the number/ name of the cp appears in the top left box of the weighting window. It's a number that normally looks something like this: CP# 253629 Thanks. I had assumed you were watching the CP#s under the Spline heading in the Project Workspace after toggling on Show More Than Drivers in TOOLS/OPTIONS on the Global tab. That would be the likely place to put a Plugin As there are two plugins there already (Measure CP Distance and Resample Spline). Of course those plugin wizards show up elsewhere as well. Likewise the CP#s will appear under the Model in an Action or Choreography and... in the window itself (especially with the Manipulator Properties panel turned on. So all in all there are lots of places to view the CP# but (for good reason) not any to renumber them. I'd guess that a utility could be created to swap out one with another but for complex Models that sure would become tedious! Quote
Admin Rodney Posted November 16, 2012 Admin Posted November 16, 2012 Named Groups were mentioned before and I see promise in that area (moreso than assigning a Bone to each CP directly). Here's the basic format for assiging a Named Group to a CP: <SPLINE> 262145 0 1 -5 0 0 . . 262145 0 2 5 0 0 . . </SPLINE> <PATCHES> </PATCHES> <NORMALS> </NORMALS> <ATTRS> </ATTRS> </MESH> <GROUPS> <GROUP> Name=ThisisCP#1 <CPS> 1 </CPS> Pivot=-5 0 0 </GROUP> <GROUP> Name=ThisisCP#2 <CPS> 2 </CPS> Pivot=5 0 0 </GROUP> </GROUPS> Within this particular Spline there are 2 CPs: <SPLINE> 262145 0 1 -5 0 0 . . 262145 0 2 5 0 0 . . </SPLINE> Named Groups are then created for each CP: <GROUPS> <GROUP> Name=ThisisCP#1 <CPS> 1 </CPS> Pivot=-5 0 0 </GROUP> and <GROUP> Name=ThisisCP#2 <CPS> 2 </CPS> Pivot=5 0 0 </GROUP> </GROUPS> This seems to me to be a much safer and stable solution than renumbering CPs directly. As this assignment should not cause A:M to crash if there is an inappropriate assignment whereas it likely will where Bones and CPs themselves are incorrectly renamed. Once the Named Group assignments were made then further assignment of Bones and CP Weights would follow by iterating through the Named Groups... likely using (or associating) the Pivot as the rotation. Aside: In comparing/contrasting two models each Named Group's location would be compared and those closest to each other would be flagged for renaming. I think at this point it would then just be a matter of sorting through the list and matching... then reassiging... each in turn and leaving any problem children out that need to be manually assigned/renamed. ALSO: Using Named Groups has the additional benefit of organizing CPs into same groups which of course is ideal for use with Bones, CP Weights etc. Named Groups can also be used as a near equivalent to Bones once locked into place (I'd say usually as separate Models joined together via constraints). Quote
detbear Posted November 16, 2012 Author Posted November 16, 2012 Hey Rodney .... Thanks again... Like I said before, you guys know much more about the programming aspect than I do. ****I took two of the model versions, Made a group on the same cps on each model....named the groups the same thing on each model......and then I moved one group in an action to get keys on it. Then I tried to copy those keys onto the same group on the other model, BUT IT STILL WOULD NOT key the cps into place because the cp names are different. Quote
Hash Fellow robcat2075 Posted November 16, 2012 Hash Fellow Posted November 16, 2012 Distantly related... the Transfer-AW plugin works by knowing when CPs from different meshes are close or in the same place. Presumably, some plugin could be devised that would rename the CPs in mesh A based on same-located CPs in Mesh B. Did you ever get the MDD import thing working? Quote
zandoriastudios Posted November 16, 2012 Posted November 16, 2012 I think the idea would be (if the CP names didn't change with every import) that you could bring in the morph target meshes, and then in a smartskin relationship paste the CP positions at the appropriate positions. Since A:M renumbers the CPs, your best bet might be try to focus on the exporter rather than importer. If you could EXPORT a .seg or .mdl file from your application, the CPs might keep the same numbers. (you might be able to go through a different program to bring in an .obj and export .seg) Then you could copy & paste the CP positions in a Pose relationship or a Smartskin Quote
detbear Posted November 16, 2012 Author Posted November 16, 2012 I think that's a good point, but the export selections are very limited. It will require much trial and error. A:M may just not be up to the task or at least not without going through a lot of R&D. Quote
Hash Fellow robcat2075 Posted November 16, 2012 Hash Fellow Posted November 16, 2012 Here's the basic problem that needs working around... You can copy and paste keys within a pose but what you are copying and pasting are offsets from the original position of the model's CPs. You can't paste an external shape into a pose, even though it may appear to be the same model, because it is a different kind of data. It is a model of absolute positions in space, not a collection of offsets. Since the Soulcage guys seem to have this solved I'd say pursuing them for more information woudl be a good way to go. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.