Namespaces in MotionBuilder

Tools MotionBuilder
1

Hola,

I’m getting really fed up with bugs in MotionBuilders handeling of namespaces, breaking my assets in animation. Especially anything relation_constraint - argh :?:

Does anyone have specific strategies for dealing with MotionBuilders namespace issues? Do you avoid them all together or maybe just for specific things? Are there certain relationships you avoid building, because you know they will break? Do you use prefixes instead of namespaces? If so, how is that working out and how is that handled animator side?

Any input would be great… I’m going home now :sigh:

2

Hey Sune, what version of Mobu and what are they breaking?
Namespaces have been in filmbox/motionbuilder for ever and I don’t remember having a problem with them.

3

I’m curious what specific issues you are having and how they are occurring. Do they occur upon import or load from existing assets or reloading a file? Are namespaces getting changed underneath of you or are artists renaming them manually?

Honestly, I have found namespaces to be quite important to many workflows and tools. The fact that they are native to Maya and Mobu is fantastic.

However, such as the case with relying on anything with purely names, can be quite catastrophic if not managed properly. I am curious as to what may be breaking constraints and how.

4

Thanks for your answers guys!

“Hey Sune, what version of Mobu and what are they breaking”

We’re on version 2011 advantage pack sp1 + hotfix.

The stuff that breaks is mainly in relation constraints. It either happens as soon as you apply you namespace and then reload your asset or once you start having multiple assets of the same type in a scene (say Char A and B). Some examples:

  • After applying a namespace to an asset, connections in relation constraints are simply missing upon re-load of the scene.
  • Relation constraints stop evaluating correctly, even though the connections are still there.
  • Namespaces swap place (say what?)… Say you have Char A in your scene. It has some nodes in the “char_a:export:” namespace. Now you bring Char B in which has similar namespaces “char_b:export:”. Now suddenly the namespaces in Char A have changed their order so it’s now “export:char_a:”.
    *MotionBuilder does not seem to propperly flush it’s namespaces between scene loads.

“Honestly, I have found namespaces to be quite important to many workflows and tools. The fact that they are native to Maya and Mobu is fantastic.”

Agree, namespaces are awesome… Until they break down and become equally un-awsome :slight_smile:

“Do they occur upon import or load from existing assets or reloading a file? Are namespaces getting changed underneath of you or are artists renaming them manually?”

As a tech artist I would usually apply the namespace to my asset before publishing it. This is done by either applying the namespace explicitely to a bunch of nodes or by applying the namespace on a scene load and the re-saving. I’ve tested it and the issues seem to be there no matter what approach I use

“However, such as the case with relying on anything with purely names, can be quite catastrophic if not managed properly.”

Yeah, I’m considering ditching namespaces completely and relying on “asset nodes” with connections (property references) to the components in my scene that a given assets is made up off (Jason Schleifer style). Then maybe using prefixes instead of namespace and having a custom “asset” loader to handle any name clashing.

The upside to doing this would be that each component could be tagged with it’s original name and that you could always find the right nodes through code, regardles of renaming issues. But other that that, it would just me doing a large amount of work to compensate for broken software :slight_smile:

Any additional thoughts or insights would be greatly appreciated.
Thanks

5

Add to that, properties “magically” getting new values

6

About relationconstraints — The issue comes with using Macro relation constraints that are namespaced.

If your character a has the following setup

kalle:Relation
kalle:awesome_Macro

and your character b has:

sven:Relation
sven:awesome_Macro

When you merge them everything usually works fine, until you save and reopen the file - at which point one sven:Relation will have a pointer to a macro without any inputs or outputs.

To solve this, I always prefix all my constraints with something unique. (in fact, my script does it for me).

7

that is a bug in Motionbuilder and should be reported. I have to say 2011/12 have had a huge amount of problems with saving data correctly and I think I read more fixes for this were in the latest build… but yes, in the move to have mobu wright to the standard FBX and not its own version of FBX, lots of stuff just broke.

8

[QUOTE=primal_r;12566]About relationconstraints — The issue comes with using Macro relation constraints that are namespaced…
…To solve this, I always prefix all my constraints with something unique. (in
fact, my script does it for me).[/QUOTE]

I’ve fixed the problem you describe in the same way. However the issues I’m talking about are happening with relation constraints that are not using macros.

Do you have an opinion on what would be the version to use? People say that 7.5 was golden, but that would cripple us quite a bit on the tool/python side at least :-). Btw. do you know when the move to generic FBX happened?

Thanks again

9

[QUOTE=bclark;12578]that is a bug in Motionbuilder and should be reported. I have to say 2011/12 have had a huge amount of problems with saving data correctly and I think I read more fixes for this were in the latest build… but yes, in the move to have mobu wright to the standard FBX and not its own version of FBX, lots of stuff just broke.[/QUOTE]

I don’t how many times I’ve had problems with animation going missing because when you save you have certain settings (everything from having 2 takes in the file or exporting them as “one file per take”).

Personally in 2011 after I installed the advantage pack and hotfix, I’ve haven’t had problems with namespaces and relation constraints.
Just the other day I had a scene with 15 copies of the same character (I will never allow that to happen again!), but no issues with their relation constraints, and they all had macros in those constraints. But I know we’ve had issues with constraints brake before we did the update.

10

Hi Erik,

Are you on the adv. pack service pack 1? And what hotfix (if you can let me know) are you on?

Recent assets that have broken due to namespaces, have all been created solely in MoBU 2011 Adv. pack SP1 with hotfix

Thanks :slight_smile:

11

It seems to me the namespace issues are quite common. I filed a bug last week in Mobu 2012. The issue was that if you merge a skinned mesh in and give it a namespace all the skin weights would pretty much be broken. They confirmed this on their side as well. Its quite unfortunate as I had to create a workaround to get passed this. It is definitely not ideal and the constraint issues seem far worse.

Also, did this get bugged? Its very likely it still exists in 2012. You can submit the bug with this form.

Thread about my specific Namespace Bug
http://area.autodesk.com/forum/autodesk-motionbuilder/autodesk-motionbuilder-2012/merging-w-namespace-breaks-skin--bug-/

12

[QUOTE=Sune;12691]Hi Erik,

Are you on the adv. pack service pack 1? And what hotfix (if you can let me know) are you on?

Recent assets that have broken due to namespaces, have all been created solely in MoBU 2011 Adv. pack SP1 with hotfix

Thanks :-)[/QUOTE]

well, under “about motionbuilder” it says Autodesk Motionbuilder 2001 Subscription advantage pack.

So I dont think i’ve installed any hotfixes actually

13

I’m on Adv. pack SP1 with hotfix and the about screen says the same as yours. I think the key is to look at the build number… Now how you figure out what version you have from doing that, is another matter :slight_smile:

14

This scenario in 2011 (which is still present in 2011 adv. pack sp1):

Make a scene the uses a macro.
Merge this into another scene twice, using a unique namespace each time.
Break a connection in one of the macros
Observe that all instances of the macro stop evaluating (across namespaces).

Seems to be fixed in 2012.

15

Any Autodesk reps around to comment?

16

There is a problem with duplicate character nodes if you duplicate one character node they both break… sounds like the same type of bug. Fun times and yuck.