Fri, Sep 2nd, 2016
posted by jjburton 09:09 PM

So I got a message from a user on Thursday saying that cgmToolbox didn’t work in Maya 2017. Got around to installing 2017 and yup – borked. Spent the evening on Thursday identifying this issue and Friday was fix day.

If you don’t care about what was wrong and just want the bottom line — cgmToolbox should be working in 2017 Maya with the new build I’ll be pushing to the repository shortly.

If you do care…

NOTE – If you use use zooToolbox and specifically zooPy.path.Path (or zoo.Path as I’ll call it), this post would behoove you to look at unless you like stumbling down the same rambling trail others have tread.

Been using zoo stuff for well over 5 years now and Hamish(creator of zooTools) is out of the game last I knew so I decided I had best fix the problem as googling the topic got jack squat and my usual sounding boards hadn’t come across it yet.

Initially I thought Autodesk had gone and changed something and blew up my stuff but at the end of the day it turned out to be the fact that the python that 2017 is running updated the python str class. It just so happens that zoo.Path runs that as a subclass and was overloading some built in calls (find and replace specifically). Anyway, there is a walk generator for path stuff that pushing an instance of the zoo.Path into it rather than a ‘native’ string. Part of that (new to 2017) walker calls on ‘replace’ and so breaks because it needs to replace the path separator which zoo.Path specifically avoids in it’s overload.  zoo.Path’s replace is ONLY for replacing tokens between the separators.

Long story short, that raises an error of ‘/’ cannot be indexed because the find call (in zoo.Path) is specifically removing in it’s searching.

Interesting tidbits:

  • With 2017, os.path.sep is now ‘\\’ up till 2017, it’s been ‘\’ at least all the way back to Maya 2011. On windows at least
  • Something changed with the os.walk generator to make it not work as it did before 2017. Maybe it used to str(arg) stuff in the process and now just passes through the string. Whatever the reason, it broke.
  • import sys || sys.version — gives you your python version. If you’re curious 2017’s is 2.7.11

Some code changes

  • zooPy.path.Path — If you have old versions of zoo installed and trying to run stuff in 2017. It’s gonna break on you if it hasn’t already. You can use this or do your own patch:)
    • osPath — call to return a os.path.sep joined version of the path. Path natively works with ‘/’ and the new double ‘//’ messes with stuff
    • _list_filesystem_items — changed the walk creator to use a osPath string to stop the failing
  • Cleaned out a bunch of stuff from __init__ files. — I’d had some built in calls for listing files and getting other info back before I knew the right way to do it or at least a better one.
  • cgmToolbox
    • clean_scriptPaths/clean_pluginPaths — The call that was breaking stuff were my path setup stuff. As such, the env for these guys got a little borked during the troubleshooting. This was a quick attempt at fixing stuff. As an experiment, this may or may not be reworked.
      • Check all paths for valid paths (will add to the env without failing)
      • Removed a bunch of .git stuff that some other scripts I’d used from someone else apparently added.
      • Acts as a report for what’s there if you didn’t know as it reports all good ones
  • core.cgmPy.os_Utils
    • get_lsFromPath — reworked from the __init__ cleanup. Accepts file paths now and just gets the director they’re in for searching

Now I can get back to cgmBlendshape for Morphy 2. Wrote some fun mesh math stuff toward that end earlier in the week as well but that’s a post for another day…:)

j@cgm

Fri, Feb 19th, 2016
posted by jjburton 10:02 AM

Sometimes you need to get stuff back to earlier versions of Maya and ignore version just doesn’t work. I needed to get a load of 2016 geo back to 2011. Here’s what worked:

  1. Export geo to a clean file in your current version of Maya
  2. If you can’t export it as an .ma file, run scene optimize on the mb file making sure to remove unknown nodes
  3. Save as an .ma
  4. In a text editor change the 2016(or whatever version you’re going from) to 2011(or whatever version you’re going to). Save it
  5. Open in the earlier version of Maya

-j@cgm

 

 

Sat, Feb 13th, 2016
posted by jjburton 08:02 PM

Released a build of Morpheus 2 this week and immediately ran into some issues with the marking menu and hot keys. I’d been using zooToolbox’s setup for years for hot keys but it didn’t work with 2016 so I dug in.

Maya 2016 has a pretty neat new editor but it’s still probably more steps than most of our users could reliably follow so wanted to get the button push setup back.

There a few things to remember when working with hot keys and in this order…

  1. runTimeCommand– This is the code that gets run. It can be python or mel
  2. nameCommand — This is required for a hot key to be setup properly
  3. hotkeySet — This is something new with 2016 and needs to be set to a new set to be able to add a new hot key because the default set is unchangable
  4. savePrefs — after setting up your hotkey, you must save the prefs or the newly created hotkeys go away (not sure if this is new to 2016 or not)

Lessons learned:

  • hotkeySets — were added in 2016. Any hotkey work you do post 2016 needs to account for them. I ended up having my stuff use the existing set if it wasn’t the default and create a new one if the default is the current one
  • hotkey -shiftModifier flag — this was added in 2016
  • Pushing dicts into mc/cmds calls — In general, something like mc.command(**_d) works with _d being your dict. However on mc.hotkey I found that the keyShortcut flag needed to be in the dict and at the start of the call to work: mc.hotkey(_k, **_d).

I ended up writing a handler and gui to set stuff up. I’ll swing back and talk about it another time if there’s interest.

Back to Morpheus…

 

 

Sun, Feb 15th, 2015
posted by jjburton 01:02 PM

While doing some optimization on Morpheus 2 and incorporating some of Red9‘s latest stuff I noticed an odd bottleneck in the code.  So I decided to dig in to it.

For those short of time, the short of it:

  • Maya’s duplicate command get’s slower based on scene complexity – regardless of manually calling or doing it through the interface
  • Maya’s duplicate command (and perhaps others) get slower based on how long you’ve been doing stuff in maya

I noticed that a relatively simple step in one of my joint chain functions was oddly slow and delved into it. In a empty or lite scene it was pretty instantaneous but in a regular scene got really slow. Dug in and came to just being duplicate being slow. That was my theory at least , so I wrote series of tests to verify. The first of those being a test that given a number of times to iterate and a number of children joints, the test will 1) create a joint chain of y joints and 2) duplicate that root joint iterating on the provided number. 

The results showed a pretty linear line of increasing speed as the scene added more objects. The more objects, the longer things got. Interesting but not enough to go on.

The second series of tests I wrote my own simple joint duplicate function using mc.joint and matching positioning, rotateOrder etc. I also checked some other items to eliminate those as possible hindrances or see if they affected speeds:

  • Undo – No difference whether it is on or off
  • History – No history on joints
  • Connections — Only connection on any tested joints in inverseScale
  • Flags — Tried all combinations on the duplicate command I could think of to no avail
My rewrite is always the same speed regardless of complexity, mc. duplicate get’s progressively slower as it goes on. Here are some results:

Breakpoint is the iteration at which my rewrite is faster than mc.duplicate for that run. Method 1 is mc.duplicate and Method 2 is my own.

How about some code you can play with yourself with a simple locator duplication?

Here are some results of this standalone for me at least:

Note – the 2015 run was a fresh open of the software and my experience doing this testing would see that getting slower.

If you run the test you’ll see for yourself the slow down. Now, what do we do with this?Working through this I created my own duplicator for curves, joints and locators. For now, I’m only going to use the joint one for Morpheus building until I can do some more testing and maybe get a better handle on it but it’s certainly an oddity.

Odder yet is the longer you do stuff in Maya, duplicate gets slower still. This I tested after noticing that after being away a bit that Windows had rebooted and suddenly duplicate was posting much better results. After a while, that slowed down. So I rebooted myself and yup, it’s faster after a reboot.  I have no idea on this one other than maybe a memory leak or..I dunno, I’m a hack at this stuff and that’s the best I got:)

If you’re interested, let me know what you find – different conclusions?

For now, Bokser told me I have to move on:)
j@cgm

Sat, Oct 13th, 2012
posted by jjburton 01:10 PM

So saw some questions on these enigmas around and wanted to attempt to shed some light on them.

optionVars are maya devices for saving information between maya sessions, from say one tool session to another or any other wide variety of things. By default you use them like something like this:

If you decided you wanted to play with optionVars. They’re awesome but can be a bugger to get working the way you want them. We use them to save settings between gui sessions and even to send info to some stand alone functions.

If you want to add to a string one you have to remember it’s a string one and use a different flag than a int or float one. It got confusing to us, so we decided to go a different route.

We wrote a class wrapper for dealing with them that made it easier for us to get a handle on so that we call them at the top of any gui with something like:

That initializes the option var to an instance that can be appended, rebuilt, culled purged, cleared, call, converted or whatever in any of our tools.

The defaultValue flag sets the value only if the optionVar doesn’t exist. We did that so that if a specific tool is reset and has it’s flags wiped. It builds again with the default ‘factory’ settings. It also converts on the fly so if you pass a string to a non string optionVar, it converts it to a string, and so on.

Settings are called and set via commands like:

We also flag all of our optionVar’s with a ‘cgmVar’ so that we can easily do a full wipe of our variables when needed for testing.

You’re welcome to give it a try if you like or take part of it it works for you and run with it or join us and help make it better. It’s in the cgmTool box from cgMonks – cgm/lib/classes/OptionVarFactory

Have a great weekend!

 
Creative Commons License

Categories