I’m finding that using the offset works a little strange. I have Sequence of frames 0-500 the artist shot starts on frame 300. I would think that offsetting the frames to 300 would make the sequence start at frame 300, However I need to set the frames to -300 to get the right range. Also when rendering the frame locally it renders correctly however when I send the job to the farm I get the below errors. Any ideas.
[sentinel075; Wed Aug 24 08:36:14 2011; Frame 1473]
8/24/2011 8:36:15 AM; Error rendering frame 1473: An appropriate frame to offset for time -300 could not be found in the sequence.
[sentinel075; Wed Aug 24 08:34:17 2011; Frame 1473]
8/24/2011 8:34:18 AM; Error rendering frame 1473: An appropriate frame to offset for time -300 could not be found in the sequence.
As you have discovered, the offset is added to the file frame numbers. If your file sequence has frames 0 to 500 and the offset is 300, it’s as if the file sequence has frames 300-800. If the offset is -300, it’s as if the file sequence has frames frames -300 to 200.
Both perspectives seem reasonable, but the current behavior is pretty entrenched in our plugins.
I assume this is the same sequence as you described above, with frames 0-500?
Would it be possible for you to please send us a copy of your .max file, either through these forums or through our ticket system?
We recognize that this is a bit backwards, but it was done this way back in 2006 in Krakatoa and stuck around. The logic is:
If you are on frame 0 and you have a sequence starting on frame 300, you enter 300 and that frame plays on frame 0.
Basically do whatever you feel is natural, but always add the opposite sign
As for the error you see, this is a known (to me) defect we should address as soon as we move away from the scripted UI of XMesh Loader.
To solve the issue, you must make sure the Range is set to the first and last existing frames, e.g. 0 to 500, and the Use Range checkbox is checked (it is by default). You can press the Range button to set the values automagically. It has bitten us several times in production, but could not be fixed before for code-related reasons. What I THINK is happening is that the scene is loaded on frame 0 (all MAX files load on 0 first, then change time). This causes the MAXScript plugin to update (without need) and it requests frame 0 which causes the time to be passed as -300. But this is outside the valid range, so it fails.
I hope that moving away from the scripted plugin to a real C++ ParamBlock will take care of this problem.
Ok so instead of offsetting Playback of the Sequences Frame numbers your offsetting the Current Frame Time. Yeah its a little confusing just because the playback curve is using the sequence number then you’re switching to offsetting time in the frame offset. I can live with it now that I know, just use to how fume and tp caches offset. It also get a little confusing when the range is offset from 0. I’ll upload a file to the ticket system for the errors
