animallogic / al_usdmaya Goto Github PK
View Code? Open in Web Editor NEWThis repo is no longer updated. Please see https://github.com/Autodesk/maya-usd
License: Other
This repo is no longer updated. Please see https://github.com/Autodesk/maya-usd
License: Other
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" () {}
}
}
}
}
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.
Looks like this is related to the changes here:
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
...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...
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).
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..
"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)
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..
with file exporter, "colourSet3_AL.usda" becomes "colourSet3_AL.usda.*.usda"
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)
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
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.
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.
USD exported from Maya with AL_usdmaya_ExportCommand are missing a valid Extent attribute (which should also be animated when exporting animation).
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
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.
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.
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.
def Xform "locked" (
al_usdmaya_lock = "transform"
)
{
def Sphere "ball"
{
}
}
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
When I click on a proxy mesh in the viewport maya will crash. This happens with all tried viewport modes,
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
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
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"
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 ??
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.
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
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
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).
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.
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)
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
)
build_alusdmaya.sh
Errors early whether in docker or standalone because TMP_DIR is not defined so raises mkdir: missing operand
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.
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
How to reproduce the issue:
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.
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?
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.
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)
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
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).
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?
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;
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
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
Hello!
What would be the simplest way to compile the plugin for Windows (assuming that I am a CMake nOOb)?
Thanks
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
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.
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:
We have a fix for 1. internally which will be released soon, 2 is still WIP
UsdImagingGL/hdEngine.h was made private as part of a refactor, see:
Currently, AL_USDMaya creates an instance of UsdImagingGLHdEngine. We should update to using UsdImagingGL
@sirpalee thanks for the report
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
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() )
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.
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.
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.
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.
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
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.
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
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
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.
To reproduce this:
AL_USDMaya 0.28.4
USD 0.8.5
Maya 2018 Update 3
CentOS 7.5
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.