[Bf-committers] [14385] trunk/blender/source/blender: Changed BLI_convertstringcode to replace any number of hashes with the frame number .

[Campbell Barton]

My assumption was that people weren't manually adding #'s in their
filename in the first place, since Blender does this internally.
I would not even say the previous way has bugs, it just isn't supposed
to be exposed to the user, and isnt even documented? (AFAIK)

So your right - when this is done manually the results are different,
Though I think the way it worked wasn't really that useful.

Regarding loading a non padded image sequence, it wont work in order,
if the application isnt smart about reading the int in the filename.
but the point of making this change is you can manually set the
padding to be enough for the frame range your using.

If your making image sequencer from 1-99 it could be good to only have
## in the filename, but if your making a 2hr movie. you'd want around
######

New users wont put # in filenames, and blender will act as it did
before (which screws up over 9999 frames)
if a user wants to render a longer animation - over 5-7min, they are
probably a bit more experienced, can read the tooltip and include
##### in their filenames so its ordered correctly.

On Sat, Apr 12, 2008 at 12:13 AM, GSR <gsr.b3d at infernal-iceberg.com> wrote:
> Hi,
>  ideasman42 at gmail.com (2008-04-11 at 1747.21 +0200):
>  > Before, A hash at the end of the string would be replaced by a
>  > number with 4 characters. This is still default if no #'s are in the
>  > string, so nothing has changed.
>
>  I have problems understanding those phrases. What I deduce from them
>  is (using extensions option):
>
>  * Some typed filenames in render output button, before:
>
>  foo_ -> foo_0099.ext foo_0100.ext
>  Test agrees with prediction.
>
>  foo_# -> foo_0099.ext foo_0100.ext
>  Just tested and the filenames are foo_00990099.ext
>  foo_01000100.ext. Bug. Nobody used it?
>
>  foo_#### -> ?
>  Test shows foo_###00990099.ext foo_###01000100.ext. Bug again.
>
>  foo_#_bar -> ?
>  The test gives foo_#_bar0099.ext foo_#_bar0100.ext.
>
>  foo_###_bar -> ?
>  Files are foo_###_bar0099.ext foo_###_bar0100.ext.
>
>  Conclusion is that # before is not very useful (position matters, to
>  the point of being completly useless) and has bugs.
>
>  * Same cases, after:
>
>  foo_ -> foo_0099.ext foo_0100.ext
>  Same than before.
>
>  foo_# -> foo_99.ext foo_100.ext
>  Not same than before (even assuming no bug), there is no padding
>  (there is no overflow either, luckly).
>
>  foo_#### -> foo_0099.ext foo_0100.ext
>
>  foo_#_bar -> foo_99_bar.ext foo_100_bar.ext
>  Another diff, but this time it becomes useful, frame number is written
>  where asked to. No zero padding, tho, so beware with regex and other file
>  ops, Blender included.
>
>  foo_###_bar -> foo_099_bar.ext foo_100_bar.ext
>  Zero padding can be controlled manually, numbers will expand as needed,
>  so still some caution needed when doing file ops.
>
>  This sounds like something has changed, any old file that used # at
>  the end will behave differently now (bug aside). Log message is
>  cryptic, in best case, the "this is" leads to multiple
>  interpretations.
>
>  I could try testing how scripts handle the new assumptions, but I am
>  tired of playing QA guy today, only other thing I tried was loading a
>  non zero padded image sequence, if it is going to happily save with
>  this scheme, it should load files back... ooops, not supported, order
>  problems. People better fully pad names (or enjoy selecting hundred of
>  files manually).
>
>  GSR
>
>  _______________________________________________
>  Bf-committers mailing list
>  Bf-committers at blender.org
>  http://lists.blender.org/mailman/listinfo/bf-committers
>