ynput
Maya: Collect instances preserve handles even if frameStart + frameEnd matches context
Brief description
This removes the fallback to context handleStart and handleEnd if instance frameStart and frameEnd matches context.
Description
Now it will always inherit handleStart and handleEnd from the context (current working asset's handles in project manager) unless the instance explicitly sets values for the handles.
This means that for a pointcache instance it will never match the context because the pointcache instance has its own handleStart and handleEnd attribute on the publish instance. (This is true for all time based instances in Maya that use the collect_animation_data which I think is all time based instances in Maya!) We might be off improving that more so that by default on creating an instance it takes the handles and its values from the current working context.
If we really want to keep some of the old behavior we could add an extra attribute on publish instances that toggles the use of the handleStart/handleEnd from the instance, like useCustomHandles or handlesFromInstance or something like which can e.g. have a default value in settings so studios can decide whether it's more up to the artists or not.
Additional info
Without this change the artist could never set custom start/end handles if the start and end frame would match that of the asset in the project manager.
Testing notes:
- Check whether publish frames for instances now work as expected.
I remember discussing this at quite some length with a client at the time when this was implemented. The general issue at hand was, how to differentiate between the cases, where the range should be validated against the DB, so we don't produce BS data, vs allowing the artist to bypass it somehow reasonably per instance.
The intended workflow was that if the artist is customizing the frame range, it is best to simply set different start and end, whether we have handles or not, if they want to override.
Truth be told, the only reason this is there is the fact that the publishing GUI is not very friendly towards choosing to validate one instance, but skip another. This would be trivial to change and make it proper in the new published GUI, unfortunately, we're failing to find the time to start converting maya families to it.
After quite some time in production, I agree that it's probably more intuitive to allow the override anytime, but then the validation of frame range is completely useless
I agree that it's probably more intuitive to allow the override anytime, but then the validation of frame range is completely useless
Actually - not necessarily. If that plug-in is optional then it would validate by default unless the Artist would explicitly say "ignore this check for this instance". It's unfortunate however that once disabled for an instance it's not 'remembered' for future runs by default like "Hey, last time you had this ticked off manually. Would you like to preserve it?"
Kind of like "Validate Containers". You can publish with outdated content in the scene but most likely you don't want to in most cases.
Truth be told, the only reason this is there is the fact that the publishing GUI is not very friendly towards choosing to validate one instance, but skip another. This would be trivial to change and make it proper in the new published GUI, unfortunately, we're failing to find the time to start converting maya families to it.
Yes - that would help even more.
If that plug-in is optional then it would validate by default unless the Artist would explicitly say "ignore this check for this instance"
That's exactly the issue. You can only ignore it per full publish. not per instance. But I don't think that's actually a large problem.
Just a note that we haven't forgotten about this at all, just considering if it can nastily influence anything in production.
Before merging this PR note that Collect Render should actually be fixed too since it does the same thing here
Still - any update on how we'd want to merge this PR?