First new rig in way too long.

This release is about getting out our first proxy rig and new character for the community to use. As you’ll see, this first release is limited geo in what we’ll be calling a proxy rig. The final release version of this little guy will be more of what you’d see here:

This rigging system is what the Morpheus 2 tech has turned into and we’re excited to push it forward. When it’s a bit further along we’ll be re-rigging Morpheus 2’s base asset with it and release that as well.

We’ll have more on our plans with the alpha 2 release hopefully in a few weeks. We have some gigs that we have to do as well and one of our partners welcomed his first son into the world last month and so he’s a little busy at present.

It’s been a busy year though updates on the site don’t reflect that very well. Turns out we were targeted by some not nice folks that kept our site locked down a lot over the last year and generally wasted a lot of our web guru’s time. We think we have that ironed out so we should start posting things here again more for more detailed stuff than what is on Facebook.

We started out 2017 with a the goal being a year to get things done. Our goal to not over promise but to let our work stand for itself. As such here’s what we have to show for the year (all the external projects are under NDA).

Getting back to it

Josh has gotten back to taking gigs and has been working jobs since the summer and had a great time doing a facial rigging class with Rigging Dojo and plans to do more with them next year. David and Josh both have continued to work on tools and worked some jobs together.

Sphinx!

We set up a Sphinx doc system and have been fleshing it out over the year as we’ve updated tools. We feel this is a great foundation on which to continue to build and provide better support for the large assortment of tools we are continuing to develop.

New tools and bits in 2017

We started this year with a 2.0 rewrite of much of our core code base as well as updating some old tools and doing new ones. We’ve made a lot of progress on this front just this year.

Toolbox 2.0 – (http://docs.cgmonks.com/toolbox.html ) We redesigned the toolbox to be accessible by a top maya menu, marking menu and a ui. There are loads of functionality to be found and it continually updated

Locinator 2.0 – (http://docs.cgmonks.com/locinator.html ) Took a stab at updating this with new tech developed and expanding features. This is a great tool for animators that need to track different things for short periods of time without finicky constraint setups. It’s one of our more popular tools.

cgmSnap 1.0 – (http://docs.cgmonks.com/snaptools.html ) We spent a lot of time working out snapping things around as we’ve been working on our rigger and for jobs in general. First attempt at trying to expose those calls in a more useful format.

cgmJointTools 1.0 – (http://docs.cgmonks.com/jointTools.html ) Having been huge fans for comet’s tool for years. There were a few things we wanted to add for our own use. Some of those key features being chain/curve splitting, planar orientation and more.

Marking Menu 2.0 – (http://docs.cgmonks.com/markingmenu.html ) Taking the ideas from Morpheus 2.0’s marking menu work and expanding on that to a unified menu with different modes for rigging, animating and more.

cgmDynParentTool 1.0 – (http://docs.cgmonks.com/dynparenttool.html ) This tool allows you to easily setup point,point/orient and orient dynamic groups for controls for rigs as well as providing the tools to switch modes on the fly when animating. We use this all the time for rigging work.

Quick addendum to last week’s post. Ran into this on some rayCasting stuff (needed specific shape connection for updatable loc via stored uv data in dicts – more on that soon). My own googling and maya fiddling came up short with successfully connecting a shapes.message plug to a message attribute. It always connects to the transform. So, I pulled out my old method of attribute storing and it seems to be working okay.

If I wanted to store shape3 to messageHolder on an attribute of testMessage. It would look like this.

The connection works like this: shape3.viewName —-> messageHolder.testMessage.

The logic plays out as follows in our needed functions:

Set message

When it checks for attribute, component stuff from previous post, it now also checks for shape

Instead of a message attribute, I use my copy_to function to copy an unassuming attribute found on shapes (‘viewName’) which then creates a new attribute on my messageHolder matching type and all so it’s connectable. That call also wires that connection

Extra data is then stored as before

Get message

It checks a passed message attribute name for type. If it’s a string, it checks the plug flag on list connections for our above wiring

Otherwise, it goes as before

Still testing but seems to be working for our purposes. We’ll see how it plays out.

The problem: storing a dag node component in a way that makes it easily callable and persistent.

As I’ve been both refactoring/optimizing our core libraries as well as updating locinator I came across this old issue. There are several ways of doing this, some better than others. Just been wrapping up rewrite of our attribute function library. A part of that was rolling out our msgList concept from cgmMeta to being outside meta as well as expanding on that with datList(more on that another day).

Short version

If you don’t care about the details and just wanna see code, grab the last master branch build of our tools and you can find the main functions here:

cgm.core.lib.attribute_utils.set_message/get_message

Walkthrough example of datList/msgList with new stuff — cgm.core.examples.help_datList_msgList.py

Note — There may be a lot of script editor activity on the example stuff as I have DEBUG on in the module currently.

Long version

Let’s say we wanna store an object ‘null1’ to call and we’re storing on ‘storageNull’ How might we do that.

string attr – example: storageNull.stringAttr = null1

This works as long as there is only one object named ‘null1’ and as long as ‘null1’ is never renamed. So in short, it works rather poorly.

msgAttr – example storageNull.msgAttr >>connection>> null.msg

This works great and was my preferred method up to this point.

The conundrum on locinator was that I had some locator types that were created from a component say ‘geo.vtx[123]’ for example. My solution back in 2010ish when I wrote it was to just use a string for the whole thing and just hope there wasn’t a name conflict.

So, how might we store this in a persistent manner. Having learned a few things since back in twenty ought ten I said self, we can can better than that now.

The new implementation is as follows:

We take our data to be stored and split out our base node from any component or attribute. Namely we split the first ‘.’ out and validate the bits to know what we have

Store the main node as a standard message connection

Store the extra bits to a json dict via Red9’s json string implementation. We also allow for a a specified dataAttr (our extra data attr) and dataKey (for the dict) for specific storage

So in this case our ‘geo.vtx[123]’ is split to the following:

storageNull.msgAttr >>connection>> geo.msg

sorageNull.dataAttr = {msgAttr/dataKey:vtx[123]}

We do this as a dict and not a simple string attr per stored object because we use lots of these and having two attrs for every stored message seemed overkill. Once I’d worked out the component store, attribute storing was pretty simple. If we wanted to also add ‘geo2.tx’, it would be added as:

storageNull.msgAttr2 >>connection>> geo2.msg

sorageNull.dataAttr = {msgAttr2/dataKey2:vtx[71], msgAttr/dataKey:tx}

The dataKey comes in particular use with our datList/msgList setup which is our solution to multi message attrs being rubbish for maintaining ordered data.

When the get_message call happens it first gets the msgAttr and then checks the default extra dat attr if none is specified. Whenever data is found it gets appended to the return.

Yes, you can do some of this stuff with objectSets or other avenues and sometimes those work great. This
is simply another way of storing data mainly for our rigging purposes.

We have some big plans this year. Plans to get moving on taking gigs and also delivering on some long overdue promises.

Over the last few years, we’ve been doing a ton of r&d with the Morpheus Rig 2.0 project and it’s time to refine that work into something usable both for us and our users. We started some of that this last fall with meshTools but there’s a long way to go.

New Marking menu

This is will be at the center of our new rigs and systems. Many of the concepts and ideas were fleshed out during the Morpheus project and this is a major elaboration of that effort. You can see the frame work for that here. As a short window there are currently two modes:

TD — This is a replacement for our old tdTools. Having more stuff at a single button press proved very helpful with the Morpheus marking menu and it made sense to expand on that. This provides access to:

Raycasting

Snapping

Contextual tools

Locinator (currently rewriting)

A myriad of utilities and much more

Anim — This is just like the old anim marking menu plus a few new features.

Eventually there will be a Puppet mode similar to what our users were testing for Morpheus 2.0

Core Rewrite

This work began in November 2016 and is ongoing. We’ve been bringing to our cgm.core those functions and modules that our necessary for our next steps and will eventually cull out the old cgm.lib.

Morpheus Rigging System

In order to take jobs again in the time windows we have, we will be pushing our rigger to completion and along with that delivering at least a rig or two to the community. This involves a bit of re-imagining of the some concepts but feel this is the best way to go to get our users and backers the most functional setup we can deliver. I’m not gonna flesh out all of our ideas here as having failed on delivering what I’d hoped for Morpheus 2.0 initially there is a rather understandable gaping canyon of trust for deliving. When it’s done, you’ll see it. Those that are involved on either our cgmTools or Morpheus slack channels will hopefully help test and push things.If anyone wants to join those, message us here or on facebook.

Rigs

Biped base Morpheus

Some sort of quad rig to push some other modules through the rigger.

Internal Project

We’ve had an internal content project on hold for way too long and we plan on getting that rolling this year

First of all, what is ray casting? Ray casting in maya is when one of several api functions is called which when given a vector, start point and shapes to hit – returns points of intersection.

Turns out you can use that information for all kinds of things. For several years now, we’ve been using it to place follicles, cast curves and shapes on other meshes and other functions. A few months ago, I took a quick pass at adding a snap to function to our implementation where a user selects objects to snap, activates the tool and then casts a ray in scene to get a point in space to snap to. It worked but penetrations were rampant and I planned on revisiting it when I had some time.

Recently I found I had small chunks of time and this was one of the things that seemed useful to use one of those chunks for.

The solution we ended up with is as follows:

Objects are selected

The tool is activated

The user left clicks the screen to cast a ray given the options they’ve provided via the marking menu

A locator is generated and continuously updated while the key is held down

When the left click is released, the snap targets:

Cast another ray either along their ‘down’ axis or casting back to the hit point depending or orient mode

The first mesh hit is assumed to be the driven shape of the control or object and provides the offset distance to use

The targets are snapped to a new point in space from the hit point out along the normal of the mesh or nurbs surface of that hit the offset distance detected or provided via the marking menu for fixed amount

The objects are oriented (if required

The core of our functionality for this work on this pass is found:

cgm.core.lib.rayCaster — I simplified our call to a more generic rayCaster.cast rather than breaking down multi hit and other modes via separate calls. Also added normal returns from hit points as it was necessary for the offseting

Duplication — Selected objects are duplicated and snapped with each left click until the tool is dropped.

cgm.core.lib.math_utils.get_vector_of_two_points — Self evident.

cgm.core.lib.distance_utils.get_pos_by_vec_dist — Get a point along a ray given a point, ray and distance along that ray

Lessons learned:

Not 100% satisfied on current orient mode and I think Bokser may take a stab at that

Maybe I was the only one still using it but zoo’s baseMel UI has some serious slowdown in 2016. Normal mc. calls are much much faster. I’m culling out our usage as I can for speedier ui’s.

Initially I was using a vector from the hit point to the snap object as the offset vector but it proved to be inconsistent – For example, if you cast to a far side of a mesh with a ‘far’ cast, the offset put it inside the shape that was hit. Ended up finding the normal of the mesh/nurbs shape hit point to be a much better offset vector to use.

There are some issues with Maya api 2.0 folks should be aware of if you should want to mess with this stuff yourselves. These were all found to be True in Maya 2016.

meshFn.allIntersections — When casting at poly edges, 2.0 fails. 1.0 does not

surfaceFn.intersect — Nurbs surface UV returns a different rawUV than 1.0’s. 1.0’s normalizes as expected, 2.0’s does not

surfaceFn.normal — Nurbs surface normal return is junk and broken with 2.0. 1.0’s is just fine.

More on all of this, a vid or two and a new tool to play with in a few weeks.

For a LONG time now, I’ve been struggling to get Morpheus 2 where I wanted it. Having a small window to get something done because of personal stuff, I wanted to get something done. It’s also been way too long since we’ve released a ‘solid’ tool build so wanted to do that here.

I’ll keep this post updated with new builds as they become more stable until the next major release.

Added Snap support – Select targets, activate and snap stuff to any geo you have loaded as targets or in the scene. This is something I wanted to do way back when I first started playing with rayCasting and I’m happy to check that box

Been struggling on this one. The problem at hand is one of trying to get transformed blendshape targets baked down from one mesh to another. This path happened to be a dead end but hope it is useful for other purposes.

There are times when it is useful to see the difference in two meshes, or add/subtract the difference between two. In general, mesh math (as we’ll call it).

There are a few new calls:

cgm.core.lib.geo_Utils

meshMath_values — this call does the math portion of mesh math

meshMath

modes

add : (target + source) * multiplier

subtract : (target – source) * multiplier

multiply : (target * source) * multiplier

average: ((target + source) /2 ) * multiplier

difference: delta

addDiff: target + (delta * multiplier)

subtractDiff: target + (delta * multiplier)

blend: pretty much blendshape result if you added as a target using multiplier as weight

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.

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…:)