SDK Renaming nodes

[Anonymous]

Hey, I have a .fbx file where in SDK version 2009.01 I get this for the hierarchy (outputted from the importscene.exe example).

c2_WORLD_TRANSFORM
     c2_skel_rleg_null
          c2j_rleg_i_foot5_jntend2
               c2j_rleg_i_foot5_jntend2_ncl1_1

In 2009.03 I get

c2_WORLD_TRANSFORM
     c2_skel_rleg_null
          c2j_rleg_i_foot5_jntend2
               c2j_rleg_i_foot5_jntend2

Why is the last node getting renamed? Do I have any control over this?

[Anonymous]

If you convert the .fbx file it to ASCII, what is it named?

[Anonymous]

You mean just look at the contents of the .fbx file? Or is there some sort of Utility you are refering to to do the conversion?

If I just look at the .fbx file in a text editor, I can find references to c2j_rleg_i_foot5_jntend2_ncl1_1, and thats the expected name based on the source the .fbx was created from.
As far as naming is concerned, the 2009.01 SDK is correct.

[daviesm]

If you can send me the file, I can investigate. On first look it seems 2009.3 is changing information, but perhaps it has simply stopped!.

It is our aim to leave the information intact as possible.

Anyway, if you can post or send me the data we can verify where this issue lies.

Mark

[Anonymous]

Hey, the file is 10 megs, so I can't attach it to a PM. How should I get it to you?

[Anonymous]

Did this get resolved? I'm getting similar results with 2009.3

It looks like it's mainly concerned with models that are instanced in many places within maya, exported, then MB concatenates the names of the nodes with unique key information.

If I save that out from MB, then try loading it it via the FBX SDK and then requesting the name of those nodes, what I get back is the original node name (ie the one that doesn't have the unique key info in it - what was exported from Maya in the first place).

For example if the original model in maya was called "String3f" then all the instances in the FBX file that are outputted via Maya have "string3f" as their model name.
Once that gets into MB, each instance gets appended, e.g. "sring3f_ncl1_1", "string3d_ncl1_2" etc.

I've looked at the text conversion of the fbx file as exported from MB and all the nodes *are* named properly, ie a combination of the original name and generated unique identifiers. (the "sring3f_ncl1_1", "string3d_ncl1_2" versions).

So where is this 'original' name coming from? Just doing a FBXNode->GetName() returns the original name of the node, not the unique one. e.g. I get back "string3f" for multiple nodes when I *should* be getting "string3f_ncl1_1".

The practical upshot of this is that you end up with a bunch of non unique names in your FBX file - ie nodes all with the same name in them.

Whats going on?? And more importantly, how do I get around this?

[Anonymous]

Solved! Don't use FBXNode->GetName, use FBXNode->GetInitialName - then you get the correct values.

Not particularly intuitive, but it does at least have the virtue of working!

[daviesm]

Intended behavior regardless of versions:

GetName : Get the current name of the object
GetInitialName : Get the original name before it was renamed by the renaming strategy system (i.e. the name that you should see in the file)

Basically, a node named "something_nlc1_1" should be renamed to "something" after an import. The "_nlc1_1" was appended by the system, and should be removed by the system as well.

The issue brought on this forum about 2009.3 not doing the right thing is wrong, because in fact, its 2009.1 that was wrong to leave the _ncl1_1 appended to the object name.

2009.3 and 2010 onwards have the correct behaviour.

mark