-
Notifications
You must be signed in to change notification settings - Fork 129
Conversation
45c7fe6
to
fb45010
Compare
…t-effects' into feature/1377-hiero-publish-with-retiming
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.
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 |
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.
Viz comment above
- also fix duration to be untouched by retimes
# calculate speed | ||
speed_in = (node["lookup"].getValueAt(timeline_in) / ( | ||
float(timeline_in) * .01)) * .01 | ||
speed_out = (node["lookup"].getValueAt(timeline_out) / ( |
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.
line too long (80 > 79 characters)
|
||
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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): |
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.
expected 2 blank lines, found 1
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!