Skip to content

Version handles calculated based on context handles#254

Open
splidje wants to merge 4 commits into
ynput:developfrom
splidje:version_handles_based_on_context
Open

Version handles calculated based on context handles#254
splidje wants to merge 4 commits into
ynput:developfrom
splidje:version_handles_based_on_context

Conversation

@splidje

@splidje splidje commented May 11, 2026

Copy link
Copy Markdown
Contributor

Changelog Description

Version handles calculated based on context handles. Handles set for plate product type as well as render.

…n context handles. Handle set for plate product type as well as render.
@BigRoy BigRoy requested review from jakubjezek001 and rdelillo May 11, 2026 14:13
@BigRoy BigRoy added type: enhancement Improvement of existing functionality or minor addition community Issues and PRs coming from the community members labels May 11, 2026
handle_end = instance.context.data["handleEnd"]
first_frame, last_frame = self._get_frame_range_data(instance)
handle_start = max(0, root_first_frame + context_handle_start - first_frame)
handle_end = max(0, last_frame - (root_last_frame - context_handle_end))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand where root_first_frame and context_handle_start come from.
Also do you mind to detail a bit more on why you need this new logic replacing instance.context_data please ?

…irst/last_frame and context_handle_start/end
@splidje

splidje commented Jun 5, 2026

Copy link
Copy Markdown
Contributor Author

I've now realised this is kind of utterly flawed!

The only thing I really need to hit - based on how the load currently works - is making sure the version start handle is the same as the shot start handle, as the load logic takes the timewarp data to be starting from script start + version start handle... then the algorithm just runs through the list one by one irrespective of any end handles.

It kind of feels like it might make sense to set the version end handle in some kind of graceful way. i.e. set it to a number which consumes all the frames at the end of the version's frame range which end up falling outside of the shot's frame range (sans handles) having applied the timewarp.

Further to that, it feels that the same could be done with the version's start handle (but currently because of the load logic, it must be the same as the shot's start handle).

Feels like the version's start/end handle should be based on which frames at the beginning and the end don't make it inside the shot's frame range after applying the timewarp.

@rdelillo

rdelillo commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

@splidje based on your last comment ? should this PR still be reviewed ?
I'm wondering if we shouldn't create an issue for your use-case and discuss its implementation there first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community Issues and PRs coming from the community members type: enhancement Improvement of existing functionality or minor addition

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants