Re: [Bf-committers] GSoC 2015 BioBlender
Hi Brad, Not speaking with any authority, my guess is that it's unlikely. Since BioBlender is not a core part of Blender and the target audience for it is relatively small, the benefit to Blender community as a whole is unfortunately small. However, if it is accepted, I would happy to nominate myself as the mentor as I wrote the first version of of BioBlender. -m On Wed, Nov 26, 2014 at 12:40 PM, Brad Hollister behol...@soe.ucsc.edu wrote: In the presentation, BioBlender in the production of The Dark Gene - Monica Zoppe, the speaker requested certain features. I have an appropriate background and am interested in this. Are feature additions for BioBlender (potentially not Blender proper) acceptable for a GSoC 2015 project? Could additions specifically meant for BioBlender, but required in Blender itself, be an acceptable project as well? Regards, Brad ___ 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 drivers have to be blocked as python scripts?
I don't think any type of checking will be safe against a determined attacker. One could conceivably rename objects to contain malicious code, and then use these as RNA path in an expression. -m On Fri, May 23, 2014 at 8:57 AM, Vilem Novak pildano...@post.cz wrote: 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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do drivers have to be blocked as python scripts?
Agree with Daniel. Perhaps a 'Halt on Error' checkbooks that prevent the rendering if there are any missing libraries, textures or disabled scripts. This should be helpful in a studio environment. M On May 23, 2014 1:13 PM, Daniel Salazar - patazstudio.com zan...@gmail.com wrote: I'm happy this is getting some attention. Apart from the usability issues this sheds some light into another problem which is: Blender should not render crippled scenes ever. At least on background mode Blender needs to stop if drives aren't functioning and/or if textures are missing. The fact that it happily continues is making us loose valuable render time. Daniel Salazar patazstudio.com On Fri, May 23, 2014 at 1:50 PM, patrick boelens p_boel...@msn.com wrote: Imho doing something like this will only worsen the situation. Right now a lot of .blends fail entirely, leaving many users to wonder why. This sucks. If we were to allow *some* expressions, but not others, potentially only half a .blend will fail. This sucks even more. At least when everything breaks it's clear there is an underlying reason; whether that is a user preference as is the case here, a bug in Blender or an unsupported version or whatever. At least more experienced users may quickly realize they did not allow script execution for this .blend. If only, say, one out of ten drivers fail, I would imagine it being tempting to go look for the cause of this at the drivers themselves; perhaps someone accidentally made a typo in an expression? I'm not sure if this has been proposed before, but would it be possible to show a pop-up when opening a (external) .blend file for the first time? Something similar to what OSX does when opening a freshly downloaded app or document: -- This .blend was created on another machine and contains executable code that could be harmful. Do you wish to allow Blender to execute these scripts? [Yes | No] -- It wouldn't solve the issue for render farms, but would at least provide clearity (as well as a much improved sense of control!) to the user. Just my two cents. Cheers, Patrick From: pildano...@post.cz To: bf-committers@blender.org CC: bf-committers@blender.org Date: Fri, 23 May 2014 17:57:31 +0200 Subject: [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 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] Replacing BGL with PyOpenGL
As a BGE user, I welcome any upgrade in the graphic pipeline. This sounds like a good idea to modernize BGE's OpenGL capabilities. Will this change require significant work to update the existing add ons that uses the BGL module? Although only Screencast-keys comes to mind. -m On Mon, Apr 7, 2014 at 1:59 AM, Mitchell Stokes moguri...@gmail.com wrote: BGL is a Python wrapper for OpenGL that is maintained by Blender. Unfortunately, it is stuck on approximately OpenGL 1.1 level features with some shader calls also exposed. It could be updated to support newer OpenGL features (at least having vertex arrays would be nice), but there really is not much need to maintain our own OpenGL wrapper. PyOpenGL[0] supports Python 3.3+, and could be used as a replacement for BGL (in other words, deprecate BGL and ship Blender with PyOpenGL). Pros: * Someone else would be maintaining the wrapper * PyOpenGL uses ctypes and the same package can be used for multiple platforms Cons: * Yet another Python package for us to ship with Blender * Adds to Blender's size * Some APIs may need to be updated (bge.texture and Image.gl_load come to mind) What are some other people's thoughts on this? --Mitchell Stokes [0] http://pyopengl.sourceforge.net/ ___ 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] Upgrading to Python 3.3.2
One thing to note: the current release of 3.3.2 is prone to segfaults when used on Mac OS X 10.9 (Maverick) due to this bug: http://bugs.python.org/issue18458, this makes Python unusable in the interpreter. Thus, if possible, I'd suggest waiting for 3.3.3 or at least use 3.3.3RC2 which has the OS X issue fixed: http://python.org/download/releases/3.3.3/ mike On Sat, Nov 16, 2013 at 4:43 PM, Alex Fraser a...@phatcore.com wrote: Hi all, Now that the release has happened and we can commit again, can we please upgrade to Python 3.3.2? I think this will require: - Update build deps to change the min version to 3.3.2 from 3.3.0 - Platform maintainers to update their copy of Python (e.g. Linux buildbot is currently building with 3.3.0) This is to fix this bug: https://projects.blender.org/tracker/index.php?func=detailaid=36963group_id=9atid=306 Cheers, Alex (z0r) On 22 October 2013 20:52, Alex Fraser a...@phatcore.com wrote: On 21 October 2013 20:46, Bastien Montagne montagn...@wanadoo.fr wrote: Eh, I thought we already were on py3.3.2 (installdeps is , at least)? I mean, mini-updates of python are bug-fixes only, so we should always use the latest, imho? But indeed svn libs are older (we even still have some py3.2!)… I'm not sure about the build environment for the official builds, but on my system it falls back to an earlier version because my system has an earlier version available as a .deb. I needed to alter install_deps.sh like this to get the right one: http://www.pasteall.org/46676/diff Not to be done before 2.69 is released, for sure! ;) Yep, absolutely. But at the same time I'd rather not wait for 3.4, if possible :) Cheers, Alex ___ 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] How goes leap motion progress?
As far as I know, Leap does not have an official Python 3 library yet, so the only way to access the device from Blender is via the web socket. I am eager to play with it too. On Thu, Oct 3, 2013 at 3:31 PM, Sean Olson seanol...@gmail.com wrote: Hey Guys, Just curious if any progress has been made on Leap Motion integration. I've got a nice paper weight on my desk right now that I'm eager to test! -Sean -- ||-- Instant Messengers -- || ICQ at 11133295 || AIM at shatterstar98 || MSN Messenger at shatte...@hotmail.com || Yahoo Y! at the_7th_samuri ||-- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] What is the status of YoFrankie?
I am interested, and would like to help if possible. A fresh set of BGE demos would be lovely. With or without Intel's support. mike On 2013-02-13, at 10:46 AM, Sinan Hassani sinan.hass...@gmail.com wrote: Hi Tom, You are correct in that the details on how this would work is not clear yet. I will discuss the details in my next meeting. Another important requirement for a game to get accepted is that it must run at minimum 30 FPS on specific hardware they would use for evaluation. Sinan On 13-02-13 01:22 PM, Sinan Hassani wrote: No 'exclusivity' with respect to the engine. As soon as a demo is release publicly, all code has to be released under GPL back to the BGE. Probably as patches for code review, not direct svn commits. When it comes to the content and assets, part of the deal my include creating new python scripts, assets, levels, blend files, etc that would have to be exclusive to Intel for about 6 months. That extra content would have its own license for redistribution during that period. After the period is over, I have to make sure the deal I have with Intel would allow the content to be licensed back to the public. So details still have to be worked out to see if this is possible with YoFrankie! license. We will also take special care to make sure we don't use any logos (no Blender logos, YoFrankie! logos, etc). Only attribution in the start-up screen will be given. Sinan On 13-02-13 12:42 PM, Tom M wrote: Hi, I'd certainly recommend using Yo Frankie. It has proven assets, proven game logic, etc. So the amount of time you need to 'get up to speed' is much less. Mostly just making sure things work well with a touch UI, and perhaps some work to improve quality. You might also want to see if Pablo (who did a lot of the character and asset creation) is available. I'm not sure how you could manage 'exclusivity' though, since the content is CC licensed and the engine is GPLed. Good luck, 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] Nvidia Fermi performance issues
As far as I know, there isn't a workaround for it yet. Disabling double-side lighitng for objects seem to help a lot, but that's as good as it gets. There was a discussion on http://projects.blender.org/tracker/index.php?func=detailaid=29724group_id=9atid=498, but nothing really came out of it. Mike On Mon, Sep 10, 2012 at 2:51 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: Hello, I must wonder if there is already a working solution to bypass the Fermi performance issues. I just installed a GTX 560 TI and i enjoy the rendering speed in Cycles. But I'm extremely unhappy with the viewport performance. It is even slower then on my old Geforce 7600 M (right a mobile card with 128 MB RAM). 1M polygons is not a big deal for my old card, but the new card is already below a framerate that could be usable for modelling. I played around with various settings, but so far it slow as hell. Any ideas on how to improve performance or is someone already working on a patch? A little sad looking Tobias Oelgarte ___ 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] Cycles performance
You are right Brecht, I just tested with a GCC-built Windows version of Blender an the result is comparable with that of Linux/Mac. Thanks! m On Tue, Mar 6, 2012 at 5:17 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, It's probably more compiler dependent than OS-dependent. Visual studio does not compile the render kernel as well as gcc. I've been developing with gcc, so that has some influence, and it's probably possible to tweak the code such that it compiles faster on visual studio. Thread management could be related but last I checked rendering threads were kept busy. Brecht. On Mon, Mar 5, 2012 at 11:26 PM, Mike Pan mike.c@gmail.com wrote: Not to start another OS debate. But... I noticed that the performance of Cycles is very OS-dependent. With the old rendering engine, the OS can influence the rendering time by ~10%. But with Cycles, i am seeing a huge difference in performance between Windows and Linux/Mac, where Linux/Mac is often twice as fast. This cleaned up chart by Olivier http://oenvoyage.wordpress.com/2012/02/25/blender-cycles-best-hardware-using-the-benchmark-spreadsheet-analysis/ clearly shows the discrepancy: http://oenvoyage.files.wordpress.com/2012/02/benchmark_win_linux.png I've done my own dual-boot test and the results as as follows: Cycles Render: (huge difference in render time) OS X: 3:27 Win 7: 6:14 Classic Render: (similar time, as expected) OS X: 1:24 Win 7: 1:29 Both OS are running natively (not under virtual machine), using the 64bit version of Blender 2.62. My question is, Is there any technical reason behind this? thread management? malloc overhead? Mike ___ 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] Cycles performance
Not to start another OS debate. But... I noticed that the performance of Cycles is very OS-dependent. With the old rendering engine, the OS can influence the rendering time by ~10%. But with Cycles, i am seeing a huge difference in performance between Windows and Linux/Mac, where Linux/Mac is often twice as fast. This cleaned up chart by Olivierhttp://oenvoyage.wordpress.com/2012/02/25/blender-cycles-best-hardware-using-the-benchmark-spreadsheet-analysis/clearly shows the discrepancy: http://oenvoyage.files.wordpress.com/2012/02/benchmark_win_linux.png I've done my own dual-boot test and the results as as follows: Cycles Render: (huge difference in render time) OS X: 3:27 Win 7: 6:14 Classic Render: (similar time, as expected) OS X: 1:24 Win 7: 1:29 Both OS are running natively (not under virtual machine), using the 64bit version of Blender 2.62. My question is, Is there any technical reason behind this? thread management? malloc overhead? Mike ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] tkinter python module
Thanks for the additional input. My use of tkinter is limited to the game engine in very small amount. Things like displaying an OS-neutral file-open dialog box. I can imagine if one were to create a secondary UI with tkinter, the two event loops might cause havok. Luckily that's not what I am doing. I know Dalai mentioned he can invoke a file-open dialog box via applescript. If anyone has another solution to display a dialog box in Windows, I'd appreciate it. Through VBscript? Or maybe a ctype windows DLL function call? Thanks m On Thu, Jan 19, 2012 at 5:36 PM, Stephen Swaney sswa...@centurytel.netwrote: On Thu, Jan 19, 2012 at 03:09:25PM -0800, Mike Pan wrote: Good to know that it's not a technical limitation. I'll roll my own release to include tkiner then. One techinical limitation you are going to run into is that both Tkinter and Blender have their own event handling loops. Trying to run two main loops can be problematic. -- Stephen Swaney sswa...@centurytel.net ___ 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] tkinter python module
Hi, I noticed that the tkinter python module is stripped out from the Blender Python installation. Is there a reason for this? Threading issue? Security Concern? Just wondering, since what I am working on projects that can really benefit from having a built-in, cross-platform UI module. Thanks! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Blender OpenCL compositor
From a user's perspective, it seems a few node (blur, defocus, vector blur) is responsible for over 90% of the node-compositing time in a real production, accelerating these will probably have a far larger impact/effort ratio than overhauling the entire framework. also, sorry about the LinkedIn spam earlier today. -mike pan On Fri, Jan 14, 2011 at 11:27 AM, Roger Wickes From IPhone rogerwic...@yahoo.com wrote: And next gen cpus are incorporating the arch from what i read Sent from my iPhone On Jan 14, 2011, at 8:17 AM, Xavier Thomas xavier.thomas.1...@gmail.com wrote: Beside, OpenCL does not specially mean GPU. OpenCL can be executed by CPU and even be accelerated by multiple CPU/Cores 2011/1/14 Knapp magick.c...@gmail.com While some of the GPU based stuff nowadays looks very spectacular, I personally still feel hesitant - I don't think CPUs (and especially multiprocessing) should be left by the wayside. Not only due to the increasing prevalence of multicore systems nowadays, but also for render farms, which are very largely CPU based. cheers Matt Yes, but for how long will that remain true?? http://www.tomshardware.com/news/nvda-china-super-computer-gpu,11545.html Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers 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] Single frame netrender
Would compositing with nodes be a problem since one needs data from bordering pixels in order to do certain operations such as blur? On Fri, Apr 30, 2010 at 3:00 PM, Roger Wickes rogerwic...@yahoo.com wrote: +1 while no single machine of mine (I have 8) can render a single frame of BBB, or even ED, (malloc returns 0), my hope is that if I could get the tile small enough, each would be able to render a portion, and then one could stitch them together. --Roger From: Martin Poirier the...@yahoo.com To: bf-blender developers bf-committers@blender.org Sent: Fri, April 30, 2010 8:39:17 AM Subject: Re: [Bf-committers] Single frame netrender Hi, Are you sure they didn't mean they wanted to be able to render a single frame on more than one machine? For tile dispatch, what's needed is a way to specify the rendered tile on command line as well as a way to load render results per tile (or at least an easy way to recomposite the full frame). Martin PS: The change you did is fine for sure, but it don't think it's usually what people think of when they talk about distributed rendering of single frames. --- On Fri, 4/30/10, Jeroen Bakker j.bak...@atmind.nl wrote: ___ 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] version naming
As far as I know, the first stable release will be called Blender 2.60, not 2.50. 2.60 would be a fine name as it denotes the rather large jump in feature and UI from Blender 2.49. Blender 2.50 would not be a very intuitive name to many users(especially non-power users), who would consider 2.49 to be almost equivalent to 2.50, which is far from true. We won't be able to wipe the internet clean of Blender 2.4 tutorials and resources in the next 4 month, and in order to hint at the users that the next release will be significantly different from the older 2.4x series can only be done through a new branding effort. So, I am all for calling it Blender 3, or at least Blender 2.60. Power-users don't seems to care about the versioning, for all we care, we can name Blender with the SVN revision numbers. But IMO proper versioning is as important as the recode, to signify the milestone that we've reached with this huge refactor. -mike On Thu, Apr 8, 2010 at 5:50 PM, Paolo Ciccone phcicc...@gmail.com wrote: Hello. There seems to be a bit of misconception about what was asked. This thread has turned from the initial request, to a debate about what would be the right version number for Blender. I apologize if I fueled the fire of that, the original question remains, though. Educators, like myself, and authors of books and DVDs that will help understand Blender are in need of knowing what the program will be called. It's not a matter of preferences, it's a matter of having a clear way to refer to the program and being able to prepare material that refers to Blender in the *proper* way. This is of benefit for everybody. It seems that some developer find the issue unimportant or irrelevant. Be assured that it's not. If you worked on just one release of a product, not a program, a product, in the software industry you should know how much time and care is spent in taking that decision. If you spend hours and hours in coding for Blender you should care if people will benefit from the fruit of so much effort. It's the role of people like me to spread the word and help users adopt Blender. At the end it's for the benefit of everybody. I dedicate two full days a week to promoting Blender. This includes finding a good topic for a tutorial, recording it, editing it, publishing it at Creative COW, blogging about it, respond to the forum requests, etc. Some of the feedback that I received included I had Blender for a year, could not figure it out, now I can, thanks to your tutorials or I thought I could never use 3D, now you made it accessible for me. I'm not bragging about it, I mention it because the final point of making a program is to have people using it. Otherwise all that coding is pointless. Preaching to the choir can be very rewarding but it doesn't go that far. There is a difference between an Array, a List or a Dictionary. You, as a developer, would not like ambiguity in that. Educators and users of your program don't like a similar ambiguity in how to refer to the darn program. Want to call it 2.6? Fine, but let's decide here and now how the program will be known to the public at large. Development versions don't count in that scheme. I have been telling people to stay clear from development versions because they are not production quality. But there is a point when the program ends the Beta phase and is released. That is what the public at large will need to use. What should we call it? It's not a hard decision or one that conflicts with the development. We are at a point where this is becoming an issue. Every day. Let's make a decision, update the websites and stick to the plan. It will give a sense of stability, a sense of what to expect and it will provide a clear way to refer to the program. What you do, as a developer, is crucial and important. What we do, as educators, is important too. When you dismiss this issue as not important you are belittling our effort and undermining endless hours of planning and design on how to make the future version of Blender a success. We are not asking for new features, we are just in need to have one simple label decided, possibly in a week or so. Thanks for your time. Cheers. --- Paolo Ciccone www.preta3d.com www.paolociccone.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Relative Paths as default setting
Of course one can do that. (ctrl+u) But for all the user that does not mess with the default setting, wouldn't relative be a better default option out of the box? mike ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
