[Bf-committers] float-upgrade to sequencer

Ton Roosendaal ton at blender.org
Wed Mar 1 21:39:05 CET 2006


Hi,

It would be interesting to do a performance test though, a lot of  
byte-only operations can become slow when you also have to clamp and  
convert (byte->int->byte) them all the time. Further, you can use  
opengl to display float buffers, so no conversions are required.

Anyhoo, assuming byte colors will still be faster, having a button  
option in Scene Buttons is no problem, of course.

The EffectHandle you propose... no time to deeply dive into it, but I  
don't see how it supports 1, 2, 3 or more input strips.

Having an entire NodeTree in a sequencer effect strip is possible, but  
I'm not too fond of the idea still. I still like it that it's an  
integrated part of the render pipeline. Or, just putting back the Scene  
strip in sequencer (temporally disabled, will do... :) also will give  
the composite features as output.

-Ton-

On 28 Feb, 2006, at 21:19, Peter Schlaile wrote:

> Hi,
>
> I'm working my way through the sequencer code and am just wondering  
> what's
> the best way to decide, if we should do effect processing on  
> rect_float or
> just rect.
>
> I'm fairly sure right now, there is no real automatic way to decide
> if the user prefers speed or quality. (If input and output is float  
> then
> everything is easy, but if both are not? Maybe we want to do float
> processing in the middle and just convert at both ends?)
>
> Best thing would be to add an additional button in the render-buttons
> window (if there is space left...). Am I right, that the user
> should be able to decide (also on compositing or scene-render) if the
> whole rendering pipeline runs on floats or not?
>
> What do you think?
>
> To the code cleanup I'm working on:
>
> I have now completely moved all effect stuff (including plugins) into a
> seperate file with a fairly clean interface that looks like this:
>
> -----
> struct SeqEffectHandle {
> 	/* constructors & destructor */
> 	/* init & init_plugin are _only_ called on first creation */
> 	void (*init)(struct Sequence *seq);
> 	void (*init_plugin)(struct Sequence * seq, const char * fname);
>
> 	/* load is called first time after readblenfile in
>            get_sequence_effect automatically */
> 	void (*load)(struct Sequence *seq);
>
> 	/* duplicate */
> 	void (*copy)(struct Sequence *dst, struct Sequence * src);
>
> 	/* destruct */
> 	void (*free)(struct Sequence *seq);
>
> 	/* returns: 0: no early out, 1: out = ibuf1, 2: out = ibuf2 */
> 	int (*early_out)(struct Sequence *seq,
> 			 float facf0, float facf1);
>
> 	/* stores the default facf0 and facf1 if no IPO is present */
> 	void (*get_default_fac)(struct Sequence * seq, int cfra,
> 				float * facf0, float * facf1);
>
> 	/* execute the effect
> 	   sequence effects are only required to either support
> 	   float-rects or byte-rects
> 	   (mixed cases are handled one layer up...)
>            the decision which one is used depends on out->rect_float */
>
> 	void (*execute)(struct Sequence *seq, int cfra,
> 			float facf0, float facf1,
> 			int x, int y,
> 			struct ImBuf *ibuf1, struct ImBuf *ibuf2,
> 			struct ImBuf *ibuf3, struct ImBuf *out);
> };
>
> struct SeqEffectHandle get_sequence_effect(struct Sequence * seq);
> ---------
>
> Ton: can you think of adding node support to the sequencer using just  
> this
> interface? Or have I missed something?
>
> This interface is at least not completely wrong since it helped me to  
> find
> a very obscure segfault situation in strip duplicate.
> (Add two movie tracks, add a wipe effect, make this a meta-strip,
> duplicate this meta-strip, and then delete both meta-strips. You will  
> get
> a segfault or a warning about a double-free.)
> It also removes the bad level call to open_plugin_seq in readblenfile.
>
> Greetings,
> Peter
>
> ----
> Peter Schlaile <peter at schlaile dot de>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org



More information about the Bf-committers mailing list