Archive for January, 2017

Mon, Jan 23rd, 2017
posted by jjburton 09:01 PM

Problem: Storing a shape (not a transform) as a messaged connection.

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.

Wed, Jan 18th, 2017
posted by jjburton 08:01 PM

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 —
  • 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:

  1. 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
  2. Store the main node as a standard message connection
  3. 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.

Still refining this but happy so far. Thus ends this post.


Sun, Jan 1st, 2017
posted by jjburton 11:01 PM

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