Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
about workaround, I asked DingTo to change the max value of the Ortho Size parameter in Blender. So if you set the camera to Ortho and the Ortho size the same value as the Resolution_x of your camera (render settings). 1 pixel on your screen becomes 1 blender unit. which can be useful for this kind of stuff (subtitles, ... ). It was possible before, but the limit was up to 1000, which means at the time you could only do that with SD footages. Now the limit is up to 4K. (but it might need to be 10K actually since I believe it is the limit of Resolution_x, just to keep it consistant) cheers, F 2011/6/19 Vilem Novak pildano...@post.cz hello, I dont have here a pepper build to test the new titles tool, but I want to say it is very very welcome. Regarding the python solution, I allready coded an addon which adds subtitles from templates(first version): http://blenderartists.org/forum/showthread.php?213402-Sequencer-subtitles-addonhighlight=subtitle since I often do some simple subtitling work for low budget projects. The addon has the advantage of simple template creation, but its not possible to have the titles animated. It was very first version which I didnt finish because I was forced to switch to another NLE in the work where I needed it, there is preliminary support for srt reading too. Regarding a proposal about ideal subtitle adding, I would imagine subtitle strips having associated templates and several animatable properties(e.g. rollspeed), where the templates would be blender scenes which would render in background and the few animatable properties would be somehow marked so that the title engine can recognise them and make them part of the strip. Cheers Vilem Původní zpráva Od: François T. francoistarl...@gmail.com Předmět: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer == Datum: 19.6.2011 09:18:44 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
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
hello, I dont have here a pepper build to test the new titles tool, but I want to say it is very very welcome. Regarding the python solution, I allready coded an addon which adds subtitles from templates(first version): http://blenderartists.org/forum/showthread.php?213402-Sequencer-subtitles-addonhighlight=subtitle since I often do some simple subtitling work for low budget projects. The addon has the advantage of simple template creation, but its not possible to have the titles animated. It was very first version which I didnt finish because I was forced to switch to another NLE in the work where I needed it, there is preliminary support for srt reading too. Regarding a proposal about ideal subtitle adding, I would imagine subtitle strips having associated templates and several animatable properties(e.g. rollspeed), where the templates would be blender scenes which would render in background and the few animatable properties would be somehow marked so that the title engine can recognise them and make them part of the strip. Cheers Vilem Původní zpráva Od: François T. francoistarl...@gmail.com Předmět: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer == Datum: 19.6.2011 09:18:44 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
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
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
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
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.
