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

François T. francoistarlier at gmail.com
Sun Jun 19 09:09:15 CEST 2011


huge +1

2011/6/16 Matt Ebb <matt at mke3.net>

> 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier


More information about the Bf-committers mailing list