I spend a long weekend in Bonn. Deswegen die Verspätung.
Thanks for posting the exact numbers. The screenshot of the Render Animation manager is illuminating.
Unfortunatly you got the math’s wrong. When you want to transpose measurements (like length or time) with various units (inch/cm or ticks/frames) they need to have the same absolute origin, being zero. Theoreticians say:” A ratio scale possesses a meaningful (unique and non-arbitrary) zero value”
That’s why the inch/cm ruler (displayed above) has zero at the same spot. That’s also why the frame-count starts at zero rather than 1 (although - I must admit - that doesn’t seems logical at first sight).
Since your animation starts at tick 10, all tick-numbers first have to be reduce by 10.
Since your animation must count 990 frames the total range is 0 to 989 (as you can see in the Render Animation manager )
Then the ratio frames/ticks can be calculated; 56 x 989/56 = 989. The ratio is 17,66071429 (989/56). Multiply and that’s it.
Since null is the kick-off of the frame numbers there is no need to add or subtract anything. I agree the inclusion or exclusion of zero in counting can be confusing.
If you like I can send you the Excel file I used for calculating.
As I foretold the keyframes do not coincide exactly with a frame. There is no such thing as :
except for the start and end of the animation. The condition of an object as defined by a keyframe does not necessarily occur exactly in a rendered frame.
When this is absolutely needed you can scale your current keyframes on the timeline according to the above calculated frames/ticks ratio using the BongoScaleKeyframes command. Then you get what Dave prefers: a tick per frame and a frame per tick. Depending on the scale-tick-origin that you use in the command the keyframes will be moved as follows:
Also here some rounding is implemented so the interrelationships between the keyframes will differ slightly relative to the initial setting.
I will reflect on how the timemanager set forth in Problem registering multiple sequences - SOLVED can maybe be appended with a kind of tick/frame and frame/tick calculator and a possibility to organize render various sequences. A graphical representation and interface seem interesting.
Finaly, as for the syntax of the Frame Range input: In my experience the classic printer-page syntax is operational. E.g. 1-330, 300-585, 555-990 works on my system.