Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On 06/07/2013 10:21 AM, Ton Roosendaal wrote:
Hi Campbell,
I don't know enough about Python internals, so I depend on someone to help
designing a sane way to handle security risks here. There must be ways we can
help users?
Look for example at the standard UI scripts. Apart from 1 case, there's no
import os anywhere. Same goes for essential scripts riggers or animators
use.
So, why not add a provision in Blender code to check on such cases. Just
don't allow import of any module = safe script? In all other cases: needs to
be explicitly permitted to run.
Something like this would make a trusted source option on file loading more
useful. Right now, unticking trusted source is almost equivalent to
disable useful features.
oh = 'SOS HELP!'
ohoh = __import__(oh[1:3].lower())
ohoh
module 'os' from
'/home/domino/Applications/blender-2.67-linux-glibc211-x86_64/2.67/python/lib/python3.3/os.py'
On Linux distros where system Python is used, I doubt anything can be
done to prevent the import function from being used.
Load Blender with a console, check there's the startup message on it.
Then paste this into say the frame number field..
eval(__import__('os').system('clear'), {})
Now check console again.. Just checking scripts for imports isn't enough.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
On 05/28/2013 11:26 AM, Campbell Barton wrote:
I still am a bit concerned that we get many complaints but very little
real evidence of the cause of addon breakage - just that it happens, I
realize not every project is opensource but enough are that links to
scripts that break would be very helpful for API devs.
For my scripts the changes to UV handling caused the most problems..
Supporting multiple Blender versions from same script version results in
code like this:
u_points = []
v_points = []
mesh = obj.data
if svn = 44243:
for f in mesh.uv_textures[uv_name].data:
for u, v in f.uv:
u_points.append(u)
v_points.append(v)
else:
if svn 45996:
uv_loops = mesh.uv_layers[uv_name].data
else:
loopindex = mesh.uv_textures.keys().index(uv_name)
uv_loops = mesh.uv_layers[loopindex].data
u_points = [v.uv.x for v in uv_loops]
v_points = [v.uv.y for v in uv_loops]
And other changes mean I have to do this to get the svn version :)
try:
svn = bpy.app.build_revision.decode().split(':')[-1].rstrip('M')
except:
svn = bpy.app.build_revision.split(':')[-1].rstrip('M')
svn = int(svn)
I think the major problem is the changes such as these where the new way
replaces the old way. I test against SVN builds so usually catch changes
quickly and before my users do. But if I developed against release
versions, then a new RC is the first time I'd be aware of issues. If I
was on holiday, then it could even get to a release version and more
users hitting problems before I got chance to do anything. Without a
release or two with depreciated APIs it's something I need to constantly
watch out and allow time for.
Things have been better the past few versions though. I've not needed to
add any more svn checks since 2.65 - currently in this particular addon,
there's over 20 checks to adjust for API changes but it does work on
2.59 to 2.67. For each version from 2.59 to 2.65 there is at least one
check for the specific svn version to tweak things.
While the majority of the changes are due to API improvements, sometimes
they seem to be changes that maybe should have been reconsidered. One
bit of my code walks over the edges of faces, so the only change needed was:
if svn = 44243:
faces = mesh.faces
else:
faces = mesh.polygons
I am overdue for a code cleanup though. My official stance is that I
support 3 older versions of Blender, so the majority of the svn checks
are due for removal. For my first example, that results in the much nicer:
mesh = obj.data
uv_loops = mesh.uv_layers[uv_name].data
u_points = [v.uv.x for v in uv_loops]
v_points = [v.uv.y for v in uv_loops]
So although the API breakage is a hassle, I do see the long term benefit
to the changes.
It's my choice to support multiple Blender versions rather than
constantly recommending Blender updates as I get fewer requests for
support that way :)
Hope that helps clarify the issues API changes create and how I manage them.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
On 05/28/2013 02:31 PM, Campbell Barton wrote:
From your mail it looks like all changes you note were from bmesh
upgrade (except build_revision)
On Tue, May 28, 2013 at 9:36 PM, Domino Marama
dom...@dominodesigns.info wrote:
For my scripts the changes to UV handling caused the most problems..
Supporting multiple Blender versions from same script version results in
code like this:
u_points = []
v_points = []
mesh = obj.data
if svn = 44243:
for f in mesh.uv_textures[uv_name].data:
for u, v in f.uv:
u_points.append(u)
v_points.append(v)
else:
if svn 45996:
uv_loops = mesh.uv_layers[uv_name].data
else:
loopindex = mesh.uv_textures.keys().index(uv_name)
uv_loops = mesh.uv_layers[loopindex].data
u_points = [v.uv.x for v in uv_loops]
v_points = [v.uv.y for v in uv_loops]
And other changes mean I have to do this to get the svn version :)
try:
svn = bpy.app.build_revision.decode().split(':')[-1].rstrip('M')
except:
svn = bpy.app.build_revision.split(':')[-1].rstrip('M')
svn = int(svn)
This isn't totally reliable, some builds dont include buildinfo, Id
suggest using blender version rather then checking revisions.
Also moving to git - revisions will work differently too.
Yeah I just posted that because of the irony in my routine for handling
API changes being affected by them. I'm sure you see the additional
irony in pointing out that it is going to break again in the future :)
In the full code the svn = int(svn) line is in a try: except with a
fallback of estimating a svn number from the Blender version. I had to
do it this way as the Blender version isn't updated until release so
when API breakages occur I need to be able to target specific commits to
test against current builds
It does but also confirms that BMesh was main offender (not sure you
were aware of this regarding UVs?).
Yeah the majority of the the current switches in my code are bmesh
related. I couldn't do a full switch to bmesh without losing backward
compatibility, so it's mostly old API with just the UV handling from
bmesh on newer versions. Now there's enough old versions with bmesh I
can plan the full migration of the code to the new APIs.
Prior to that the last big script shakeup was the switch to python3.
I really posted as an example of a different way that script authors may
be working. Assuming a new Blender release with API changes means that
script authors will do new versions of their scripts makes work for
people who may not have scheduled for it. Having a few releases where
depreciated functions give warnings lets people schedule these things in
rather than having to make it their main priority. For those of us who
support older versions on same scripts, it also makes life a little
easier as we could fall into synch with the depreciation cycle rather
than having to work around things to keep compatibility.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [53930] trunk/blender: Python i18n API.
On 01/20/2013 05:29 PM, Bastien Montagne wrote:
Revision: 53930
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=53930
Author: mont29
Date: 2013-01-20 17:29:07 + (Sun, 20 Jan 2013)
Log Message:
---
Python i18n API. Many thanks to Campbell and Brecht for the reviews and
suggestions!
This commit adds:
* A new bpy.app.translations module giving some info about
locales/translation stuff (current active locale, all locales currently known
by blender, all translation contexts currently defined, etc.).
Is there any reason this was added rather than just using pythons i18n
stuff?
I add translation to my (multiple python file) scripts in my primstar
addon with:
__init__.py
import os
import gettext
LOCALE_DIR = os.path.join(os.path.dirname(__file__), 'locale')
translator = gettext.translation('primstar', LOCALE_DIR, fallback=True)
_ = translator.gettext
8--
a_script.py
import bpy
from . import _
class ObjectBakeSculpt(bpy.types.Operator):
bl_idname = object.sculpty_bake
bl_label = _(Bake Sculpt Maps...)
8-- So here the idname is fixed string, label is translatable.
It's then normal po mo stuff for each supported language..
#! /bin/bash
xgettext -LPython -oaddons/primstar/locale/primstar.pot
--from-code=UTF-8 --copyright-holder='Domino Marama'
--package-name=Primstar --package-version=2 addons/primstar/*.py
msginit --no-translator -o po/en_GB.po -i
addons/primstar/locale/primstar.pot
msgfmt -o addons/primstar/locale/en/LC_MESSAGES/primstar.mo po/en_GB.po
So my translators can use all their usual tools for editing the po files..
Just wondering why this commit was added to do something that's already
possible...
Cheers,
Domino
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada-patch for testing
On 02/01/2012 09:05 AM, Gaia Clary wrote: Hi. Should we fully switch discussion to the Wiki page ? I answer here and add a comment to the Wiki as well. http://wiki.blender.org/index.php/Dev_talk:2.5/Source/Development/Todo/Import_Export More see below... I'd prefer a collada specific mailing list to be setup rather than using wiki for discussion. That and irc would allow more efficient collaboration among the new Collada team and any interested users. I don't want to have to check a wiki page frequently to stay on top of things, either I want realtime discussion (irc) or I want new information to come to me (mailing list) - having to go somewhere and check whether there's new info or not isn't a good use of my time. Wiki and bug tracker are good for somewhere to go just when I need to know what to look at next, but not as a daily chore. Best Wishes, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada-patch for testing
On 02/01/2012 10:33 AM, Ton Roosendaal wrote: Hi, Let's wait a bit with a new list; we can do that when this project is really being tackled actively and everyone here's getting bored of collada discussions :) Fair enough. There's the opencollada implementation and at least 3 partial python based exporters - I just thought that discussion of the relative pros and cons of those may result in fairly heavy traffic for awhile. It's the outcome of those discussions that I'd expect to form into a plan that would go onto the wiki. You're for sure very welcome to join irc.freenode.net #blendercoders. There's always 100-150 people hanging out. I'd love to figure out what you can do precisely, or where your interest is mostly. I've arranged to set aside part of the income from sales of our Second Life addon scripts (Avastar and Primstar) to fund my work on Collada. Collada is an essential feature for Second Life both for Blender users and for users of other applications such as Maya and ZBrush who use Blender to convert their content to Second Life via our scripts. We've also users who model in Blender, and take content out to ZBrush for detailing. so a solid Collada implementation for both import and export is a priority for us. The funding I have will cover at least four hours a week spent on Collada issues, so my medium term goal would be to become the maintainer for the Collada features in Blender. Short term goal is to get up to speed with the code base by fixing a few bugs.. Best Wishes, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Mon, 2012-01-09 at 11:43 +0100, Ton Roosendaal wrote about Juan's script: So; Collada users here, please check it the code and report back? As it is at the moment, I found it too buggy to use. It doesn't handle parented objects well at all. My most basic test is a chain of 3 empties, translated and rotated. All 3 imported back at 0,0,0 and the child ones have the wrong rotations. I had a quick look at the code, and decided it was overly simplistic and wouldn't handle a lot of valid cases correctly. A mesh shared between two objects for example, I think would end up stored as two meshes rather than one with multiple links to it. Given how spectacularly it failed on the tests I threw at it, I went back to coding on my own exporter which I started when you announced your preference for dropping Collada. It only does cameras and empties so far though, so it's not a viable alternative yet either :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Mon, 2012-01-09 at 14:30 +0100, François T. wrote: I had a quick look at the code, and decided it was overly simplistic and wouldn't handle a lot of valid cases correctly. A mesh shared between two objects for example, I think would end up stored as two meshes rather than one with multiple links to it. this is too bad because AFAIK collada is well designed to support instances. Actually the entire design of it is based on that (or did collada structure change so much since I looked into it a few years back. I double checked and it does do shared meshes.. So either I'm misremembering the problem, or was just mistaken.. I've 4 different Collada exporters installed for testing so I might be getting their various issues mixed up. Sorry for any confusion.. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Mon, 2012-01-09 at 11:07 -0300, Juan Linietsky wrote: The exporter i submitted handles both parented objects and shared meshes between instances. If you have testcases where this doesn't work, send them over and i'll see what is wrong. I've had a look at the code, and it's a simple fix.. The matrix should come before the node.. *** export_dae_orig.py 2011-10-12 08:33:39.0 +0100 --- export_dae.py 2012-01-09 15:23:21.639603139 + *** class DaeExporter: *** 755 --- 756 + self.writel(S_NODES,il,'matrix sid=transform'+strmtx(node.matrix_local)+'/matrix') *** class DaeExporter: *** 759 - self.writel(S_NODES,il,'matrix sid=transform'+strmtx(node.matrix_local)+'/matrix') --- 759 Best Wishes, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Sat, 2012-01-07 at 12:06 -0300, Juan Linietsky wrote: Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. One thing that would need changing is the handling of libraries. Empty ones should not be included in the .dae - having them there causes compliance errors. Schema validation error: Error: ERROR_VALIDATION_MIN_OCCURS_UNMATCHED Element: library_images, Line: 14, Additional: child: image Best Wishes, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Thu, 2012-01-05 at 13:59 +0600, Sergey Sharybin wrote: I'm not so familiar with this format and not so fan of digging into it deep enough (wanted to concentrate on other things needed for mango and so). But if it's just guiding through blender architecture or communicating people together i can do that. You can count me in on the people to guide. Collada is a key feature for people who use Blender for creating Second Life content. We've just released a commercial script for that which relies on Collada, so I've assigned a portion of the income from the script to fund my time fixing Collada bugs. I'm not yet skilled enough to volunteer as maintainer, but I can volunteer for bug fixing with a long term view to becoming maintainer. So Sergey, if you are happy to act as advisor and code checker for my patches, hopefully we can get the bug count down. I've made a small test file for exporting a rigged mesh that shows 5 seperate bugs in round tripping a Collada export and I'm currently working on fixing these - the first patch from this process is here: http://projects.blender.org/tracker/index.php?func=detailaid=29705group_id=9atid=127 Once these are fixed, I was going to see if the changes fixed any current bugs (I suspect the armature strangeness ones could be affected) and move on from there. The bugs my test file identified were issues with naming of armature and skeleton, armature being exported with a new empty as a root object, armature exported with world based matrix, all local transforms are applied.. The mesh naming problem the patch is for.. Oh and the last bone in a chain also has odd rotation issues.. So I'm currently working on getting up to speed with the codebase with those issues in mind. Best Wishes, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Thu, 2012-01-05 at 23:28 +0100, Brecht Van Lommel wrote: From the point of view of attracting more developers, a python importer seems the best solution, also since there's good python utility code already there from other IO addons. However from what I can see the bpycollada importer is still at prototype level. One concern I have with the bpycollada importer is the use of numpy and datetime modules by pycollada which it's based on. Particularly numpy as it's use seems to be for things like matrix transforms and things that are already possible with bpy. Having an extra dependancy to duplicate features just seems wrong to me.. But the alternative is forking pycollada and rewriting a large chunk to use blender specific features. pycollada also uses pil for some features and that's not available for python 3.. I've not looked closely at how much of a problem that would cause though. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Change Representation and Initialisation of Matrices to Conform with Standard Notation
On Fri, 2011-12-09 at 23:57 +1100, Andrew Hale wrote: Also, note that MatLab stores arrays in column major format but still uses matrix[row, column] for indexing entries. numpy also uses row, column indexing http://docs.scipy.org/doc/numpy/reference/generated/numpy.matrix.html import numpy m = numpy.matrix(1 2; 3 4; 5 6) m matrix([[1, 2], [3, 4], [5, 6]]) m[0] matrix([[1, 2]]) m[0,1] 2 This is the order I'd expect for any matrix implementation without reading any docs too.. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] redo operator with last used settings (patch)
Reply to Douglas E Knapp's comment: Problem is that if you press num 7 top view and add a grid you can't see what is there until you go into edit mode and at that point you can't change it. I know that in a perfect calculated world you would just figure out what you need beforehand but it often does not work out that way. After all we are artists and not math students. :-) You get that same problem with a smooth sphere sometimes to, I want to SEE the verts and lines as I adjust it. Tick this box :) File - User Preferences - Editing - New Objects - Enter Edit Mode ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] sphinx compiling err, anytips
On Thu, 2011-04-07 at 03:21 +, Yousef Hurfoush wrote: i tried to compile api docs using sphinx and i get this error: C:\BlenderSVN\blender\Relblender --background --python ..\doc/python_api/sphinx _doc_gen.py found bundled python: C:\BLENDE~1\blender\Rel\2.56\python Traceback (most recent call last): File string, line 1, in module File string, line 1183, in module File string, line 1141, in main File string, line 1040, in rna2sphinx File string, line 505, in pycontext2sphinx File C:\BLENDE~1\blender\Rel\2.56\python\lib\ctypes\__init__.py, line 340, i n __init__ self._handle = _dlopen(self._name, mode) WindowsError: [Error 126] The specified module could not be found Blender quit C:\BlenderSVN\blender\Rel i have sphinx installed 1.07 and python 2.6 on windows 7 x64 and i have compiled blender successfully. any tips will be welcome :) This looks like the same error that sparked the experimental pydna discussion. If so there's an unofficial hack http://www.pasteall.org/20504 to get it working. I'm not on Windows, so I can't confirm that it's the same, but the error reported by my script users was identical. File C:\BlenderSVN\primstar\image_buffer_raw_access.py, line 75, in _api blend_cdll = ctypes.CDLL() File C:\BLENDE~1\install\win32-vc\2.56\python\lib\ctypes\__init__.py, line 340, in __init__ self._handle = _dlopen(self._name, mode) WindowsError: [Error 126] module not found I guess the real reason for the hack was lost by associating it with pydna, I think it's really to get ctypes working on Windows. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36006] trunk/blender/source/blender/ makesrna/intern/rna_image.c: Fix for slow Image.pixels, make it a flat instead of multidimen
On Mon, 2011-04-04 at 17:10 +, Brecht Van Lommel wrote: Revision: 36006 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=36006 Author: blendix Date: 2011-04-04 17:10:48 + (Mon, 04 Apr 2011) Log Message: --- Fix for slow Image.pixels, make it a flat instead of multidimensional array. That working great now thanks, just one more small patch needed though.. It's just to mark the image as dirty when image.pixels is set :) === modified file 'source/blender/makesrna/intern/rna_image.c' --- source/blender/makesrna/intern/rna_image.c 2011-04-04 17:10:48 + +++ source/blender/makesrna/intern/rna_image.c 2011-04-05 08:29:44 + @@ -304,6 +304,7 @@ for(i = 0; i size; i++) ((unsigned char*)ibuf-rect)[i] = FTOCHAR(values[i]); } + ibuf-userflags |= IB_BITMAPDIRTY; } BKE_image_release_ibuf(ima, lock); ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35976] trunk/blender/source/blender/ makesrna/intern/rna_image.c: Image pixel acces, through Image. pixels as floating point valu
On Sun, 2011-04-03 at 16:17 +, Brecht Van Lommel wrote: Revision: 35976 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35976 Author: blendix Date: 2011-04-03 16:17:39 + (Sun, 03 Apr 2011) Log Message: --- Image pixel acces, through Image.pixels as floating point values. It's not the most efficient solution, but this can be optimized later. It's best to copy out all the pixels at once into a list, rather than accessing them one by one. Thanks for that. It is considerably slower than using pydna, but at least everyone can use it easily :) I've posted a simple ImageBuffer class here http://blenderartists.org/forum/showthread.php?213940-Image-Buffer-Pixel-level-access-to-images Cheers, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Mon, 2011-03-07 at 14:43 +0100, Tobias Oelgarte wrote: That may work for Fedora. But i could not find any packages for Ubuntu 10.10 so far. So i will need to compile python on my own and make a mess out of my system again... I've updated the documentation on how I build Blender with Collada on Ubuntu 10.10 http://wiki.machinimatrix.org/index.php/Development/Building-Blender the trick with python is to use sudo make altinstall so it goes in /usr/local and doesn't overwrite the standard python. just add BF_PYTHON = '/usr/local' BF_PYTHON_VERSION = '3.2m' to your user_config.py and do ln -s /usr/local/lib/python3.2 ../install/linux2/2.56/python/lib/python3.2 after building blender. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] presets.py as_filename bug?
Just spotted this browsing the .py files..
In ./release/scripts/op/presets.py starting at line 35
def _as_filename(self, name): # could reuse for other presets
for char in !...@#$%^*(){}:\;'[],./?:
name = name.replace('.', '_')
return name.lower()
shouldn't it be
def _as_filename(self, name): # could reuse for other presets
for char in !...@#$%^*(){}:\;'[],./?:
name = name.replace(char, '_')
return name.lower()
so all the funky characters are replaced and not just '.'?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC intentions: non-traditional devices
On Wed, 2010-03-31 at 14:34 -0500, Mike Erwin wrote: I'd like to focus on the Intuos4 and SpaceNavigator I like the Second Life approach to handling the SpaceNavigator on Linux which bypasses the 3DConnexions driver completely. http://wiki.secondlife.com/wiki/SpaceNavigator#Linux Life's so much simpler without drivers ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
