[Bf-committers] list veiw vs outliner functionality
Hello, I just saw one of the feature videos for 2.74. Listview was extended in particles properties to enable toggles for view and render. list view also got a lot of other features recently, like alphabetical sorting, searching e.t.c. While this kind of features are of course very usefull and everybody is gratefull for them, because artists do really need them, there is something behind this patch that made me worried about the design part of it. The new toggles are there basically so that the user doesn't have to switch to modifiers to switch off the particles. As with the other features mentioned, the newly added features basically duplicate outliner functionality. It's something list view was since the beginning - a small outliner inside the property window. So the question is, why isn't all this functionality inside the outliner window? Something where you could see modifers, various vertex/edge groups,particle systems e.t.c. directly inside the outliner. Then, the space of the UI would be more optimally used, and there would be no need for such workarounds. Kind regards Vilem N. developer of Blender CAM ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle polygonizer
Hello, this is I think the newest implementation - a plugin with a .dll The person wanted to go on integrating this when OpenVDB stuff gets into blender, And there is a steady communication in the thread. Maybe you could join efforts... http://blenderartists.org/forum/showthread.php?284678-MSMesherhighlight= msmesher from artist point of view, this is a very much missing feature in blender, since the SPH fluids simply cannot be rendered, and the volume-based fluids with domain are usually too heavy to achieve reasonable results with splashes e.t.c. Also, this could possibly replace metaballs, which are very slow currently... Regards VIlem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Do drivers have to be blocked as python scripts?
brYes, that would be one way to do it. Perhaps a render appliance. Well this has some disadvantages, first, larger memory consumption, second,br this is possible if you set up your own renderfarm. If you set up your own renderfarm, then you don'tbrneed to worry about security from your own files. brThis was about projects like Sheep-it, Burp, renderfarm.fi, and then about all sorts of commercial renderfarms around the world, brwhich mostly also offer blender rendering, but probably all with default blender settings.brbrBut this all seems to me like restarting the discussion, which allready came to some conclusions.brbr On Thu, Jun 5, 2014 at 12:29 AM, Daniel Salazar - patazstudio.com a href='http://lists.blender.org/mailman/listinfo/bf-committers'zanqdo at gmail.com/a wrote: i That sounds like a VM to me? /ii Daniel Salazar /ii patazstudio.com /ii /ii /ii On Thu, Jun 5, 2014 at 1:07 AM, Dahlia Trimble a href='http://lists.blender.org/mailman/listinfo/bf-committers'dahliatrimble at gmail.com/a /ii wrote: /ii Rather than trying to sandbox python or limit functionality, why not just /ii sandbox the environment blender is running in? One could set up a render /ii server which clones a previously set up user with all the necessary /ii software installed in the user's path and setroot it so it can't touch /ii anything outside of it's home directory. Any render scripts could do /ii whatever they want and when finished, the user could be archived or /ii deleted. No need to worry about any malicious scripts because if they /ii mess /ii anything up it would only be in the temporary user's space and it would /ii be /ii deleted once the job is finished. /ii /ii /ii On Wed, Jun 4, 2014 at 11:17 PM, Daniel Salazar - patazstudio.com /ii a href='http://lists.blender.org/mailman/listinfo/bf-committers'zanqdo at gmail.com/a wrote: /ii /ii In my experience non techy people will happily ignore the little /ii warning we have (happens over and over to my clients and coworkers). I /ii propose making a blocking popup like this: /ii /ii This file contains drivers and python scripts that have been disabled /ii for security reasons. /ii /ii * Continue with disabled drivers and scripts /ii * Reload with enabled drivers and scripts (trusted sources only) /ii * Always open files with enabled drivers and scripts (trusted sources /ii only) /ii /ii This will make it easier for people to understand what's happening and /ii ensure it can't be ignored. /ii /ii Daniel Salazar /ii patazstudio.com /ii ___ /ii Bf-committers mailing list /ii a href='http://lists.blender.org/mailman/listinfo/bf-committers'Bf-committers at blender.org/a /ii a href='http://lists.blender.org/mailman/listinfo/bf-committers'http://lists.blender.org/mailman/listinfo/bf-committers/a /ii /ii ___ /ii Bf-committers mailing list /ii a href='http://lists.blender.org/mailman/listinfo/bf-committers'Bf-committers at blender.org/a /ii a href='http://lists.blender.org/mailman/listinfo/bf-committers'http://lists.blender.org/mailman/listinfo/bf-committers/a /ii ___ /ii Bf-committers mailing list/i ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Do drivers have to be blocked as python scripts?
As an outcome of the discussion, I added a point in the wiki TODO, section render: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Render Don't render and warn when a driver or pre-render script can't be executed, a texture is missing, physics are not baked. Needed e.g. when renderfarms have scripts blocked. I am not sure how the wiki todo is handled, if anybody actually reads it and works on the topics. With the Phabricator system, not sure if I should-could add some TODO task there. Regards Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Do drivers have to be blocked as python scripts?
If I understand the outcome of this discussion right: Sandboxing of python in general isn't functional and is too complicated. After reading all of the possible solutions, there are 2 which I seem to be reasonable: 1.Do not render when some drivers in the scene/linked data can not be executed. (wow, how much of my time would that save...) 2.do a primitive, very restrictive check of the expressions(vars, operators, math funcs.) This could accompany a warning, that would show when the expression doesn't make it through this check - 'Driver won't execute with scripts disabled' - this would display even when scripts ARE enabled, because of the case of sending files to renderfarms or sharing them in any other way. I really expect this to be quite rare.. Any of these 2 solutions would be satisfactory in production , I think... Not to fill the mail list with a long discussion, can I add this as a TODO topic somewhere in the wiki? By the reaction, I assume this is a topic that really needs some solution... Regards Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Do drivers have to be blocked as python scripts?
Hello, I realize how important is the security when .blend files are distributed, but I thought, is there a way to exclude drivers from the relatively new strict blocking mechanism? To me as animator, it caused allready many problems. Last is ruining several days of rendertime on a renderfarm which has scripts blocked(as is by default!). Actually, it happened to me allready several times- setting up renders, render nodes, and forgetting about some drivers and the new feature. I realized so far none of the crowd-render farms for blender don't support scripts on (sheepit, burp). That it of course a logical choice. So the idea is - can there be some check to determine if a driver is actually a python script? If it's using any commands, and not only numerical / logical operators? And then, could such simple drivers be enabled? It would really save my life very often. Now I have to write a script that bakes all drivers before sending file to render farm... Regards Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Do drivers have to be blocked as python scripts?
thanks for the reactions. From the proposed solution I think that most sane solution would be some limitation for the one-line expressions, assumably all of those which Joshua proposed. Maybe there is a simple way to put all these limitations into a simple string-checking operation, just check if expression does not have: anything else but driver vars, operators, math functions(this might be the complex part, to define what should be included in this.)... I mean- rather check if there's what is allowed, then you don't have to care what all should be forbidden, because that is everything else... Of course, this can again lead to similar situation - an artist does something not allowed, he is again stuck with not knowing what is wrong (e.g. on the renderfarm), but I assume it would be much less cases. I cannot currently imagine creative cases which would end like this. Regards Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developers meeting, April 20, 2014
Just a note to project list: http://wiki.blender.org/index.php/Dev:Doc/Projects Pie menus is allready several releases as a this or next release target. Fast search through the svn shows no commits to this project in several months, is it a real target for 2.72? Regards, Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Edge/Face groups proposal
Hello, my appologies, the link was broken in the email. I converted the proposal for the wiki: http://wiki.blender.org/index.php/Face/Edge_groups_proposal so it can also be edited by others. Regards Vilem. -- Původní zpráva -- Od: Vilem Novak pildano...@post.cz Komu: bf-committers@blender.org Datum: 6. 4. 2014 9:34:11 Předmět: Edge/Face groups proposal Hello, I wrote down a little proposal for edge and face groups. I was surprised to not find anything about this topic in the wiki, and also not in the GSOC ideas page. It is now here as a google docs document, can I place it somewhere in the wiki? https://docs.google.com/document/d/11JJjrgp-KXSs7S59502K3KnTO2sGElo1RT3gGDBr 49s/pub (https://docs.google.com/document/d/11JJjrgp-KXSs7S59502K3KnTO2sGElo1RT3gGDBr49s/pub) What are the opinions of the core coders, could this be on a todo/ideas list for the future? Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Edge/Face groups proposal
Hello, I wrote down a little proposal for edge and face groups. I was surprised to not find anything about this topic in the wiki, and also not in the GSOC ideas page. It is now here as a google docs document, can I place it somewhere in the wiki? https://docs.google.com/document/d/11JJjrgp-KXSs7S59502K3KnTO2sGElo1RT3gGDBr 49s/pub (https://docs.google.com/document/d/11JJjrgp-KXSs7S59502K3KnTO2sGElo1RT3gGDBr49s/pub) What are the opinions of the core coders, could this be on a todo/ideas list for the future? Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer meeting notes, February 9, 2014
Hello, regarding proxies, it would also be nice if they would work based rather on hierarchy, than on a group of linked objects.(not as group as blender type, these work different when linked?) Imagine you add some object to a character, or split some in two, this makes the scenes where this character is linked outdated, since these don't relink the new objects? Usually, it's a good way of organizing a character, to have everything eihter paranted to armature object, or to some root empty. Also, linking with all children would be in this respect a very usefull feature, sometimes selecting all the objects needed can be complicated, while this way, only the root object would be linked to get whole character. Regards V. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Addressing Vertical Tab Concerns - Followup
span style='font-family: helvetica, arial, sans-serif;'you wrote:/span span style='font-family: helvetica, arial, sans-serif;'I could only find this page, about horizontal tabs:/spanbr a href='http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/UI/December_2010_-_Vilem_Novak'http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/UI/December_2010_-_Vilem_Novak/a I understand you can't read everything, but this proves you didn't read the proposal. There is a section about tool access in this proposal, with several other ideas. I really should have done a video. Maybe then I can explain the simple math of multiplying the number of tabs that will potentially fit with the number of tools each tab can access, and compare it to the number of tools that are in blender and should be available through a subspace called toolbar. A simple calculation: Ospan style='font-family: helvetica, arial, sans-serif;'n full HD screen, with timeline visible at bottom, and last operator area on a reasonable size:/span 10 tabs * 20 buttons= 200. It's not bad, it's much better than it was! And really thanks for that. 20 menus with up to 32-40 options = 640-800 -that would be a bit better in my opinion. prespan style='font-family: helvetica, arial, sans-serif;'both of these solutions require a 2 click access to any of the available tools and approximately same travel path of mouse. With menus, you save the extra space on the left. Regarding muscle memory, they are approximately the same, but tabs have uneven size. If you happen to resize your window, you start scrolling with tabs much sooner(again), which is much heavier than clicking regarding time if you measure it. It's a very rough estimate. /spanbr prea fast script loop over all operators in blender counts 1563 operators, of course, a fraction only are tools, but some operators are in the ui more times(with different options on call). So, really, I think tabs are a good improvement, as I allready wrote, and big thanks for those, I just think they are not the best solution. br The fact nothing happened with the idea is just because it's not an idea everyone immediately thought of brilliant, let's do it, it solves all issues. I think we can do better. :) I sincerely hope so, for many years allready :) Vilem -- Původní zpráva -- Od: Vilem Novak pildano...@post.cz Datum: 10. 2. 2014 Předmět: Addressing Vertical Tab Concerns - Followup Ok, there was a bit of misunderstanding from my side. this is from email in this list from JW with a topic called Addressing Vertical Tab Concerns: I have updated my original wiki proposal with a section on *Addressing Tab Concerns: * a href='http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface#UI_Proposal:_Tabbed_Interface_for_Screen_Layouts_and_Toolbar'http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface#UI_Proposal:_Tabbed_Interface_for_Screen_Layouts_and_Toolbar/a If you have any other concerns I'll be happy to do my best to answer them and add them to the wiki. I understood it that way that the place to discuss this is actually on the wiki. So I wrote my part there. I didn't enter the other discussions. Regarding 'giving it a rest' - that is what I did 3-4 years ago. That's approximately the last time I spent loads of my time thinking and writing down ideas in proposals for the UI. When I realised nobody is actually reading this stuff, I really gave it a break, not wanting to waste more of my time. I now use this developer time to develop addons for blender, currently without any connection with the foundation. That's also why I didn't search for any other place where the discussion is actually happening and didn't know about it, I mostly only read mailing lists. I didn't suggest BF should have more money or people for this, there are allready people perfectly capable of doing such work, but new features often seem to be of higher priority. I considered this as an opportunity to step a bit into the discussion after a long time,and of course if there would be actually any reaction, I would react and continue drafting things , that's what I consider helping regarding design of UI. Regards Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Addressing Vertical Tab Concerns - Followup
Sorry, sent mail accidentally with html, sending again without: you wrote: I could only find this page, about horizontal tabs: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/UI/December_2010_-_Vilem_Novak I understand you can't read everything, but this proves you didn't read the proposal. There is a section about tool access in this proposal, with several other ideas. I really should have done a video. Maybe then I can explain the simple math of multiplying the number of tabs that will potentially fit with the number of tools each tab can access, and compare it to the number of tools that are in blender and should be available through a subspace called toolbar. A simple calculation: On full HD screen, with timeline visible at bottom, and last operator area on a reasonable size: 10 tabs * 20 buttons= 200. It's not bad, it's much better than it was! And really thanks for that. 20 menus with up to 32-40 options = 640-800 -that would be a bit better in my opinion. both of these solutions require a 2 click access to any of the available tools and approximately same travel path of mouse. With menus, you save the extra space on the left. Regarding muscle memory, they are approximately the same, but tabs have uneven size. If you happen to resize your window, you start scrolling with tabs much sooner(again), which is much heavier than clicking regarding time if you measure it. It's a very rough estimate. a fast script loop over all operators in blender counts 1563 operators, of course, a fraction only are tools, but some operators are in the ui more times(with different options on call).So, really, I think tabs are a good improvement, as I allready wrote, and big thanks for those, I just think they are not the best solution. The fact nothing happened with the idea is just because it's not an idea everyone immediately thought of brilliant, let's do it, it solves all issues. I think we can do better. :) I sincerely hope so, for many years allready :) Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Addressing Vertical Tab Concerns - Followup
Ok, there was a bit of misunderstanding from my side. this is from email in this list from JW with a topic called Addressing Vertical Tab Concerns: I have updated my original wiki proposal with a section on *Addressing Tab Concerns: * a href='http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface#UI_Proposal:_Tabbed_Interface_for_Screen_Layouts_and_Toolbar'http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface#UI_Proposal:_Tabbed_Interface_for_Screen_Layouts_and_Toolbar/a If you have any other concerns I'll be happy to do my best to answer them and add them to the wiki. I understood it that way that the place to discuss this is actually on the wiki. So I wrote my part there. I didn't enter the other discussions. Regarding 'giving it a rest' - that is what I did 3-4 years ago. That's approximately the last time I spent loads of my time thinking and writing down ideas in proposals for the UI. When I realised nobody is actually reading this stuff, I really gave it a break, not wanting to waste more of my time. I now use this developer time to develop addons for blender, currently without any connection with the foundation. That's also why I didn't search for any other place where the discussion is actually happening and didn't know about it, I mostly only read mailing lists. I didn't suggest BF should have more money or people for this, there are allready people perfectly capable of doing such work, but new features often seem to be of higher priority. I considered this as an opportunity to step a bit into the discussion after a long time,and of course if there would be actually any reaction, I would react and continue drafting things , that's what I consider helping regarding design of UI. Regards Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Addressing Vertical Tab Concerns
Hello, I added to the wiki page a link to old proposal regarding 2.5 UI. I did an carefull analysis which is still valid - I will be glad if you read it. I am very thankfull for any work which is done in the direction of solving the issues we have with the UI, however I think still there could be put efforts into really optimizing UI by making more serious decisions. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GSoC 2013 - Motion Tracking
As a new media artist, I can't resist to say something: new media artists and scientists need to find new ways how to use things and to experiment. For this, they rather need an api than an integration which you are speaking about... The point is, they allready have it. I have used blender many times in interactive art - with midi, various tracking and motion recognition systems. And doing things regarding communication on the blender side was almost always the easiest part of the work, and it never took more than a few hours to get connected to whatever device. You can use serial, network, simulate mouse... e.t.c. and I don't think you could make it easier, since the use is very different case by case. So, I think I would recommend you a different project for a whole summer... e.g. integrating Leap motion or something similar, if it has to be about hardware. But take this just as an opinion ;) Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender CAM initiative (as in CAD/CAM)
Hello, I wanted to point (possibly interested) developers to the Blender Computer Aided Machining - CAM addon. It has a homepage here: http://blendercam.blogspot.cz/p/blender-cam-description.html It's currently purely Python on the side of Blender, and is using numpy and Polygon python libraries. It took me several months of work to get to a phase where I use the addon in my personal artistic work for real machining. Of course, the addon is GPL. The reason for starting such initiative was that I didn't find any actually well working opensource 3d CAM software I am currently distributing the addon with Blender 2.64 builds - for the simple reason that the used libraries won't run with Python 3.3 yet, only 3.2, and I guess typical user won't be experienced with all the background stuff to be able to compile the libraries self - That's also a reason not to include the addon into blender repositories (yet), not to confuse users. If anybody would be interested in joinging the development, these are the tasks which would lead to increase in precision and performance, especially when done in C and possibly exposed to the Python addon: http://blendercam.blogspot.cz/p/todo.html And I am also looking for testers ;) cheers Vilem Novak ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] numpy integration followup
last remarks - yesterday I tried again with official blender release and official numpy builds on windows, and didn't suceed. here are some other user's trouble installing numpy: http://blenderartists.org/forum/showthread.php?246635-Import-numpy-again!- Mac-OS-X-10-6-8-Blender-2-62 for windows, I ended up digging the right numpy installation from an older blender build on my harddrive which was allready with numpy.It was a 2.63 build, so probably during the 2.63 phase numpy really was distributed with blender. In summary, it's really not easy for a common user to install matching python libraries which need building. So, the conclusion is, numpy can be quite hard to install for casual user, where only exception is linux. I just wanted to make this discussion complete, I understand if there isn't time for this. Cheers Vilem -- Původní zpráva -- Od: Vilem Novak pildano...@post.cz Datum: 21. 11. 2012 Předmět: numpy integration followup Well today I tested various builds on mac including official release build and buildbot build, where none had numpy in it. On windows I tested the same. I also tried to build numpy for mac with python 3.3 and 3.2, and both were unsuccessfull.(so on mac i didn't get it running at all...) On windows, installing numpy is a simple task, since it is really bundled quite comfortably. On ubuntu, its super-simple, as long as you have your machine connected to internet. If not, I cannot imagine how to do that - because you also cannot check if you have all the dependencies. The idea is not only that I as addon developer have to go through some trouble to get things running, also possible users of the addons using the lib have to do the same, where I can see this as a very discouraging moment for possible users. Blender has a full python in it, but to build numpy(on mac), you have to download install python, download numpy and try to build it. then you have to copy it and then you can uninstall python again, in the case you use it only in blender. - which probably most artists do. Cheers Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] numpy integration followup
Several months ago, there was a discussion on this list, where integrating numpy was agreed with. However, it obviously didn't happen, probably due to lack of time on the side of platform maintainers. I am now developing a CAM addon for blender, and numpy would really speed up a lot of computations and make life easy for many other interesting addons. I do not want to make an addon which would depend on many external libraries, for obvious reasons. I use myself several platforms on different computers and building same python library can be an uneasy task, especially without an internet connection in my studio(it's hard to believe, but yes, there are still computers/houses without internet out there...) That's why I wanted to ask if there's somebody who would be willing to proceed with the plan of numpy integration ...?please :) Thanks Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] numpy integration followup
Well today I tested various builds on mac including official release build and buildbot build, where none had numpy in it. On windows I tested the same. I also tried to build numpy for mac with python 3.3 and 3.2, and both were unsuccessfull.(so on mac i didn't get it running at all...) On windows, installing numpy is a simple task, since it is really bundled quite comfortably. On ubuntu, its super-simple, as long as you have your machine connected to internet. If not, I cannot imagine how to do that - because you also cannot check if you have all the dependencies. The idea is not only that I as addon developer have to go through some trouble to get things running, also possible users of the addons using the lib have to do the same, where I can see this as a very discouraging moment for possible users. Blender has a full python in it, but to build numpy(on mac), you have to download install python, download numpy and try to build it. then you have to copy it and then you can uninstall python again, in the case you use it only in blender. - which probably most artists do. Cheers Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
I would like to thank everybody who contributed to the discussion, there's clearly visible interest in improving the UI, and I consider good proposals for the UI a valuable work for the community. I apologize for not having really time until today to make myself a big picture, read all the mails in the thread and look into the proposals. Mindrones, thanks for taking up the task of ordering the ideas on the wiki, so much, and big thanks to Jorge Rodriguez! I've also made a proposal some time ago, which is located here: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/UI/December_2010_-_Vilem_Novak It proposes some solutions for tabs, scrollability, last operator area, sroll areas and a bit more. But I saw some very similar ideas are allready on the wikipage you started, which made me really happy. I really like the problem - possible solutions approach. Regarding UI decisions - I think there should be a board of advanced users who use blender everyday for production, who could be contacted by devs for specific questions on which solution of the problems to choose. Why advanced users? Optimal workflow is much more important than first impression and is what makes a long time effect on the size of real user community. If you have a good first impression but in a few weeks you discover how many things are hard to reach, it's much worse than overcoming initial confusion with the help of good tutorials and then feel the bliss of having your work done effectively and fast. Also, the need to compress things together surprises me, as if somebody still would think all the blender data can fit in the screen. - Of course it can, but then everything can look like the super awesome layers button. (I hope the sarkasm is clear here). This button, Toggles instead of checkboxes, columns, compressed buttons with 2 letters on them - that is still old blender style. And as history showed, squishing something together just doesn't solve the problem... So thanks, Vilem Novak ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] blender UI state
Hello, about a year ago I wanted to start a discussion about the UI of blender, also making some proposals. While the UI recode project brought some really nice changes, I was very surprised that the project somehow stopped somewhere in the middle. In between work has been done on issues like antialiasing and some minor details in the ui, while the big issues are largely ignored. So I would like to ask what are the reasons. Was there no more time or will to finish the UI project? Sincerely, I consider blender UI very cluttered and not much more effective on the user side. Of course, code - wise the changes are beautifull, allowing so much easier integration of scripts and a lot more. Issues I am talking about are mainly - no tabs, endless scrolling and inconsistent height of ui thanks to the folding of various panels and even changing the order of the panels(with tablet very easily accidental). last operator area and tool area conflicting - neither one has reasonable space, looks like a bad joke and forces you go fullscreen and back all the time. lots of stuff in the n-key areas, which basically replace and duplicate property window functionality. right-click menus and preset system are other of the todos of the project I remember... . Of course I appreciate the work of the coders and I see the constant improvement also in the UI area, just would like to start at least a little discussion about this. Cheers Vilem Novak ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Release targets for 2.62
I can confirm I have tested this and the impact is huge on ati cards. So if this could make it really in it would be great for some users. selection with the old code can take up to a minute if you are in complex scene(I always use outliner since some point), and with this patch the selection is just fine in such scenes. Původní zpráva Od: Antony Riakiotakis kal...@gmail.com Předmět: Re: [Bf-committers] Release targets for 2.62 Datum: 21.12.2011 17:10:40 Come to think of it I would also like to add the occlusion query based selection. It's not working with depth but it can solve selection issues for some users, even in its current state. Is it OK to add this in for this release? ___ 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] reactor particles
Hello, by doing some job, I just realized that reactor particles were removed. Is it one of the features which accidentally disappeared by the 2.5 merge, or were they removed intentionally? They had very usefull behaviour, so I am wandering why the removal happened. Cheers, Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Asking for help with patch conversion (bas-relief)
Hello,
I finally found some time today to try to set up a building environment today
on a work machine,
but didn't succeed in building the patch, I got similar bugs as Thomas did
(inline)
I just want to ask if somebody has maybe a build on a hard drive, since its
really taking me time and I wont likely be successfull with the building, since
I never built blender on windows and have no clue what the problems might be.
The patch from Campbell should be valid for revisions before 39941.
Thanks
Vilem
Původní zpráva
Od: Vilem Novak pildano...@post.cz
Předmět: Re: [Bf-committers] Asking for help with patch conversion
(bas-relief)
Datum: 28.8.2011 17:57:20
Hello,
just want to say thanks a lot to all who participated in this, I didn't expect
such a nice reaction... :)
I wasn't on internet for a week so I appologize for not reacting on the
e-mails.
Regarding the old patch, It did build well, but there probably is some bug
somewhere(maybe the one which Lucas fixed), since it crashed occasionally.
Are there any builds of the patch on graphicall?
thanks a lot
Vilem.
Původní zpráva
Od: Campbell Barton ideasma...@gmail.com
Předmět: Re: [Bf-committers] Asking for help with patch conversion
(bas-relief)
Datum: 25.8.2011 20:10:52
Somethings wrong if you have to apply manually, did you try my patch
on trunk? did it build ok?
http://codereview.appspot.com/download/issue4924046_1.diff
On Fri, Aug 26, 2011 at 3:42 AM, Peter K.H. Gragert
pkhgrag...@gmail.com wrote:
Oh. even more patches are not done ... have to do them Manually, it seems,
sorry
Greets
Peter
2011/8/25 Peter K.H. Gragert pkhgrag...@gmail.com
Hmm does not help ...
I think I have to understand where and how NodeBasReliefData should be
defined ... or found?
It is NOT in your patch?
Yes it is, but not done by tortoise SVN ?!!! now included myself ...
and a second not done too #define CMP_NODE_BASRELIEF 304
;-)
... waiting for compilation to finish ... finished ;-)
Now how to use ... WHERE is the bas_relief to be found ...
Peter
2011/8/25 Lukas Tönne lukas.toe...@googlemail.com
Try including the DNA_node_types.h directly. This should be included
by the CMP_util.h, don't know why this doesn't work for your compiler
(other node files do this the same way).
On Thu, Aug 25, 2011 at 2:51 PM, Peter K.H. Gragert
pkhgrag...@gmail.com wrote:
@Lukas
Your patch is not ok for mingw32-make and cmake
e.g.
C:\BlenderSVN\blender\source\blender\nodes\intern\CMP_nodes\CMP_basrelief.c:
In function 'node_composit_exec_basrelief':
C:\BlenderSVN\blender\source\blender\nodes\intern\CMP_nodes\CMP_basrelief.c:627:4:
error: 'NodeBasReliefData' undeclared (first use
in this function)
C:\BlenderSVN\blender\source\blender\nodes\intern\CMP_nodes\CMP_basrelief.c:627:4:
note: each undeclared identifier is reported only once for each
function
it
appears in
C:\BlenderSVN\blender\source\blender\nodes\intern\CMP_nodes\CMP_basrelief.c:627:23:
error: 'nbrd' undeclared (first use in this function)
C:\BlenderSVN\blender\source\blender\nodes\intern\CMP_nodes\CMP_basrelief.c:628:4:
error: ISO C90 forbids mixed declarations and code
Greets
Peter
2011/8/25 Lukas Tönne lukas.toe...@googlemail.com
Updated patch here (built against svn 39689):
http://www.pasteall.org/24281/diff
The node definition code has been changed to a set of initializer
functions instead of the previous struct initialization (so you only
have to init the parts you need).
Beside that i found a bug with the levels value, this was not
initialized before calculation. I added the levels=0 line for that,
not sure if that is correct though! It seems to work now, but i can't
get much detail in the final image from the z buffer. Let me know if
there are any further problems.
Cheers,
Lukas
On Wed, Aug 24, 2011 at 7:02 PM, Peter K.H. Gragert
pkhgrag...@gmail.com wrote:
Cambell, forgot to say thanks for the order of files in
CMakeList.txt
do
not
matter, sorry.
Peter
2011/8/24 Peter K.H. Gragert pkhgrag...@gmail.com
Hi can some confirm that the bas_relief worked in 2.49, meaning
that
the
advanced algorithm C-code does (in 2.49) good computations? Is
there a
patched Bl 2.49 available for me? Can anyone give me a link?
It is very much interesting to look at how to get it work in Bl
2.59
Biggest problem for me is at this momen NodeBasReliefData nowhere
defined,
I suspect that it could be (from the patch Thomas gave) that
bNodeType cmp_node_basrelief= { //loking like a bNode
has a wrong
[Bf-committers] Blender UI - Finished?
Hello, I would like to ask something and maybe initiate some discussion. I was wandering how is it possible that the UI project got frozen. Long time ago there was talk about tabbing. When tool and property areas were added, they were referred to as experimental. But, they were very soon full of different stuff, and now I e.g. noticed that in node editor development there is talk about making the property area wider to fit in node props and similar.(instead of displaying the node properties in -- property editor?) So, after looking forward for some kind of unification to property access, now I end up very often with my screen just full of property areas and have to call it a mess. Especially windows which tend to have something on both sides - like animation windows(channel names on left, props on right),or 3d view(tools, props, and the so much discriminated last operator area) / tend to end up as very narrow. Am I using it wrong or is this just unfinished ? Is scrolling and opening/closing panels so often considered efficient? Some time ago, I wrote a proposal to wiki, which tried to target these issues: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/UI/December_2010_-_Vilem_Novak I thought that when the proposal got ignored, that maybe some other solutions for these problems are planned, but since then, stable releases of the 2.5x series are out and there is silence about this area. Don't take me wrong please, as a python coder, I just have to love the amount of freedom the coder has now while making addons. I really like how far has blender changed code wise, and want to say a big thanks to everybody involved. Just as a user - I often feel some discomfort. Btw. as far as I had the possibility to test it, In cycles branch, the UI interaction is more satisfactory than in trunk. If you read that far, thank you. Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers IRC meeting minutes, 3 july 2011
Dynamic paint is really great, only thing I dont see for it is distance falloff for brushes or ability to paint with empties (but its still in development), and for some tasks it might be just too coplex - its similar to having the simple deform modifier compared to curve modifier. Many times I missed dynamic weight groups. and, I never used the simple deform modifier. Cheers Vilem Původní zpráva Od: Daniel Salazar - 3Developer.com zan...@gmail.com Předmět: Re: [Bf-committers] Blender developers IRC meeting minutes, 3 july 2011 Datum: 05.7.2011 20:27:22 Is there an actual usage example of why this is useful? specially now that dynamic paint has a *flexible* way to animate weightgroups. Dynamic Paint is generic, works with particle systems, custom shapes etc Daniel Salazar 3Developer.com On Tue, Jul 5, 2011 at 5:35 AM, Campbell Barton ideasma...@gmail.com wrote: - Campbell reviewed patch for Vertex Group modifier, needs to be split. An open issue still is whether it's good to accept such modifiers in general... or wait for recode with nodes. Discussed with Brecht, while these are nicer as nodes, we agree this is OK to go into blender. Left more detailed feedback in the tracker regarding the patch. http://projects.blender.org/tracker/index.php?func=detailaid=26108 ___ 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] 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-addonhighlight=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. francoistarl...@gmail.com 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 m...@mke3.net 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 aligor...@gmail.com 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. ---
Re: [Bf-committers] cycle todo list
Another question is, why not to take an OpenCL renderer which is allready quite usable and go on from it? there has been recently a new release of smalluxgpu renderer, and in the accompanying forum a wish for direct integration into blender was mentioned. http://www.luxrender.net/forum/viewtopic.php?f=34t=5987 for those who are not familiar with slg, here you can see the direct interaction between slg and blender in Livemode: http://www.youtube.com/watch?v=bSQoJW9ajmU note that this livemode isn't integrated and has to transport all data to the renderer. Smalluxgpu is based on Luxrays, a raytracing library supposed to work with OpenCL and CUDA, just that the CUDA backend wasn't started/used yet(as far as I know), because there was no need for it. SLG was allready tested on various hardware, and because it is OpenCL, you can also run it only on the processor, without GPGPU cards. Cheers, vilem Původní zpráva Od: Aurel W. aure...@gmail.com Předmět: Re: [Bf-committers] cycle todo list Datum: 29.4.2011 11:49:37 Hi, before taking this too much off the ground, wouldn't it be better to just stick to OpenCL right from the beginning? I think if this is too much tightened to CUDA from the beginning, we won't see an OpenCL port afterwards. I haven't looked at the architecture of cycles yet and to which degree it's implemented in CUDA, but when it is more, than just a simple raytracing core, as it's done now in luxrender, it would be painful to get OpenCL porting, after a lot of functionality is implemented. aurel On 28 April 2011 22:55, Dan Eicher d...@trollwerks.org wrote: Also... This boost-1.44 patch breaks the compile: https://svn.boost.org/trac/boost/changeset/62245/trunk/boost/detail/sp_typeinfo.hpp ___ 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] LibMV versus OpenCV / VXL
Hello, just few notes: libmv development started specifically for use in blender several years ago. I am not sure if the talk here is about use in compositor too, but libmv is as far as I know mainly targeted for robust camera motion matching. At the same time, it should be of course usable for various compositing tasks(point tracking, video stabilisation). I dont know about VXL, but OPENCV has far more than that(so new dep. size is bigger), while I don't remember seeing a good 3d reconstruction demo with it. Sincerely Vilem Původní zpráva Od: Troy Sobotka troy.sobo...@gmail.com Předmět: [Bf-committers] LibMV versus OpenCV / VXL Datum: 21.4.2011 07:38:55 Just read Tom M's posting on LibMV and was wondering where the discussions have taken place for it regarding future directions. Nuke apparently (according to the User Guide[1]) harnesses VXL for some of its algorithms. OpenCV, for example, has a simple relevant point optical flow tracking example (lkdemo.cpp 151 lines of code[2]) that would seem to at least be worth examining, if it hasn't already been considered.[3] I am wondering the upside benefit of pushing LibMV over existing options. Sincerely, TJS [1] http://thefoundry.s3.amazonaws.com/products/nuke/documentation/NukeUserGuide_6.1v5.pdf [2] https://code.ros.org/trac/opencv/browser/trunk/opencv/samples/cpp/lkdemo.cpp?rev=4240 [3] I am aware of Ton's reluctance to add another dependency, but perhaps the complexity of computing vision here warrants it? ___ 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] Fracture Tools don't work in Blender 2.57
My appologies for not replying to this, I am currently overwhelmed with many tasks, so I was postponing this. Thanks a lot for the fixes. Vilem Původní zpráva Od: Michael Williamson micha...@cowtoolsmedia.co.uk Předmět: Re: [Bf-committers] Fracture Tools don't work in Blender 2.57 Datum: 16.4.2011 11:54:03 I committed a fix for this just yesterday ;-) Cheers, Mike On 16/04/11 09:51, Markus Kasten wrote: Hello, The Fracture Tools don't work in the official Blender 2.57 release, caused by serval Python API changes. I created a patch and send it to the original author, but I still have no answer (send it about a week ago, probably the mail has been eaten by his spamfilter). Maybe somebody from the bf-committers mailing list can apply them to the subversion repository. I uploaded the fracture_ops.py patch here: http://www.pasteall.org/20738 and the edited data.blend with fixed Bomb- and Recorderscript here: http://www.pasteall.org/blend/6013 Greetings from Germany, Markus Kasten ___ 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] Geometry in Compositor or Quadrangulation???
Hi, I think the rasterizer would be really interesting, since it would also probably be based on opengl and much faster than re-rendering the scene? if a widget system could be implemented for 2d views(image editor, sequencer), it could be incredibly usefull, since curve-based matte editing could possibly happen in those views instead of 3d view and the workflow would be much more natural and expectable. This would be beneficial generally for parameter editing in node editing and sequencer. By widgets I mean basically curves/rectangles/lines/points in the views, something like this: http://www.pasteall.org/pic/show.php?id=10388 (from this addon work http://blenderartists.org/forum/showthread.php?185423-Stereo-Camera-Python-Script-for-Blender-2.5) As a long time user and occasional developer, I don't think quadranculation is such an essential feature, even in 3d coat where its done really well the results are relatively hard to tweak and some kind of advanced retopo system might be more powerful for production. Besides that, there are probably some of this years GSOC proposals going in this direction ? these are of course my personal preferences, but since you were asking... ;) Vilem Původní zpráva Od: pete larabell xgl.asyl...@gmail.com Předmět: [Bf-committers] Geometry in Compositor or Quadrangulation??? Datum: 10.4.2011 22:17:16 Hey all, I am planning on building a system (initial intent is for double edge matte comp. node) that will rasterize any 3d object in the scene into a 2d mask in the compositor. I know that is the entire purpose of ID Mask and render layers, but I'm specifically referring to the ability to rasterize the off-screen portions for the feathering/gradient calculations needs to correctly implement a double edged matte/mask. I am also going to implement the greedy mixed integer quadrangulator. Now, what I'd like to ask is: Given that it would probably not be best to try two additions at the same time... which one is is more desired in blender first? I suppose I should maybe be asking blender USERS rather than just coders, but oh well :) Is there one of these two that more people would like to see??? As a note: the reason I ask is simple; I know that more people *want* the quadrangulator, but the GMIQ will also take longer to implement than the object rasterizer. Anyway, I'd be interested to hear the thoughts of others before I get too deep into either one. Cheers! Peter ___ 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] Subtitles workflow in the sequencer
Hello, I wanted to ask if there are any ideas/plans for bringing a reasonable subtitle workflow into the sequencer internally. I am asking mainly because I started developing an addon for subtitles where this functionality is planned: User adds an subtitle strip, which is actually an image strip. A default subtitle template is rendered in background and added as this strip. User can change the template and edit the text, changes are rendered in background. additionally to this changing template of all subtitles in sequence editor, importing or exporting subtitles as .srt could be done. Advantage of this system would be easy adding of subtitle templates(just blender files with anything in them), usage of background computing. Any ideas to this will be welcome. Cheers Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New WeightVGroup Modifier
Regarding this topic, I just wanted to let you know that I consider this kind of modifier very valuable in many production cases. It would be possibly great if vertex groups could be more 'dynamic' generally, but this is a great step forward. cheers Vilem Původní zpráva Od: Bastien Montagne montagn...@wanadoo.fr Předmět: Re: [Bf-committers] New WeightVGroup Modifier Datum: 25.2.2011 14:31:07 As far as i could see and read it uses the distance to the origin of the target. Which is pretty fine for your Dynamic Subsurf task. But for only mesh weights, i would really appreciate if it could use the (shortest) distance to another mesh. That would give this modifier a whole lot more possible usages. (Something similar to bone heat weights) Correct! And yes, using the shortest distance to another mesh is a good idea – I think I’ll try to implement it next week, it shouldn’t be too hard :) Just for curiosity: Does it change the weights of the affected group permanent or on the fly? No, the change is on the fly (ie the original vg is not modified, the modifier does a CDDM_copy of the given derived mesh and modifies that copied data layer). So the change is only available for modifers below in the stack. Bastien ___ 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] Do you have think create the engine for xbox 360 and PS3 game development?
Actually you could look into gamekit - http://code.google.com/p/gamekit/ it's made by some blender developers and it's not so restrictive, so publishing should be possible with it once it's finished. Původní zpráva Od: iozk hz iozk...@gmail.com Předmět: [Bf-committers] Do you have think create the engine for xbox 360 and PS3 game development? Datum: 02.2.2011 05:50:22 I thinking about 'if blender game engine also works over xbox 360 and PS3 ' some know if blender will be adapt in a future? ___ 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] Proposal: Blender OpenCL compositor
I'd like to have 2 more questions: Where did go the idea of integrating gegl as the library driving compositor processing(originally 1 of durian targets?)? Btw, gegl just released a new version 0.1.4 Will it be harder to develop nodes for the tile based system than now? will it still be possible to write non-tile based nodes, or non-opencl nodes? Thanks Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Blender OpenCL compositor
Maybe an interesting comparison could be smalluxGPU, since it has both cpu only and cpu-opencl enabled, so you can compare performance on cpu with both ways with getting similar results, although in raytracing. Původní zpráva Od: Matt Ebb m...@mke3.net Předmět: Re: [Bf-committers] Proposal: Blender OpenCL compositor Datum: 15.1.2011 08:19:25 Thanks, Jeroen. On Sat, Jan 15, 2011 at 6:04 PM, Jeroen Bakker j.bak...@atmind.nl wrote: Farms are already being migrated to OpenCL farms. As they are cheaper in hardware costs. BTW. renderfarm.fi should be capable of running OpenCL as this is proposal is implemented! 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A proposal for further 2.5x UI evolution
I would like to ask people to comment on the wiki page, so that there can be some constructive development of ideas. I am not really sure how many people who responded to the topic are actually producing 3d animations with blender. I would also be glad if some experienced devs and designers of the new UI would comment, otherwise it's just waste of time. Thank you Vilem Původní zpráva Od: David Hutto smokefl...@gmail.com Předmět: Re: [Bf-committers] A proposal for further 2.5x UI evolution Datum: 17.12.2010 20:47:38 On Fri, Dec 17, 2010 at 1:44 PM, GSR gsr@infernal-iceberg.com wrote: Hi, pildano...@post.cz (2010-12-17 at 1244.27 +0100): But, you have to look, and you have to scroll. Remember that clicking is actually faster than looking, and in a good written ui, I don't have to look to see if my property is there. also as said, my proposal talks about outliner, which definitely needs more space. When you say look, do you mean search with click and scroll? Or just look with eyes? Because eyes are faster than clicking, as clicks require arm/hand precise motions (plus eyes too). I was thinking em readings from probes implanted directly into the brain. GSR ___ 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
[Bf-committers] A proposal for further 2.5x UI evolution
Hello, I put together a proposal for some further possible changes in the 2.5x UI. I think it doesn't go against blender UI paradigms, and hope it's quite the opposite. I tried to put things short, so it's not long, but I spent quite some time with it, after doing several projects with the 2.5 breed of blender and thinking what could be optimal solution for some aspects of the UI. You can find the proposal on this page in a .pdf on the wiki, I hope some comments will appear there: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/post_2.55_UI_proposal_/Vilem_Novak_/_Dec.2010 I hope that especially people who have designed and coded the 2.5 UI will look into it. Thanks for attention cheers Vilda Novak ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sequencer movie strips frame rate - bug or missing feature?
Well, I looked in the code and realized the frame rate is read and considered at least probably by ffmpeg reading, so I submitted a bug report, and would really like if the further discussion went on there(bug #24355). I also had the idea of making a python op which would solve this with the speed effect, the problem is, the strips frame rate is not exposed to the rna api, so the only solution would be to find the find the matching audio strip and match the lengths. This can be done, however it's quite a hack, don't you think? Especially if blender has most of the code needed for a proper handling of frame rates. I am not a hobbyist, so to say, I make my living with av art and producing animations etc., so there's no need to explain here the very basics of how video editing works and bringing the discussion to offtopic area. Of course that if you are producing a movie and are not stupid you keep your settings consistent through the whole process(unless you make a documentary, where you use different footages etc. ) If you say that professionals don't use frame rate conversions, then tell me how e.g. everyday news shot in ntsc are screened(and re-edited) in europe? Or how is it possible that tv's screen motion pictures shot at 24 fps? Or how the same movies are distributed on pal(ntsc) dvds?(or even better, videotapes :) ) Btw, animated textures have the same problem as in sequencer, so how do you apply an animated texture which you get at 12 fps when you are rendering in 25fps? Or how you export your 12fps animation for a dvd? Really, there are many cases where you convert frame rates also in professional use... Yes, you can make all of this with external conversion, for best results with retimer or some similar software, but that really makes your production time much higher. Greetings, VN Původní zpráva Od: Troy Sobotka troy.sobo...@gmail.com Předmět: Re: [Bf-committers] Sequencer movie strips frame rate - bug or missing feature? Datum: 22.10.2010 05:51:48 I think Roger summed it up best. Remember that in the vast bulk of professional and semi-professional / independent motion picture production you are shooting for a fixed target. All of your footage is consistent. In a conversion, we begin to get into countless complexities. Duplicate frames? Drop? Etc. And even then, the discussion doesn't even begin to engage colourspaces and other deeper questions. Optical flow is within the domain of post production visual effects, not editing per se. It would likely be cut with proxy footage and generated in the post production phase. The bottom line is that converting frame rates in a system that is by design perfectly frame accurate is likely adding complexity where it isn't likely warranted. ___ 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] Sequencer movie strips frame rate - bug or missing feature?
This is probably a misunderstanding. There was nothing about converting the footage in the post, please read carefully. There was talk about the footage being read with wrong framerate, depending on the output(!) frame rate of blender. Also, my experience with this is from e.g. Final Cut and Avid, which I do not consider hobby systems. (athough also premiere or vegas have this, or kdenlive, if we look in the opensource world). I was not refering to any other 3d application, since blender is as far as I know the only 3d application which has a full NLE video editing system included(and a pretty good one). :] Also, I didn't want this mailing list get flooded with feature requests - I am quite sure many users miss this functionality, but I also know blender is in feature freeze state, that's also why in the subject of this thread is the question whether I should consider it a bug and fill in a bug report. greetings, Vilem N. Původní zpráva Od: Troy Sobotka troy.sobo...@gmail.com Předmět: Re: [Bf-committers] Sequencer movie strips frame rate - bug or missing feature? Datum: 21.10.2010 03:09:37 By design. Only a hobby grade system will attempt to convert for you. In general, most will control their content and not rely on a single pipeline tool to prepare it for uptake. On Oct 20, 2010 8:19 AM, Vilem Novak pildano...@post.cz wrote: Hello, I want ask one question. If I load movie strips to sequencer, it synces audio with video correctly only when blender output frame rate is set to frame rate of the imported movie. This makes it very hard to work with different movie sources. It is strange that blender loads the audio with the correct length, but the strip length gets always adapted with a ratio 1 blender frame = 1 strip frame. also, after changing blender's frame rate the strip length doesn't change any more, so the strip must have it's frame rate stored internally? would it be possible to expose the frame rate of the strip, or even better, try to set up correct frame rate on load? This would be something like 'Interpret footage' feature in some editing softwares. greetings Vilem N. ___ 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
[Bf-committers] Sequencer movie strips frame rate - bug or missing feature?
Hello, I want ask one question. If I load movie strips to sequencer, it synces audio with video correctly only when blender output frame rate is set to frame rate of the imported movie. This makes it very hard to work with different movie sources. It is strange that blender loads the audio with the correct length, but the strip length gets always adapted with a ratio 1 blender frame = 1 strip frame. also, after changing blender's frame rate the strip length doesn't change any more, so the strip must have it's frame rate stored internally? would it be possible to expose the frame rate of the strip, or even better, try to set up correct frame rate on load? This would be something like 'Interpret footage' feature in some editing softwares. greetings Vilem N. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender and OpenCL
Hello, maybe focusing on performance - heavier nodes would make sense? Rather performance heavy in my experience can be quality blurs(especially defocus), UV remap, bilateral blur. With these the advantages would be visible even with the bus problems. With regards, Vilem Novak Původní zpráva Od: Jeroen Bakker j.bak...@atmind.nl Předmět: Re: [Bf-committers] Blender and OpenCL Datum: 29.8.2010 11:19:15 Hi Lukas, Your explanation is a good one. Didn't come up to write it down that way. The issue with memory during compositing is the way the nodes-editor works. When changing a node-value (like degree) only the rotate-node and all dependent nodes are re-calculated. The input-image is not re-calculated it is still in memory. This is a good optimization during editing time you only need to reevaluate a part of the node-system, but in complex node-systems I think this will not work for OpenCL due to the needed memory. I am looking for a situation what is good during editing (decrease the feedback-time to the end-user) and rendering (overall performance of the system). But haven't found a good solution. At the moment I am evaluating 2 things: a. per viewer and compositor node a opencl kernel/program will be generated and executed. b. per node a program and kernel is created. and evaluation is done as the current situation. A question back. Have you seen any speed-up? My system (three years old dual core 2...@2000mhz laptop with 1...@400mhz nvidia cores and a bus of 800Mhz) was not able to see big differences. I think that a desktop system with a faster Bus and more and powerful gpu cores would get much better performance. Regards, Jeroen On 08/28/2010 09:40 PM, Lukas Tönne wrote: I have tried out your patch, nice work :) Here are some more thoughts on how to process data in the node tree. I hope i'm not getting too verbose or tell you guys obvious stuff ;) Basically when talking about data in the tree i see two different types of dependency: 1. Inter-node dependency (vertical): A node can only be executed (be it for a single pixel or the whole image) when all it's inputs are done. This dependency _always_ exists in node trees to a certain degree. 2. Inter-element dependency (horizontal): An element (pixel, sample, particle, vertex, etc.) depends on the state of other elements (neighbouring pixels, particles in a certain radius, connected vertices). Vertical dependency does not depend on the tree type, but only on the connectivity of the nodes (complexity of the tree). Here's a made-up example with strong connectivity in the middle part: http://www.pasteall.org/pic/5405 Horizontal (inter-element dependency) on the other hand chiefly depends on the type of tree you're looking at: * Shader- and texture trees have _no_ horizontal dependency at all, the color of a material or texture sample does not depend on other samples. This is why shader trees can be evaluated per sample and do not need to store large amounts of data. * Compositor tree are the other extreme: while some nodes, such as Mix, operate per-pixel, others like Blur and Defocus heavily depend on neighbouring or even _all_ other pixels of the input images respectively. * Particles are not as extreme as compo trees (less neighbours to take into account), but they lack the inherent ordering of image pixels and need kd trees for finding neighbours. One relatively simple thing one could probably do to decrease memory usage is removing data that is not needed any more (I am not sure if the current compositors do something like this already, if so, just skip this section). As soon as all nodes, which use a certain socket for input, have been processed, that sockets data can be freed from memory. This of course only works as long as connectivity is relatively low and node relations are local. In the example above the result of the Blur node would have to be kept in memory until all the mix nodes are finished, whereas the initial renderlayer node could free its buffer right after Blur is done. It might even be an option to bite the bullet, if memory usage gets dangerously high, and discard intermediate results used very late in the tree and recalculate them later. Another improvement i currently use in the simulation trees is splitting the large data blocks into smaller parts (batches). This has the advantage of making better use of available processing power, especially when some nodes need significantly more time than others. In the compositor nodes one thread processes the full image for one node at a time, which can lead to threads idly waiting for the result of one other (iirc Brecht recently coded internal multithreading for the especially heavy Defocus node though). At the same time by staying with one node for a range
Re: [Bf-committers] Blender 2.5x beta status
If you are a real mac user, you use .dmg images very often, since it's the way most apps do it, so why should this be confusing? I guess I would rather be confused by a zip on mac. as said, it takes the same amount of clicks. So, my voice is for .dmg Původní zpráva Od: jmso...@free.fr Předmět: Re: [Bf-committers] Blender 2.5x beta status Datum: 14.7.2010 10:42:41 +1 for an uncomplicated .zip approach! jms ___ 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] Proposal to Remove Features
'Bounds draw types for objects' doesn't mean you won't be able to select bounds as drawtype for an object, it's a droplist where you can select if there are bounds drawn additively to the mesh, and there are several types to choose from(sphere, cylinder, cone, e.t.c. ). the option is quite uselessly displayed in the object draw options, but is of crucial importance in the game engine physics panel, and it's the same property(or 2 props linked?)! I didn't know that, and as a GE user, I am now definitely against the removal of such feature, but I guess in the ui it should go away from the draw options(the placement there probably is why brecht put it to the list).Instead, there could be a checkbox if to draw or not to draw. Původní zpráva Od: Daniel Salazar - 3Developer.com zan...@gmail.com Předmět: Re: [Bf-committers] Proposal to Remove Features Datum: 09.7.2010 09:58:31 Oh I didn't read about removing bounds draw type, this is the fastest draw type by far and it makes no sense removing it. It makes things possible that are otherwise impossible, specially with blender's ability to handle so many instances that would make the viewport impossibly slow in any other mode. Now I'm talking specifically about the *object* display type, not about the viewport display mode.. but I'm sure theres people that find that useful too. Also what is the reason this is unwanted? sticky coordinates is something I've HAD to use in the past (followed be a script to convert to UVs) because of project from view not working quite right if that's fixed then fine! About sticky coordinates, I have been able to use the UV project modifier without any kind of problem. I don't see the need for sticky coords to exist anymore! About particle billboards... again I use that for feathers on characters.. this would break my characters without possibility to fix it :s pretty *bad* regression. I don't mind redoing stuff at all, as long as there's a new and better way to do it. Daniel Salazar On Fri, Jul 9, 2010 at 1:36 AM, Michael Williamson micha...@cowtoolsmedia.co.uk wrote: /File browser should hide hidden files and filter types by default. Every file browser does this, and it just seems to be what you want nearly always anyway. Especially on mac/unix hidden files are really in the way in the home directory. / Yes please! could it filter more types? sticky coordinates is something I've HAD to use in the past (followed be a script to convert to UVs) because of project from view not working quite right if that's fixed then fine! * Controversial list: *I'm sure that I'm not alone, but here's the things on that list I have used (and so would miss) all edges option should be on if removed! it's crucial to be able to see all the edges rather than hiding them for game dev blend sky is useful for quick access as well as lighting... bounds draw type is something I use a lot for organising scenes for games worlds... shadow render pass seems like a bad thing to remove... particle line/path/billboard seems to have no alternative? I presume that if the cubic material interpolation option is removed it'll be switched on right? On 08/07/10 18:30, Brecht Van Lommel wrote: Hi, Here's a proposal to remove a number of features before 2.6. I've been gathering items on this list for the last few months as I came across them. If there is enough agreement I can make the changes quickly. If you agree or disagree with items on the list, please read the explanation at the top and comment on the wiki page. http://wiki.blender.org/index.php/Dev:2.5/RemoveFeaturesProposal Thanks, Brecht. ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bind Camera to markers
Mike, Where in the e-mail did I mention markers? :) actually, it's the opposite. I think this kind of animation shouldn't be bound to markers at all! I guess in this case markers were used instead of proper keyframes. What I suggested is to have animatable certain properties, in this case scene.camera, which would have as possible keyframe values all the camera objects(or their names). The closest thing to this also in 2.49 is animation of layers, since the keys are nothing which could be interpolated by any other curve than constant, which would be also in these cases(change meshes, cameras, text data, ...) I can imagine there could be a group which would define the possible set of keyframes for some property, e.g. group of meshes which would be intended to replace some thing. Which would possibly by the way enable another interesting feature, which is LOD Game engine has this feature for meshes for ages, as the replace mesh actuator. Hope this clears things up finally :) Původní zpráva Od: Mike Belanger mikejamesbelan...@gmail.com Předmět: Re: [Bf-committers] Bind Camera to markers Datum: 12.6.2010 01:01:11 Ok, so if I understand your proposal correctly, there should be a way to 'bind some kind of operator' to a Marker. Rather than having a python hack ( the current system ) there should be a hard-coded, more extensible system for markers. On 2010-06-11, at 2:36 AM, Vilem Novak wrote: Ok, this is a bit of a misunderstanding: Besides the original cameras topic we are talking about replacing some properties, so e.g. replacing a mesh, which would be a typical case if you e.g. simulate clay-based animation with replacement heads/mouths, since in such case you don't always want to do things from 1 shape and animate it as shapes. Another case is something I use quite often nowadays - conversion of greasepencil animation to real curves so it can be rendered. By 'animating text' I meant not animating of the object, but of the 'content' of such object, thus e.g. doing animation of somebody typing, or else. These things can allready be done, when you animate object layers or hiding. or if you make a set of object misplaced by e.g. 1000units, parent them all to an empty and then offset this empty. I used both of these methods. Hiding/Layers don't work currently well with the current system, since what is hidden, is also hidden in the dopesheet, so you can't actually move the keys (everything has to be scripted). The 'misplacement' method is not optimal because of it makes scene bounds huge, so you can't use the home key anymore, and probably during rendering with raytracing it can cause some serious performance hit. When we go back to the 'camera switching' topic, besides that the method is probably used by durian team, (which is a strong argument why something is userfull), it's a way close to classical film making - you don't run around with 1 camera, you shoot with several cameras and you make cuts.So, you can do it another way too, but if properly implemented, this is more intuitive. If I remember right, Motion builder has a tool called camera switcher as a separate thing, with it's own timeline. Hope this explains what I actually meant in the previous e-mail. Cheers Vilem Původní zpráva Od: Mike Belanger mikejamesbelan...@gmail.com Předmět: Re: [Bf-committers] Bind Camera to markers Datum: 11.6.2010 02:31:12 What kind of usage case scenario would that fill? The current animation system can animate text, do camera moves, and keyframe meshes. I'm unsure what you mean by uses in rigging. Markers are kind of neat, but IMO they're meant to remain simple. On 2010-06-10, at 12:08 PM, Vilem Novak wrote: If I remember it right, the commit was in the svn mailing list commented as a temporary hack. I would love some animation support for such properties, which are in the ui represented as the name of the datablock/string, since it could also be used not only to replace scene camera, but also replace meshes in some cases or to animate text. I can also imagine it could be used for some rigging cases. Not sure if this could be done through the animation system? Původní zpráva Od: Mike Belanger mikejamesbelan...@gmail.com Předmět: Re: [Bf-committers] Bind Camera to markers Datum: 10.6.2010 15:01:14 I honestly don't know either reevuedelibre. I just keyframe the camera, I don't see the point in learning a different tool just for camera moves. Also, you can use the NLA to keep track of shots : http://www.vimeo.com/5860167 On 2010-06-10, at 1:41 AM, revuedelibre . wrote: Hello, I recently discover that way to change
Re: [Bf-committers] Parallel Blender
Just a little opinion towards why and what to parallelize. I think what artists/animators would benefit from is faster/parallelized modifier evaluation, since that would speed up anim playback greatly. (I'm talking mostly about rig-specific modifiers like subsurf and armature). With the estimates of what num of cores artists will use in future - I recently bought an 8 core machine, and although it's a beast for rendering, I was generally disappointed with the performance in many apps. I realized that the best parallelized app is Z-brush(which I actually don't use for my work :) ). So I guess 4 cores will still dominate for some time still V. Původní zpráva Od: Benjamin Tolputt btolp...@internode.on.net Předmět: Re: [Bf-committers] Parallel Blender Datum: 11.5.2010 00:10:15 André Susano Pinto wrote: And btw whats the problem with python? And is there any compiled list of what needs to be improved and what current problems block it from being parallelized? Python has a Global Interpreter Lock (the infamous GIL) that prevents mutlitple threads from running Python bytecode at the same time in the same executable. You can run multiple executables (processes) with Python interpreting byte-code at the same time without problem, just not multiple simultaneous Python *threads* in the same executable. This really only affects the Python byte-code interpretation so, provided a majority of the execution is in native code outside the Python interpreter - this is not a big problem. However, for rigs needing to call drivers hundreds of times a second (or similar constraints) - this threading issue will become noticeable. ___ 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] Script Xtras (proposal)
I think this is a great idea, just some ideas: -somehow there should be resolved grouping of such scripts, so that more at once get loaded, could be solved with categorisation. -these groups would possibly have similar subdirectories like the main blender scripts - ops, io, ui,...(think big! :)) -possibly, when switching such group on, it could 'override' default ui, if ui scripts with same names are found. - Why? because if you think about special uses, you can soon think about customizing the ui which is common. Then you can specially tweak blender for any task imaginable, distribute such modifications with the main software(huge advantage against the 'find it on the forum' model), satisfy much more users,... I have personally thought about a special tweak of the ui for 2d animation, which would enable faster setup for 2.5d or pure 2d animations, and add some macro tools. WIth such organisation of the ui, this would be potentially distributable with blender.(did you notice how many 2d movies are done with blender?) cheers, Vilem Původní zpráva Od: Tom M letter...@gmail.com Předmět: Re: [Bf-committers] Script Xtras (proposal) Datum: 13.2.2010 20:09:04 On Sat, Feb 13, 2010 at 7:47 AM, Campbell Barton ideasma...@gmail.com wrote: One of the reasons I thaught of this is Colin was asking if the durian scripts we have would make it into blender. We added some scripts in a shared script dir, its interesting that mostly only 1-2 of the of the team members needs them, so for example Colin uses some utilities for camera naming, camera switch renders, camera rigs Cessen wrote. Soenka/JS/Ben have a script for scattering stones, Soenka for setting lamp-buffer resolutions. So even in a small team it would be nice for them to be able to enable/disable certain tools. Well they aren't really 'specialized' scripts - in that pretty much every small film team will need similar scripts - they aren't specialized if they will pretty much always be needed in every reasonably efficient pipeline. That said I think your proposal is a good idea. LetterRip ___ 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] Shading System Proposals
I'm not sure if this is relevant for this project, but luxrender developers started a preparation of an accelerated raytracing library which should be reusable in other projects: http://www.luxrender.net/wiki/index.php?title=LuxRays This library will have backend for OpenCL and Cuda. Main idea behind it is that the raytracing computation happens on OpenCL/Cuda devices, while the rest of the renderer is separated and not limited by the memory and code length restrictions of gpgpus. I just thought it might be usefull in future of the new shading system. Cheers, Vilem ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch: New functionality for background images
Such a system would be indeed a much more robust solution than binding the images to empty objects. Possible uses of this in 2d would be control of compo nodes, effects in sequencer (both in respective preview windows), mentioned transform of bg images in 3d view, transforming of trackers, bezier masks, In 3d this could be a solution for alternative pivots, e.g. for game physics constraints e.t.c. there could be different classes for different uses, which then could be bound to respective RNA properties - like 2d point(2 props), rectangle(4 props), line,3d point e.t.c Vilem Původní zpráva Od: Matt Ebb m...@mke3.net Předmět: Re: [Bf-committers] Patch: New functionality for background images Datum: 19.1.2010 02:12:53 On Tue, Jan 19, 2010 at 12:06 PM, Campbell Barton ideasma...@gmail.com wrote: - Placement is currently cumbersome, what about using an object to place images? - realize having an empty for each image could get annoying too but would allow for easy rotation too. Failing that we could have a button that places the image based on the active object but still stores its own coords. This is the sort of thing that a generic manipulator system would be useful for, not object. I've got some ideas on this, but for investigation later... Matt ___ 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
