Hiero: publish with retiming #1545
Conversation
![create-issue-branch[bot]](https://avatars.githubusercontent.com/in/36017?s=60&v=4){kind=small}
jakubjezek001
added
type: enhancement
jakubjezek001
force-pushed
the
feature/1377-hiero-publish-with-retiming
branch
2 times, most recently
from
45c7fe6
to
fb45010
Compare
…t-effects' into feature/1377-hiero-publish-with-retiming
There was a problem hiding this comment.
No success for me with this one. I have source clip that is 44 frames long. I use timewarp in hiero to make it 2x speed and result in 22 frame long timeline clip.
When I publish the retime seems to be published correctly and it loads into Nuke as well, however the actual frames that get published are only 1-22, so I'm missing half the required footage in the publish.
Also a question. Shouldn't we support also a simple editorial retime in here? Just setting a clip to 200% for example without applying timewarp effect. In most simple scenarios that is more likely to happen, than a timewarp.
This is implemented and should be working. It is taking the editorial retime percentage and converts it into expected framerange. Then in nuke it is creating retime node under read node automatically with expected framerange. I was testing it and was working for me. |
|
@mkolar try it now. I found a bug where speed of track item was not projected within duration. Also different speed then 1 was not switching on retime family. So I guess it should cover both of your issues |
|
Retime is working now, but I keep getting the same result where I'm missing half of the frames that should be published. I'm trying with exr sequence and only half of the frames are copied to the publish folder. Secondly we have some conflicts that need to be resolved. Aand lastly, precollector alone can't work because of undefined variable, I fixed it locally for me for testing, but needs to be committed properly. |
- also fix duration to be untouched by retimes
![hound[bot]](https://avatars.githubusercontent.com/in/3598?s=60&v=4){kind=small}
| # calculate speed | ||
| speed_in = (node["lookup"].getValueAt(timeline_in) / ( | ||
| float(timeline_in) * .01)) * .01 | ||
| speed_out = (node["lookup"].getValueAt(timeline_out) / ( |
|
|
||
| # calculate available material before retime | ||
| available_in = int(track_item.handleInLength() * speed) | ||
| available_out = int(track_item.handleOutLength() * speed) |
There was a problem hiding this comment.
local variable 'available_out' is assigned to but never used
| speed = track_item.playbackSpeed() | ||
|
|
||
| # calculate available material before retime | ||
| available_in = int(track_item.handleInLength() * speed) |
There was a problem hiding this comment.
local variable 'available_in' is assigned to but never used
| import math | ||
| from openpype.hosts.hiero.otio.hiero_export import create_otio_time_range | ||
|
|
||
| class PrecollectRetime(api.InstancePlugin): |
|
Merging with the limitations mentioned in the PR text. those need to be made into separate issue. Especially the reviewable with retime applied |
closes #1377
Next steps
!! attantion !!
This PR is follower of #1511 and should not be merged before!