Comments (8)
Filed as internal issue #137455.
from openusd.
Hi Eoin,
Good observation that starting a new Maya scene should cause all state to be flushed, including the StageCache. Does Maya have a hook we can latch onto at "New" to clear the StageCache?
You should never need to worry about the Sdf_LayerRegistry, because it only holds weak references to SdfLayers, and therefore will never keep them alive - that's what allows us to keep the registry as an internal detail.
If you have verified that the StageCache is indeed being flushed (you can set the TF_DEBUG env var to "USD_STAGE_CACHE" for diagnostics), then my suspicion is that either the PluginStaticData for the maya usd proxyShape is not being released (it holds a strong pointer to the stage), or Maya is not guaranteeing that the old nodes are fully decomissioned prior to creating any new nodes.
I don't know anything about Maya plugin object lifetime management, but I'll check with our experts.
Cheers,
--spiff
from openusd.
Hi Spiff,
the stageCache is being cleared on maya new scene/open scene/close scene events, that's working OK
Thanks for the insight into the layerRegistry behaviour - makes sense.
One of our Maya gurus has already fingered MpxData (https://knowledge.autodesk.com/search-result/caas/CloudHelp/cloudhelp/2016/ENU/Maya-SDK/cpp-ref/class-m-px-data-html.html) as a likely suspect, and it's derived type MPxGeometryData is used in https://github.com/PixarAnimationStudios/USD/blob/2eb01f5cd4c2dae4e1ef9912ca27a93083bb6ef4/third_party/maya/lib/usdMaya/stageData.h... so it sounds like the culprit might either be in PluginStaticData or stageData... I will follow up with him tomorrow, but would be great to see if anyone at Pixar has any ideas - can also talk to the Autodesk Maya peeps and see what they think.
Thanks!
Eoin
from openusd.
Hi Spiff and the rest of team USD,
did a bit more digging into this, and it looks like maybe the MPxData is not responsible after all (although not definitive)
If I run my code above that mutates the layer, then I do
from maya import cmds
cmds.file(new=True, force=True)
cmds.unloadPlugin('pxrUsd')
Then -
from pxr import Sdf
layers = Sdf.Layer.GetLoadedLayers()
for currLayer in layers:
print currLayer
we can see that it's still hanging onto the layer we originally loaded, plus it's session layer, even though the USDMaya plugin is unloaded.
What's nasty is that the session layers keep accumulating (as a new one is created for each session) on each file new.
I did put some print statements in the USDMaya plugin to see if things were being destroyed correctly - and it mostly looked like they were... but that's not definitive
Luckily, I now have a workaround, which is on file close/new event, I can run something like this (or the C++ equivalent)
layers = Sdf.Layer.GetLoadedLayers()
for l in layers:
l.Reload()
Thanks
from openusd.
Hey Eoin,
Matt Johnson found the problem - something in our maya imaging adapter was not getting reset properly and hanging onto strong pointers to the stage. Fix is IP.
--spiff
On Sep 25, 2016, at 9:54 PM, murphyeoin [email protected] wrote:
Hi Spiff and the rest of team USD,
did a bit more digging into this, and it looks like maybe the MPxData is not responsible after all (although not definitive)If I run my code above that mutates the layer, then I do
from maya import cmds
cmds.file(new=True, force=True)
cmds.unloadPlugin('pxrUsd')
Then -from pxr import Sdf
layers = Sdf.Layer.GetLoadedLayers()
for currLayer in layers:
print currLayer
we can see that it's still hanging onto the layer we originally loaded, plus it's session layer, even though the USDMaya plugin is unloaded.
What's nasty is that the session layers keep accumulating (as a new one is created for each session) on each file new.
I did put some print statements in the USDMaya plugin to see if things were being destroyed correctly - and it mostly looked like they were... but that's not definitiveLuckily, I now have a workaround, which is on file close/new event, I can run something like this (or the C++ equivalent)
layers = Sdf.Layer.GetLoadedLayers()
for l in layers:
l.Reload()
Thanks—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
from openusd.
Hi Spiff.. great! Send our thanks to Matt for figuring that one out - a few of us spent a couple of hours on it with no luck.
Thanks
Eoin
from openusd.
This issue should be fixed by commit 3482797 in the dev branch.
from openusd.
Commit has been merged into release v0.7.2, closing.
from openusd.
Related Issues (20)
- Duplicated fragment code in BasisCurves.glslfx HOT 1
- Compilation fails against MaterialX_v1_39_0 HOT 2
- Python 3.13 support? HOT 6
- Unresolved External Symbols when trying to use custom schema & general custom schema guidance HOT 2
- Build failure on latest dev due to missing OpenEXR dependency of OpenImageIO HOT 3
- Bad comment producing a syntax error in a glslfx file HOT 1
- UsdGeomMesh has no member "GetPrimvar" HOT 2
- `_CreateUsdzPackage` fails to generate a valid USDZ when the first added file is an image HOT 2
- hdf5 version in build_usd.py doesn't build with newer clang versions HOT 5
- GfQuat types are missing GfIsClose HOT 6
- Bug in Ar Resolver with nested packages HOT 1
- ARCH_HAS_GNU_STL_EXTENSIONS causes cross clang/gcc link failure. HOT 2
- Incorrect location of third-party source folder with --build option HOT 1
- error: use of deleted function ‘tbb::detail::d1::hash_compare<pxrInternal_v0_24__pxrReserved__::Usd_CrateFile::CrateFile::_FileMapping::_Impl::ZeroCopySource, std::hash<pxrInternal_v0_24__pxrReserved__::Usd_CrateFile::CrateFile::_FileMapping::_Impl::ZeroCopySource>, std::equal_to<pxrInternal_v0_24__pxrReserved__::Usd_CrateFile::CrateFile::_FileMapping::_Impl::ZeroCopySource> >::~hash_compare()’ 73 | concurrent_unordered_set() = default; HOT 2
- Lifetime issues for `type_index` keys in `TfType::GetCanonicalTypeName()` cache HOT 5
- Incorrect material tag detection for OpenPBR surface HOT 1
- UsdUtils.ExtractExternalReferences converts <udim> to 1001 in 23.11 HOT 1
- Segmentation fault processing USD+MaterialX file HOT 3
- Shadows not working on Metal with MaterialX HOT 1
- Incremental improvement requests for the USD MaterialX parser HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openusd.