Why does Houdini start at frame 1 instead of 0?

[magneto]

Hi,

I was wondering about this for a long time, and this comes up in tutorials a lot due to differing behavior between time for example, so thought I would ask.

Houdini generally seem to favor zero based indices/numbers, just like a lot programming languages, which makes things simpler IMO. The first frame number is the only 1 based default I can remember.

As with everything in Houdini, I don't think this is a coincidence

Can I change this default? If so, would it break anything, or have some unforeseen consequences due to some code assuming the timeline starts at frame 1 instead of 0?

Thanks

[sanostol]

Most programs start at frame 1, ( I often used 0 as a kind of initial pose)

it makes sense to start at 101 or 1001 so it there are timing changes or the animation gets extended in front You can easily do this, without going into negative frames, (for sims I often need more frames ahead so it can settle)

but keep in mind that all simulation stuff has its first frame set to 1 and You have to modify this to,( simulation start frame, object creation frame and so on )

Edited June 15, 2013 by sanostol

[Annon]

Yeah I always default to frame 1001 as well, makes things simpler.

[Skybar]

A big swedish company I know of always start on frame 101 as well, I guess most do to some extent (?).

[old school]

Yeah I always default to frame 1001 as well, makes things simpler.

A question about starting at 1001. In what situations do you need 41.667 seconds of run-up time for a simulation? Or are there other issues driving this starting frame with four digit padding being the number one contender for simplicity?

As for frame 1, that's a default inherited from antiquity and that in itself gives it persistence but doesn't necessarily make it correct in the slightest.

I have seen many large facilities start at 101. Everyone is always free to submit an RFE for 101 or 1001 to be the default. Or just leave it at 1 and leave the trivial task of changing this start-end frame preset to whatever you want. Most studio asset systems have this built-in and in most cases the artist fires up Houdini in a shot environment where $FSTART and $FEND are already pre-defined for you (hscript or python commands to do this). For a single artist working alone or outside of a Houdini-friendly config environment, just put this in to the 123.cmd or 123.py.

Houdini tends to properly sort sequences without resorting to padding frame numbers in all it's browsers along with the command line tool Spy.

Edited June 15, 2013 by old school

[sanostol]

using 101 or 1001 is kind of preference I think.

I like starting at 1 as default for testing out things an doing rough setups, and as jeff said, for production work it is quite advisable to have tools that care about shots settings, necessary prerolls, assets and footage to load in, its a huge timesaver

[anim]

...

A question about starting at 1001. In what situations do you need 41.667 seconds of run-up time for a simulation? Or are there other issues driving this starting frame with four digit padding being the number one contender for simplicity?

...

1001 is quite common start for shot in many studios

it doesn't mean that simulation is run from 1 as the DOPnet is usually set to start at around 1001 as well

it's just convenient to preroll a few frames if necessary without getting into negative frames (even though houdini usually handles them well, many other softwares don't, especially for caches)

and even if there is no need for pre-roll, the edit of the shot may change so suddenly you need to start 125 frames sooner and in that case you just shift your shot start frame to 876 without any other change in the scene instead of shifting any keyframes etc.

so just convenience

but there is no need to make it factory default, everybody can set default fps, start, end frame, ... in Global Animation Optioins

and to the original question why 1 instead of 0 or 1001 instead of 1000?

let's say you have 24fps

then 1s = 24f

so at frame 24 you want to have 1s for convenience

but if you start at 0 you will have at frame 24 actually 25th frame and that's 1.04166 s, not convenient at all, therefore 48 is not 2s etc

so as an artist your seconds are 1-24, 25-48, 49-72

as a programmer you may be ok with 0-23, 24-47, 48-71

it's just a preference and you will not break anything if you know what you are doing but as sanostol said be careful with default dop settings as many objects have set absolute creation time instead of using simulation time which is just a simple checkbox anyway

[old school]

Thanks for the clarifications Tomas.

[magneto]

Thanks alot guys. I never heard of using 101 or 1001 as the start. Can you please give an example how this would be used? Like anim said, if you suddenly need to start 125 frames earlier, what do you do? You only change FSTART to 876? But if you cached your sim, then those will be using wrong frame numbers now, right?

Also I thought to emulate $T, you needed ($F-1)/$FPS, that's why I wondered.

[sanostol]

yes , that easy, just change Your globals to the new range and don't forget to adjust your sim start frames too. the cache will change, but most of the time extending means that the animation so far keeps the same, the editor just wants to cut in earlier. so you animation work on emitter and forces is at least untouched so far , just extended too, and You don't have to shift animations

You frames keep kind of fixed, and for my part I found it quite error prone to shift animations, in combination with different software packages, departments, and people. it might be not the only modification on the shot length and things tend to get messy.

Edited June 15, 2013 by sanostol

[anim]

$T in houdini is quite strange since it's 0 is always at 1f no matter of the start frame setting, and for that I don't know exact reason

I was more talking about playback seconds not actual time variable in houdini

for the 1001 start it's just a start setting in Global Animation Options

when your shot edit changes you just change the values in there and choose No to the question about stretching channels

everything stays as it was, but you will gain more frames at the begining

so if you have cached something in range 1001-1200 it will still be on those frames (supposing you've used $F in any way in the file names)

the same for caches coming from other softwares

EDIT: Martin was faster

Edited June 15, 2013 by anim

[magneto]

Thanks alot guys, that makes sense now. But if your old cache starts an explosion at frame 1001, after you change the start frame to 876 for example, your explosion will now start at 876, so the old cache of frame 1001 on disk will be wrong, no?

[sanostol]

when the editor wants to cut in earlier, the explosion will probably happen at the same frame, but he wants to have some more time before. probably there will change a lot of things so You will resim it anyway. but the idea is that You don't change time, just the scope of the time you watch

in a full cg shot it might be more work to change, but working on footage, for examle the tracking data keeps the same. and it is a good thing to track the complete shot, too

Edited June 15, 2013 by sanostol

[magneto]

Thanks alot sanostol, I get it now, very interesting

[rdg]

Also I thought to emulate $T, you needed ($F-1)/$FPS, that's why I wondered.

Is $T a requirement for your workflow?

Personally I prefer working in frames - it feels more natural.

As for starting at 1001: As oldschool mentioned not every software gives you the luxury of handling negative frames seamlessly like Houdini.

Wouldn't be the first time foo.-89.obj broke a workflow.

Also cut ranges and handles often change over the live time of a shot, again starting at 1001 prevents the numbers to go into the negatives. Unless you offset everything to keep the frame numbers consistent.

Having said that, yes I've seen shots with 15000 frames preroll - everything's possible.

Btw, are you writing a thesis about this, the topic seems quite academic?

[magneto]

Thanks rdg, no just curiosity. Because $T and ($F-1)/$FPS comes in particle related tutorials often that's why I was wondering.

[Annon]

A question about starting at 1001. In what situations do you need 41.667 seconds of run-up time for a simulation? Or are there other issues driving this starting frame with four digit padding being the number one contender for simplicity?

Hey Jeff,

It's not a case of having 40+ seconds of pre-role, just a force of habit. I've worked at a few places where the farm strips frame padding as well, so 1001 will always ensure $F4.

Also it avoids going into negative frames etc.

[old school]

Thank-you Christian.

[edward]

so as an artist your seconds are 1-24, 25-48, 49-72

as a programmer you may be ok with 0-23, 24-47, 48-71

it's just a preference and you will not break anything if you know what you are doing but as sanostol said be careful with default dop settings as many objects have set absolute creation time instead of using simulation time which is just a simple checkbox anyway

Thanks for the great explanation, Tomas!

Using $T=0 to mean $F=1 makes it convenient to judge the length of animation, while making it harder to convert between the time units of "frames" vs "seconds". As a programmer, I've found that the latter case more commonly occurs. I wonder though as an artist, which situation comes up more often (or is more important) for the pipeline.

[anim]

currently in houdini $T(0) == $F(1) no matter what, to me the most logical would be:

$T(0) to be $F(0)

but I would still start at 1 because in my head frame 1 has duration from 0 to 1 since that's how long it is on the screen in the final product and that's what matters

so in 24fps frame 1 would be from time 0 to 0.04166667s

so I'm not quite sure why Houdini pivots it's time at $F==1 (so $F(0) is always negative $T)

maybe a little option to set that would be great

but anyway I think the pure decision of start frame hardly matters, and many times it's decided in the edit so we just simply deliver required frames