Re: [Bf-committers] making CurveMapping objects editable from Python
You do not need to search. If YOU submitted the patch, then it will show up on your home page of projects.blender.org in the Submitted Artifacts section. 2011/1/18 Dan Eicher d...@trollwerks.org On Mon, Jan 17, 2011 at 8:38 PM, Stephen Swaney sswa...@centurytel.net wrote: On Mon, Jan 17, 2011 at 04:17:27AM -0700, Dan Eicher wrote: I did a patch for this a while back but it was rejected for reasons I can't remember now. http://www.pasteall.org/18339/diff Reasons we submit patches to the patch tracker are so * they do not get overlooked or forgotten * they can be discussed * problems can be corrected Just a thought... -- Stephen Swaney sswa...@centurytel.net Pretty sure I did submit it just too lazy to search (and it was easier to pasteall it). Or maybe not, either way still too lazy to search... ___ 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 upside down
The color wheels are HSV, there is no standrad way to represent them but using some of the more commom math/trigo rules: a Hue of 0º (Red should be on the +X axis) and rotaion go in the trigonometric sense (conterclock wise) Scopes have nothing to do with this: Colorwheels are represented in HSV space with HS beeing used as polar coordinates Vectorscope is in YUV sapce with UV beeing used as cartesian coordinates Xavier 2011/1/18 Troy Sobotka troy.sobo...@gmail.com Look at Blender ones, the red is at the bottom, while all in that page put it at the top or the right side, following typical starts for clocks or angles (resp.). That is what he is pointing, that Blender is yet another style with hard to explain 0 points down. As opposed to 0 being lower left or middle right? There certainly is no such thing as a standard here from what research is available. And if the video scopes do something else as he pointed, that is really bad, because it is inconsistent with itself and only causes headaches. Agree. Xat and Matt would be able to help on the reasoning behind the scopes. Unifying the wheel orientations for internal consistency makes solid design sense. As to models to follow, it comes down to audience. If the audience is a grading specialist, probably following Resolve or Lustre makes sense. Just throwing it out there... Lustre: http://download.autodesk.com/us/systemdocs/help/2010/Lustre2010/help/images/MED/Lustre/Help/English/primary_colour_grading/ink_svg/PR_lin.png Avid: http://digitalfilms.files.wordpress.com/2010/03/blg_wheels_avid_1.jpg Davinci Resolve: http://www.digitalcontentproducer.com/mag/510MIL_BetaSight-daVinci1.jpg ___ 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 upside down
Would it be possible to make the color wheel rotateable/mirrored via a modifier key? Then all preferences could be had. On Tuesday, January 18, 2011, Xavier Thomas xavier.thomas.1...@gmail.com wrote: The color wheels are HSV, there is no standrad way to represent them but using some of the more commom math/trigo rules: a Hue of 0º (Red should be on the +X axis) and rotaion go in the trigonometric sense (conterclock wise) Scopes have nothing to do with this: Colorwheels are represented in HSV space with HS beeing used as polar coordinates Vectorscope is in YUV sapce with UV beeing used as cartesian coordinates Xavier 2011/1/18 Troy Sobotka troy.sobo...@gmail.com Look at Blender ones, the red is at the bottom, while all in that page put it at the top or the right side, following typical starts for clocks or angles (resp.). That is what he is pointing, that Blender is yet another style with hard to explain 0 points down. As opposed to 0 being lower left or middle right? There certainly is no such thing as a standard here from what research is available. And if the video scopes do something else as he pointed, that is really bad, because it is inconsistent with itself and only causes headaches. Agree. Xat and Matt would be able to help on the reasoning behind the scopes. Unifying the wheel orientations for internal consistency makes solid design sense. As to models to follow, it comes down to audience. If the audience is a grading specialist, probably following Resolve or Lustre makes sense. Just throwing it out there... Lustre: http://download.autodesk.com/us/systemdocs/help/2010/Lustre2010/help/images/MED/Lustre/Help/English/primary_colour_grading/ink_svg/PR_lin.png Avid: http://digitalfilms.files.wordpress.com/2010/03/blg_wheels_avid_1.jpg Davinci Resolve: http://www.digitalcontentproducer.com/mag/510MIL_BetaSight-daVinci1.jpg ___ 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 -- ||-- Instant Messengers -- || ICQ at 11133295 || AIM at shatterstar98 || MSN Messenger at shatte...@hotmail.com || Yahoo Y! at the_7th_samuri ||-- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] color wheel upside down
On Tue, Jan 18, 2011 at 6:04 PM, Sean Olson seanol...@gmail.com wrote: Would it be possible to make the color wheel rotateable/mirrored via a modifier key? Then all preferences could be had. Just put it in the user preferences as a degree off set. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] bd_dna problem
Hi, just to let to know I did not update code for a while and today fresh svn gives the following output 1-- Build started: Project: bf_dna, Configuration: Debug Win32 -- 1 Generating dna.c 1 Running makesdna at debug level 0 1 Program version: $Id: makesdna.c 33448 2010-12-03 17:05:21Z campbellbarton $ 1CUSTOMBUILD : error : still 1 structs unknown 1 *** Unknown structs : 1PreviewImage on both 32 bit and 64 bit under windows. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bd_dna problem
Does the same on 32bit linux... On Tue, Jan 18, 2011 at 12:18 PM, Sergey Kurdakov sergey.fo...@gmail.comwrote: Hi, just to let to know I did not update code for a while and today fresh svn gives the following output 1-- Build started: Project: bf_dna, Configuration: Debug Win32 -- 1 Generating dna.c 1 Running makesdna at debug level 0 1 Program version: $Id: makesdna.c 33448 2010-12-03 17:05:21Z campbellbarton $ 1CUSTOMBUILD : error : still 1 structs unknown 1 *** Unknown structs : 1PreviewImage on both 32 bit and 64 bit under windows. Regards Sergey ___ 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] bd_dna problem
sorry, using CMake, it also produces that error under 32bit linux. On Tue, Jan 18, 2011 at 12:43 PM, pete larabell xgl.asyl...@gmail.comwrote: Does the same on 32bit linux... On Tue, Jan 18, 2011 at 12:18 PM, Sergey Kurdakov sergey.fo...@gmail.comwrote: Hi, just to let to know I did not update code for a while and today fresh svn gives the following output 1-- Build started: Project: bf_dna, Configuration: Debug Win32 -- 1 Generating dna.c 1 Running makesdna at debug level 0 1 Program version: $Id: makesdna.c 33448 2010-12-03 17:05:21Z campbellbarton $ 1CUSTOMBUILD : error : still 1 structs unknown 1 *** Unknown structs : 1PreviewImage on both 32 bit and 64 bit under windows. Regards Sergey ___ 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]Fix issue to build blender-2.56 with python-3.2 Beta 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, I have tried to build blender-2.56 agains the Beta 2 of python-3.2 which you may find in the rawhide repsitory of Fedora. to get the build working, I have create the following patch: diff -up blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp.py32 blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp - --- blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp.py32 2011-01-16 22:44:18.70680 +0100 +++ blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp 2011-01-16 22:44:54.668810004 +0100 @@ -408,7 +408,7 @@ void SCA_PythonController::Trigger(SCA_L */ excdict= PyDict_Copy(m_pythondictionary); - - resultobj = PyEval_EvalCode((PyCodeObject*)m_bytecode, excdict, excdict); + resultobj = PyEval_EvalCode((PyObject*)m_bytecode, excdict, excdict); /* PyRun_SimpleString(m_scriptText.Ptr()); */ break; Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAk01/rUACgkQZLAIBz9lVu8zewQAqTk3PDjcwgRNd0b8Ms8HtN1a KiKBVm9XI6c/R2FUNHTkeyntYvJOgUCEGAGNmsyZQOEWLq8u44hbaxo8aDqt6Kj8 oF8HgHv/Pxvqv3yktyahDxi7oGAxsBGv/eYMMgeRJaHPiMZUYikO/g79+qc8yTXw uRo8KzUugr5y5DSHoK8= =IEtB -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Patch]Fix issue to build blender-2.56 with python-3.2 Beta 2
Needed to made a few other changes for 3.2 support, committed r34392. On Tue, Jan 18, 2011 at 8:57 PM, Jochen Schmitt joc...@herr-schmitt.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, I have tried to build blender-2.56 agains the Beta 2 of python-3.2 which you may find in the rawhide repsitory of Fedora. to get the build working, I have create the following patch: diff -up blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp.py32 blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp - --- blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp.py32 2011-01-16 22:44:18.70680 +0100 +++ blender-2.56-beta-source/source/gameengine/GameLogic/SCA_PythonController.cpp 2011-01-16 22:44:54.668810004 +0100 @@ -408,7 +408,7 @@ void SCA_PythonController::Trigger(SCA_L */ excdict= PyDict_Copy(m_pythondictionary); - - resultobj = PyEval_EvalCode((PyCodeObject*)m_bytecode, excdict, excdict); + resultobj = PyEval_EvalCode((PyObject*)m_bytecode, excdict, excdict); /* PyRun_SimpleString(m_scriptText.Ptr()); */ break; Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAk01/rUACgkQZLAIBz9lVu8zewQAqTk3PDjcwgRNd0b8Ms8HtN1a KiKBVm9XI6c/R2FUNHTkeyntYvJOgUCEGAGNmsyZQOEWLq8u44hbaxo8aDqt6Kj8 oF8HgHv/Pxvqv3yktyahDxi7oGAxsBGv/eYMMgeRJaHPiMZUYikO/g79+qc8yTXw uRo8KzUugr5y5DSHoK8= =IEtB -END PGP SIGNATURE- ___ 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] Makefile support
Hi, t...@blender.org (2011-01-16 at 1951.57 +0100): I already gave up on Makefiles for OSX a month ago or so... it was giving me inpredictable instable builds, and trying to figure out why I gave up after a day. When new functions are added or old dropped, it does not detect all the dependencies and you have to do a full build, instead of a quicky one. Or so it seems. It seems to me it's still used by a couple of people here. I'd like to know if there's - apart from personal taste - there's important reasons to keep supporting it? The system is close to collapse under its own weight, seems to me. :) Here it keeps going. I would ask people in Irix or similar, if they really need it or we can move to cmake. It could also mean dropping scons and just get one single build system, finally. Let me confirm that switching to CMake was painless and quick and it builds faster than ever. I'm not totally happy with the noisy colorful prints of cmake, but I'm quite sure that's a matter of time to get solved too. You can disable colour, even if by just tricking it into a pipe like | grep --line-buffered '' or with the right parameter/option. OTOH, if you want to use | less -R you lose colours without option to keep them (the -R would show them). Nevermind cmake colours are mostly per line, instead of useful syntax highlighting (important words, not full blocks of the same colour). It even lies and adds useless lines (now that we are talking about its output), saying it has built something when in reality it did not because the targets was up to date. Obviously; if we remove makefiles from svn, it'll allow in source builds for cmake. cmake documentation recommends against that, some things depend on out of tree builds, maybe Blender does not use them now, but could and then you have to go back to out of source. Better not depend on it. Anyway, commiting the result would not work (full paths are not portable), and out of tree has other adventages, like tools not wasting time with meaningless files or being able to clean for sure. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Blender OpenCL compositor
thx for answering to my blog post via your proposal, to answer some of your questions there : *expression py* - only because it is User/Artist oriented. While python is great for doing this kind of stuff and pretty popular to most people, I'm not so sure about openCL language. by the way this is not a way to make new node, it is just a node which can control some parameter or datas in your comp. Look at what is done with Expression in AE : http://www.videocopilot.net/basic/tutorials/09.Expressions/ I don't think it does need OCL power to do this kind of thing. Probably more for the Nuke kind of Expression node because it can be do some pixel processing, but then it is just a wrapper ? Maybe on a programmer stand point of view it needs to be openCL or whatever... maybe not for the front end user. IMO this needs to be consistent with the rest of the scripting language in Blender. Again production tool :) *custom passes* are not mask, they are just render passes (normal, P pass, vector pass... ), but more on a 3d render side rather than the compositor. *masks* if you refer to the Addon RotoBezier, then yes it is still to be done IMO. this should be a native tool with all the features that comes with. Probably a new node any way. As I said RotoBezier is a great work around in the mean time, but not a production tool at all. *openFX* please pretty please :D F 2011/1/16 Erwin Coumans erwin.coum...@gmail.com Bullet uses its own MiniCL fallback, it requires no external references, the main issue is that it is not a full OpenCL implementation (no barriers yet etc). We developed MiniCL primarily for debugging and secondary to run the Bullet OpenCL kernels on platforms that lack an OpenCL implementation. The Intel and AMD OpenCL drivers for CPU perform similar to regular multi threaded code (pthreads, openpm etc) but it is more suitable for data parallel problems and not for complex code with many branches. So while you can port a compositor or cloth simulation to OpenCL, most general purpose code requires large refactoring and simplification causing reduced quality, so don't expect miracles. Still, it will be fun to see compositing, physics simulation etc in Blender being accelerated through OpenCL, optionally. Thanks, Erwin On Jan 16, 2011, at 5:34 AM, Jeroen Bakker j.bak...@atmind.nl wrote: On 01/15/2011 03:55 PM, (Ry)akiotakis (An)tonis wrote: On 15 January 2011 09:19, Matt Ebbm...@mke3.net wrote: While I can believe that there will be dedicated online farms set up for this sort of thing I was more referring to farms in animation studios, most of which are not designed around GPU power - now, and nor probably for a while in the future. Even imagining if in the future blender uses openCL heavily, if a studio has not designed a farm specifically for blender (which is quite rare), CPU performance will continue to be very important. I'm curious how openCL translates to CPU multiprocessing performance, especially in comparison with using something like blender's existing pthread wrapper. cheers, Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers I have to disagree on that. Almost every 'serious' user today has an OpenCL capable GPU and they can benefit from an OpenCL implementation. Besides OpenCL allows for utilization of both CPU and GPU at the same time. It's not as if it sets a restriction on CPUs. In my understanding the issue is that internal renderfarms have no 'OpenCL' capable GPU (yet). It is not an issue on the user side. Like during durian, we have workstations with medium gpu's and only cpu based renderfarm. The question is how would a cpu-based renderfarm benefit from opencl? Users on the otherhand have different issues. Our user population also have non OpenCL capable hardware/OS's. therefore we still need a full CPU-based fallback or the bulletsolution by implementing an own opencl driver. The bullet solution is complicated in our situation as it needs a lot of external references (compilers, linkers, loaders etc) Jeroen ___ 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
Re: [Bf-committers] Proposal: Blender OpenCL compositor
I would just like to chime in on this proposal with my personal experience developing in OpenCL for use in the Blender Game Engine. As has been pointed out, not everything can be sped up with OpenCL, and because it supports multiple device architectures, a code optimized for the GPU won't run fast on the CPU. Then there is the question of user's having the hardware to even run it, necessitating a CPU only fall-back. With all these factors one might ask, is it worth it? I personally think it is very well worth it, especially if it is viewed as an optional accelerator rather than wholesale algorithm replacement. The speed benefits for the highly parallelizable problems already mentioned such as compositing/filters as well as physics such as particle systems (plug: http://enja.org/2010/12/16/particles-in-bge-fluids-in-real-time-with-opencl/ ) are very convincing. There is a lot of research going into GPU computing for CG applications, and NVIDIA is pushing CUDA hard. While Blender won't adopt a proprietary solution such as CUDA, many of the algorithms and techniques developed for it can be translated to OpenCL. I'm excited about this proposal not because I want faster compositing, but because it sets up a framework for dealing with OpenCL in a sane way inside Blender. I'm currently developing my library standalone and linking it to Blender, using my own OpenCL wrappers around the Khronos ones. As I learn more about the Blender codebase, as well as look to Bullet I am dismayed by my own code's fragility. Sure it runs fast on the machines I've tested but I do not trust it to be in a consumer facing application for a while. As a student and a researcher I'm compelled to spend most of my time developing the algorithm and as much as I'd like to integrate my code cleanly it will be a while before that can happen. This proposal would give me as a developer a better platform for contributing directly to Blender, as well as a central location for me to put any effort into standardizing an OpenCL interface based on my experience with it. Furthermore, as other developers start to accelerate their code we will need a solid way of managing device resources and avoid redundant or competing memory transfers. With the new architectures coming out, the prevalence of capable GPUs and the increasingly sophisticated algorithms available I think OpenCL is going to be essential. I'd like to throw what little weight I have behind this proposal along with my 2 cents :) Ian Hi all, The last few months I have worked hard on a the proposal of the OpenCL based compositor. Currently the proposal is ready that it is clear how the solution should work and what the impact is. As the proposal is on the technical level the end-user won't feel a difference, except for a fast tile based compositor system. In functionality it should be the same. There are 2 aspects that will be solved: * Tiled based compositing * OpenCL compositing To implement these I will introduce additional components: * Tiled based memory manager * Node (pre-)compiler * Configurable automatically data conversion for compositor node systems * OpenCL driver manager * OpenCL configuration screen * Some debug information: * OpenCL program, performance etc. * Execution tree (including data types, resolution and kernelgrouping) * Visualizing tiles needed for calculation of an area. And introduce several new data types * Kernels and KernelGroup * Camera data type * Various color data types I have put all the documents on a project-website for review. As the proposal is quite long and complex. (all decisions are connected with each other.) Please use bf-committers or #blendercoders to discuss the proposal also if something is not clear. http://ocl.atmind.nl/doku.php?id=design:proposal:compositor-redesign Cheers, Jeroen Bakker -- Ian Johnson http://enja.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
