[Bf-committers] Proposition: Multilayer EXR support
* Problem statement Multilayer EXR files are used in 2 places. 1. to temporarily store the render buffers to reduce the memory footprint between the render pass and the composition pass. 2. to store the final output image as a multilayer exr. the problem is that multilayer exr's are stored upside down. For 1 it is not a problem as the file is temporarily and used by blender renderer. for 2: the output image makes the file's not easilly usable. You first have to flip the image, before you can use it. * Expectation the temporarily file must still be stored in the current form (upside down) for performance reasons. the output file must not be stored upside down, but still have all render layers available. (open file with exrdisplay -C RenderLayer.Combined.R filename.exr to see problem) Identifying the problem. both accesses the same function in openexr_api.cpp and both are triggered from the pipeline.c (blender renderer), but both have different requirements: * Proposition/alternatives there are several options how we can solve this: 1. leave all the same, but just before writing the multilayer exr output image, flip all render buffers. The implementation of the multilayer does not use the imbuf API, so will not effects other file formats and is easilly doable 2. update the imbuf api, to support multilayer images. more work, but more futureproof to possible other (professional, non existing) output formats 3. use the exr tiles to save the image upside down (is something in between solution 1 and 2) I would have chosen for option 1 as it is not that much work, and I don't know what the requirements are for other professional output formats. Solution 3 Other issues in this area: the multilayer has is no default image/layer; all images are default black in other applications like nuke or exrdisplay. What do you think what is the wise thing to do? @Brecht, Campbell, is it OKE to patch pipeline as you are restructuring the renderer? Greetings, Jeroen Bakker. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposition: Multilayer EXR support
Hi, It's not upside down, it's an accepted documented option in exr that has issues... both directions are allowed, but when i worked on it there were weird things in the windows version of openexr or so... too long ago to recall. Investige this? -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 29 Jan, 2010, at 15:34, Jeroen Bakker wrote: * Problem statement Multilayer EXR files are used in 2 places. 1. to temporarily store the render buffers to reduce the memory footprint between the render pass and the composition pass. 2. to store the final output image as a multilayer exr. the problem is that multilayer exr's are stored upside down. For 1 it is not a problem as the file is temporarily and used by blender renderer. for 2: the output image makes the file's not easilly usable. You first have to flip the image, before you can use it. * Expectation the temporarily file must still be stored in the current form (upside down) for performance reasons. the output file must not be stored upside down, but still have all render layers available. (open file with exrdisplay -C RenderLayer.Combined.R filename.exr to see problem) Identifying the problem. both accesses the same function in openexr_api.cpp and both are triggered from the pipeline.c (blender renderer), but both have different requirements: * Proposition/alternatives there are several options how we can solve this: 1. leave all the same, but just before writing the multilayer exr output image, flip all render buffers. The implementation of the multilayer does not use the imbuf API, so will not effects other file formats and is easilly doable 2. update the imbuf api, to support multilayer images. more work, but more futureproof to possible other (professional, non existing) output formats 3. use the exr tiles to save the image upside down (is something in between solution 1 and 2) I would have chosen for option 1 as it is not that much work, and I don't know what the requirements are for other professional output formats. Solution 3 Other issues in this area: the multilayer has is no default image/ layer; all images are default black in other applications like nuke or exrdisplay. What do you think what is the wise thing to do? @Brecht, Campbell, is it OKE to patch pipeline as you are restructuring the renderer? Greetings, Jeroen Bakker. ___ 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] Patch review needed: [#20882] add scale_bilinear_compbuf to node/intern/{CMP_util.c, CMP_util.h}
As the title says. https://projects.blender.org/tracker/index.php?func=detailaid=20882group_id=9atid=127 It would also be possible if someone change the scale node to apply this method. -- James Ruan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] MultiRes Shapekeys??
Hi guys! This is just a thought... What if Blender was able to use more than 1 multires modifier per object? Imagine that you have a highpoly multires character, then, you add a second multires modifier which uses the previous multires modifier as its base. Then, with that second modifier enabled, you sculpt veins, or little wrinkles. The information that the second modifier should store would only be the displacement against the previous modifier, so the file size should not be too big. The idea would be to control the influence of the second modifier with a driver or something, that way you would be able to have a kind of high resolution shapekey. _ ¡Usá Messenger en todas partes! Sumate a Somos Messenger Siempre y chateá desde tu celu http://www.somosmessengersiempre.com/?ocid=TWLH ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New gettext and fftw3 libraries for MinGW compilation
Sergey I. Sharybin schrieb: Hi Belnder Community, In IRC people often asks about error at Blender startup when it's compiled with MinGW (something with code 0x0005, don't remeber I was not able to compile a working Blender with minGW since a while. It just crashes at start. I would be very pleased if this could be tackeled, I cant afford (space wise on my Disk) to install MSVC Express on my laptop. Thanks, Carsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Particle surfaces update
Oh awesome. We've been needing something like this. Joe On Thu, Jan 28, 2010 at 7:23 AM, Raul Fernandez Hernandez ra...@info.upr.edu.cu wrote: Hi all Last nigth I have finishing implementing the surface refinement for particles, this allow to increase the resolution of the mesh for smoother surfaces. I still need to redefine my current surface evaluation from particles because I´m getting the wrong isosurfaces but still I could show you my progress. I'm very exited about it because I'm learning the necesary skills to tackle later Voxel Sculpting since are based on the same technologies :) Is not a beatufl pictures and for end users this may still tell noting but a month ago I only could dream about achiving this: http://farsthary.wordpress.com the longest journey start with a step ;) Cheers Farsthary ___ 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] MultiRes Shapekeys??
I don't think this would work, unfortunately. It'd be more feasible to support branching within a single multires modifier, and it's probably much more practical to simply make sure the existing shape key tools do what we need. Joe On Fri, Jan 29, 2010 at 7:38 AM, Juan Pablo Bouza jpbo...@hotmail.com wrote: Hi guys! This is just a thought... What if Blender was able to use more than 1 multires modifier per object? Imagine that you have a highpoly multires character, then, you add a second multires modifier which uses the previous multires modifier as its base. Then, with that second modifier enabled, you sculpt veins, or little wrinkles. The information that the second modifier should store would only be the displacement against the previous modifier, so the file size should not be too big. The idea would be to control the influence of the second modifier with a driver or something, that way you would be able to have a kind of high resolution shapekey. _ ¡Usá Messenger en todas partes! Sumate a Somos Messenger Siempre y chateá desde tu celu http://www.somosmessengersiempre.com/?ocid=TWLH ___ 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] New gettext and fftw3 libraries for MinGW compilation
I'm trying. But for this somebody should check compilation with libraries, which I've uploaded to the tracker. Without this libraries cross-compilation isn't working. The same history is with OpenCollada, but I've written about it some days earlier. Carsten Wartmann wrote: I would be very pleased if this could be tackeled, I cant afford (space wise on my Disk) to install MSVC Express on my laptop. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.5 Python API Introduction.
Hi Shul, (on IRC clarified that 'usability aspects of developing' means context problems with operators not running). There are 2 main problems 1) Running from the console/text editor wont work for many operators. 2) When an operator wont run there is no message to say why. For 1, many operators were quickly ported over and only tested from the user interface, some may be checking for the 3D view but not actually need it (or similar checks POLL might to for context) But since there will remain operators that do need to run in a certain window type it would be good to have some way the console could execute operators in a different space. Tricky to do well since the operator may also expect the mouse to be in the view. (Maybe have the console as a separate window and drag over the same you want to execute in ugh!). As for 2), Maybe we should have an OperatorType-poll_description. Can say something like Requires the 3D view to run or Needs an edit mode mesh In C these messages could be re-used, just as the poll functions are. These messages would be used in the python error message. Another nice thing about this is greyed out buttons could give this message in their tooltip's, something I found odd/confusing in complex applications that there is no way of knowing why a buttons disabled. It seems to me that this isn't something that has one fix, more a matter of testing the python integration and resolving limitations as we go. I expect this wont all happen in the next 3-5 months but hopefully the most annoying problems will be resolved before a stable release. - Campbell On Thu, Jan 28, 2010 at 4:43 PM, Shaul Kedem shaul.ke...@gmail.com wrote: Campbell, What are we going to do with the usability aspects of developing scripts in 2.5? following our talk in IRC is there some kind of a proposition for a well defined workflow? Thanks, shul On Thu, Jan 28, 2010 at 10:38 AM, Campbell Barton ideasma...@gmail.com wrote: The PDF is more an example of what we can get closer to the release, since I like to keep these docs updated every week or two its a hassle to build both and upload. Eventually I'll automate this process. Ill add build-info (date revision) into the docs soon. On Thu, Jan 28, 2010 at 3:43 PM, I S kiso...@gmail.com wrote: Thu, 28 Jan 2010 12:53:31 +0200, Campbell Barton ideasma...@gmail.com: Heres PDF generated from sphinx 6.4 http://www.blender.org/documentation/250PythonDoc/250PythonDoc.pdf Thanks :) A link to the PDF at http://www.blender.org/documentation/250PythonDoc/ and maybe generation date in the name would be nice also :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New gettext and fftw3 libraries for MinGW compilation
Hi Sergey, I'm reading your scons patch - greatly appreciate the effort - but something in the patch looks 'wrong' to me. In line 13 of the patch you add gnu_gettext.dll to dllsources, and then the next line dllsources is set to a group of files. This would seem like it would override your previous action. for iconv it seems like you are now excluding win32-vc from getting iconv added ? LetterRip On Fri, Jan 29, 2010 at 10:27 AM, Sergey I. Sharybin g.ula...@gmail.com wrote: I'm trying. But for this somebody should check compilation with libraries, which I've uploaded to the tracker. Without this libraries cross-compilation isn't working. The same history is with OpenCollada, but I've written about it some days earlier. Carsten Wartmann wrote: I would be very pleased if this could be tackeled, I cant afford (space wise on my Disk) to install MSVC Express on my laptop. -- With best regards, Sergey I. Sharybin ___ 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] cleaning out dead patches
Hi all, if you have a patch in the tracker and it is probably no longer of any use to anyone (ie not worth porting to 2.5 etc.) could you please close it? We have about 150 patches in the tracker right now, and at a guess half can probably be closed as no longer relevant. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New gettext and fftw3 libraries for MinGW compilation
Oh. Stupid mistakes. At line 15 it shoudld be += instead of =. gnu_gettext.dll is necessary only if gnu_gettext.lib from lib/windows/gettext is used. But for MinGW static libintl.a is using. If I'm not mistake libintl.a is linked staticly to the iconv, so iconv.dll is unnecessary with new gettext lib. So at line 33 it is also stupid typo, It should be != not =. I've uploaded changed patch to the tracker. P.S. Sorry for this very stupid typos. It was hard week.. Tom M wrote: Hi Sergey, I'm reading your scons patch - greatly appreciate the effort - but something in the patch looks 'wrong' to me. In line 13 of the patch you add gnu_gettext.dll to dllsources, and then the next line dllsources is set to a group of files. This would seem like it would override your previous action. for iconv it seems like you are now excluding win32-vc from getting iconv added ? LetterRip On Fri, Jan 29, 2010 at 10:27 AM, Sergey I. Sharybing.ula...@gmail.com wrote: I'm trying. But for this somebody should check compilation with libraries, which I've uploaded to the tracker. Without this libraries cross-compilation isn't working. The same history is with OpenCollada, but I've written about it some days earlier. Carsten Wartmann wrote: I would be very pleased if this could be tackeled, I cant afford (space wise on my Disk) to install MSVC Express on my laptop. -- With best regards, Sergey I. Sharybin ___ 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 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
