Remove "requires" from within Maya?

2,471 views
Skip to first unread message

Fredrik Averpil

unread,
Mar 13, 2015, 5:41:01 AM3/13/15
to python_in...@googlegroups.com
Anyone know if you can remove the "requires" statements which you can see at the top of a Maya Ascii file - but from within Maya?

I'm trying to remove some of these from files which are binary, so I can't just open up the files from outside of Maya and edit the lines out...

Regards,
Fredrik


Fredrik Averpil

unread,
Mar 13, 2015, 6:05:13 AM3/13/15
to python_in...@googlegroups.com
And in this case, it's part of a workflow, so it won't help me to temporarily save down an ASCII file, edit it and save it back to binary. I really would need to be able to remove these "require" statements somehow from the binary file.

// F

Marcus Ottosson

unread,
Mar 13, 2015, 6:07:31 AM3/13/15
to python_in...@googlegroups.com
I can't say for sure, but I'd imagine a "requires" statement are similar to Python's "import" statements and without them some things may not work​ as expected, like missing node-types.

Having such a thing being part of a workflow sounds dangerous; would it be possible for you to elaborate on the why? Maybe there's another way.

Fredrik Averpil

unread,
Mar 13, 2015, 6:18:00 AM3/13/15
to python_in...@googlegroups.com
I totally agree. This sounds dangerous if not handled properly, but in our case this problem propagates like a virus across all projects.

The reason is that we once had e.g. the xfrog plugin, and it was used in a popular asset, such as a bunch of flowers sitting in a pot or something. This model was not cleaned up before submission to our model database (which currently is still quite old school, and is made up of standard maya ascii files). But the mesh was cleaned up from any xfrog nodes by exporting it to obj and then back in. In fact, the whole scene may have been "cleaned" from these nodes. But the requires statement is still in there.

So, a few thousand projects later, and after having started working in binary format, all projects that has been using this model has the "requires" statement in the scene. The problem with this is that it's hard to get to the bottom of the problem as the issue keeps re-appearing although we sometimes sweep the entire server for .ma files and removes a couple of very specific "requires" statements.

And we have LOTS of these old "requires" statements, which are simply refering to renderers, plugins etc that are no longer used (really!) in our scenes.


// Fredrik



On Fri, Mar 13, 2015 at 11:07 AM Marcus Ottosson <konstr...@gmail.com> wrote:
I can't say for sure, but I'd imagine a "requires" statement are similar to Python's "import" statements and without them some things may not work​ as expected, like missing node-types.

Having such a thing being part of a workflow sounds dangerous; would it be possible for you to elaborate on the why? Maybe there's another way.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAZj0m9FcnymsVGmmitCTNzarCtt2ydXH2KaXmfNfq%3Dsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

owen burgess

unread,
Mar 13, 2015, 6:18:55 AM3/13/15
to python_in...@googlegroups.com
Hi Fredrik,

The key here is understanding why Maya will write a 'requires' line
for a plugin.

If there is a node in your scene which is an instance of a custom-node
type, Maya recognises a dependency on the plugin that registers the
node type (or typeID if we're speaking binary) and will add a
'requires' line for this plugin when you save/export your scene.

You can predict which plugins are 'in-use' in the current scene, and
will be written to file, by using the MEL command:

//
pluginInfo -q -pu;
//

If you don't want Maya to write a 'requires' line for this plugin (eg
Mayatomr) then you'll first have to identify which nodes are of the
type registered by the plugin, and delete them from the scene

Taking Mayatomr as the example, you'll need to first query the node
types registered by the plugin:

//
pluginInfo -q -dn Mayatomr;
//

Then find and delete each node of these types.

Once you're done, Maya will not write a 'requires' line for this plugin.

Note: you don't have to unload the plugin - so long as there are no
nodes in the scene with a dependency on a plugin, ie the plugin isn't
returned by the pluginInfo -q -pu command, it won't be written to file

And that's almost it.

Let's say that you receive a scene file from a third party which
'requires' a plugin that isn't in your MAYA_PLUG_IN_PATH, Maya will
register the plugin in its internal plugin database and save this
information out again when you save your scene file. In short, Maya
preserves info for plugins that cannot be loaded on file>open.

So it can be confusing when you open a scene file again and Maya is
still trying to load plugins that you don't have.

Unfortunately, there is currently no mechanism for identifying these
'unknown' plugins, or removing them.

Regards,
Owen
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_m...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWPmFom%2BgkmU0%3DVu1vMn3c-JmiksLT2EYvTM8W6Lk%2BabWA%40mail.gmail.com.

Fredrik Averpil

unread,
Mar 13, 2015, 6:23:34 AM3/13/15
to python_in...@googlegroups.com
Hi Owen,

> If there is a node in your scene which is an instance of a custom-node
> type,  Maya recognises a dependency on the plugin that registers the
> node type (or typeID if we're speaking binary) and will add a
> 'requires' line for this plugin when you save/export your scene.

I don't think that's right. I just opened up a scene here, which has the "requires" for xfrog and spits this out in the script editor when opening the scene:

requires "xfrog" "1.0";


I performed your suggested command:

pluginInfo -q -pu;

 ...and it gave me: 

// Result: vrayformaya 3.05.04 //

I'm 100% sure there are no xfrog nodes in my scene. Also, if I remove the "requires" statement from an .ma I get zero errors or warnings during scene opening or rendering.

You are probably completely right that he "requires" is created when a scene is saved with plugin dependencies, but it is never removed if the plugin's nodes are removed.

// Fredrik



--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGTPGODK%2B5RHF%3Dk9ApnGB8V%3DT%2BgCAm_Re-Dt-RdTnxXhpqOzWg%40mail.gmail.com.

Justin Israel

unread,
Mar 13, 2015, 6:35:32 AM3/13/15
to python_in...@googlegroups.com

I don't know too much about this, but what Fredrik says rings a bell. I remember how mental ray would "infect" the file if it had ever been loaded. Even if there were no mental ray nodes, it would still seem to load the plugin again simply from being included as a requires header.


To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMgnAOBNEiu2k8Rp%2BU8yeighADe4htAZiZsHDY5Eyu-Pg%40mail.gmail.com.

owen burgess

unread,
Mar 13, 2015, 6:40:16 AM3/13/15
to python_in...@googlegroups.com
Do you have the XFrog plugin in your PLUG_IN_PATH ? If not, then it
won't get loaded, its services won't be registered and it will be
classed as an 'unknown' plugin. If a plugin's services are not
registered, the pluginInfo command cannot identify it.

So assuming that this XFrog plugin falls into the category of
'unknown' plugins, a 'requires' line will be written into the next
scene file you save. This can lead to situations where a 'requires'
line for that plugin will show up in every scene file even if you
never have any intention of using the XFrog plugin again.

Like I say, Maya doesn't yet have a mechanism for identifying and
removing 'unknown' plugins.

Happy to take this offline if you like.
O
>> > email to python_inside_m...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWPmFom%2BgkmU0%3DVu1vMn3c-JmiksLT2EYvTM8W6Lk%2BabWA%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to python_inside_m...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_m...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMgnAOBNEiu2k8Rp%2BU8yeighADe4htAZiZsHDY5Eyu-Pg%40mail.gmail.com.

owen burgess

unread,
Mar 13, 2015, 6:53:46 AM3/13/15
to python_in...@googlegroups.com
In my experience, when you delete every node that gets created
automatically when the Mayatomr plugin initialises (eg:
mentalrayGlobals, etc...) then Maya doesn't write the 'requires' line
(the plugin itself can still be loaded).

Start with a blank scene in Maya 2015, load the Mayatomr plugin and
then immediately save the scene file to ascii.

The file contains the line:

requires -nodeType "mentalrayFramebuffer" -nodeType "mentalrayOptions"
-nodeType "mentalrayGlobals"
-nodeType "mentalrayItemsList" -dataType "byteArray"
"Mayatomr" "2015.0 - 3.12.1.18 ";

..because the following nodes were added to the scene when I loaded the plugin:

createNode mentalrayItemsList -s -n "mentalrayItemsList";
createNode mentalrayGlobals -s -n "mentalrayGlobals";
createNode mentalrayOptions -s -n "miDefaultOptions";
createNode mentalrayFramebuffer -s -n "miDefaultFramebuffer";

Now, in your Maya session, if you remove these nodes from the
Outliner, and then do a pluginInfo-q -pu; you'll see that Mayatomr is
not on the list of plugins 'in-use'.

Save the scene file again and you will no longer see the 'requires' line.

Cheers,
O

Fredrik Averpil

unread,
Mar 13, 2015, 7:17:45 AM3/13/15
to python_in...@googlegroups.com
Hi Owen,

I don't have the xfrog plugin in my paths. Also, I don't have any unknown nodes.

I'm attaching a Maya binary file. When you open this up you'll see that it is empty, and it does not contain any xfrog nodes or unknown. But it says it requires xfrog 1.0 (and also a couple of other plugins).

My problem is I would like to get rid of this "requires" but I can't figure out a way to do it. Your suggestion is to remove plugin nodes and/or unknown nodes and save to get rid of the requires line, but it is possible that this requires the plugin to exist for this this to work. In my scenario, I've got thousands of files where the plugin does not exist (we don't have a license for xfrog 1.0) but the requires line is in there. And I don't want it.


Regards,
Fredrik

requires.mb

Fredrik Averpil

unread,
Mar 13, 2015, 7:22:12 AM3/13/15
to python_in...@googlegroups.com
Edit: I can't figure out a way to do it (without saving down as .ma, edit e.g. via python from outside of Maya, open it, save as binary) ... which is a process I need to batch. But it would be much better if I could avoid this cumbersome chained process and instead can execute a command inside of Maya...

// Fredrik


AK Eric

unread,
Mar 15, 2015, 5:57:21 PM3/15/15
to python_in...@googlegroups.com
So this is a complete hack, and just off the cuff, and presuming you tested it and it didn't mangle your scene:  You could select all the top-level assemblies and do and export-selected on top of the same file.  Sort of using a sledgehammer to do surgery, but if the patient lives....

I use this brute force technique all the time (heck, I have it mapped to a marking menu) to clean files up (admittedly they're usually just simple models, not complex scenes):  Just last month I got a file form 90+ megs down to around 5 using this.  I asked the modeler:  "Did you notice how long this scene (with maybe 10k polys in it) took to save?  "yah, it seemed a little slower than usual..." 
:)
Gotta love how cruft can slowly just glob up your files over the years...
I've been hit by the same Mental Ray requires plague as well.  Grr....

Paul Molodowitch

unread,
Mar 15, 2015, 6:37:35 PM3/15/15
to python_inside_maya
We've had the same issue as Fredrik - rogue plugins that "infect" other scenes. In our case, we didn't actually have any of the plugins in question installed on any of our machines - can't remember if that was a requirement for the plugin to spread infectiously.

We had to immunize by creating dummy python plugins, that would also add a post-save callback that would remove their own requires statement from any ma files written out.  Not elegant, but once the outbreak is contained, the plugin doesn't load, so it seems acceptable.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

Sreenivas Alapati

unread,
Mar 18, 2015, 9:26:02 AM3/18/15
to python_in...@googlegroups.com
I am facing the same issue here...
While the modeler tries to publish the model, I select the top assemblies and the necessary polysets and use the export command with export selected flag. The resulting file has only the required model and chop off the shaders and curves the modeler creates in the process. I can pass the model to rigger and every thing works fine and dandy.

But, I use the same .ma file to generate the obj files as a background process using mayapy when the texture guy tries to import the asset in mari. Even though the modeler has not added the arnold shaders, just because the arnold plugin is enabled It writes out the 
requires Mayatomr line and while doing the mayapy background job it crashes saying... The mesh 'badgeShape' has no '.ai_translator' attribute. setAttr: No object matches name: .ai_translator. Error reading file. 

Strange thing, couldn't understand why it writes out the require line with out it actually being used in the scene. So, to fix that I have to load the arnold plugin in batch mode, with out any real purpose. 

owen burgess

unread,
Apr 13, 2015, 10:43:40 AM4/13/15
to python_in...@googlegroups.com
Autodesk has just released Maya 2015 SP6 (and Maya Ext1 & SP6) which includes a mechanism for identifying and removing an "unknown" plug-in from your Maya session, so you can avoid having Maya write a "requires" line when you save the scene.

The relevant MEL commands are:
* unknownPlugin
* unknownNode
I'll publish a tutorial on the MayaStation blog later this week.

Owen

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

Fredrik Averpil

unread,
Apr 13, 2015, 11:37:31 AM4/13/15
to python_in...@googlegroups.com
Fantastic, excellent, yes!
Thank you Owen!


Paul Molodowitch

unread,
Apr 13, 2015, 10:37:42 PM4/13/15
to python_inside_maya
Wooooohoooo!

(Yup, I really am that excited.  And yes, I am that lame...)

- Paul

owen burgess

unread,
Apr 14, 2015, 5:08:18 PM4/14/15
to python_in...@googlegroups.com
This tutorial should give you all the elements you need to deal with those pesky plug-ins:

Regards,
Owen

Fredrik Averpil

unread,
Apr 20, 2015, 5:19:28 AM4/20/15
to python_in...@googlegroups.com
Awesome write-up. Thanks Owen!

Cheers,
Fredrik


Reply all
Reply to author
Forward
0 new messages