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