Re: [Bf-committers] GPU buffer changes
Uploaded patch for review here: http://codereview.appspot.com/4631052/ -Nicholas 2011/6/15 Ρυακιωτάκης Αντώνης : > Great, this code is in great need for refactoring :) > ___ > 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
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-addon&highlight=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. > 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 > > > 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 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 pe
[Bf-committers] Blender developers irc meeting minutes, 19 june 2011
Hi all, Short summary of today's topics: (check at least the 2.58/9 proposal!) 1) - Via python (and custom properties) scripters can now define own 'update' calls, to trigger dependencies on other data. A document example for boolean is here; http://www.blender.org/documentation/blender_python_api_2_57_1/bpy.props.html#bpy.props.BoolProperty - The current change log: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/changelog_258 Feel free to arrange/organize, but don't add new items (is being handled by Campbell & Mario) - Question from Dalai: BGE fixes in GSoC branch can go to trunk anytime, if maintainers agree of course. - Open release targets still: - Keymap saving/load, add-on key changes - VSE: correct frame interpolation for 'speed' effect strip - Group-linked cloth fails still (ton goes over todos and keymap issue with Campbell/Brecht to make a final target list) - According to Dalai there are already new icons for Game Logic, Ton mails Jendzrych to check - To respect our bimonthly release schedule, proposal is: - call for a 2.58 this tuesday, release 1-2 days after (no real freeze needed) - define August 1st as last day of "bug fix & 2.5 targets period" and release 2.59 for Siggraph. - Then starting in august, branches and patches can migrate over. - The removal of "texture face" part one proposal is nearly ready: http://wiki.blender.org/index.php?title=User:Dfelinto/TexFace This gets a review for 2.59. It doesn't remove the per-face assigning for Images yet! 2) Other projects - We still need a good 2.6x migration planning for branches, but a lot of good patches are awaiting anyway (nodes, weight modifier, FBX import, camera sensor, texface removal) - Status of BMesh? Can Joe report about feasible deadline date to move trunk & release? - Ton also proposes to review Brecht's old "remove from Blender" list again for the 2.60 version. - Update from Ton on Mango: announcement of project has been postponed to be september earliest, this to accommodate for long Blender & Foundation todos as well. Project start then is late 2011 or early 2012 soonest. 3) GSoC - Motion tracking: libmv works on 3d reconstruction now. Might see first tests work in 2 weeks. - Ton will collect all student's wiki progress pages, for everyone to easier browse student's work Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bf-committers Digest, Vol 83, Issue 26
Hi, On Sun, Jun 19, 2011 at 8:43 PM, Peter Schlaile wrote: > I know, your first idea was adding a very simple text tool, but there it > usually doesn't stop. You will be faced with people, who want to do > something special to the text, have it 3D extruded, adding parameters and > then you start to add a seperate 3D renderer to the sequencer. > I find this very hard to believe. It's not uncommon for video editors to have simple text tools for adding titles, subtitles, etc. FCP has it, Vegas has it, Premiere has it - compositors like Nuke, Fusion, Shake have it, and none of them have gone down a slippery slope resulting in 3d extruded text effects. If anybody needs something like that, they can easily render it in Blender, but for 90% of the usage cases, having a quick, simple way to edit text in-place would be a real boost. It's very easy to define that such a tool is for simple 2d text rendering only - for anything more complicated you use other effects in the sequence editor, or use 3d text in blender (which is a total pain in the rear when used for this purpose), or do what you have to do now if you want anything usable: make images in an external app like Photoshop. (BTW: your text-tool even doesn't solve Algorith's problems. Fun fact :) > He wanted some automatic layout with his title cards, and so the whole > thing needs some fancy scripting to be right in all circumstances.) > I don't see how it wouldn't solve his problems - all you'd need is a text area with width, height, X and Y position, plus some formatting options like left/right aligned/centred and vertical alignment top/middle/bottom. Along with a font and size, that's pretty much all you need, it's what most other editors have, and covers most normal use cases. No scripting required. The idea is to have something that is super fast for the 90% of situations where you want text - not to have something that's totally flexible but clumsy to use. To summarize: I think, the most easy way to add this to blender is to add > some small features to the scene strips, so that parameters can be passed > to a scene and add some small operators, which make it possible to handle > all this with python templates. > Blender already has an API for drawing 2d text to a bitmap. To me, that's a lot simpler than a solution that has to access disparate parts of blender and tie it all together with scripts, and more efficient than kicking off blender's internal 3d renderer every time you want text. cheers, Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bf-committers Digest, Vol 83, Issue 26
Hi Matt, I didn't want to make it hard to use from a user perspective. In fact, I'd want to make it possible to easily script features like those implemented in a hardcoded way by Algorith. And: the most general solution still looks like a possibility to add special strips, that internally (read: more or less hidden to the user) use scene templates. Idea: you get 100% flexibility + extensibility *and* easy UI. Speed problems could be handled by OGL rendering or cache rendering to disk. I still don't get, why this should be overcomplicated (I don't really need something like that currently, but it shouldn't be more than around 3 days of coding work). I know, your first idea was adding a very simple text tool, but there it usually doesn't stop. You will be faced with people, who want to do something special to the text, have it 3D extruded, adding parameters and then you start to add a seperate 3D renderer to the sequencer. (BTW: your text-tool even doesn't solve Algorith's problems. Fun fact :) He wanted some automatic layout with his title cards, and so the whole thing needs some fancy scripting to be right in all circumstances.) Do you know, where other open source video editors end up? They usually add a strip for fancy 3D text, which uses Blender as a render backend. So that is really ironic, isn't it? (e.g.: http://www.openshot.org/screenshots/ ) To summarize: I think, the most easy way to add this to blender is to add some small features to the scene strips, so that parameters can be passed to a scene and add some small operators, which make it possible to handle all this with python templates. That is easy to code, easy to use and 100% flexible. Just my 2 Cents. Cheers, Peter On Sun, 19 Jun 2011, bf-committers-requ...@blender.org wrote: > >> 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 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
[Bf-committers] [BGE PROPOSAL] Saving converted scenes
Hi, i made a more detailed proposal for saving converted scenes to file. You can find it here http://wiki.blender.org/index.php/User:Makers_F/Save_converted_BGE_data_out_to_a_file There are still some thing undefined, but i would really like to know if i took a good path for doing this, or there are better methods. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Environment Map Rendering
Hi, I'm new to lists so forgive me if I've sent the wrong sort of thing to the wrong place or any other faux pas. I require some improvements to environment map rendering, and willing to offer the little money I have. Things such as volumetric objects appearing in envmap renders is what I need done. I understand the developers plan to make these improvements but it would be a great help if it were available sooner rather than later. Is anyone initially interested in making an arrangement? Jai Lee Ljubić ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
huge +1 2011/6/16 Matt Ebb > 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 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 > > 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
