Followup
| Message |
 |
- Date: 2010-12-02 06:37
- Sender: Juan Pablo Bouza
- I forgot to mention that this is a playback issue, the render turns out just fine.
| - Date: 2010-12-02 12:55
- Sender: Ton Roosendaal
- OK; so this is sequencer!
Confirmed issue, in 2.55 release it works, now it doesn't anymore. Will ask campbell if he recalls why.
| - Date: 2010-12-03 01:40
- Sender: Juan Pablo Bouza
- I just made a test render and the problem seems to affect the render too.
| - Date: 2010-12-06 06:57
- Sender: Campbell Barton
- This works for me r33498, both when scaling the image and rendered 1:1
| - Date: 2010-12-06 14:00
- Sender: Juan Pablo Bouza
- Yes, it seems to be fixed in 33505 here too.
| - Date: 2010-12-07 17:19
- Sender: Ton Roosendaal
- Still doesn't work for me. I'm not sure even what "replace" is meant to do, the other options are all about mixing... in the sequencer code there are also strange exceptions for case SEQ_BLEND_REPLACE
| - Date: 2010-12-08 07:20
- Sender: Campbell Barton
- Ok, now I get this too.
This would work if the animation system called the update function of the property. This is an animation system issue.
Aligorith, could we have the animation system call property update functions now?.
| - Date: 2010-12-16 16:23
- Sender: Ton Roosendaal
- No it's not that simple... here's what I found out sofar:
- SEQ_BLEND_REPLACE type is specially handled, and breaks from loops before blending can happen.
- its opacity is only applied once, and can't be animated yet
- Other sequence blend modes work, but that's more by accident: if you change "opacity" the RNA calls rna_Sequence_update() which totally frees buffers in a strip. On frame changes the animation system does set correct opacity values, and because sequencer code treats it as effect-strip it recreates all buffers.
- If you animate other values on image strips (like mult or saturation) nothing happens during animation.
My main conclusion is that sequencer isn't ready for animated properties yet. The code with all cacheing is too fuzzy for me to get this simply coded.
| - Date: 2010-12-17 09:15
- Sender: Peter Schlaile
- OK, found it.
The problem goes like this: when using SEQ_STRIPELEM_IBUF, we cache preprocessed (including mul, opacity on replace, color corrected etc.) images.
Therefore, if we have a cached version, we don't want to apply the preprocessing twice on.
So now there is the additional problem of extruded still images. They are cached seperately (it is very common, to extrude them on several frames and animate only prefilter parameters). Here, we cache the *unprocessed* image seperately using SEQ_STRIPELEM_IBUF_ENDSTILL and _STARTSTILL. That's fine and dandy, only the code, switched off prefiltering for cached ENDSTILL/STARTSTILL images, too, which is wrong, since they are cached before prefiltering is done.
Ton, regarding your questions:
* SEQ_BLEND_REPLACE is indeed handled specially (no surprise, the stack shouldn't work it's way beyond REPLACE images), it is handled specially in two places,
* so: animating opacity actually *does* work (not only applied once, you misread the code a bit, take a look at input_preprocess() and input_have_to_preprocess() )
The only problem was, what I described above: I made a mistake using the cache system.
Sorry, for the late response.
Cheers,
Peter
| |
|
