-
Notifications
You must be signed in to change notification settings - Fork 128
Maya: Implement iter_visible_nodes_in_range
for extracting Alembics
#3100
Conversation
- Functionality added in Maya 2018 - Usage without `MDGContext.makeCurrent()` is deprecated since Maya 2022
Previously an empty string could be yielded for e.g. `"|cube"` splitting to `["", "cube"]`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is some issue with sets containing hidden geo
// Error: pyblish.plugin : Traceback (most recent call last):
File "D:\REPO\OpenPype\.venv\lib\site-packages\pyblish\plugin.py", line 522, in __explicit_process
runner(*args)
File "D:\REPO\OpenPype\openpype\hosts\maya\plugins\publish\extract_pointcache.py", line 93, in process
File "D:\REPO\OpenPype\openpype\hosts\maya\api\lib.py", line 1241, in extract_alembic
cmds.AbcExport(j=job_str, verbose=verbose)
File "D:\REPO\OpenPype\openpype\hosts\maya\plugins\publish\extract_pointcache.py", line 2, in AbcExport
RuntimeError: -selection specified but nothing is actively selected.
Traceback (most recent call last):
File "D:\REPO\OpenPype\.venv\lib\site-packages\pyblish\plugin.py", line 522, in __explicit_process
runner(*args)
File "<string>", line 93, in process
File "D:\REPO\OpenPype\openpype\hosts\maya\api\lib.py", line 1241, in extract_alembic
cmds.AbcExport(j=job_str, verbose=verbose)
File "<string>", line 2, in AbcExport
RuntimeError: -selection specified but nothing is actively selected.
You're trying to export a pointcache with NO geometry whatsoever due to it always being hidden and thus being excluded. :) I was actually expecting that to happen! I instead assumed user would use this for pointcaches of multiple pieces of geometry where at least one piece of geometry or transform is visible during the timeline. Thus this should get validated for both scenarios, however this visibility check is relatively slow for large scenes so it could potentially mean the Validator would be slow. Plus, we'd have the plug-in likely "cache" the visibility states so the Extractor doesn't have to do it again but that also means a Validator is technically "collecting" information. Moving that to a Collector means that technically the collecting stage can be slow. OR We'd just log a warning in the Extractor and do nothing instead? Thoughts? Anyway, thanks - will look into this edge case. |
You are right, if I used only one pointCache instance for all geo it would pass. |
I think, this might be the right approach in this situation. Probably more intuitive to export nothing if everything is hidden rather than crashing. |
@BigRoy just a ping that if we do the last tweak mention in you comment, this will be good to merge |
@mkolar I've just pushed the change to the extractors so that the message is logged and the extractor continues. However, the integrator will currently still error on any instances that do not produce any files whatsoever. How would you like me to proceed? |
That's somewhat tricky. We should either figure this out in the validator, or this particular instance should never get to integration stage. No files, nothing to integrate. It could get really confusing for the artist though, so I think validation should flag this, if we're able to catch it. If not, then the extractor, should figure out it produced no files, hence not create a representation and the integrator can then gracefully skip |
Agreed. This particular "validation" could run relatively slow - but I guess that's the side effect of this. Will add it. |
I've changed the function to an iterator to allow a much faster validation for 99% of the cases where at least a single node is detected to be visible. It's good to be aware that the validation allows any dag node to be visible. That also includes e.g. a group node which I felt makes sense to be the least restrictive and it also wouldn't fail on the extraction (which is what we were trying to solve anyway.) Should be good to test now @mkolar |
|
||
if instance.data["family"] == "animation": | ||
# Special behavior to use the nodes in out_SET | ||
nodes = instance.data["out_hierarchy"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning
It's good to be aware that this logic depends on THIS Collector plug-in.
The bug/issue is that if the instance in Maya is set to active=False
on the objectSet/instance directly that that Collector does not run. This bug is present in many more areas actually so be aware.
There are two solutions to that:
- Have the instance collector NOT collect the active state directly but instead collect as e.g.
__active
. Then have a very later Collector (CollectorOrder + 0.499
) which setsinstance.data["active"] = instance.data,pop("__active", True)
- so that up to that point all collectors do run as expected. - Use/implement something like Post collectors like
PYBLISH_QML_POST_COLLECT
see: Implementing "Post Collect" pyblish/pyblish-qml#356 - that way we can have these collectors that should always run for an active instance in the post collection step after the user toggled states. Upside to this is that collecting will be MUCH faster since many collectors could move to the post collector order.
@mkolar Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that during local publishing (artist publishing where he can toggle instance activity) we process during collection all instances no matter if they are active or not (until collector check that on it's own?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(until collector check that on it's own?).
It's any collector that appends data into an instance that would fail to do so for inactive instances. So I suspect the issue will also exist for these:
- https://github.com/pypeclub/OpenPype/blob/develop/openpype/hosts/maya/plugins/publish/collect_look.py
- https://github.com/pypeclub/OpenPype/blob/develop/openpype/hosts/maya/plugins/publish/collect_model.py
- https://github.com/pypeclub/OpenPype/blob/develop/openpype/hosts/maya/plugins/publish/collect_history.py
- https://github.com/pypeclub/OpenPype/blob/develop/openpype/hosts/maya/plugins/publish/collect_rig.py
- And more...
Basically anything running over the instance would not actually run because Collect Instances already collects directly whether the instance should be considered "active" to run over the instance for. So the issue is much more widespread than just this particular one.
I have stupid question. What does it return? I miss one word in the function name: "Get visible ... in frame range". |
It's currently been renamed to |
I would say it's more important then it's from frame range :) (Maybe |
get_visible_in_frame_range
for extracting Alembicsiter_visible_nodes_in_range
for extracting Alembics
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we merge this? |
Merging. Thank you. |
Brief description
This fixes #3085 by implementing a per frame visibility check for all dag nodes in the pointcache instance and only returning those visible nodes for exporting.
Description
The
visibleOnly
attribute already existed on Animation and Pointcache instances in Maya in the Creators but was unused previously as far as I'm aware.Additional info
Here's a TEST for just the
iter_visible_nodes_in_range
function. You can also try and publish these particular nodes in a pointcache to confirm the functionality in that regard:Testing notes: