Re: [Bf-committers] Multi Layer EXR issues
What if you just use the multi output node lukas added recently, you could keep consistently the difference between renderlayers (each node) and the passes (each layer of the node) does it make sense to you? Every output node is a layer Every input of an output node is a pass E-Mail Sent via BlackBerry from BT Mobile -Original Message- From: Lukas Tönne lukas.toe...@googlemail.com Sender: bf-committers-boun...@blender.org Date: Fri, 18 May 2012 15:26:27 To: bf-blender developersbf-committers@blender.org Reply-To: bf-blender developers bf-committers@blender.org Subject: Re: [Bf-committers] Multi Layer EXR issues If you setup your scenes to render in passes and layers, the names you give to this are meaningful and should be allowed to use. I don't understand why such a feature gets dropped? Yes, if the renderer generates multilayer files directly it can organize them in layers and passes. But when writing files from the compositor using the file output node, or when importing general files from somewhere else there is usually no such notion of render layers. That's why trying to sort the content of every multilayer file into a set of render layers doesn't work. ___ 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] libredcode
Very interesting question! Looking forward to know more about choice on R3D files. In fact they're quite compressed and easy to use compared to EXR converted from them! --Original Message-- From: Nate Wiebe Sender: bf-committers-boun...@blender.org To: bf-committers@blender.org ReplyTo: bf-blender developers Subject: [Bf-committers] libredcode Sent: 19 Feb 2012 19:37 Forgive me if this is the wrong mailing-list. I noticed that Camalot AV Facilties sponsored a Red Epic for the filming of Mango. So my questions are: Will libredcode be updated to support the newer firmware and .R3D codec? or Will a new library (perhaps Red's API) be integrated into blender? or Will another application be used to convert R3D files into say EXR's? or How will the RAW camera footage be used in blender? (Because it seems kind of a waste if the raw data isn't used) -NateW ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers E-Mail Sent via BlackBerry from BT Mobile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color space and alpha issues
Hi all, I'm really interested in this discussion since I found myself unable to understand how alpha works in the blender compositor and how I can clearly use it. In my quite long experience with many compositing system I always had the need to keep separated RGB from any other channel, alpha included since anything but RGB describe the color of the image. As an artist I would never take care of how blender internally handle the premultiplication but while making the network of nodes I must have the chance to premult or postdivide an image every time I need it because there are so many situation where a choice in this field as to be taken. Situation that require postdivided img: 1. Avoid black edges around obj 2. Better color correction handling 3. More saturated half transparent layer 4. Capability of work or undestand how to modify that half transparent edges 5. Ability to treat color and alpha in a separated manner Of course a the end of the chains there are almost always premultiplied images. About the teaching part For a compositor being able to handle premult/ postdivide is quite like for a modeler make the right topology. Hope this is usefull for further proposal/ discussion! :) Francesco E-Mail Sent via BlackBerry from BT Mobile -Original Message- From: James Ruan ruanbeih...@gmail.com Sender: bf-committers-boun...@blender.org Date: Mon, 19 Dec 2011 21:03:43 To: bf-blender developersbf-committers@blender.org Reply-To: bf-blender developers bf-committers@blender.org Subject: Re: [Bf-committers] Color space and alpha issues 2011/12/19 François T. francoistarl...@gmail.com: If it does, it makes more sense to go with added complexity and force the artist to learn the ins and outs of alpha for certain operations. As usual I'm more for the teaching rather the hiding :) As Matt said, only comp expert are going to want to mess with this anyway (I'm even sure some expert will bypass it in some cases). But people who wants to get serious about it will have to learn it no matter what with any application out there cheers, F. -- 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 I don't think the opposite of teaching is hiding. I think we need a uniform format for alpha. Artists don't need to know in which format there file is stored or processed. Only the well defined result counts. So giving every node in Node System to choose there input and output format is not a good option. The issue with compositing is that the image buffers are not just used for final storage and distribution, but they're used as a work-in-progress scratch pad, and it's often that the way you work with channels doesn't always represent something logical (eg. keeping masked out RGB pixels around so you can retrieve them later). +1. Good internal representation should store the most info. And RGB+mask alpha is the best choice for compositing. Maybe, we can handle both format by adding a tag in the imbuf, then define a RECOMMEND format for certain application (eg. premultiplied for rendering buffers). Image that used in other format will be converted to the RECOMMEND for only once. This will add a lot of code for checking and converting the format of imbuf though. But by using a cache, we can find a balance between CPU and Memory (maybe disk cache). And it's a good habit to check the input data and outputs to a RECOMMEND format (always assuming others doing wrong and do it right itself). Or we just use the unassociated alpha everywhere since it preserves most info and do conversions every time it is needed. After all, it should be easy, simple and correct for the users. They should not care about in which format their image is stored. -- James Ruan ___ 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] Color wheel proposal
another +1 for me too actual way of usig color wheel simply drive me crazy! E-Mail Sent via BlackBerry from BT Mobile -Original Message- From: Jonathan Williamson shadowdrag...@gmail.com Sender: bf-committers-boun...@blender.org Date: Mon, 21 Nov 2011 19:27:55 To: bf-blender developersbf-committers@blender.org Reply-To: bf-blender developers bf-committers@blender.org Subject: Re: [Bf-committers] Color wheel proposal +1. It would make me very happy! Jonathan Williamson http://blendercookie.com http://mavenseed.com On Nov 21, 2011, at 3:25 PM, François T. francoistarl...@gmail.com wrote: Yet another one :/ I have been trying to do lots of grading lately in Blender, and lost half of my hairs, so here is my proposal to make it (yes IMO, I know) more confortable *1 - where ever I click on the color wheel (CW), the mouse jump to cw cursor * right now its the other way around. While I understand it makes it easier to quickly change to a total different color, it makes it almost impossible to fine tune the current color. *2 - precise mode by default *(perhaps with a logarithmic curve on the mouse ?) This might be just a color grading thing, but again I find myself more looking for the color I'd like surrounding the current one, rather than totally jumping to a total different one. So pressing the shift key is a bit annoying *3 - When releasing the cw cursor the mouse jump to it* Yet I believe that would be solved by its own if the first step was done. But just to notice how annoying this behave right now. Especially since you have to release the cw cursor to see the new values being updated in the viewer. you would find yourself to click drag release, click drag release, click drag release. But since the mouse doesn't move to the new location, you keep going back to the previous color (gr). So you have to think about moving the mouse as close as possible to the cw cursor which makes fine tuning IMPOSSIBLE. 4 - *having a Hue saturation wheel when in HSV mode* (not a big deal, just makes it easier to see what you are doing a makes more sense IMO) - Making everybody happy - click far from the cw cursor makes it jump to the mouse position - click close to the cw cursor makes the mouse jump (snap) to it - when releasing the cw cursor the mouse postion gets the cw cursor (that with the two above makes click-drag-release not so painful) - (mode selfish ON) pressing shift turn off the precise mode ? 8-) cheers, F. -- 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 ___ 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] Blender tangent space calculation
Chiamami domani verso ora di pranzo al 3777074625 ora sono molto impegnato sto lavorando su una Correzione Colore E-Mail Sent via BlackBerry from BT Mobile -Original Message- From: Eugene Minov minov@gmail.com Sender: bf-committers-boun...@blender.org Date: Tue, 15 Nov 2011 21:43:12 To: bf-blender developersbf-committers@blender.org Reply-To: bf-blender developers bf-committers@blender.org Subject: Re: [Bf-committers] Blender tangent space calculation Yes, I absolutely agree, hard faces obviously must be exported in the same way how they seen in render. I think they can welds along with tangents. On Tue, Nov 15, 2011 at 9:01 PM, Morten Mikkelsen mikkels...@gmail.comwrote: There is no point in doing this unless you export the correct tangents and normals. That is the ones that were used to bake the normal map. I realize it blows that there is no API function to get the render normal. So what you have to do is produce it yourself like is done in DerivedMesh.c https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c and many other places as well. An example in this file is the static function GetNormal() which is used as a call-back function by mikktspace.c and you can see how it uses the averaged normal if the face is set to smooth and it uses the face normal which it calculates itself if the face is set to flat. If you are going to make an api to export tangents I for one cannot emphasize enough that I prefer an all or nothing solution. Either do it right or don't do it at all. The last thing we need is to introduce a new tangent space standard within blender. Either export the correct basis that was used for baking (this includes the normal) or don't try to do it at all. ___ 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
Re: [Bf-committers] Including documentation in BCon cycle
I'm not a developer so I see your suggestion from an artist point of view: It's an incredile pain try to figure out how a tool works! Really, I think here in our studio we spent dozen of hours in testing, defining our own ideas of what is done by a tool without really know if what we imagine is true. And this in many situation lands to not use that tool but just find another way to do something that works! I agree in the relationship: No docs = not ready for trunk Maybe it's time to hire someone to get a well documented wiki ;) E-Mail Sent via BlackBerry from BT Mobile -Original Message- From: mindrones mindro...@gmail.com Sender: bf-committers-boun...@blender.org Date: Sun, 06 Nov 2011 22:04:29 To: bf-blender developersbf-committers@blender.org Reply-To: bf-blender developers bf-committers@blender.org Subject: [Bf-committers] Including documentation in BCon cycle Hi all, Bastien and I are in the middle of reviewing the 2.5 manual and, sadly, it's not in a good shape, really. A complete report will follow in docboard mailing list. We'll work to grow the wiki team but really, I think it's time to rethink a bit about the documentation, especially adopting a 2 months BCon cycle. I'd like to propose a very simple way to get stuff documented. ¦¦ ¦ Documentation phase should be included in the release cycle. ¦ ¦¦ Ref: http://wiki.blender.org/index.php/Dev:Doc/Process/Release_Cycle In other words I'm saying: --- ¦ ¦ ¦ No documentation in wiki - No release. ¦ ¦ ¦ --- We have discussed this in irc a bit and many (would) agree, and it was a hot topic at the Blender Conference too as far as I know. Really, having faster release cycles is all good, but it has to take in account documentation too, otherwise users will get pissed off after 5 releases in a year and no decent docs. And even if users are happy like this (which I doubt), I think it's a waste having such beautiful tools undocumented: I'm sure a great part of the developer work won't be used at all, which is a shame :) IMHO the documentation has to start from the developer, not from users. -- A couple of proposals to make the developers life easier on wiki docs. 1) Informal chats --- The dev explains the tool he has developed in an informal chat with the documenter, which puts the info he gets in wiki nicely. 2) Unformatted docs from devs --- Since many suffer the mediawiki syntax, it would be ok even if the developer types pure text in a wiki page, not formatted as wikitext. Writers would then help formatting, beautifying, adding tutorials, images, examples, etc. -- Any feedback is welcome :) Regards, Luca http://wiki.blender.org/index.php/User:Mindrones http://www.mindrones.com ___ 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
