Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
It doesn't seem to be so much an improvement to be honest, such a test will be more or less about nothing. It shouldn't be full testing, it should be per-area time measuring. For example, we could speedup viewport opengl display but accidentally slowdown dependency graph and having just an aggregated number will tell you simply nothing. it is also important to setup a strictly controlled environment for such tests if we want the numbers to mean anything. Otherwise we'll end up with folks reporting speed regressions in blender while it might be just new antivirus application being installed on their desktop. Surely if we'll have such an environment setup then it'll be handy, but the proposal for it needs much more work i'm afraid. On Wed, Jun 10, 2015 at 12:09 PM, Martijn Berger martijn.ber...@gmail.com wrote: Hello everyone, Blender is evolving at a rather nice pace currently but I feel we could use better measurements to guide its the performance aspect of this a bit better. Some 3d games (like quake) have a feature called “timedemo” this basically runs the game as fast as the hardware will let it run. I tried doing something similar in blender and found a number of little things that maybe could be tweaked to make this possible. Overview of how this would work: The user runs the command: “blender --factory-startup --python-expr=import bpy; bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0); demo_scene.blend” The following happens: 1. Blender starts and loads demo_scene.blend 2. Blender executes the python expression passed to it 3. debug_timer() is invoked: 1. Move animation counter to the start of the range 2. unlock max fps ( if vsync is disabled this allows very high framerates) 3. Gets an accurate time measurement 4. Run the animation and render 1 OpenGL frame per frame of animation 5. At the end of the range, capture time again 6. Print this time ( to stdout ?) 4. sys.exit(0), exit blender What we need for this to work: 1. implement bpy.ops.debug_timer() 2. Allow higher then 120 fps for animation playback 3. Not sure, if we allow gl frames to be locked to blender animation frames 4. (optional) implement ‘python-expr’ command line argument I might have missed stuff but the purpose of this message is to inform and discus the possibility as well as map out the bits and pieces that need to be done in order to get this functionality. I think something like this could also be instrumental in achieving high performance in the viewport project. Martijn ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
I didn't say it's difficult, i only mentioned that it is to be thought much more careful defining which exact information is useful for us and how to gather it. On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com wrote: Hi Martijn, think its fine to have more comprehensive performance tests (which can include extending, bpy.ops.wm.redraw_timer or add related operators to give more comprehensive info). This seems like 2 separate projects, - ability to perform tests and collect feedback. - extend existing performance tests. Second needs review of each kind of test added, but that can be done on case-by-case basis, to see whats really useful to measure. Ability to execute operators directly from command line is handy, uploaded patch. https://developer.blender.org/D1347 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
Hi Sergey, I agree that the overall timer + playback has limited use cases compared to proper full instrumentation of all parts of blender. But I don't really suggest it does. What things would be good to be able to make this thing do in order to extract better information? Martijn On Wed, Jun 10, 2015 at 1:38 PM, Sergey Sharybin sergey@gmail.com wrote: I didn't say it's difficult, i only mentioned that it is to be thought much more careful defining which exact information is useful for us and how to gather it. On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com wrote: Hi Martijn, think its fine to have more comprehensive performance tests (which can include extending, bpy.ops.wm.redraw_timer or add related operators to give more comprehensive info). This seems like 2 separate projects, - ability to perform tests and collect feedback. - extend existing performance tests. Second needs review of each kind of test added, but that can be done on case-by-case basis, to see whats really useful to measure. Ability to execute operators directly from command line is handy, uploaded patch. https://developer.blender.org/D1347 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
Hi Sergey, On Wed, Jun 10, 2015 at 12:47 PM, Sergey Sharybin sergey@gmail.com wrote: It doesn't seem to be so much an improvement to be honest, such a test will be more or less about nothing. It shouldn't be full testing, it should be per-area time measuring. For example, we could speedup viewport opengl display but accidentally slowdown dependency graph and having just an aggregated number will tell you simply nothing. Yes this could be an issue. But I still think it is also useful to measure the whole application performance. it is also important to setup a strictly controlled environment for such tests if we want the numbers to mean anything. Otherwise we'll end up with folks reporting speed regressions in blender while it might be just new antivirus application being installed on their desktop. This argument could be made about all possible ways to do this. The numbers produced by some random user and posted on a forum somewhere have little meaning always no matter how you look at it. Surely if we'll have such an environment setup then it'll be handy, but the proposal for it needs much more work i'm afraid. What exactly you think is difficult? Unlocking the max fps or making interface frames map to animation frames on a 1 to 1 basis ? It could maybe help if you could provide additional technical oriented feedback to that? On Wed, Jun 10, 2015 at 12:09 PM, Martijn Berger martijn.ber...@gmail.com wrote: Hello everyone, Blender is evolving at a rather nice pace currently but I feel we could use better measurements to guide its the performance aspect of this a bit better. Some 3d games (like quake) have a feature called “timedemo” this basically runs the game as fast as the hardware will let it run. I tried doing something similar in blender and found a number of little things that maybe could be tweaked to make this possible. Overview of how this would work: The user runs the command: “blender --factory-startup --python-expr=import bpy; bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0); demo_scene.blend” The following happens: 1. Blender starts and loads demo_scene.blend 2. Blender executes the python expression passed to it 3. debug_timer() is invoked: 1. Move animation counter to the start of the range 2. unlock max fps ( if vsync is disabled this allows very high framerates) 3. Gets an accurate time measurement 4. Run the animation and render 1 OpenGL frame per frame of animation 5. At the end of the range, capture time again 6. Print this time ( to stdout ?) 4. sys.exit(0), exit blender What we need for this to work: 1. implement bpy.ops.debug_timer() 2. Allow higher then 120 fps for animation playback 3. Not sure, if we allow gl frames to be locked to blender animation frames 4. (optional) implement ‘python-expr’ command line argument I might have missed stuff but the purpose of this message is to inform and discus the possibility as well as map out the bits and pieces that need to be done in order to get this functionality. I think something like this could also be instrumental in achieving high performance in the viewport project. Martijn ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
Hi Martijn, think its fine to have more comprehensive performance tests (which can include extending, bpy.ops.wm.redraw_timer or add related operators to give more comprehensive info). This seems like 2 separate projects, - ability to perform tests and collect feedback. - extend existing performance tests. Second needs review of each kind of test added, but that can be done on case-by-case basis, to see whats really useful to measure. Ability to execute operators directly from command line is handy, uploaded patch. https://developer.blender.org/D1347 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
It would be nice to be able to separate this total performance time to sub-costs, otherwise it would indeed difficult to make out something out of that number apart from performance changed - which indeed says little, performance changes with every change. On 10 June 2015 at 13:38, Sergey Sharybin sergey@gmail.com wrote: I didn't say it's difficult, i only mentioned that it is to be thought much more careful defining which exact information is useful for us and how to gather it. On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com wrote: Hi Martijn, think its fine to have more comprehensive performance tests (which can include extending, bpy.ops.wm.redraw_timer or add related operators to give more comprehensive info). This seems like 2 separate projects, - ability to perform tests and collect feedback. - extend existing performance tests. Second needs review of each kind of test added, but that can be done on case-by-case basis, to see whats really useful to measure. Ability to execute operators directly from command line is handy, uploaded patch. https://developer.blender.org/D1347 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender performance measuring instrumentation improvement proposal
Hello everyone, Blender is evolving at a rather nice pace currently but I feel we could use better measurements to guide its the performance aspect of this a bit better. Some 3d games (like quake) have a feature called “timedemo” this basically runs the game as fast as the hardware will let it run. I tried doing something similar in blender and found a number of little things that maybe could be tweaked to make this possible. Overview of how this would work: The user runs the command: “blender --factory-startup --python-expr=import bpy; bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0); demo_scene.blend” The following happens: 1. Blender starts and loads demo_scene.blend 2. Blender executes the python expression passed to it 3. debug_timer() is invoked: 1. Move animation counter to the start of the range 2. unlock max fps ( if vsync is disabled this allows very high framerates) 3. Gets an accurate time measurement 4. Run the animation and render 1 OpenGL frame per frame of animation 5. At the end of the range, capture time again 6. Print this time ( to stdout ?) 4. sys.exit(0), exit blender What we need for this to work: 1. implement bpy.ops.debug_timer() 2. Allow higher then 120 fps for animation playback 3. Not sure, if we allow gl frames to be locked to blender animation frames 4. (optional) implement ‘python-expr’ command line argument I might have missed stuff but the purpose of this message is to inform and discus the possibility as well as map out the bits and pieces that need to be done in order to get this functionality. I think something like this could also be instrumental in achieving high performance in the viewport project. Martijn ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal
Hi, We actually have something like this already bpy.ops.wm.redraw_timer()(i.e. Ctrl-Alt-T) This can be used for testing how long it takes to do things like redrawing the screen/area/region(?) 10 times, and also for things like animation playback and undo/redo times. If you need anything else specific, it could probably be added there I guess... Joshua On Wed, Jun 10, 2015 at 10:09 PM, Martijn Berger martijn.ber...@gmail.com wrote: Hello everyone, Blender is evolving at a rather nice pace currently but I feel we could use better measurements to guide its the performance aspect of this a bit better. Some 3d games (like quake) have a feature called “timedemo” this basically runs the game as fast as the hardware will let it run. I tried doing something similar in blender and found a number of little things that maybe could be tweaked to make this possible. Overview of how this would work: The user runs the command: “blender --factory-startup --python-expr=import bpy; bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0); demo_scene.blend” The following happens: 1. Blender starts and loads demo_scene.blend 2. Blender executes the python expression passed to it 3. debug_timer() is invoked: 1. Move animation counter to the start of the range 2. unlock max fps ( if vsync is disabled this allows very high framerates) 3. Gets an accurate time measurement 4. Run the animation and render 1 OpenGL frame per frame of animation 5. At the end of the range, capture time again 6. Print this time ( to stdout ?) 4. sys.exit(0), exit blender What we need for this to work: 1. implement bpy.ops.debug_timer() 2. Allow higher then 120 fps for animation playback 3. Not sure, if we allow gl frames to be locked to blender animation frames 4. (optional) implement ‘python-expr’ command line argument I might have missed stuff but the purpose of this message is to inform and discus the possibility as well as map out the bits and pieces that need to be done in order to get this functionality. I think something like this could also be instrumental in achieving high performance in the viewport project. Martijn ___ 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] Blender performance measuring instrumentation improvement proposal
Martijn, thinking of something similar to current Debug Timer operator (or even an extension of it) which will perform some operation N times (N = 10) and report total/average time on it. The operations could be: - Viewport draw (which we already have) - Full scene depsgraph evaluation - Scene depsgraph evaluation caused by timesource changes - Specified object evaluation - Internal datastructures performance testing (similar to ghash performance tests) - More extremes, which i'm not really sure how to do in a nice way: Cycles scene export time, Cycles BVH build time - Some more stuff which we can define in the future. IMO goal should be to make all those tests as reproachable as possible and much independent from external factors as possible. That's why idea of fps-based thing is something i consider unusable for reliable testing (since video driver might easily ruing your day with that). The work from Campbell about making it possible to run given code from a command line argument is handy, but not totally crucial for performance framework (since it could all be done in a .py file) On Wed, Jun 10, 2015 at 1:44 PM, Martijn Berger martijn.ber...@gmail.com wrote: Hi Sergey, I agree that the overall timer + playback has limited use cases compared to proper full instrumentation of all parts of blender. But I don't really suggest it does. What things would be good to be able to make this thing do in order to extract better information? Martijn On Wed, Jun 10, 2015 at 1:38 PM, Sergey Sharybin sergey@gmail.com wrote: I didn't say it's difficult, i only mentioned that it is to be thought much more careful defining which exact information is useful for us and how to gather it. On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com wrote: Hi Martijn, think its fine to have more comprehensive performance tests (which can include extending, bpy.ops.wm.redraw_timer or add related operators to give more comprehensive info). This seems like 2 separate projects, - ability to perform tests and collect feedback. - extend existing performance tests. Second needs review of each kind of test added, but that can be done on case-by-case basis, to see whats really useful to measure. Ability to execute operators directly from command line is handy, uploaded patch. https://developer.blender.org/D1347 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Multiple soft body settings per object
Hi there! My name is Luke and I've been an amateur Blender user for a few years and I love it! Recently, I had a cool idea where I wanted to try to emulate muscles of the human body to create a more realistic style of animation. This was mostly to satisfy personal curiosity and perhaps to create an interesting new style of art. However, at some point I hit a snag where I wasn't able to move forward. The problem can be summarized as follows: the built in soft body engine of Blender is great, but what I really needed was to have more than one soft body setting per object. This was to allow me to sort of pin different things together, like pinning skin to muscle. Skin and muscle have very different levels of softness but sometimes the skin and muscle for one person may need to share points (be connected or glued together). What I needed was to have one edge connected to a point with a certain push/pull value and a different edge connected to the same point with a different push/pull value (this is just an example, the idea is that any soft body setting for which you can select a vertex group would be able to have multiple settings). I couldn't figure out any way to do this or properly emulate this within blender. True, there are ways to copy data from one point to another but the soft body forces wouldn't transfer which would leave me with an unrealistic result. To solve this problem, I decided to break open the internal C code to try and add this capability myself. Now before I get into details I want to tell you a little about myself. I got my bachelor's in computer science 6 years ago and since then I have been a professional web programmer. The vast majority of my experience with programming has been c#/Java and scripting languages like PHP/Python, etc. I also do front end stuff like html, css, and javascript. I don't have a lot of experience with very low level code like c or c++. However, I'm always eager to try new things and, to be honest, I was surprised at how approachable the blender code base was! In any case, please be patient with me if I have any trivial misconceptions about c coding. This email/document is meant to be a project proposal and specification. I will include as many details as I can and I invite everyone and anyone to provide feedback and criticism. Feature Description This section describes the feature without discussing any implementation details. Implementation will be covered in the next section. In general, blender soft body settings can be split into two different groups, general settings and vertex group specific settings. The vertex group specific settings allow you to select a vertex group (or no vertex group indicating all vertices) to apply the settings to. All vertices not part of the specified vertex group will not have the settings, and will not be part of this animation. This has a disadvantage if you are trying to simulate heterogenous soft bodies for which part of the body may have different settings than another part. To alleviate this problem, I propose allowing MULTIPLE soft body settings for the vertex-group type of setting. For reference, here is a list of the different settings associted with vertex groups Vertex Group Specific Settings: Soft Body: Friction, Speed, Mass Soft Body Goal: Goal Strength: Default, Minimum, Maximum Goal Settings: Stiffness, Damping Soft Body Edges: Settings: Pull, Push, Damp, Plastic, Bending, Length Stiff Quads: Stiff Quads, Shear Aerodynamics: Simple|Lift Force, Factor Collision: Edge, Face All of the remaining settings are general settings and will not be affected by this change. The question naturally arises what will the soft body settings be of a vertex that is a member of multiple groups? If we imagine trying to emulate jello that is very jiggly on one side but rigid on the other with a smooth transition, the most intuitive way to do this would be to have a rigid vertex group and a soft vertex group. Then using weight painting, you can smoothly transition between the two groups to create a nice effect. To enable this, we institute the following rule: a vertex's specific value for any setting listed above will be the weighted average of all of the settings for all of the vertex groups that apply to it, including the all group if there is a setting for that. Now let's talk about how the UI will enable the user to control this feature. There are already multiple examples in the blender UI of having a list of settings that the user is allowed to modify on a per-item basis. Some examples are render layers, textures and materials. The soft body settings will work the same way. First, we will move all of the General soft body settings to the top so that the user does not get confused thinking that it applies only to a vertex group. Then, we will have a list selector. For an example list selector, see the render layers list selector. In the list selector
[Bf-committers] Blender 2.75 RC1 release AHOY!
Hi, We've switched to bcon5 today which means two things: 1. Only crucial fixes are allowed in the master branch 2. We're doing RC1 builds Information for platform maintainers: - Branch: blender-v2.75-release - Branch hash: bff8b5ddad29e2ba5b2a6b92e640870e45466d1d - Locale hash: da05fa08d4e80a634a91a82f211589587f9169bc - Addons hash: fe47d3d49371b03691774ba3b915c5c047876ab9 Suggested name: blender-2.75-rc1-platform Thing to test: there should be now python binary be included into the archive. In order to test this you can check bpy.app.binary_path_python in the python console. Usual reminder: it is a REAL release candidate. Meaning, if we do a fix, we backport it to the branch and do another RC. If no fixes are to be backported (or if they're really tiny small) we do final release. Also please note Git is considered frozen for until all the builds are up (approx ~24hrs from now on). No commits are allowed to the master branch for until unfreeze message is sent t this ML (expect this tomorrow afternoon-ish). Thanks everyone for the work! :) -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Keymaps and presets - Security issues?
Even with JSON or XML you could create a malicious keymap. For example
you could use an operator to type any text into the text editor and
execute it, and assign that to a commonly used key shortcut. It just
requires a bit more creativity.
On Wed, Jun 10, 2015 at 5:15 PM, Diego Gangl dnico...@gmail.com wrote:
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
Wouldn't this be more in the addon territory? I'm sure those keymap authors
could write an addon as well.
2015-06-10 1:33 GMT-03:00 Campbell Barton ideasma...@gmail.com:
On Wed, Jun 10, 2015 at 9:59 AM, Diego Gangl dnico...@gmail.com wrote:
Hi guys,
There's something that's been on my mind recently, keymaps and presets
are
python files that run whatever code is in them everytime they are used.
I tried pasting this code in the middle of a keymap file:
from subprocess import Popen
Popen('touch ~/boo.test', shell=True)
and sure enough the file boo.test is created. Are there any limitations,
or
checks when running these files? Because it looks like it would be easy
for
someone to hide malicious code in there (not trying to sound like RMS
:) )
Presets/keymaps are often shared online, and users can't be expected to
inspect these files for evilness. Why not use json or some other data
format?
Cheers!
Hi Diego, yes, this is a real issue, we could use JSON/XML (as we do
already for themes).
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
___
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] Keymaps and presets - Security issues?
On Thu, Jun 11, 2015 at 3:59 AM, Marc Dion marcdion1...@gmail.com wrote:
It's likely that as soon as one person is affected by malicious code,
everybody is going to hear about it rather quickly. News spreads fast
around here.
People usually have to build up trust for some time before code or .blends
they've put together start to become of interest to others.
If I'm not mistaken, *User Preferences-File-Auto Execution: Auto Run
Python Scripts* can be disabled for people who are concerned about this.
Yes, and this is default off so opening Blends from un-trusted sources
wont execute code by default.
Perhaps someone will take the initiative to build a utility that can scan
Blender related material for suspicious code, (something that can detect
file deletion commands would be a solid start for this ;)
Such tools have near zero use, you can scan for 'os.remove', but then
someone can just workaround with
'getattr(__import__(.join(reversed(list(so,
.join(reversed(list(evomer'
Render farm maintainers might appreciate something like this since who
knows what people are going to send over to their machines.
Containers apparently have very low overhead these days and provide
good sand-boxing mechanisms.
On Wed, Jun 10, 2015 at 10:26 AM, Sergey Sharybin sergey@gmail.com
wrote:
I'm not really sure why switching to any other format of storing keymaps
will help in any way, apart form introducing inconvenience to the folks who
keeps customization operators in the keymap (well, granted it's not best
approach in the world but that's how maya/3ds keymaps worked in blender for
quite some time).
The thing is, even if the keymapare safe, you're still having risk when
installing someone's addon or even opening the .blend file.
So my question is: shall we really worry about this?
On Wed, Jun 10, 2015 at 7:08 PM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Even with JSON or XML you could create a malicious keymap. For example
you could use an operator to type any text into the text editor and
execute it, and assign that to a commonly used key shortcut. It just
requires a bit more creativity.
On Wed, Jun 10, 2015 at 5:15 PM, Diego Gangl dnico...@gmail.com wrote:
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
Wouldn't this be more in the addon territory? I'm sure those keymap
authors
could write an addon as well.
2015-06-10 1:33 GMT-03:00 Campbell Barton ideasma...@gmail.com:
On Wed, Jun 10, 2015 at 9:59 AM, Diego Gangl dnico...@gmail.com
wrote:
Hi guys,
There's something that's been on my mind recently, keymaps and
presets
are
python files that run whatever code is in them everytime they are
used.
I tried pasting this code in the middle of a keymap file:
from subprocess import Popen
Popen('touch ~/boo.test', shell=True)
and sure enough the file boo.test is created. Are there any
limitations,
or
checks when running these files? Because it looks like it would be
easy
for
someone to hide malicious code in there (not trying to sound like
RMS
:) )
Presets/keymaps are often shared online, and users can't be expected
to
inspect these files for evilness. Why not use json or some other
data
format?
Cheers!
Hi Diego, yes, this is a real issue, we could use JSON/XML (as we do
already for themes).
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
___
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
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] CMake error when trying to compile blender
Hello, Haven't built from fresh sources in several months and was trying to today. upon executing cmake ../ I get the following output: CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR) Call Stack (most recent call first): /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:374 _FPHSA_FAILURE_MESSAGE) build_files/cmake/Modules/FindPythonLibsUnix.cmake:184 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:838 (find_package) Has anyone any ideas of how to resolve such an error? (python2.7 and python3.3 are both on the machine) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.75 RC1 release AHOY!
Also please note Git is considered frozen for until all the builds are up (approx ~24hrs from now on). No commits are allowed to the master branch for until unfreeze message is sent t this ML (expect this tomorrow afternoon-ish). Apparently I oversaw this email and commited a small error message fix in master. Sorry about that, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-06-10 12:55 GMT-03:00 Sergey Sharybin sergey@gmail.com: Hi, We've switched to bcon5 today which means two things: 1. Only crucial fixes are allowed in the master branch 2. We're doing RC1 builds Information for platform maintainers: - Branch: blender-v2.75-release - Branch hash: bff8b5ddad29e2ba5b2a6b92e640870e45466d1d - Locale hash: da05fa08d4e80a634a91a82f211589587f9169bc - Addons hash: fe47d3d49371b03691774ba3b915c5c047876ab9 Suggested name: blender-2.75-rc1-platform Thing to test: there should be now python binary be included into the archive. In order to test this you can check bpy.app.binary_path_python in the python console. Usual reminder: it is a REAL release candidate. Meaning, if we do a fix, we backport it to the branch and do another RC. If no fixes are to be backported (or if they're really tiny small) we do final release. Also please note Git is considered frozen for until all the builds are up (approx ~24hrs from now on). No commits are allowed to the master branch for until unfreeze message is sent t this ML (expect this tomorrow afternoon-ish). Thanks everyone for the work! :) -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] CMake error when trying to compile blender
You need python 3.4 to build blender. Le 10/06/2015 20:58, xglasyliax . a écrit : Hello, Haven't built from fresh sources in several months and was trying to today. upon executing cmake ../ I get the following output: CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR) Call Stack (most recent call first): /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:374 _FPHSA_FAILURE_MESSAGE) build_files/cmake/Modules/FindPythonLibsUnix.cmake:184 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:838 (find_package) Has anyone any ideas of how to resolve such an error? (python2.7 and python3.3 are both on the machine) ___ 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] Blender 2.75 RC1 release AHOY!
Hey guys (and girls?) Sorry I've been absent from building FreeBSD builds for release for quite some time. I have just compiled (and run) a 64bit build of 2.75-rc1 Don't want to sound totally ignorant here, but what exactly is the current procedure for uploading builds? Same as before? (if you still want the BSD builds for releases...) 2015-06-10 10:55 GMT-05:00 Sergey Sharybin sergey@gmail.com: Hi, We've switched to bcon5 today which means two things: 1. Only crucial fixes are allowed in the master branch 2. We're doing RC1 builds Information for platform maintainers: - Branch: blender-v2.75-release - Branch hash: bff8b5ddad29e2ba5b2a6b92e640870e45466d1d - Locale hash: da05fa08d4e80a634a91a82f211589587f9169bc - Addons hash: fe47d3d49371b03691774ba3b915c5c047876ab9 Suggested name: blender-2.75-rc1-platform Thing to test: there should be now python binary be included into the archive. In order to test this you can check bpy.app.binary_path_python in the python console. Usual reminder: it is a REAL release candidate. Meaning, if we do a fix, we backport it to the branch and do another RC. If no fixes are to be backported (or if they're really tiny small) we do final release. Also please note Git is considered frozen for until all the builds are up (approx ~24hrs from now on). No commits are allowed to the master branch for until unfreeze message is sent t this ML (expect this tomorrow afternoon-ish). Thanks everyone for the work! :) -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Keymaps and presets - Security issues?
I'm not really sure why switching to any other format of storing keymaps
will help in any way, apart form introducing inconvenience to the folks who
keeps customization operators in the keymap (well, granted it's not best
approach in the world but that's how maya/3ds keymaps worked in blender for
quite some time).
The thing is, even if the keymapare safe, you're still having risk when
installing someone's addon or even opening the .blend file.
So my question is: shall we really worry about this?
On Wed, Jun 10, 2015 at 7:08 PM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Even with JSON or XML you could create a malicious keymap. For example
you could use an operator to type any text into the text editor and
execute it, and assign that to a commonly used key shortcut. It just
requires a bit more creativity.
On Wed, Jun 10, 2015 at 5:15 PM, Diego Gangl dnico...@gmail.com wrote:
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
Wouldn't this be more in the addon territory? I'm sure those keymap
authors
could write an addon as well.
2015-06-10 1:33 GMT-03:00 Campbell Barton ideasma...@gmail.com:
On Wed, Jun 10, 2015 at 9:59 AM, Diego Gangl dnico...@gmail.com
wrote:
Hi guys,
There's something that's been on my mind recently, keymaps and presets
are
python files that run whatever code is in them everytime they are
used.
I tried pasting this code in the middle of a keymap file:
from subprocess import Popen
Popen('touch ~/boo.test', shell=True)
and sure enough the file boo.test is created. Are there any
limitations,
or
checks when running these files? Because it looks like it would be
easy
for
someone to hide malicious code in there (not trying to sound like RMS
:) )
Presets/keymaps are often shared online, and users can't be expected
to
inspect these files for evilness. Why not use json or some other data
format?
Cheers!
Hi Diego, yes, this is a real issue, we could use JSON/XML (as we do
already for themes).
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
___
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
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Keymaps and presets - Security issues?
It's likely that as soon as one person is affected by malicious code,
everybody is going to hear about it rather quickly. News spreads fast
around here.
People usually have to build up trust for some time before code or .blends
they've put together start to become of interest to others.
If I'm not mistaken, *User Preferences-File-Auto Execution: Auto Run
Python Scripts* can be disabled for people who are concerned about this.
Perhaps someone will take the initiative to build a utility that can scan
Blender related material for suspicious code, (something that can detect
file deletion commands would be a solid start for this ;)
Render farm maintainers might appreciate something like this since who
knows what people are going to send over to their machines.
On Wed, Jun 10, 2015 at 10:26 AM, Sergey Sharybin sergey@gmail.com
wrote:
I'm not really sure why switching to any other format of storing keymaps
will help in any way, apart form introducing inconvenience to the folks who
keeps customization operators in the keymap (well, granted it's not best
approach in the world but that's how maya/3ds keymaps worked in blender for
quite some time).
The thing is, even if the keymapare safe, you're still having risk when
installing someone's addon or even opening the .blend file.
So my question is: shall we really worry about this?
On Wed, Jun 10, 2015 at 7:08 PM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Even with JSON or XML you could create a malicious keymap. For example
you could use an operator to type any text into the text editor and
execute it, and assign that to a commonly used key shortcut. It just
requires a bit more creativity.
On Wed, Jun 10, 2015 at 5:15 PM, Diego Gangl dnico...@gmail.com wrote:
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
Wouldn't this be more in the addon territory? I'm sure those keymap
authors
could write an addon as well.
2015-06-10 1:33 GMT-03:00 Campbell Barton ideasma...@gmail.com:
On Wed, Jun 10, 2015 at 9:59 AM, Diego Gangl dnico...@gmail.com
wrote:
Hi guys,
There's something that's been on my mind recently, keymaps and
presets
are
python files that run whatever code is in them everytime they are
used.
I tried pasting this code in the middle of a keymap file:
from subprocess import Popen
Popen('touch ~/boo.test', shell=True)
and sure enough the file boo.test is created. Are there any
limitations,
or
checks when running these files? Because it looks like it would be
easy
for
someone to hide malicious code in there (not trying to sound like
RMS
:) )
Presets/keymaps are often shared online, and users can't be expected
to
inspect these files for evilness. Why not use json or some other
data
format?
Cheers!
Hi Diego, yes, this is a real issue, we could use JSON/XML (as we do
already for themes).
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
___
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
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.75 RC1 release AHOY!
If you'll be around later to do final release builds and so feel free to provide the build and put it to incoming folder on our ftp and let me now after that. P.S. Surely there are girls in there, no need to questionmark it i bet :) On Wed, Jun 10, 2015 at 10:22 PM, xglasyliax . xgl.asyl...@gmail.com wrote: Hey guys (and girls?) Sorry I've been absent from building FreeBSD builds for release for quite some time. I have just compiled (and run) a 64bit build of 2.75-rc1 Don't want to sound totally ignorant here, but what exactly is the current procedure for uploading builds? Same as before? (if you still want the BSD builds for releases...) 2015-06-10 10:55 GMT-05:00 Sergey Sharybin sergey@gmail.com: Hi, We've switched to bcon5 today which means two things: 1. Only crucial fixes are allowed in the master branch 2. We're doing RC1 builds Information for platform maintainers: - Branch: blender-v2.75-release - Branch hash: bff8b5ddad29e2ba5b2a6b92e640870e45466d1d - Locale hash: da05fa08d4e80a634a91a82f211589587f9169bc - Addons hash: fe47d3d49371b03691774ba3b915c5c047876ab9 Suggested name: blender-2.75-rc1-platform Thing to test: there should be now python binary be included into the archive. In order to test this you can check bpy.app.binary_path_python in the python console. Usual reminder: it is a REAL release candidate. Meaning, if we do a fix, we backport it to the branch and do another RC. If no fixes are to be backported (or if they're really tiny small) we do final release. Also please note Git is considered frozen for until all the builds are up (approx ~24hrs from now on). No commits are allowed to the master branch for until unfreeze message is sent t this ML (expect this tomorrow afternoon-ish). Thanks everyone for the work! :) -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Keymaps and presets - Security issues?
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
Wouldn't this be more in the addon territory? I'm sure those keymap authors
could write an addon as well.
2015-06-10 1:33 GMT-03:00 Campbell Barton ideasma...@gmail.com:
On Wed, Jun 10, 2015 at 9:59 AM, Diego Gangl dnico...@gmail.com wrote:
Hi guys,
There's something that's been on my mind recently, keymaps and presets
are
python files that run whatever code is in them everytime they are used.
I tried pasting this code in the middle of a keymap file:
from subprocess import Popen
Popen('touch ~/boo.test', shell=True)
and sure enough the file boo.test is created. Are there any limitations,
or
checks when running these files? Because it looks like it would be easy
for
someone to hide malicious code in there (not trying to sound like RMS
:) )
Presets/keymaps are often shared online, and users can't be expected to
inspect these files for evilness. Why not use json or some other data
format?
Cheers!
Hi Diego, yes, this is a real issue, we could use JSON/XML (as we do
already for themes).
Though some keymap authors define their own operators menus, so we
wouldn't want to drop support for Python keymaps entirely.
___
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
