prSelectionUi 2023.0 update with Python 3.0 support

A few months ago I released an update (2023.0) for prSelectionUi that supports Python 3 (Maya >2022.x). It also still works with older Maya versions (Python 2.0).

You can get it here: https://pazrot.gumroad.com/l/prselectionui

It still requires PyMEL to be installed, which sadly has become more difficult with the PyMEL installation switching to pip. I think that installation change was a bad call and I regret using PyMEL. The time I saved was not worth the time lost for the users, and I might now have to rewrite the script with maya.cmds anyways.

Common sense #1: Investing

Because the investing information market place is dominated by bad actors, which directly or indirectly promote bad investment behavior, I want to do my part by sharing my favorite educational material, which allows anyone to understand the underlying principles and resulting incentives. And as a result see through the noise and not act against their own interest.

Summary

good 

• total market index funds 
• minimize fees 
• minimize taxes 

mid 

• factor investing 
• leverage

bad 

• trying to beat the stock market 
• actively managed funds 
• stock picking (country picking, sector picking, dividend investing, ..) 
• market timing 

very bad 

• speculating on non productive asset prices (precious metals, crypto/nft)

Sources

Why total market index funds and not trying to beat the stock market: 

• (51 min interview) Jack Bogle on Index Funds, Vanguard, and Investing Advice 
• (Text) Jack Bogle: "The Relentless Rules of Humble Arithmetic" 
• (5 hour audiobook) Jack Bogle - The Little Book of Common Sense Investing 

Once you understand how trying to beat the stock market is a bad idea, you also understand that trying to beat the market of non productive asset pricing is an even worse idea.

Testimony

• (3 min video) Warren Buffett pays tribute to Jack Bogle 
• (6 min video) Warren Buffett - How to Invest in Index Funds 

Advanced

The only reasonable divergence, that I am aware of, to actually increase expected returns, but comes with major increase in risk, volatility and complexity:

• factor investing
• (7 min interview) Eugene Fama - Why Small Caps and Value Stocks Outperform
• (16 min video) Ben Felix - Small Cap and Value Stocks
• leverage: 
• (13 min video) Ben Felix - Investing With Leverage

2019 - Scoob! rigging reel

• Content from 2019, for the animated feature film "Scoob!". It was my first show after moving to Canada and starting as Senior Rigging Artist at Reel FX.
• Was done for my 2020-2021 demo reel that got me to Vancouver / VFX
• I used a blinn/highlight shader to be more honest and show the surface curvature. With lambert/flat shaders you can get away with a lot more. Even wireframe is pretty forgiving. 
• Velma body rig (0:01 - 0:32):
• I could not actually find good body deformation shots in the movie, because she does not move much in general and wears a thick sweater. 
• 0:08 Deformation issue when metacarpals are offset. This area was always a struggle, because of the topology. It was the standard hand topology at the time and not supposed to be changed. That's why I didn't show the hands in the breakdown.
• 0:11 clavicle up chest corrective blending issue. It stops suddenly, when it should fade out or extend instead.
• Cpt. Caveman face rig (0:32 - 0:59)
• His face has a high range of motion with close ups in the movie, so I was happy with the shots that I could select for this demo.
• 0:48 Eyelid, mouth corner topology distortions: I did major retopology, maybe full retopology for his face, but afterwards there was a design change, which created these topology distortions in this somewhat neutral pose (The design/model change was great though)
• 0:57 shape and blend issues between eyebrows.

prPanelCtx - making of

Source

https://pazrot.gumroad.com/l/prpanelctx

Description

This script allows the user to have temporary panel settings during manipulator dragging and timeline changes (dragging, playback). The idea was to hide control shapes during this time, to allow animators to evaluate the deformation.

When using this script together with Mayas controller autohide on proximity, it can get pretty close to "Pixar style controls"

Related

The purpose is similar to "Pixar style controls". I'm not aware of a publicly available version of them. I have only seen around a dozen videos of prototypes from independent users.

Origin

I randomly stumbled upon the -preDragCommand and -postDragCommand flags of the manip*Context commands (manipMoveContex, ...). Before that I was not aware that the user can access these events. So when I saw them I thought they can be used for the purpose of this script.

Evolution
At first I thought about setting an attribute in the rig (global control visibility switch). But then I realized that it makes more sense to use it like a Maya setting and change the panel settings ("Panel > Show > .."), because:

• It works for any rig and does not introduce any per asset requirements (visibility attribute has to exist and has to be hard coded in the script)
• It can hide shot objects that are not part of the rig, like locators used for constraint setups
• It makes the animator completely independent and gives them full control over what to hide
• Can be used to hide the manipulator itself and other panel settings (wireFrameOnShaded, ...)

After that was done I added the timeline dragging / playback context. This is partially already possible in Maya:

- Custom Playblast settings "panel > show"

- Display layer playback setting

Comparison

Compared to "Pixar style controls" it is not as intuitive, but there are some advantages:

- It has less complexity than writing a Locator plugin that works in all Maya Viewports (legacy, 2.0) and on different OSs.

- It does not introduce dependency. The animator does not rely on an RnD department to develop the plugin and a rigging department to create these custom controls for each asset.

- It does not slow down the rig. In my limited speed testing it actually did speed up all the rigs a little bit.

Limitations
I could not find a way to access camera and channelBox dragging.
I could not find a way to make it work with component selection for modeling. Because the command flags I'm using require there to be a specific node type in the selection.

Personal usage
I don't think its that useful when rigging. I usually auto-hide the manipulators and only sometimes do I hide the controls in the timeline context when I'm working on the deformation. 

Tips when working remotely in Maya with VNC

I spent a few hours optimizing my VNC homeoffice setup and this is what I learned. (I only tried the free editions of realVNC and tightVNC.)

TL;DR

• realVNC supports dual monitor full screen
• tightVNC has more control for compression/encoding
• While moving the viewport camera, let go of ALT, but keep holding the mouse button to get rid of lag
• Maya settings to improve framerate
• Set background to solid color (don't use gradient)
• Disable "Display > Grid"
• Hide as many objects as possible for the moment
• Get rid of color transitions on surfaces
• Use solid shader colors 
• Viewport panel "Shading > Wireframe" 
• Use small viewport panel

Explanation

1. realVNC supports dual monitor full screen. tightVNC does not (in the free edition).
2. tightVNC has more control for compression/encoding, but it does never seem to get faster than realVNC, even with low quality and fast encoding.
3. While moving the viewport camera, let go of ALT, but keep holding the mouse button to get rid of lag. It seems like a random bug to me: While holding a mouse button at the same time as either ALT, CTRL, SHIFT there is an artificial lag with both VNC clients. The workaround can get annoying when quickly switching camera movement types, so I thought about changing the ALT hotkey. It would also be a good idea to look at more VNC clients, to see if one does not have this issue.
4. Maya settings to improve framerate By reducing image complexity and changes between each frame you can increase the framerate a lot, because the compressing and encoding of images will be faster (...something like that)
• Set background to solid color (don't use gradient) ALT+b hotkey
• Disable "Display > Grid"
• Hide as many objects as possible for the moment this includes creating temp mesh duplicates with all polyFaces deleted that are not needed for the current task.
• Get rid of color transitions on surfaces because this is often responsible for most of the pixel changes between frames
• Use solid shader colors for this I got rid of the color falloff on the default material (diffuse 0.0, set incandescence), so I can switch to "use default material" + "wireframe on shaded" most of the time.
• Viewport panel "Shading > Wireframe" 
• Use small viewport panel to have a smaller moving object. It's the same benefit as when zooming out (==fewer changing pixels over time)

The One Tool Challenge

Because there are so few useful and production ready Maya tools online. I was thinking how nice it would be, if every technical Maya user in the world would share (+support) even just one such tool in their lifetime. Putting it that way, should make it sound trivial. And if it were the case we would all be better off.
For myself I would consider prSelectionUi (https://vimeo.com/pazrot/prselectionui) to be a success in that regard. It is mostly for animators and after publishing it on highend3d and making a Vimeo video in 2012 it self distributed and to this day I find it installed at every company I go to and a lot of animators are using it.

In general I would recommend to consider:

• Is the tool actually useful? (doing something difficult != doing something useful)
• Can it already be done in Maya? Or has someone else already made a publicly available version?
• Is it useful enough for other people to be worth the time and effort to learn it, install it and keep it updated?
• Test it a while in production with a small group of people before sharing it publicly.
• Are you willing to support it?

If someone is looking for useful tool ideas. The most fundamental Maya UIs have a lot of room for improvement, so pretty much ever Maya user would benefit from those:

• Connection editor with name search/filter field to reduce the time and focus required to find the right attribute. Even with alphabetic ordering is it pretty tedious and that also does not work well together with child attributes, because it orders them together with the root attributes. In addition, it would also be nice to make it scalable, like the option to connect one output into multiple nodes input attributes at the same time.
• Add and Edit Attribute Editor for the 21st century. They have probably not been changed since 1999 and could benefit a lot from a major overhaul. I would also merge them into one.
• A non-destructive Node editor / Hypergraph: One that does not move the editor-view and nodes around on it's own when working with it. The node editor version would be a lot more work, so I would probably start with something closer to the Hypergraph.
• Attribute editor for multiple nodes at once (setting values applies to all nodes, not just one). I don't know how the aeTemplate reading works, so it might be really hard to do. In that case an improved Attribute Spread Sheet could be a better goal.

I'm not much of a UI guy, so that's probably why those have been on my mind for a while and I haven't done any of them. They also don't have the biggest impact, but a huge target audience.

prKeepOut.py making-of

A custom Maya node that can be found here:
https://github.com/parzival-roethlein/prmaya

A few months ago I started making improved array versions of Maya nodes for smaller, scalable, procedural graphs.
The prKeepOut node specifically had some relevance for production: I had an asset with around a hundred armor pieces and I thought about using keepOut nodes, but ended up deciding against them because it would have been overkill: Each armor piece would have required multiple keepOut nodes, which would have slowed down the rig a lot, take a long time to setup and probably never really work that well, because of multiple armor pieces overlapping in areas with multiple deformation axes. In the end I copied the skinCluster and blendShapes from the body and tweaked them to make the armor deform more rigid and add some offset controls for a few of the armor pieces.

It took me a few evenings after work to write prKeepOut, so in hindsight I wondered why I hadn't done it sooner. The "algorithm" is less than 100 lines and the rest is just the verbose Maya API way of creating/querying/setting attributes.
I thought about writing more about the making-of and reasoning. But it's open source and just basic Maya API, linear algebra usage. And I imagine the changes make sense to anyone who has used the 10 year old Maya keepOut node.
Initially I had shape inputs specific for each ray to support multi layer collision, but removed it again, because it would make the node usage too complex and risk evaluation cycles.
With the recent input matrix announcement for transforms in Maya 2020+ I'm thinking about switching to matrix outputs.

A few weeks later Autodesk announced bifrost graph, which looks amazing and will hopefully make these kind of custom nodes obsolete.

New job at Reel FX

This week I started at Reel FX Montreal as Senior Rigging Artist and I'm really looking forward to working on their animated features.

When looking for a new job my main goal was to find the most interesting work. After five years in Germany where I had a lot of control on the whole rigging pipeline (I often was the only rigger on the project) and I completed some of my main goals:

• Create a non-destructive rigging pipeline in production: Almost complete freedom in the template and rig-built stage while always being able to undo/redo the rig build
• Improve modeling / topology skills by creating complete characters and topologies based on "The Art of Moving Points"

Maya API ramp attribute bug?

1. When saving:

2. What gets stored in the ascii file: 

setAttr -s 2 ".falloff[1]"  1 1 1;

3. After opening the scene again:

I recently noticed in Maya 2018 that custom Python API 1.0 node ramp attribute elements with position/value/interpolation : 0.0/0.0/linear do not get saved with the Maya scene (if their index is the lowest). I guess this is a bug. Some debug infos I gathered:

• Probably bug source: By default Maya does not save attribute default values
• Does not happen with default Maya nodes like remapValue
• MPxNode.shouldSave documentation explains why this should not happen (but it is not true): "This method is not called for ramp attributes since they should always be written."
• Since shouldSave gets wrongfully called it has to be overwritten to fix the problem
• Only returning 'unknown' will not save the attribute. OpenMayaMPx.MPxNode.shouldSave(...) does exactly that.
• The Python devkit example of shouldSave pyApiMeshShape.py is a bit misleading: From what I have tested all these return values seem to force save: True, False, None 

Implementations of this workaround can be found in prClosestPoint:

https://github.com/parzival-roethlein/prmaya

Update 2020-03-31:
Another situation with the same problem was with a float array attribute in Python API 2.0. The fix is in my /plugins/prUpCurveSpline.py: 
https://github.com/parzival-roethlein/prmaya

prPyMath.py making-of

A custom Maya node that can be found here:
https://github.com/parzival-roethlein/prmaya
Direct file link:
https://github.com/parzival-roethlein/prmaya/blob/master/prmaya/plugins/prPyMath.py

Origin
I wanted to create a node for some trigonometry functions, so I don't have to pollute the node graph with expressions. But after noticing that the functions I needed are all part of the Python math module I decided to just wrap the whole module, to make the node more useful.
There are only a few repeating argument in the whole module and all functions return one or two numbers. Which means there are also few Maya attributes needed to cover all cases.

Usability
A math node with that many operations is not typical for Maya.
When comparing such general purpose math nodes it might be better to just use a Python expression node like this one: http://around-the-corner.typepad.com/adn/2012/08/a-mathematical-dg-node.html

Code
It was the first time I used the Maya Python API 2.0 for an MPxNode. But in this simple case it did not make a big difference. For the Attribute Editor buttons "Create element", "Delete element" I had to look into querying the node in the Attribute Editor context for the first time. Currently it is a workaround with a hidden textfield. I guess a global MEL variable might be the proper way to handle that?!