Please remove or weaken run_time validation in Animation class, so as to allow animations with run_time = 0 #4004
Comments
puppis
added
the
new feature
|
In the new pyav-based rendering, Disallowing individual animations with non-positive run times is, by far, the easiest solution to make sure this does not happen. Technically, animations with a run_time of 0 still work, as long as there are other animations in the same play call that push the duration of the written partial movie file to any duration that is at least one frame. It would be possible to split the check, to restrict that individual animation run times need to be non-negative, while every play-call has to process something with an actually positive (and sufficiently long) run time. Semantically, I am not a big fan of animations with a run time of 0. Can you describe in detail why and for which situation exactly you rely on them? Maybe we could come up with a better solutions than misusing animations. |
|
A simple example, as I said, is to have an animation that makes an object
appear (eg. with FadeIn and run_time=0). I cannot use the add method of
scene because I want to collect this animation and similar other ones in a
group that will later be rendered (the group can represent sequential or
parallel animations, depending on the situation).
Let me understand: the problem with the broken movie file happens also if
you set run_time to be extremely small (eg. less than the frame rate)?
Il dom 10 nov 2024, 11:39 Benjamin Hackl ***@***.***> ha
scritto:
… In the new pyav-based rendering, self.playing an animation that has a
run_time of 0 effectively breaks the rendering because a broken partial
movie file is written.
Disallowing individual animations with non-positive run times is, by far,
the easiest solution to make sure this does not happen. Technically,
animations with a run_time of 0 still work, as long as there are other
animations in the same play call that push the duration of the written
partial movie file to any duration that is at least one frame. It would be
possible to split the check, to restrict that individual animation run
times need to be non-negative, while every play-call has to process
something with an actually positive (and sufficiently long) run time.
Semantically, I am not a big fan of animations with a run time of 0. Can
you describe in detail why and for which situation exactly you rely on
them? Maybe we could come up with a better solutions than misusing
animations.
—
Reply to this email directly, view it on GitHub
<#4004 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARRCR2MFVMWGU3IA3D44ZDZ74ZXLAVCNFSM6AAAAABRPR6HG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWGY4DAOJWGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Just give this particular animation a runtime of |
That gave me an idea: what about an |
Unfortunately this will not work for me: I need the run times of the animations to be precise, since for instance in a Succession Animation those tiny durations will sum up, and in a parallel Animation one will easily lose synchronisation. As far as I understood the problem mentioned is about the duration of a whole rendered animation; in my case this is the result of several parallel and succession animations, some of which must have run_time = 0. I also understand that validating every single animation is the simplest thing to do, but in my opinion it is not the correct fix. |
|
Just to document this here as well: we have discussed this some more; we intend to change the run time check for Help with changing the current implementation is appreciated! |
|
I really appreciate this. Thank you very much! :)
Il gio 14 nov 2024, 10:44 Benjamin Hackl ***@***.***> ha
scritto:
… Just to document this here as well: we have discussed this some more; we
intend to change the run time check for Animation to only check that run_time
>= 0, while introducing a separate check for Scene.play that makes sure
the duration of any passed groups of animations is at least 1 /
config.frame_rate.
Help with changing the current implementation is appreciated!
—
Reply to this email directly, view it on GitHub
<#4004 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARRCR3XLNXR6ZZYUPLBED32ARWHFAVCNFSM6AAAAABRPR6HG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZVHA3DONRVHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I just made a pull request addressing this issue! |
A validation on the value of run_time in the class of Animation has been recently introduced. In the current version I have this is implemented inside the begin method, but this might have already been moved in recent versions.
The problem with this validation is that it does not allow animations with run_time = 0.
For example, with run_time = 0 one could make an object appear instantly. Note that it is not always possible to implement this example behaviour using the add method from Scene: it is conceivable that, sometimes, one may want to have a proper animation object for this, which is then combined with other animations.
Also, having run_time = 0 does not really create any problem with the animation rendering, so, strictly speaking, the validation is not needed. My current ugly solution for this is to override the method begin to bypass this validation.
The text was updated successfully, but these errors were encountered: