« Enable component selection for MPxSubsceneOverride of apiMeshShape sample | Main | Specifying a File path correctly in MEL/Python »

July 27, 2016

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Robert Cervellione

does this also apply to high volume mel commands? I am having the same issue when i evaluate a mel command at every frame on the time line, the system locks and crashes due to a memory access violation. i assume because the previous command was not finished operating on the object before the new mel command was called on the same object.

Chengxi Li

I think this is applied to commands need to be executed during idle. Maybe it is a little different from your issue.

Jakob Steffensen

We are also working with custom locators and something baffles me...

if you do a spaceLocator or nurbsCurve, copy it 400 times and set keys on the transform you might get about 200 fps when doing playback...

Compile the footPrintNode from the devkit and do the same and you get 23 fps (60 fps with the geometryOverride version)

Without keys on the transform the viewport performance is fine.... any clue why?

Best wishes... Jakob

Luke Harris

This bug is pretty nasty. Even calling out to mel from python causes the crash so unless you can rewrite your whole tool in mel the work around isn't doable. Further, even disabling parallel evaluation will not fix it in all cases. If parallel is disabled but viewport2.0 is enabled it will usually still crash when calling cmds.playblast(). In other words you can't use python node plugins with viewport2.0 OR parallel eval. Not good.

The comments to this entry are closed.

Cyrille Fauvel

SyntaxHighlighter