animallogic / al_usdmaya

This repo is no longer updated. Please see https://github.com/Autodesk/maya-usd

Note: This repository is now read-only

As of October 2019 we will no longer be updating this repo or accepting new Pull Requests or issues. The code has migrated to the Autodesk maya-usd repo where it will continue to be maintained and developed by Animal Logic, Autodesk, Luma Pictures and others.

What is AL_USDMaya?

Represent Maya data in Maya, and USD data in USD - for example, we use AL_USDMaya to allow native Maya entities such as complex maya referenced rigs (and other assets not easily represented in USD) to be embedded in USD scenes and imported into Maya in their native form. The plugin maintains a "live" connection between the USD and Maya scene, and can respond to various events, keeping the Maya and USD scenes in sync. This affords a dynamic user experience which allows artists to swap in and out different representations of objects in their scene (e.g Rigs for Geometry Caches, different levels of detail etc). Additionally, heavyweight scene elements such as sets/crowds can be represented in OpenGL in the Maya viewport, and manipulated either with USD or Maya tools and UI components.

Motivation

Why did we need an alternative USD Maya Bridge to the USDMaya plugin that comes with USD?

Pixar's USDMaya plugin was originally designed for quite a specific (Set Dressing) workflow using Maya's Scene Assembly Feature. Maya is our most important DCC app, and while, like in the Pixar plugin, we try and avoid representing most of our data (particularly large and complex things) in the Maya native data model, we do use it as the hub of our Scene Building and artist workflow - our Layout Artists, Animators, Set Dressers and Lighters work mostly in Maya, so it made sense to try and implement something that was more tailored to the way we work at Animal Logic. We played with the idea of modifying/forking the existing Pixar USDMaya, but in the end we diverged so much that it didn't make sense. We do have a plan to merge these two at some point and get the best of both worlds. There is a partial feature comparison here

Contact

We have a google group for discussion and technical assistance: https://groups.google.com/forum/#!forum/al_usdmaya-discussion. For CLAs or to contact us directly, use email [email protected].

Videos

We have some videos explaining some of the workflows we support. We are hoping to add to this as we go:

• Animation & Layout
• Modelling & Surfacing

Detailed Documentation

• Building it
• FAQ
• Python
• Contributing
• Translation
• Basic Usage
• Maya developer tools and utilities
• Proxy Shape
• Selection
• Schema Translator Plugins
• Events
• Layers
• Animation
• Import Export
• Asset Resolution and versioning
• Workflows
• Example Plugins
• Testing
• Comparison with Pixar USDMaya plugin
• Extra Data Translator Plugin

Developer Documentation

Source code documentation

How is the repository layed out?

The important parts:

Location	Description
lib	The core AL_USDMaya Library
plugin	maya plugin and test plugin
samples	mixed bag of test inputs
schemas	Schemas - Maya specific schemas for which we have translators
translators	Reference Schema Translator Plugins
tutorials	a few tutorials
utils	For now just contains the event System (AL_EventSystem)
mayautils	a library of code which depends on Maya only (AL_MayaUtils)
usdutils	a library of code which depends on USD only
usdmayautils	a library of code which depends on USD and Maya (AL_USDMayaUtils)

Libraries

Package	Library	Folder Hierarchy	Namespaces	Major Dependencies
AL_EventSystem	AL_EventSystem.so	utils/AL/event	AL::event
AL_MayaUtils	AL_MayaUtils.so	mayautils/AL/maya/utils	AL::maya:utils	Maya
AL_USDUtils	AL_USDUtils.so	usdutils/AL/usd/utils	AL::usd::utils	USD
AL_USDMayaUtils	AL_USDMayaUtils.so	usdmaya/AL/usdmaya/utils	AL::usdmaya::utils	USD, Maya

The core AL_USDMaya library

Best to have a look here but a quick summary here:

Location	Description
lib/AL_USDMaya/AL/usdmaya/cmds	Maya MpxCommands
lib/AL_USDMaya/AL/usdmaya/fileio	File Import/Export code including some general purpose USD<->Maya interchange utilities e.g DGNodeTranslator DAGNodeTranslator
lib/AL_USDMaya/AL/usdmaya/nodes	Maya MpxNodes such as the proxy Shape

al_usdmaya's Issues

importAsNative functionality has disappeared

We used to have functionality which allowed us to tag (via metadata) particular meshes etc as "import them into maya as maya geo". This has disappeared - please bring it back and add some tests for it.

Instanced prims breaking selection

Hi,

I'm getting some incorrect results when using the plug with the following arrangement of usd files. I've modelled this structure on information from Sebastian on the usd-interest google group so it should be sound.

I've included the contents of some usd files that I'm using to test with. When I load the shot_layout.usda file, it will always select RockA_01 no matter which one I select. If I set instanceable to false in the component.usda file it works as expected.

Thanks
Jason

// shot_layout.usda -- instancing 2 rocks in a shot layout

#usda 1.0
(
    defaultPrim = "world"
)
def Xform "World" {
    def Xform "RockA_01" (
        add references = @./component.usda@
    )
    {
        double3 xformOp:translate = (5, 5, 5)
        uniform token[] xformOpOrder = ["xformOp:translate"]
    }

    def Xform "RockA_02" (
        add references = @./component.usda@
    )
    {
        double3 xformOp:translate = (-5, -5, -5)
        uniform token[] xformOpOrder = ["xformOp:translate"]
    }
}

// component.usda  --  The interface file for the rock component
#usda 1.0
(
    defaultPrim = "RockA"
)

def Xform "RockA" (
    assetInfo = {
        asset identifier = ""
        string name = ""
    }

    kind = "component"
    instanceable = true

    payload = @./payload.usda@

    variants = {
        string LevelOfDetail = "proxy"
    }
    add variantSets = ["LevelOfDetail"]
)
{
    variantSet "LevelOfDetail" = {
        "high" {}
        "medium" {}
        "low" {}
        "proxy" {}
        "bbox" {}
    }
}

// payload.usda -- mesh data that makes up the rock
#usda 1.0
(
    defaultPrim = "RockA"
)

over "RockA" (
    variants = {
        string LevelOfDetail = "proxy"
    }
    add variantSets = ["LevelOfDetail"]
)
{
    variantSet "LevelOfDetail" = {

        "high" {
            def Xform "geom"
            {
                def Sphere "Mesh01" () {}
                def Sphere "Mesh02" () {}
            }
        }

        "medium" {
            def Xform "geom"
            {
                def Sphere "Mesh01" () {}
                def Sphere"Mesh02" () {}
            }
        }

        "low" {
            def Xform "geom"
            {
                def Sphere "Mesh01" () {}
                def Sphere "Mesh02" () {}
            }
        }

        "proxy" {
            def Xform "geom"
            {
                def Sphere "Mesh01" () {}
                def Sphere "Mesh02" () {}
            }
        }

        "bbox" {
            def Xform "geom"
            {
                def Sphere "Mesh01" () {}
                def Sphere "Mesh02" () {}
            }
        }
    }
}

Make makeUsdPath() handle namespace in DAG path

Please make makeUsdPath() in Maya->USD export facility handle namespaces in DagPaths somehow. The SdfPath in USD doesn't like colons, which are used as namespace separators in Maya. The current implementation returns an empty SdfPath as that's exactly what SdfPath::SdfPath() leaves when presented with an invalid path.

For example:

MDagPath makeDagPath(const char*);
makeUsdPath(makeDagPath("|a|b"), makeDagPath("|a|b|c:d")); // returns empty SdfPath

@aloysbaillet

Is MayaReference Translator in the correct location?

To build the translators I had to alter this include: https://github.com/AnimalLogic/AL_USDMaya/blob/develop/translators/MayaReference.cpp#L29

Based on the DgNodeTranslator above it, should the MayaReference Translator be moved into AL/usdmaya/filio/translators ??

Rename MayaReference to AL_usd_MayaReference

https://github.com/AnimalLogic/AL_USDMaya/blob/develop/translators/MayaReference.h

MayaReference should be called AL_usd_MayaReference to match up with the call to AL_USD_MAYA_DEFINE_TRANSLATOR here: https://github.com/AnimalLogic/AL_USDMaya/blob/develop/translators/MayaReference.cpp#L46

ProxyShape.h:694:68: error: ‘kSerial’ was not declared in this scope during building

Does anyone got below issue?

-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.5")
-- Found Maya: /apps/shared/maya/2016/platform-linux/bin/maya (found version "201610")
-- Boost version: 1.55.0
-- Found the following Boost libraries:
-- python
-- Found GTest: /data/share/usd/dependency/googletest/1.8.0/lib/libgtest.so
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
CMake Warning at tests/CMakeLists.txt:28 (message):
maya_tests not active since unsupported version of maya is available in the
environment

-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:

GLEW_LOCATION
OPENEXR_LOCATION
OPENGL_gl_LIBRARY

-- Build files have been written to: /home/mjun/workspace/AL_USDMaya/build

[ 1%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/maya/CodeTimings.cpp.o
[ 2%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/maya/CommandGuiHelper.cpp.o
[ 3%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/maya/DgNodeHelper.cpp.o
[ 7%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/maya/NodeHelper.cpp.o
[ 7%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/maya/MenuBuilder.cpp.o
[ 7%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/maya/FileTranslatorOptions.cpp.o
[ 8%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/AttributeType.cpp.o
[ 10%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/DrivenTransformsData.cpp.o
[ 11%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/Global.cpp.o
[ 12%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/StageCache.cpp.o
[ 13%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/StageData.cpp.o
[ 15%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/TransformOperation.cpp.o
[ 16%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/Utils.cpp.o
[ 17%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/DebugCodes.cpp.o
[ 18%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/Metadata.cpp.o
[ 20%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/LayerCommands.cpp.o
[ 21%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/ProxyShapeCommands.cpp.o
[ 22%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/ProxyShapePostLoadProcess.cpp.o
In file included from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/Global.cpp:19:0:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h: In member function ‘virtual MPxNode::SchedulingType AL::usdmaya::nodes::ProxyShape::schedulingType() const’:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h:694:68: error: ‘kSerial’ was not declared in this scope
MPxNode::SchedulingType schedulingType() const override { return kSerial; }
^
In file included from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/cmds/ProxyShapeCommands.h:18:0,
from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/cmds/ProxyShapeCommands.cpp:18:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h: In member function ‘virtual MPxNode::SchedulingType AL::usdmaya::nodes::ProxyShape::schedulingType() const’:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h:694:68: error: ‘kSerial’ was not declared in this scope
MPxNode::SchedulingType schedulingType() const override { return kSerial; }
^
In file included from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/cmds/ProxyShapePostLoadProcess.cpp:28:0:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h: In member function ‘virtual MPxNode::SchedulingType AL::usdmaya::nodes::ProxyShape::schedulingType() const’:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h:694:68: error: ‘kSerial’ was not declared in this scope
MPxNode::SchedulingType schedulingType() const override { return kSerial; }
^
make[2]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/LayerCommands.cpp.o] Error 1
make[2]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/ProxyShapeCommands.cpp.o] Error 1
make[2]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/ProxyShapePostLoadProcess.cpp.o] Error 1
In file included from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/cmds/ProxyShapeCommands.h:18:0,
from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/cmds/UnloadPrim.h:18,
from /home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/cmds/UnloadPrim.cpp:18:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h: In member function ‘virtual MPxNode::SchedulingType AL::usdmaya::nodes::ProxyShape::schedulingType() const’:
/home/mjun/workspace/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.h:694:68: error: ‘kSerial’ was not declared in this scope
MPxNode::SchedulingType schedulingType() const override { return kSerial; }
^
make[2]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/cmds/UnloadPrim.cpp.o] Error 1
make[1]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/all] Error 2

The Maya version is 2016sp5.

Can't select individual instances in viewport

Logging this for visiblity, it's been mentioned by a few people both internally and externally, but no Issue logged so far.
When selecting instances in the Hydra viewport, there are 2 problems:

1. Querying the selected paths always results in the first instance being returned.
2. Selection highlighting selects all instances. This is a direct result of PixarAnimationStudios/OpenUSD#444. We can attempt to implement a suggested masking workaround see https://groups.google.com/forum/#!topic/usd-interest/3L2I93UjHss

We have a fix for 1. internally which will be released soon, 2 is still WIP

error importing pxr.Tf (or... why does the stub pxr module exist?)

Noticed that if you start up maya + AL_USDMaya in a context without pkg_resources, and where AL_USDMaya_ROOT/lib/python is on the PYTHONPATH before USD_ROOT/lib/python, then try:

import pxr.Tf

...it will fail because of the stub pxr/__init__.py installed by AL_USDMaya.

This could be fixed by modifying the stub pxr/__init__.py to fallback to using pkg_util.extend_path (as it does in other places)... but the bigger question is... why do we even need this stub pxr module? All it seems to do is set __all__ = []. There are no other files in the module. Why do we need to set __all__ to an empty list?

Respect upAxis metadata when reading usd

AL (as opposed to the built-in pixar plug in) ignores the "upAxis" setting in the root metadata of a usd scene.

For an example, download and import the KitchenSet provided by pixar (http://graphics.pixar.com/usd/downloads.html), which has upAxis = "Z"

Crash on selection / Import transforms

When I click on a proxy mesh in the viewport maya will crash. This happens with all tried viewport modes,

• viewport2 w/ legacy opengl
• viewport2 w/ compatibility
• legacy viewport
• with and without MAYA_VP2_USE_VP1_SELECTION=1

It also give the same stack trace if I select the ProxyShape and use "Import Transform as Transforms"

CentOS 7
Maya 2017 Update 4
USD 0.8

➜  AL_USDMaya git:(master) ✗ ./setup_environment.sh /usr/local/USD
root:/usr/local/USD
-Updating PATH-
/usr/local/USD/src:/home/boulder/bin:/usr/local/bin:/usr/lib64/qt-3.3/bin:/home/boulder/perl5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/boulder/bin:/usr/local/USD/bin
-Updating PYTHONPATH-
/usr/local/USD/lib/python:/home/boulder/git/usd-qt-components::/usr/local/USD/lib/python
-Updating LD_LIBRARY_PATH-
/usr/local/USD/lib64:/usr/local/USD/lib:
-Updating MAYA_PLUG_IN_PATH-
/usr/local/USD/plugin:
-Updating MAYA_SCRIPT_PATH-
/usr/local/USD/lib:/usr/local/USD/share/usd/plugins/usdMaya/resources:
-Updating PXR_PLUGINPATH-
/usr/local/USD/share/usd/plugins:

Initialized VP2.0 renderer {
  Version : 2016.3.78.11. Feature Level 4.
  Adapter : Quadro M4000/PCIe/SSE2
  Vendor ID: 4318. Device ID : 
  Driver : 4.5.0 NVIDIA 384.59.
  API : OpenGL V.4.5.
  Max texture size : 16384 * 16384.
  Max tex coords : 8
  Shader versions supported (Vertex: 4, Geometry: 4, Pixel 4).
  Shader compiler profile : (Best card profile)
  Active stereo support available : 0
  GPU Memory Limit : 8192 MB.
  CPU Memory Limit: 30337.5 MB.
MultiDraw consolidation attempted to enable, but the graphics device does not support it.  MultiDraw will be disabled.
}
OpenCL evaluator is attempting to initialize OpenCL.
Detected 1 OpenCL Platforms: 
 0: NVIDIA Corporation. NVIDIA CUDA. OpenCL 1.2 CUDA 9.0.130.
 Supported extensions: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_khr_gl_event cl_nv_create_buffer
OpenCL evaluator choosing OpenCL platform NVIDIA Corporation.
Choosing OpenCL Device Quadro M4000.  Device Type: GPU  Device is available.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

TBB Warning: Max number of workers has been already set to 13. The request for 15 workers is ignored.

maya.bin: /home/boulder/git/AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp:261: void AL::usdmaya::nodes::ProxyShape::makeTransformReference(const pxrInternal_v0_8__pxrReserved__::SdfPath&, const MObject&, AL::usdmaya::nodes::ProxyShape::TransformReason): Assertion `!isRequiredPath(path)' failed.
Stack trace:
  gsignal
  abort
  /lib64/libc.so.6(+0x2e146) [0x7f7bb956f146]
  /lib64/libc.so.6(+0x2e1f2) [0x7f7bb956f1f2]
  AL::usdmaya::nodes::ProxyShape::makeTransformReference(pxrInternal_v0_8__pxrReserved__::SdfPath const&, MObject const&, AL::usdmaya::nodes::ProxyShape::TransformReason)
  AL::usdmaya::nodes::ProxyShape::insertTransformRefs(std::vector<std::pair<pxrInternal_v0_8__pxrReserved__::SdfPath, MObject>, std::allocator<std::pair<pxrInternal_v0_8__pxrReserved__::SdfPath, MObject> > > const&, AL::usdmaya::nodes::ProxyShape::TransformReason)
  AL::usdmaya::nodes::SelectionUndoHelper::doIt()
  AL::usdmaya::cmds::ProxyShapeSelect::redoIt()
  AL::usdmaya::cmds::ProxyShapeSelect::doIt(MArgList const&)
  THcommandObject::doIt(TargList&)
  TmetaCommand::doCommand(TargList&)
  Mel_Command_Dispatch(SphNode*)
  f_function_entry_node
  node_exec
  sophia_call_executable
  SophiaExecutable::evaluate(void*)
  TcommandEngine::executeCommand(Tstring const&, bool, bool, TmelCmdResult*, unsigned int)
  MGlobal::executeCommand(MString const&, MStringArray&, bool, bool)
  AL::usdmaya::nodes::ProxyShapeUI::select(MSelectInfo&, MSelectionList&, MPointArray&) const
  THsurfaceShapeUI::select(TselectInfo&, TselectionList&, T4dDblPointArray&) const
  TselectTraversal::processThisObject(TdagObject*)
  TdrawTraversal::processObject(TdagObject*)
  TselectTraversal::processObject(TdagObject*)
  TfrustumCullTraversal::cull(TdagObject*)
  TfrustumCullTraversal::traverseChildren(TdagObject*, bool)
  TselectTraversal::processThisObject(TdagObject*)
  TdrawTraversal::processObject(TdagObject*)
  TselectTraversal::processObject(TdagObject*)
  TfrustumCullTraversal::cull(TdagObject*)
  TfrustumCullTraversal::traverseDag()
  TdrawTraversal::traverseView(T3dView*, bool)
  TselectTraversal::select(TselectionList&, T4dDblPointArray&)
  TbaseOpenGLRenderer::select(TselectInfo&, bool, TselectionList&, T4dDblPointArray&)
  Tmodel::select(Tpoint const&, TselectionTypeSet const&, bool, bool, TselectionItem*&, T4dDblPoint&, TselectionList*, T4dDblPointArray*, TselectionMethod, bool, bool)
  TselectContext::doClickSelection(Tevent const&)
  TselectContext::doRelease(Tevent const&)
  TselectToolContext::doRelease(Tevent const&)
  TtoolContext::preDoRelease(Tevent const&)
  TstandardContext::preDoRelease(Tevent const&)
  TtoolCallback::doIt(Tevent const&)

Fatal Error. Attempting to save in /usr/tmp/boulder.20170814.1153.ma
Writing crash report in /usr/tmp/boulder.20170814.1153.crash
Killed

Don't clear selection list before file save

There is a callback registered here: https://github.com/AnimalLogic/AL_USDMaya/blob/develop/lib/AL_USDMaya/AL/usdmaya/Global.cpp#L140
which clears the selection list before file save. I see from the comment why this is necessary, but this affects all scenes after the AL usdmaya plugin has been loaded, even scenes which do not have any AL nodes. I believe there is a much more surgical approach to this that could be applied (e.g., only deselecting what is necessary, or not allowing transient nodes to be stored in the Maya file via MPxNode::setDoNotWrite).

FYI: our current use case does not create transient nodes, so I'm just disabling the callback in our local version, but this is not a long term solution.

Camera squeezeRatio is not round-tripable.

Currently on export from Maya, the lensSqueezeRatio is a scalar multiplied with the horizontalFilmAperture, verticalFilmAperture, horizontalFilmApertureOffset, and horizontalFilmApertureOffset. If the squeeze ratio is anything other than 1, this means that the values being imported back into Maya will no longer match the original camera values.

We might need to add the squeeze ratio into our own schema to get around this problem (unless it's pointless, in which case we can remove it).

Compatibility with USD Version 18.09

Hi guys
I wonder The Current Version of Al_USDMaya is compatible with USD Version 18.09 or we should wait for next release?

thanks

Allow automatic saving of USD stage rather than serialization

Quoted from #53 (comment)

Yes, we also considered this, and there's a lot to like about storing this data in a side-car file that can be accessed outside of Maya. It'll take some wrangling to make sure that callbacks are always firing at the right moments so that data is not lost. Xgen pre-2017 is a good example of how this approach can go wrong, but I think it's a solvable problem and we'd love to see this become an option.

Our maya pipeline is built on sidecar files with quite a bit of bookkeeping to handle importing and referencing, so maybe we can look into how to contribute back some of this work in order to support this workflow.

Enable pre-compiled headers in the build

The time it takes to re-compile a single change in a single file is a little bit sad.
Enable pre-compiled headers for all the common Maya API + Usd header files (so we can isolate ourselves from the template instantiation cost).

OS X build

I noticed that current branch has no support for OSX build, I think it's shame cause it works fine on OSX with Maya 2018.

can't find '__main__' module in ".../schemas"

Hello, after multiple tries to find the right directory for the AL_USDMayaSchemas, i have this error.
I tried to use this path for the schemas but the same error '/home/nseif/packages/usd_maya_al/AL_USDMaya/schemas'

-- C++ namespace configured to (external) pxr, (internal) pxrInternal_v0_8
-- Boost version: 1.53.0
-- Found the following Boost libraries:
-- python
-- thread
-- filesystem
-- chrono
-- system
-- date_time
-- atomic
-- Building AL_USDMayaSchemas
/usr/bin/python: can't find 'main' module in '/home/nseif/packages/usd_maya_al/AL_USDMaya/schemas/AL/usd/schemas'
CMake Error at schemas/AL/usd/schemas/CMakeLists.txt:49 (message):
Schemas generation failed

CMakeError.log
CMakeOutput.log

Thanks,
Nohra
SqueezeStudio

ProxyShape::makeUsdTransformChain does not always setup resulting path.

If the function finds the path in the list of already existing paths, the resultingPath is set to an empty string.

This

    if(resultingPath)
    {
      MFnDagNode fn;
      MDagPath path;
      fn.getPath(path);
      *resultingPath = path.fullPathName();
    }

should be

    if(resultingPath)
    {
      MFnDagNode fn(nodeToReturn);
      MDagPath path;
      fn.getPath(path);
      *resultingPath = path.fullPathName();
    }

at

AL_USDMaya/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp

Line 442 in a8f80cd

MFnDagNode fn;

Selection highlight doesn't work in VP2 wireframe mode

To reproduce this:

• Change to wireframe mode in VP2
• Use the AL_usdmaya_ProxyShapeSelect command to select any primitive in the usd stage
• Primitive won't be displayed as selected in viewport

AL_USDMaya 0.28.4
USD 0.8.5
Maya 2018 Update 3
CentOS 7.5

Extra transforms being introduced on selection

We're evaluating using the AL plug, or a something derived from it, in our pipe and we're seeing some transforms being introduced on selection.

We're testing with Pixars kitchen set on this page: http://graphics.pixar.com/usd/downloads.html

Upon selection of the plates in the dish rack, they pop into another position. It happens for other assets in the set as well.

Error loading AL_USDMayaPlugin.so: undefined symbol: _ZNK5boost10filesystem4path14root_directoryEv

Looks like this is related to the changes here:

f27551a

I'm guessing that there are some changes that haven't gotten pushed, or got lost in a merge, or something, as this:

AL_USDMaya/lib/AL_USDMaya/CMakeLists.txt

Line 198 in 6492597

if(NEED_BOOST_FILESYSTEM)

...would imply that NEED_BOOST_FILESYSTEM needs to be set, but it's not refered to elsewhere. (Also probably need to add filesystem to the list of required boost components, in the top-level cmake).

Or, can make a PR if that would be easier...

Copying failed during building since there is no generatedSchema.usda

Hi There, Got below error during building it:

-- Boost version: 1.55.0
-- Found the following Boost libraries:
-- python
-- Building AL_USDMayaSchemas
CMake Warning (dev) at schemas/AL/usd/schemas/CMakeLists.txt:60 (get_target_property):
Policy CMP0026 is not set: Disallow use of the LOCATION target property.
Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.

The LOCATION property should not be read from target "AL_USDMayaSchemas".
Use the target name directly with add_custom_command, or use the generator
expression $<TARGET_FILE>, as appropriate.

This warning is for project developers. Use -Wno-dev to suppress it.

CMake Error at schemas/AL/usd/schemas/CMakeLists.txt:75 (file):
file COPY cannot find
"/home/mjun/workspace/AL_USDMaya/build/schemas/AL/usd/schemas/generatedSchema.usda".

Any ideas about this? Thanks a lot.

EditTarget: Iterate through a prim's NodeIndex's when determining the MapFunction

Currently when trying to determine the MappingFunction for the EditTarget, we iterate through the AddedItems of the reference list on the targeted prim.
It is recommended to not do this since doing it this way only iterates through the top later of references and doesn't take into account nested references.

https://github.com/AnimalLogic/AL_USDMaya/blob/9f87b82fa5fff5cfb671778e62eec64299a078e7/src/lib/AL_USDMaya/AL/usdmaya/cmds/LayerCommands.cpp#L724

Selection change causes Usd_IssueFatalPrimAccessError

Changing the selection with AL_usdmaya_ProxyShapeSelect a few times consistently causes Maya to abort.

I've only seen this in maya2019 for now.

This is a stack trace and some debug information:

ProxyShapeSelection::removeUsdTransformChain
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::onSelectionChanged 0
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::TransformReference::checkRef 1 : 1 0 0
ProxyShapeSelection::SelectionUndoHelper::doIt 0 1
ProxyShapeSelection::removeTransformRefs 1
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::TransformReference::decRef 1 0 0
ProxyShapeSelection::TransformReference::decRefEnd 0 0 0
ProxyShapeSelection::doSelect
ProxyShapeSelection::makeUsdTransformChain_internal
ProxyShapeSelection::makeUsdTransformChain /Kitchen_set/Arch_grp/Kitchen_1/Geom/TileFloor/pPlane218
ProxyShapeSelection::makeUsdTransformChain /Kitchen_set/Arch_grp/Kitchen_1/Geom/TileFloor
ProxyShapeSelection::makeUsdTransformChain /Kitchen_set/Arch_grp/Kitchen_1/Geom
ProxyShapeSelection::makeUsdTransformChain /Kitchen_set/Arch_grp/Kitchen_1
ProxyShapeSelection::makeUsdTransformChain /Kitchen_set/Arch_grp
ProxyShapeSelection::makeUsdTransformChain /Kitchen_set
ProxyShape::makeUsdTransformChain created transformType=AL_usdmaya_Transform name=Kitchen_set
ProxyShapeSelection::TransformReference::checkIncRef 0 0 0
ProxyShape::makeUsdTransformChain created transformType=AL_usdmaya_Transform name=Arch_grp
ProxyShapeSelection::TransformReference::checkIncRef 0 0 0
ProxyShape::makeUsdTransformChain created transformType=AL_usdmaya_Transform name=Kitchen_1
ProxyShapeSelection::TransformReference::checkIncRef 0 0 0
ProxyShape::makeUsdTransformChain created transformType=AL_usdmaya_Transform name=Geom
ProxyShapeSelection::TransformReference::checkIncRef 0 0 0
ProxyShape::makeUsdTransformChain created transformType=AL_usdmaya_Transform name=TileFloor
ProxyShapeSelection::TransformReference::checkIncRef 0 0 0
ProxyShape::makeUsdTransformChain created transformType=AL_usdmaya_Transform name=pPlane218
ProxyShapeSelection::TransformReference::checkIncRef 0 0 0
ProxyShapeSelection::SelectionUndoHelper::doIt 1 0
ProxyShapeSelection::makeTransformReference /Kitchen_set/Arch_grp/Kitchen_1/Geom/TileFloor/pPlane218
ProxyShapeSelection::TransformReference::incRef 0 0 0
ProxyShapeSelection::TransformReference::incRefEnd 1 0 0
ProxyShapeSelection::TransformReference::incRef 0 0 0
ProxyShapeSelection::TransformReference::incRefEnd 1 0 0
ProxyShapeSelection::TransformReference::incRef 0 0 0
ProxyShapeSelection::TransformReference::incRefEnd 1 0 0
ProxyShapeSelection::TransformReference::incRef 0 0 0
ProxyShapeSelection::TransformReference::incRefEnd 1 0 0
ProxyShapeSelection::TransformReference::incRef 0 0 0
ProxyShapeSelection::TransformReference::incRefEnd 1 0 0
ProxyShapeSelection::TransformReference::incRef 0 0 0
ProxyShapeSelection::TransformReference::incRefEnd 1 0 0
ProxyShapeSelection::removeTransformRefs 0
ProxyShapeSelection::onSelectionChanged 0
Coding Error (secondary thread): in AddXformOp at line 198 of 
./usd/pxr/usd/lib/usdGeom/xformable.cpp -- The xformOp 'xformOp:translate:rotatePivotTranslate'
 already exists in xformOpOrder [[xformOp:translate:translate, xformOp:translate:pivot, 
xformOp:translate:rotatePivotTranslate, xformOp:rotateXYZ:rotate, xformOp:rotateXYZ:rotateAxis, 
xformOp:translate:scalePivotTranslate, xformOp:transform:shear, xformOp:scale:scale, 
!invert!xformOp:translate:pivot]].
Coding Error (secondary thread): in SetXformOpOrder at line 421 of
 ./usd/pxr/usd/lib/usdGeom/xformable.cpp -- XformOp attribute <> does not belong to 
schema prim </Kitchen_set/Arch_grp/Kitchen_1/Geom/TileFloor>.

------------------------ 'maya.bin' is dying ------------------------
maya.bin crashed. FATAL ERROR: Used null prim
in Usd_IssueFatalPrimAccessError at line 243 of ./usd/pxr/usd/lib/usd/primData.cpp
------------------------------------------------------------------
/usr/net/app/autodesk/maya2019-pr95/bin/maya2019: line 188: 29124 Aborted  
/usr/net/app/autodesk/maya2019-pr95/bin/maya.bin

AL_USDMaya 0.29.1
USD 18.09
Maya 2019
CentOS 7.5

Public usd-docker?

Hi

I'm hitting issues in the 3 ways I tried to build (I'm a cmake/docker beginner so maybe other beginners will stumble across this too)

1. Docker
   Do you intend to release the docker-usd repo https://github.com/AnimalLogic/docker-usd? At the moment I am attempting with mottosso/maya/ from dockerhub by changing the FROM in Dockerfile_centos7#L4 but not getting far (cmake: command not found)

2. build_alusdmaya.sh
   Errors early whether in docker or standalone because TMP_DIR is not defined so raises mkdir: missing operand

3. build_lib.sh
   I'm just learning cmake, so probably my build string is silly. I needed to add in -DUSD_CONFIG_FILE='/usr/local/USD/pxrConfig.cmake to build_lib.sh, but still haven't been able to get past the errors

cmake -Wno-dev \
      -DCMAKE_INSTALL_PREFIX='/usr/local/AL_USDMaya' \
      -DCMAKE_MODULE_PATH='/usr/local/USD/cmake;/home/lharris/git/AL_USDMaya/cmake/modules;/home/lharris/git/USD/cmake/modules' \
      -DCMAKE_BUILD_TYPE=RelWithDebInfo \
      -DBOOST_ROOT='/usr/local/USD/build/boost' \
      -DMAYA_LOCATION='/usr/autodesk/maya' \
      -DOPENEXR_LOCATION='/usr/local/USD/build/OpenEXR'\
      -DOPENGL_gl_LIBRARY='/usr/lib64/libglfw.so'\
      -DGLEW_LOCATION='/usr/local/USD/lib64/libGLEW.a'\
      -DUSD_CONFIG_FILE='/usr/local/USD/pxrConfig.cmake'\
      ..


-- Found the following Boost libraries:
--   python
CMake Error at CMakeLists.txt:87 (add_subdirectory):
  add_subdirectory given source "lib" which is not an existing directory.


CMake Error at CMakeLists.txt:88 (add_subdirectory):
  add_subdirectory given source "plugin" which is not an existing directory.


-- Building AL_USDMayaSchemas
CMake Error at CMakeLists.txt:96 (add_subdirectory):
  add_subdirectory given source "schemas" which is not an existing directory.

StageCache.h: Extend to show correspondence with Proxy Shape

If I have more than one proxy Shape, I've got no way of knowing which stage in the stage cache relates to which proxy shape

Update for Usd v0.8.1

Very little appears to be affected by the API changes to Usd v0.8.1. I believe these are the required changes: Update build settings to accommodate the optional use of python. Remove calls to UsdStage::Close(). Change one test example's call from UsdRelationship::AppendTarget to UsdRelationship::AddTarget.

Proxy shape does not import animated transforms if animation has single key.

If you try to create proxy shape with usd like this:

def Xform grp {
        float3 xformOp:translate.timeSamples = {
            1: (5, 5, 5),
        }
}

it will not read any values for translate attribute. Same is with any xformOp with single key.

TransformationMatrix::updateToTime tries to be clever and update animation only if there is more than one sample on xformOp. Initial values are read in TransformationMatrix::initialiseToPrim. When initialiseToPrim is called, the m_time is not set and values are read with UsdTimeCode::Default().
And when UsdAttriubute::Get gets default timecode - it ignores timeSamples fields and fails to get any values.

This can be solved by: initialising TransformationMatrix::m_time to some sane value which is not UsdTimeCode::Default(), special casing single sample values, or treating single sample values as animated.

Usd files like that are created by pxrUsd exporter.

Colour Export Problems

This is probably a devtask.
Bugs 2 and 3 below should definitely be fixed - the others are maybe part of a bigger overhaul of what this export stuff actually does..

1. "AnimalSchema" export - do we still need it? If so work out how to keep the AL (glimpse) stuff out of opensource... and add flags for everything else eg indexed subd stuff, colour (see below)

2. file export ignoring some or all flags when run from command e.g

AL_usdmaya_ExportCommand -f "/scratch/dev/AL_USDMaya/src/samples/colours/faceColours.usda" -useAnimalSchema 0;

uses the animal schema (so ignores the flag)

file -force -options "Dynamic_Attributes=1;Meshes=1;Nurbs_Curves=1;Duplicate_Instances=1;Use_Animal_Schema=0;Merge_Transforms=1;Animation=1;Use_Timeline_Range=1;Frame_Min=1;Frame_Max=1;Filter_Sample=0;" -typ "AL usdmaya export" -es "/var/tmp/colourSet3.usda";

whereas....... does the right thing..

3. with file exporter, "colourSet3_AL.usda" becomes "colourSet3_AL.usda.*.usda"

4. Non Use_Animal_Schema mode seems to export ONLY faceVarying? What should it be doing? I think - writing whatever the maya data says (i.e any of F,V,FV)

5. AL_Mode seems to export Face or Vert (not sure what criteria it uses?) again should be able to handle all 3. So what are we using the AL_mode for anyway?

see AL_USDMaya/src/samples/colours/faceColours.ma

crash if you try and move a locked prim

While testing some of the various prim attributes defined in Metadata.h that can customize created maya nodes, I was a little too harshly punished for trying to move a locked prim.

Reproduction steps

• Load a proxy shape with stage that has a prim defined like:

    def Xform "locked" (
        al_usdmaya_lock = "transform"
    )
    {
        def Sphere "ball"
        {
        }
    }

• select it
• try to move it
• crashes with:

FATAL ERROR: Used null prim
in Usd_IssueFatalPrimAccessError at line 224 of /mnt/Samsung/luma/rez-build/usd/0.8.2.luma03/src/pxr/usd/lib/usd/primData.cpp

Building on Windows

Hello!

What would be the simplest way to compile the plugin for Windows (assuming that I am a CMake nOOb)?

Thanks

Calling proxy shape select does not highlight the selected transform properly

When selecting a transform in the outliner, each of the parent transforms should have a dim blue background, and the last transform should have a brighter blue background. However, they all have the same background.

This happens, because the selections are pushed back to the MSelectionList via MObjects instead of MDagPaths. I'm not sure if this is an undocumented behavior or a bug, or it's just not stated in the docs.

Here is a quick patch to solve the issue. The other option is to change the interfaces to pass around MDagPaths instead of MObjects. That could be a cleaner (since we work with transforms anyway), but passing around an MDagPath is probably heavier, so the occasional conversion could end up cheaper.

diff --git a/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp b/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp
index 4503116..302c90a 100644
--- a/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp
+++ b/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp
@@ -26,6 +26,14 @@
 #include <set>
 #include <algorithm>
 
+namespace {
+  auto _addObjToSelectionList = [](MSelectionList& list, const MObject& object) {
+    MFnDagNode dgNode(object);
+    MDagPath dg; dgNode.getPath(dg);
+    list.add(dg, MObject::kNullObj, true);
+  };
+}
+
 // printf debugging
 #if 0 || AL_ENABLE_TRACE
 # define Trace(X) std::cout << X << std::endl;
@@ -989,7 +997,7 @@ bool ProxyShape::doSelect(SelectionUndoHelper& helper)
         MString pathName;
         MObject object = makeUsdTransformChain_internal(prim, helper.m_modifier1, ProxyShape::kSelection, &helper.m_modifier2, &hasNodesToCreate, &pathName);
         newlySelectedPaths.append(pathName);
-        helper.m_newSelection.add(object, true);
+        _addObjToSelectionList(helper.m_newSelection, object);
         helper.m_insertedRefs.emplace_back(prim.GetPath(), object);
       }
 
@@ -1005,7 +1013,7 @@ bool ProxyShape::doSelect(SelectionUndoHelper& helper)
         }
         else
         {
-          helper.m_newSelection.add(object, true);
+          _addObjToSelectionList(helper.m_newSelection, object);
           m_selectedPaths.push_back(iter);
         }
       }
@@ -1049,7 +1057,7 @@ bool ProxyShape::doSelect(SelectionUndoHelper& helper)
         MString pathName;
         MObject object = makeUsdTransformChain_internal(prim, helper.m_modifier1, ProxyShape::kSelection, &helper.m_modifier2, &hasNodesToCreate, &pathName);
         newlySelectedPaths.append(pathName);
-        helper.m_newSelection.add(object, true);
+        _addObjToSelectionList(helper.m_newSelection, object);
         helper.m_insertedRefs.emplace_back(prim.GetPath(), object);
       }
     }
@@ -1179,7 +1187,7 @@ bool ProxyShape::doSelect(SelectionUndoHelper& helper)
         MString pathName;
         MObject object = makeUsdTransformChain_internal(prim, helper.m_modifier1, ProxyShape::kSelection, &helper.m_modifier2, &hasNodesToCreate, &pathName);
         newlySelectedPaths.append(pathName);
-        helper.m_newSelection.add(object, true);
+        _addObjToSelectionList(helper.m_newSelection, object);
         helper.m_insertedRefs.emplace_back(prim.GetPath(), object);
       }
       helper.m_paths = m_selectedPaths;

Layers not initialising properly on file load

This assert (and a matching one in setInternalValueInContext) is failing when loading a maya file that has Layers which deserialized (as part of Global.cpp::postFileOpen).
https://github.com/AnimalLogic/AL_USDMaya/blob/develop/lib/AL_USDMaya/AL/usdmaya/nodes/Layer.cpp#L578

This can easily be reproduced by running the supplied endToEndMaya Layout tutorial and saving the maya file, reopening the file, and doing anything that calls get/setInternalValue (e.g., looking at the node in the attribute editor, resaving the file).

The failure appears to be because Layer::setLayerAndClearAttribute is called (which sets m_handle), but m_shape has not been set (this can only be set via Layer::init).

I have what appears to be a fix, and I'm in the process of getting the CLA through legal (I am at Walt Disney Animation Studios).

Finding Maya2018 issue

Hi,

We've encountered an issue where we weren't able to build AL_USDMaya because cmake wasn't able to find Maya 2018. This was caused by FindMaya.cmake where MAYA_DEVKIT_INC_DIR can be MAYA_DEVKIT_INC_DIR-NOTFOUND but doesn't get checked.

Alex

meshTransform cannot execute twice

https://github.com/AnimalLogic/AL_USDMaya/tree/master/tutorials/meshTranslation

When working through this tutorial process, I can import the sphere, pull some verts, and save those changes to the session layer. This initial process works fine. When I try to do this a second time, where I import the mesh, move different verts, then save those changes to the session layer, the second edit is lost. The code never hits the Mesh::writeEdits logic the second time around.

I tracked it down to TranslatorContext::unloadPrim, (line 532), there is a test to ensure preTearDown is only called once.
// call pretearDown if it hasn't been called before
if(!translator->isTearingDown()) {...call preTearDown...}

This "isTearingDown" test prevents the edits from being saved the second time the mesh is edited and saved back to the session layer. I changed this in a local build to remove the if statement, and then the mesh edits save each time I import, edit, and save to the session layer. I don't know if that is a valid fix for this though.
meshTranslationEdits.py.txt

Serializing large Usd files into maya ASCII crashes maya

We probably shouldn't be storing our data like this, so that's a workflow issue on our end, but I thought I would submit an issue here.

We're generating fairly large edit layers (~10MB of text), and we're running into issues where Maya (currently Maya 2018 Update 3) is crashing when trying to save these files (in batch mode). We've tracked down the issue being the LayerManager trying set the serialized layer into one giant MString attribute. We've run into this bug in Maya in the past, so it does seem to be at its core a Maya problem, not a USDMaya problem.

TLS error when loading usdMaya plugin

Get the following error when attempting to load the usdMaya plugin if there are too many other plugins loaded.

Error: ImportError: file <SOME_PATH_TO_USDMAYA>/init.py line 16: dlopen: cannot load any more object with static TLS

Work around at the moment is to unload a bunch of other plugins until it loads.

Add ability to create, delete, or reparent translated custom plugin prims live from within maya

We have created some custom MPxNodes which read/write directly to USD via get/setInternalValue, and have defined Translators (via the translator plugin system) to automatically create them.

We would like to be able to define commands for creating these UsdPrim/nodes and adding them to an existing UsdStage/ProxyShape. Similarly, we would like to define specialized commands for reparenting or deleting existing nodes (within the same stage).

Briefly looking through the code, it seems that for the case of creating, we could do this by calling methods from ProxyShapePostLoadProcess to ensure the proper transform chains are created (and marked as required) and the necessary bookkeeping is performed. Presumably we could utilize methods used for variant switching to modify or remove existing nodes.

I am intending to begin working on this functionality very shortly, so I wanted to submit the sug here. I'm also interested in any feedback on whether or not this is a good idea/ something that could be contributed back.

maya/MTypes.h missing in 2018

Hello guys,
Just wanted to point out that this file include/maya/MTypes.h mentioned in cmake/modules/FindMaya.cmake is actually missing since Maya 2018.

PixarAnimationStudios/OpenUSD#265

thanks.

NurbsCurves not obeying schema

Hi,
As opposed to pxr's plugin the round trip of curves works with AL_USDMaya within Maya. Thanks.
However I noticed that the import/export does not seem to obey the schema/spec for NurbsCurves but instead just moves Maya's data back and forth:

https://github.com/PixarAnimationStudios/USD/blob/master/pxr/usd/lib/usdGeom/schema.usda#L1341

Any plans to adapt? The problem would become obvious once we have the curves represented in hydra.

Clean up importer concepts

Looks like there's really only one kind of main import an average user would want to do - i.e as described in https://github.com/AnimalLogic/AL_USDMaya/blob/develop/docs/importExport.md
This is the proxy shape importer i.e

AL_usdmaya_ProxyShapeImport -file "animallogo01.usd";

Should probably have a file importer for this, and remove the existing importer which looks like this (or keep it around but have it less prominent

file -import -type "AL usdmaya import"  -ignoreVersion -ra true -mergeNamespacesOnClash false -namespace "somenamespace" -options "Parent_Path=;Import_Meshes=1;Import_Curves=1;Import_Animations=1;Import_Dynamic_Attributes=1;Use_Scene_Assembly=0;"  -pr "someshot.usda";

We might also want to update the USD Menu and rename the proxy shape import

USD dev branch removes UsdImagingGLHdEngine, breaks compilation

UsdImagingGL/hdEngine.h was made private as part of a refactor, see:

• PixarAnimationStudios/OpenUSD@e174a37
• PixarAnimationStudios/OpenUSD@cb88487
  and a number of other commits by @c64kernal currently on the dev branch

Currently, AL_USDMaya creates an instance of UsdImagingGLHdEngine. We should update to using UsdImagingGL

@sirpalee thanks for the report

"fatal error" when built target AL_USDMayaSchemas

Hi,

I tried to move my AL_USDMaya test to new release 0.2.3.1 but still got error on building target AL_USDMayaSchemas.Well,I couldn`t go through the endToEndMaya tutorial because there was no AL.usd module in pythonpath in release 0.2.0.2.

I want to try rigging file with USDMaya.That would be very useful for us!

error line:

/home/xukai/Git/git_origin/AL_USDMaya/schemas/AL/usd/schemas/wrapHostDrivenTransformInfo.cpp:29:39: fatal error: pxr/usd/usd/pyConversions.h: No such file or directory
 #include "pxr/usd/usd/pyConversions.h"
                                       ^
compilation terminated.
/home/xukai/Git/git_origin/AL_USDMaya/schemas/AL/usd/schemas/wrapMayaReference.cpp:29:39: fatal error: pxr/usd/usd/pyConversions.h: No such file or directory
 #include "pxr/usd/usd/pyConversions.h"
                                       ^
compilation terminated.

build log:

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /opt/rh/devtoolset-2/root/usr/bin/gcc
-- Check for working C compiler: /opt/rh/devtoolset-2/root/usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/rh/devtoolset-2/root/usr/bin/g++
-- Check for working CXX compiler: /opt/rh/devtoolset-2/root/usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /opt/rh/python27/root/usr/bin/python2.7 (found version "2.7.8") 
-- Found Maya: /mnt/usr/autodesk/maya2017update3/bin/maya (found version "201740") 
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   python
-- Building AL_USDMayaSchemas
-- Found GTest: /home/xukai/Git/build_repo/googletest/install/lib/libgtest.so  
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Building AL_USDMayaTranslators
CMake Warning (dev) at translators/CMakeLists.txt:20 (get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target
  "AL_USDMayaTranslators".  Use the target name directly with
  add_custom_command, or use the generator expression $<TARGET_FILE>, as
  appropriate.

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    GLEW_LOCATION
    OPENEXR_LOCATION
    OPENGL_gl_LIBRARY


-- Build files have been written to: /home/xukai/Git/build_repo/alum_v0231

KT

error: invalid initialization of reference of type ‘const SdfPathVector& {aka const std::vector<pxrInternal_v0_8__pxrReserved__::SdfPath>&}’

I got these error when running "make",
[ 18%] Building CXX object lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/nodes/ProxyShape.cpp.o
/myshare/AL_USDMaya-master/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.cpp: In member function ‘void AL::usdmaya::nodes::ProxyShape::onObjectsChanged(const pxrInternal_v0_8__pxrReserved__::UsdNotice::ObjectsChanged&, const UsdStageWeakPtr&)’:
/myshare/AL_USDMaya-master/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.cpp:1059:64: error: invalid initialization of reference of type ‘const SdfPathVector& {aka const std::vector<pxrInternal_v0_8__pxrReserved__::SdfPath>&}’ from expression of type ‘pxrInternal_v0_8__pxrReserved__::UsdNotice::ObjectsChanged::PathRange’
const SdfPathVector& resyncedPaths = notice.GetResyncedPaths();
^
/myshare/AL_USDMaya-master/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.cpp:1067:78: error: invalid initialization of reference of type ‘const SdfPathVector& {aka const std::vector<pxrInternal_v0_8__pxrReserved__::SdfPath>&}’ from expression of type ‘pxrInternal_v0_8__pxrReserved__::UsdNotice::ObjectsChanged::PathRange’
const SdfPathVector& changedInfoOnlyPaths = notice.GetChangedInfoOnlyPaths();
^
make[2]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/AL/usdmaya/nodes/ProxyShape.cpp.o] Error 1
make[1]: *** [lib/AL_USDMaya/CMakeFiles/AL_USDMaya.dir/all] Error 2
make: *** [all] Error 2

Selecting the same prim twice and clearing the selection crashes AL_USDMaya

The selected prims can stack up in helper.m_paths, then their reference counts are going below zero.

A quick workaround for this problem is to avoid storing the same path twice, but in the long term a second look at the internal reference counting, and avoiding crashing Maya on invalid states is a better option.

diff --git a/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp b/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp
index 4503116..6f8465e 100644
--- a/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp
+++ b/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShapeSelection.cpp
@@ -1040,7 +1040,15 @@ bool ProxyShape::doSelect(SelectionUndoHelper& helper)
         }
       }
 
-      helper.m_paths.insert(helper.m_paths.end(), helper.m_previousPaths.begin(), helper.m_previousPaths.end());
+      const auto newSize = helper.m_paths.size() + helper.m_previousPaths.size();
+      if (helper.m_paths.capacity() < newSize) {
+        helper.m_paths.reserve(newSize);
+      }
+      for (const auto& path : helper.m_previousPaths) {
+        if (std::find(helper.m_paths.begin(), helper.m_paths.end(), path) == helper.m_paths.end()) {
+          helper.m_paths.push_back(path);
+        }
+      }
 
       uint32_t hasNodesToCreate = 0;
       for(auto prim : prims)

Building in Centos7 and ‘UsdSchemaType’ does not name a type

Greetings,
First time posting in this forum.

I am trying to build AL_USDMaya with Maya2018sp4, Centos7 and CMake.
Everything seems to be going well, but at 85% of the build, I get a type definition error:

--start--
In file included from AL_USDMaya-master/schemas/AL/usd/schemas/ModelAPI.cpp:24:0:
AL_USDMaya-master/schemas/AL/usd/schemas/./ModelAPI.h:67:18: error: ‘UsdSchemaType’ does not name a type
static const UsdSchemaType schemaType = UsdSchemaType::NonAppliedAPI;
^
AL_USDMaya-master/schemas/AL/usd/schemas/./ModelAPI.h:116:13: error: ‘UsdSchemaType’ does not name a type
virtual UsdSchemaType _GetSchemaType() const;
^
AL_USDMaya-master/schemas/AL/usd/schemas/ModelAPI.cpp:65:1: error: ‘UsdSchemaType’ does not name a type
UsdSchemaType AL_usd_ModelAPI::_GetSchemaType() const {
^
make[2]: *** [schemas/AL/usd/schemas/CMakeFiles/AL_USDMayaSchemas.dir/ModelAPI.cpp.o] Error 1
make[1]: *** [schemas/AL/usd/schemas/CMakeFiles/AL_USDMayaSchemas.dir/all] Error 2
---stop---

I could not find anybody else with this error... Which tells me the problem is not the code but maybe my environment. Any idea how to fix it?

Manually selecting the parent of an already selected transform is causing a maya error

How to reproduce the issue:

• Load up an usd file into a proxy with several levels of prims.
• Use the proxy shape select to select one of the prims in the deeper levels.
• Open the outliner and click on one of its parents.

Explanation.
This whole issue starts from the OnSelectionChanged callback. Whenever the user clicks on the outliner, the second branch is executed in ProxyShape::onSelectionChanged (i.e., selectionMode is zero). This ends up calling AL_usdmaya_ProxyShapeSelect, and passes the prims that are not in the current selection list as parameters. Since the active selection list is already updated to the new one, it contains one of the parent prims, so the previously selected prim is about to be removed.

This jumps through a couple of functions and ends up in ProxyShape::removeUsdTransformChain_internal.

Here, the prim passed to the command is getting deleted, and all of its parent prims. However, this deletes the prim that was just selected. And Maya throws an error.

My initial pass at the problem was not to delete objects that are in the current selection list. (pseudocode below)

MSelectionList sl;
MGlobal::getActiveSelectionList(sl);
...
if(it->second.checkRef(reason))
{
  MObject object = it->second.m_node;
  MFnDagNode dgNode(object);
  MDagPath dg;
  dgNode.getPath(dg);
  if (sl.hasItem(dg)) { return; }
  ...

However, this approach does not take branches in the hierarchy account. Ie, the usd file looks something like this

- A
  - B
    - C
    - D

We have both C and D selected, and the user deselects C in the UI. That'll trigger deletion of C, and because none of its parent transforms is selected, all of them are going to be selected.

While the snippet above added to the code helps the first time a parent is selected, the second time it fails too. (none of the transforms are removed, and the stuck around) That happens, because proxy->selectedPaths is going to be empty, and the selection command exits early.

I tried to force reselection of the nodes that are part of the active selection list in the onSelectionChanged callback to ensure they still exist / / maintained properly in the internal selection lists, but that created other problems.

So far it looks like this issue is a general problem of how the selections are tracked. Unless I missed something very trivial in other parts of the pipe.

Any feedback would be greatly appreciated.

Exported Geometry is missing a valid Extent attribute

USD exported from Maya with AL_usdmaya_ExportCommand are missing a valid Extent attribute (which should also be animated when exporting animation).

Handle importing files with ProxyShapes

Does it make sense to disable executing the post load process when importing in files? I.e., change https://github.com/AnimalLogic/AL_USDMaya/blob/master/lib/AL_USDMaya/AL/usdmaya/nodes/ProxyShape.cpp#L1099

to
if(m_stage && !MFileIO::isOpeningFile() && !MFileIO::isImportingFile() )

Unit tests failing

Heads up about unit tests failing on HEAD

$ make test
Running tests...
Test project /mnt/scratch/nyue/projects/AL_USDMaya/build
Start 1: AL_MayaUtilsTests
1/4 Test #1: AL_MayaUtilsTests ................ Passed 52.19 sec
Start 2: TestAL_USDMaya
2/4 Test #2: TestAL_USDMaya ................... Passed 21.25 sec
Start 3: TestAdditionalSchemas
3/4 Test #3: TestAdditionalSchemas ............***Failed 0.02 sec
Start 4: TestAdditionalTranslators
4/4 Test #4: TestAdditionalTranslators ........***Failed 6.87 sec

50% tests passed, 2 tests failed out of 4

Total Test time (real) = 80.35 sec

The following tests FAILED:
3 - TestAdditionalSchemas (Failed)
4 - TestAdditionalTranslators (Failed)
Errors while running CTest
make: *** [test] Error 8