btw, you confirm that Expression PY & Python Pixelizer are two different thing right ? by Expression PY, I meant behing able to type some python for each parameter. (I don't have any UI design for that, but it could be something like : right click on a param > click on Set Expression > a textfield popup to type the expression > click OK > the param goes to red color to show it is control by an expression)
while a Python pixelizer as I understand it is more like a pixel processing node (like the Expression Node in Nuke) which could be coded via Py (which can call ocl, glsl, c, ... functions) ? And I understand this is not a performance processing approach, but as in a production & artist side... not everyone can have time or capabilities to create a new node/filter in C and recompile the entire blender while sometimes an simple equation could just be type and get the results. I think that for a list of missing nodes or nodes to get rid of it, Sebastian & Pablo should join the talk :) Thx François, 2011/1/19 Jeroen Bakker <j.bak...@atmind.nl> > Hi Francois! > > well... my answer is still in a very early draft :). Today I took the > time to dive into your posting in detail. I missed some parts when I > read it first. > > Expression PY and Python pixelizer is do-able. I just need to include > this in the proposal. I really see the value of having this. In my > perception this is on all settings of a node (in Nuke I thought it was > in a different node. perhaps we can borrow this idea from them.) also a > Python based pixelizer can be done. but can have some limitation in > performance. But that is to the artist to decide. > > On OpenFX I still haven't looked into the details. Currently I think > that the bottleneck of implementing this is more on the Blender UI. As > OpenFX has plugin capabilities the UI should be capable of handling > flexible node settings etc based on your installed plugins. And also the > reading and writing to a blend file is not that flexible (yet). I will > spend some time next month in this subject. Also an issue is that it is > Windows only. They state that a port is in the planning to Linux. > > Also what I personally miss is to really be able to twitch the internals > of a node. In October I have, with the knowledge of Ton, reverse > engineered the defocus node and came to a conclusion that it was > implemented differently than we initially thought. Also when reading how > many 'feature request' on this node is are placed in the bug-tracker and > the complexity of the node there should me more options on the node to > finetune the usage. This way nodes can become more generally usable. The > main settings could be altered on the node, but the detailed settings > can be altered in a panel (the N-key in the compositor). There is more > place and will be more dynamic as it is python based. > > A different thing I want to change in the proposal is the current > connector types. Currently they are buffers of 1, 2, 3 or 4 float > values, representing Value, Vector and Color. The node system is > flexible, but simple tasks can become a spaghetti of lines. I think that > when we put all data of a single pixel in a single type. When connecting > a rendered layer to the vector-blur node for example, will be one line, > containing all needed data. Tweaking of the vectors can be done by > settings, or by an expression node. This way we can reduce the number of > links and make the node system easier to use. Perhaps we will introduce > some limitations, but they can be tweaked. The node system will be > cleaner (in functionality and usage). Also color model should be > included in this data type. > > My question back is in this kind of situation, what nodes do we expect, > and what nodes shall not be used anymore. > > I really like this discussion. It will take the proposal to the next level! > > Jeroen. > > On 01/19/2011 12:30 AM, François T. wrote: > > 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 Ebb<m...@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 > >> > > > > > > > -- > > Met vriendelijke groet, > > Jeroen Bakker > > *At Mind BV > * > > Telefoon: 06 50 611 262 > E-mail: j.bak...@atmind.nl <mailto:j.bak...@atmind.nl> > > > _______________________________________________ > 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