[Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==

Matt Ebb matt at mke3.net
Thu Jun 16 23:49:40 CEST 2011


Personally, I think a text strip has been sorely missing from the sequencer
(and compositor) for a while, and it's great to see it added. Doing it via
blender scenes and python is a really slow, nasty overcomplicated way of
doing something which really should be quite simple, and is a really simple,
common, basic tool in most other editors.

Editing the text from the sequence editor interface and having it rendered
directly to a strip is the fastest and best way of having such a feature,
and it's something I would have loved to have had plenty of times. Note: I
haven't tried the current patch but it would be best as a generalised 'text
strip' rather than anything aimed specifically at title cards, with
properties like text box height and width, and typographic/paragraph
controls too.

cheers

Matt



On Thu, Jun 16, 2011 at 9:26 PM, Joshua Leung <aligorith at gmail.com> wrote:

> Hey Peter,
>
> Cheers for the feedback!
>
> Indeed, as I started to pick through things, the issues faced by users
> who would want to use this as a base on which to start extending it in
> some ways did come up. Sure, a script which sets up a generic template
> would be nice in this situation, and is one way I'd thought of doing
> it.
>
> Some factors which made me favour this approach though were that:
> 1) Using this approach, we let automation take over making sure that
> the text fits and is aligned nicely in frame when things change. From
> experience, I've ended up scaling and re scaling text, moving it all
> over the place trying to get it to fit and be in frame. Registering a
> special operator for this, and/or trying to find somewhere decent to
> put it so that it can be easily found is an issue.
>
> 2) Text colours can be set in one place with this method, without
> fudging with material settings (and doing material-unlink dances after
> copying some text and deciding you want it a different colour - then
> again here, the level of control over this stuff is entirely
> hardcoded)
>
> 3) AFAIK, scene strips were synonymous with constantly being
> re-rendered and re-evaluated every single time they're encountered,
> when doing scene evaluation combined with rendering is a comparatively
> sluggish process for Blender. The alternative would have been to force
> people to always render these out to image files (something that I'm
> trying to avoid here) before they could be used.  (*1)
>
> 4) With this approach, including text in the sequencer feels more like
> a "first-class" entity than just a weirdo heavy-duty workflow, where
> you have a proliferation of "scene" strips in your timeline which are
> essentially just there to display text (but outwardly don't
> communicate this)
>
> 5) There's also the issue of a buildup of scene files in the file,
> each one for a different slide, making it easy to accidentally delete
> the wrong one from the file, and also making it slower to find the
> scene to go in and edit its text.  (*2)
>
> -------------
>
> (*1) From your mail below, it sounds like that's something the cache
> voodoo might be able to take care of under certain circumstances. As
> only a very infrequent user of VSE, I wasn't aware of this.
>
> (*2) I'm not really convinced about the idea of these template
> parameters for the scene strips. It sounds even more like a
> specialised hack from user perspective than shoehorning an entire
> strip type with some predefined slots where people commonly place text
> for common purposes.
>
> ---------------
>
> Anyhow, as an "experimental" feature, this was certainly a good
> exercise for seeing how such functionality could look like, and to
> generate debate over what use cases for this sort of stuff users have.
> (It was also a good exercise in exploring how the sequencer works,
> though I might add that the number of places where you have to
> redefine how a new strip type is a bit excessive)
>
> Personally, this is probably sufficient, though maybe with a few more
> optional slots for text. If nothing else, I can now save off this
> build for future use where necessary ;)
>
> Perhaps as you suggest, an operator which generates some preset
> title-card scene setups would be handy to have. Though it's the
> details of how we allow people to tweak the content there which
> worries me a bit.
>
> Regards,
> Joshua
>
> On Thu, Jun 16, 2011 at 10:35 PM, Peter Schlaile <peter at schlaile.de>
> wrote:
> > Hi Algorith,
> >
> > don't you think, we should add some other extensions to
> > blender, that make it possible, to script something like this with
> Python?
> >
> > Problem is: you wrote a *very* special solution for a
> > very special problem you had, and I'd like to keep the
> > sequencer core clean and simple.
> >
> > Would be cool, if you could specify a SCENE as template and only fill in
> > parameters.
> >
> > Add some tweaks to the SCENE strip, that make it optionally render to
> > files by default, add template parameters for the SCENE strip and there
> > we go.
> >
> > Then your title cards will end up as ONE additional scene as template and
> > template parameters to edit within the strip.
> >
> > That is in the long run a much better solution, since you give people the
> > freedom to make title cards or even fancy title cards as they like.
> >
> > You can add a Python script, that wraps this all nicely, so that you can
> > add some default title cards / whatever. (Which could add a template
> SCENE
> > automagically.)
> >
> > BTW: I personally use additional scenes within the same file, length 1,
> > which get extruded and animated properly. That way, the SCENE is rendered
> > once into the memory cache and the cached result is animated (with fades
> > etc.)
> >
> > If I didn't get the problem correctly, just let me know. I really like to
> > work out a generic solution for that!
> >
> > Cheers,
> > Peter
> >
> > ----
> > Peter Schlaile
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list