Hi everyone,

After reviewing the changes made in the last update, I've revised one small change I made to the start and end frames for an SD file. This issue has been deceptively simple:

1) Houdini's “Time Zero” is normally at Frame #1, Real Flow's “Time Zero” is at Frame #0,

2) Negative frame numbers are legal in Houdini, not so in Real Flow.

It seemed natural to make everything conform to starting at “T ZERO”, but that's not the case, thus the revised rules for frame ranges. So, starting frames equal to or greater than zero are legal but not negative starting frames.

However, I've uncovered some strange behaviors in the way Real Flow handles SD files that start on a frame other than zero. After exporting an SD file that has a start frame greater than one, Real Flow still treats that starting frame as frame zero. As a quick example, I created two simple SD files containing a box that is spinning about the X axis. The file test_box_1-360.sd start at from 0, ends at frame 360, the file test_box_100-360.sd starts at frame 100, ends at 360. When played back in Real Flow the file test_box_100-360.sd continues it's rotation at frame 0, and ends the rotation at frame 260 (360 - 100). I'll be talking with Next Limit ASAP to find out how to address this. You can get the SD files at: http://www.digitalcinemaarts.com/dev/debug/sd_anim_test_objects.tar.gz [digitalcinemaarts.com]

The same changes to the frame ranges will be in the Real Flow ROP soon once other changes are in place to conform to RF3 (same is true of the RF Import SOP).

They are available at:
http://www.digitalcinemaarts.com/dev/real_flow/download.html [digitalcinemaarts.com]


From the change log:

January 2, 2005: v0.98.4 -
SOP_RF_Export:
1) Changed the zero based SD file export rule to accommodate start frames
greater than 0 (start frames can not be less than zero).
2) Added HTML help pages (still needs more editing).



–Mark