huge +1 2011/6/16 Matt Ebb <m...@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 <aligor...@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 <pe...@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@blender.org > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- ____________________ François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers