-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switching Representations with different loaders #377
Comments
This is an amazingly interesting case, and a big plus if we can figure it out in a stable way. Unfortunately this isn't trivial. When "switching" from a referenced Alembic GEO to a gpuCache it means that the Alembic GEO reference should actually be removed from the scene, right? Or what other special logic would you apply? Whenever you remove the referenced Alembic GEO then any local changes to that geometry would be gone, any shader assignments, any tweaks or changes in positioning. As such, switching back and forth makes no sense. What was your idea on tackling that? Currently with "switch" it's all done on the Loader itself, as such, any data that needs to persist on the switch can be tracked there. It's up to the Loader (if not a Maya reference, as that would store reference edits even if failed anyway) to potentially store that data somewhere if it needs to remain after switching back and forth. However, if you do the same between different Loaders - then every loader would need to take into account any other loader and what kind of data it might want to preserve?) In your case, if the removal of data is alright, it's a matter of calling "remove" on the existing instances and "load" on the new ones. Yes? And yes, the other problem is knowing what Loader to switch to if a specific representation and subset supports multiple loaders. (If we are allowed to "switch Loader") |
Correct. that's the only way I can think of at this point.
we're aware of that and don't really have a good solution at this point to be honest. However we would keep the transform of the top group at the very least which is trivial. At this point I'd approach it with a warning before the actual switching notifying the user that all his changes apart from the position will be lost.
I thought a good solution might be adding a a 4th dropdown that lists available loaders, so the user can choose |
actually I had a though. Maybe we could store the changes that can be serialized (like ref edits) in an attribute on the container. So if artist switches back to original loader at later time we could reapply them. For instance. I have model loaded using reference loader. When switching to gpu cache we take all ref edits and serialize them into json format and save to attribute.\ on container
when switching back to reference, we try to find |
Just to throw this in there, could a loader call another loader? That way, maybe there could be a "loader container" of sorts. class LoaderA(...):
...
class LoaderB(...):
...
class LoaderContainer(...):
def load(...):
if some_expression:
return api.find_loader("LoaderA").load(...) Maybe wouldn't even have to be a "container", just one loader calling another.
Could it default to index[0], and bring up a popup/menu to select if there is any question? |
I think I could share something on this. :) My implementation for switching proxy (GPU cache), take my model loader for example, was done by extracting not only model gpu_files = ["modelDefault/v001/gpu.abc"]
output_path = "modelDefault/v001/gpu.ma"
MayaAscii_template = """//Maya ASCII scene
requires maya "2016";
requires -nodeType "gpuCache" "gpuCache" "1.0";
"""
gpu_node_template = """
$cachefile = `file -q -loc "{filePath}"`; // Resolve relative path
createNode transform -n "{nodeName}";
createNode gpuCache -n "{nodeName}Shape" -p "{nodeName}";
setAttr ".cfn" -type "string" $cachefile;
"""
gpu_script = ""
for gpu_path, node_name in gpu_files:
gpu_path = gpu_path.replace("\\", "/")
gpu_script += gpu_node_template.format(nodeName=node_name,
filePath=gpu_path)
with open(output_path, "w") as maya_file:
maya_file.write(MayaAscii_template + gpu_script) And then I could swap the reference between model file and the gpu cache with the same model loader. Not sure about other renderer specific like Arnold stand-in or VRay proxy, haven't gone that far, yet. But I think as long as we could wrap everything into a Maya referenceable format, should be good enough for this issue, right ? |
Had a deeper look at this since I was also trying to implement cross loader switch for switching in between Arnold Stand-In and model or rig. I imaging the ultimate goal would be something like this :
An XGen hair subset for example, can be switched to hair card model, gpu cache, or other representation of asset Hat. We could switch freely as long as the chosen loader has been implemnted to be able to process the subset which was not loaded by itself. Implementation proposalAssume that we all using scene file referencing to load those subset. Asset Switcher GUIThe switcher GUI must aware of all Loaders that matched with the selected representation. So for this issue:
I propose to implement like this to reslove:
|
So when you load StandIn, it is already wrapped in maya file so you can reference it? Our ass loader create a new standin node and set's its paths to correct values. Functionally I quite like the changes. |
Yes, the
Thanks ! Those GUI stuff was built upon #376 (obviously), hope it gets merged soon. |
Just to double check. So it's up to the new Loader to return whether the switch can be done from a container with a different loader. What is good about this one is that it does not hardcode the idea of References for maya. It allows the studio configuration to "store" ref edits temporarily on a custom attribute in the container like: I'm a bit afraid of the conplexity and managing the multiple directions. With this I'd love to see an example that switches consistently between a ASS standin (non-referenced) and a Maya reference. I think it's interesting to hear that you are wrapping the ASS in maya references. Doesn't that takeaway quite a large bit of the loading speed of the scene? As |
Yes, but still wondering if there are any better name than
Perhaps (in my imaging) we could use that
Here's a long GIF I tested on a animated rig from Mixamo. Not sure why when I switching back to Rig from Ass, the rig require to refresh to pick up animation. :/
Haven't think about that before actually, not often using stand-in here (we just begin to adopt Arnold). But that's a good point, hmmm..., maybe that depends on how often you want to switch things... need to think more on this. |
It does...When we have big scenes that are mostly built up with ass files, the difference trying to recreate this by hand noticeable indeed. I think the same will be true for vray proxies. |
For this part, how about just unload that reference, and using a callback like this: from maya.api import OpenMaya as om # API 2.0
def before_load_reference(reference_node,
referenced_file,
clientData=None):
"""Check if the reference is okay to be reloaded"""
if not cmds.objExists("DO_NOT_LOAD"):
return True
dep_fn = om.MFnDependencyNode()
fn_node = dep_fn.setObject(reference_node)
ref_node = fn_node.name()
if ref_node in (cmds.sets("DO_NOT_LOAD", query=True) or []):
# Or any other condition
return False
return True
# Register the callback
om.MSceneMessage.addCheckReferenceCallback(
om.MSceneMessage.kBeforeLoadReferenceCheck,
before_load_reference
) With this callback, the reference will get reloaded only on certain condition, e.g., not being a member of |
Adding more input, not having a result, yet. Using asset container node to hold import-only subsetOn the part that switching imported subset to referenceable type or another import-only subset, currently experimenting on using Maya asset container node to hold the import-only subset. By adding import-only subset nodes into a DAG type asset container node, it could provide a limited editing interface via exposing bonded attributes only, e.g., Arnold stand-in node's frame range attributes and hide the rest. With that limitation, we can focus only on the attributes that we exposed while switching. And because we could use custom attribute name to bind the subset node's attribute like : cmds.container("Hulk_01_AST", edit=True, publishAndBind=["node.anyAttr", "abs_name"]) Then we would able to implement a way to remap those attribute's connections and values to the subset that is being switched into scene, by using published attribute name After the connections and values' remapping and preserving is done, we could safely delete nodes in that asset container, since those were the only variations that artist could apply to. And hide it from outliner if it's being switched to a reference. |
Problem
Currently we seem to be only supporting switching representations if they are all supported by the same loader. This effectively prevent using this for switching proxy geometries for render time proxies (geometry -> arnold standin for instance)
Solution
From my initial testing it seems that it would be enough to get the loader from the new representation being loaded, rather than container and all should be good. Now obviously if there are more loaders per representation, then there's the question which one to use.
Additional problem is that I have artists asking on a daily basis for being able to keep the representation but change the loader. For instance changing referenced alembic to gpu cache and back. This is very useful for huge scenes.
The text was updated successfully, but these errors were encountered: