Blender interface & scripting
Edward K. Ream
that over a million people download each new release.
blender: http://www.blender.org/
blender scripting: http://wiki.blender.org/index.php/Doc:Manual/Modeling/Scripts
The interface is "dense": This is the first program I've ever used
that required careful study of the manual before I could make sense of
the screen: http://wiki.blender.org/index.php/Doc:Manual/Interface
The default startup screen has a large array of windows and panels.
It's fairly easy to add panels:
http://www.blender.org/documentation/blender_python_api_2_59_0/info_quickstart.html
This is a very cool windowing environment. Perhaps there are some
features Leo could use.
Scripting is straightforward: as in Leo the built-in Python interp
defines several objects automatically, as announced when the built-in
Python 3.2 interp signs on.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> I've been studying blender for the last day or so. The site claims
> that over a million people download each new release.
Too funny. I've used it for years, but only yesterday finally started
delving into the python API. Working on an animated visualization,
will post a link when it's done.
Cheers -Terry
Kent Tenney
http://airplanes3d.net/downloads/pydev/pydev-blender-en.pdf
It's from an interesting site:
http://airplanes3d.net/index_e.html
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
>
Edward K. Ream
> This seems a well written book on Python scripts for Blender using Eclipse.
> http://airplanes3d.net/downloads/pydev/pydev-blender-en.pdf
>
> It's from an interesting site:
> http://airplanes3d.net/index_e.html
Thanks for this. But besides Eclipse, I think I heard somewhere of
this strange IDE called Leo...Wouldn't it be better to define a Leo
window within Blender?
Edward
Edward K. Ream
On Sep 4, 10:16 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> Thanks for this. But besides Eclipse, I think I heard somewhere of
> this strange IDE called Leo...Wouldn't it be better to define a Leo
> window within Blender?
notion that C and Python even need to merge. Sometimes details at non-
Python level just need to be confronted. It's a challenge to my
intuitions, at any rate.
Anyway, building Leo into Blender (as a replacement for the utterly
lame editor) might be the best kind of advert for Leo. It's a form of
marketing that appeals to the coder in me :-)
BTW, the scons build system looks very cool. It's pure Python:
http://www.scons.org/
http://en.wikipedia.org/wiki/SCons
Edward
Edward K. Ream
On Sep 4, 10:50 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> BTW, the scons build system looks very cool. It's pure Python:
>
> http://www.scons.org/
> http://en.wikipedia.org/wiki/SCons
EKR
Gour-Gadadhara Dasa
> BTW, the scons build system looks very cool. It's pure Python:
There is Waf as well (http://code.google.com/p/waf/). ;)
For my own purposes, I hope that Bentoo will be enough
(http://cournape.github.com/Bento/)
Sincerely,
Gour
p.s. Even Scons wiki admits Waf is fast. (see
http://scons.org/wiki/SconsVsOtherBuildTools#Waf)
--
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Kent Tenney
:-]
My interest was at the level of what seemed a clear explanation
of scripting Blender, and a framework to start working within. Blender
has teased me for ages with it's power and confounding interface.
I also have never used Eclipse, I became curious what the fuss was about.
I stil haven't worked rendering into my routine, struggling with customizing
to manage sets of related text files in a standardized way.
Thanks,
Kent
>
> Edward
Terry Brown
Kent Tenney <kte...@gmail.com> wrote:
> This seems a well written book on Python scripts for Blender using Eclipse.
> http://airplanes3d.net/downloads/pydev/pydev-blender-en.pdf
Ok, so after getting past the mis-interpretation that the book was
written using Eclipse :-) that's a great link, hopefully I can use its
notes on integrating Blender and Eclipse to integrate Blender and
Leo :-)
I've been using Blender's built in python editor, it's only so so.
Thanks -Terry
Edward K. Ream
> Ok, so after getting past the mis-interpretation that the book was
> written using Eclipse :-) that's a great link, hopefully I can use its
> notes on integrating Blender and Eclipse to integrate Blender and
> Leo :-)
That would be a great project for the Blender community. One could
imagine the entire book being collapsed into a Leo outline that would
present the bevel operation clearly.
Furthermore, one could also imagine updating Leo's execute-script
command to make it work seamlessly with Blender: this would be a big
collapse in complexity.
Finally, one could imagine helper classes, defined either in the .leo
file, or automatically in the execute-script command, that would
automate any or all aspects of the blender integration.
Please keep us informed about this: integrating Blender and Leo could
be the project that awakens the world to what Leo can do.
Edward
Edward K. Ream
> Please keep us informed about this: integrating Blender and Leo could
> be the project that awakens the world to what Leo can do.
The first step, it seems to me, would be to create an
execute-blender-script command: it's important to get something
working quickly. This would short-circuit several chapters of the
Jaworski book :-) I'll be playing around with this today...
My main idea re blender is that even the best documentation, a la
Jawarski, is no match for simple work flows, tools and helper classes.
Eliminating the need for most documentation will be a revolution in
the blender world...
Once we can execute blender scripts easily, the next step would be to
consider creating a blender gui for Leo. Presumably, this would use
blender's existing outline and status panes, or subclasses thereof.
Obviously, Leo has huge advantages over Eclipse as far as integration goes...
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> Please keep us informed about this: integrating Blender and Leo could
> be the project that awakens the world to what Leo can do.
After a quick skim of the book it seems that it does two things of
merit:
- set up Blender API autocompletion in the Eclipse IDE - this seems to
require special "header file" versions of the Blender API code,
which seems odd given that plenty of other systems introspect python
code without such a step
- hook a debugger into Blender scripts which can breakpoint code in
Eclipse started from Blender.
To be honest I never use debuggers in Python, maybe I should do more,
but tracebacks and print()s usually get me to the problem quite fast.
I used gdb with C/C++, but C/C++ errors are more "exactly which
statement accessed invalid memory", vs. Python's errors closer to the
actual problem domain.
So for me anyway, autocompletion would be great, particularly seeing in
Blender it only works in the Python console, not in the editor, but in
terms of integration of Leo and Blender I feel I'd be 95% there with
"import mycode; reload(mycode)" in the Blender Python console, with
up-arrow, Enter to execute :-}
I guess the answer to autocompletion is the same as the answer to
Kent's question about ctags - I'm not really sure what the current
state of play for autocompletion in Leo is.
Cheers -Terry
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> The first step, it seems to me, would be to create an
> execute-blender-script command: it's important to get something
> working quickly. This would short-circuit several chapters of the
> Jaworski book :-) I'll be playing around with this today...
Be interested to know if you get that going - seems to me Jaworski did
not do that, instead using a helper script activated from a button in
Blender to start the script under development.
Cheers -Terry
Terry Brown
a long running script. Trying to unto that I got this in the console
window:
>>> sys.__stdout__.write('3\n')
2
ha ha ha
Of course it wrote '3\n' to the terminal window from which Blender was
launched. '2' is the number of bytes written, but still, it looks
amusing.
Cheers -Terry
Edward K. Ream
> Be interested to know if you get that going - seems to me Jaworski did
> not do that, instead using a helper script activated from a button in
> Blender to start the script under development.
Rev 4450 contains the first draft of blender work. It's in test.leo:
@button blender-script @key=Alt-7
===========================
'''Run blender_script.py as a blender script.'''
import subprocess
args = [
r"C:\Program Files (x86)\Blender Foundation\Blender\blender.exe",
"-P",
r"C:/prog/blender_script.py", # *************** change as needed.
]
data = subprocess.Popen(args, None)
@file c:/prog/blender_script.py
=======================
print("Hello from c:/prog/blender_script.py")
print('Builtin Modules: bpy, bpy.data, bpy.ops, bpy.props,
bpy.types, bpy.context, bpy.utils, bgl, blf, mathutils')
print('Convenience Imports: from mathutils import *; from math import *')
# import sys
# for z in sys.path:
# print(z)
print('Builtin Modules: bpy, bpy.data, bpy.ops, bpy.props,
bpy.types, bpy.context, bpy.utils, bgl, blf, mathutils')
print('Convenience Imports: from mathutils import *; from math import *')
# from mathutils import *
# from math import *
import bpy
C = bpy.context
print('\ndir()...')
for z in dir():
print(z)
print('\ndir(bpy)...')
for z in dir(bpy):
print(z)
print('\ndir(C)...')
for z in dir(C):
print(z)
This shows that the environment in which the script executes is
basically the same as the environment that scripts execute in the
blender python console.
The drawback, at present, is that each Alt-7 brings up a new copy of
blender: I haven't found a way of connecting the script to an
already-running blender as is done in the vim plugin with vim's server
option.
Edward
Terry Brown
import sys
import imp
sys.path.append('/home/tbrown/Desktop/Blender/mnbba')
file, pathname, description = imp.find_module('mnbba02')
imp.load_module('mnbba02', file, pathname, description)
Basically a forced import of the module being developed, a simple
import mnbba02; imp.reload(mnbba02) doesn't work because it runs the
code twice the first time, and import mnbba02 by itself only works once.
Place this in the Blender *Text* window (not Python console), and click
the Run Script button in blender to run. print() output goes to the
terminal window which launched Blender.
But autocompletion in Leo would sure be nice.
Cheers -Terry
Edward K. Ream
> Here's my Leo/Blender integration script :-)
Yes. There are almost too many ways got get the job done.
Another way would simply be to have Leo write files to the blender
scripts folder, or the addons or modules subfolders.
> Basically a forced import of the module being developed, a simple
> import mnbba02; imp.reload(mnbba02) doesn't work because it runs the
> code twice the first time, and import mnbba02 by itself only works once.
>
> Place this in the Blender *Text* window (not Python console), and click
> the Run Script button in blender to run. print() output goes to the
> terminal window which launched Blender.
I think you could also do:
try:
del mnbba02
except Exception:
pass
import mnbba02
> But autocompletion in Leo would sure be nice.
Yes.
I'm also playing around with various ways of initing blender on
startup. The -P option works. But apparently blender/Lib/site.py is
*not* executed on startup, so neither is sitecustomize.py. Indeed
importing the site module causes any message printed by
sitecustomize.py to be displayed (the first time only, of course).
It's a bit strange...
I feel somewhat like the early days of Leo/IPython integration. There
is a sense that relatively small hacks could produce great things.
Edward
Edward K. Ream
> I'm also playing around with various ways of initing blender on
> startup. The -P option works. But apparently blender/Lib/site.py is
> *not* executed on startup, so neither is sitecustomize.py.
Curiouser and curiouser: -P site.py fails with sysexit(10). -P
sitecustomize.py works.
Oh well. It would probably be clear to do something like -P
ekr_blender_init.py.
Edward
Edward K. Ream
> ... in terms of integration of Leo and Blender I feel I'd be 95% there with
> "import mycode; reload(mycode)" in the Blender Python console, with
> up-arrow, Enter to execute :-}
I understand this remark now. One could develop in Leo, having Leo
write files to standard blender places, and then use a forced import
in blender to get access to the code.
This is certainly good enough for now.
The point about autocompletion, I suppose, is that the blender api is
large, and it's a little hard to know where to start, so any help is
useful.
On a complete newbie note: I discovered that the "save user settings"
saves the present screen layout, including window size, window
arrangement, font sizes, etc. It doesn't save the state of the
console window, though :-) However, it should be possible to pre-load
the code under test in ekr_blender_init.py. We shall see...
Edward
Edward K. Ream
> But autocompletion in Leo would sure be nice.
It is becoming clear that absolutely everything is possible.
Indeed, the bulk of blender is python code: the C code merely provides
"services".
I am busy studying the python code in the blender/scripts and
blender/python folders. The blender/scripts/modules folder is
probably what we want.
The only question is, how best to hook into blender? I don't know a
clean way yet, but even ugly ways will work.
Example: the "signon" message in the blender Python console is put
there by Python code. We could monkey-patch that code to do anything
we want.
Presumably, the "autocomplete" button in blender executes Python code.
So Leo can execute that code!
Indeed, we can execute Leo *from blender*, say at startup time. That
will make all the blender data available to Leo. Some simple bridges
will make the autocompletion code available to Leo, as well as
everything else!
Do you see? We can make Leo be a part of blender!
Edward
Edward K. Ream
> Do you see? We can make Leo be a part of blender!
Well, maybe. Strange things are going on:
- The code in blender/scripts/modules/console_python.py:banner()
apparently puts up the console prompt.
- However, changing the banner function in console_python.py does not
change the console prompt.
- There are no .pyc or .pyo files anywhere. There is a
blender/scripts/modules/__pycache__ directory, but it never changes,
not even when I change console_python.py.
Anyone have an idea about what is going on?
Edward
Edward K. Ream
> On Mon, Sep 5, 2011 at 4:55 PM, Edward K. Ream <edre...@gmail.com> wrote:
>
>> Do you see? We can make Leo be a part of blender!
>
> Well, maybe. Strange things are going on:
>
> - The code in blender/scripts/modules/console_python.py:banner()
> apparently puts up the console prompt.
When I import console_python, the console reports:
<module 'console_python' from 'C:\Program Files (x86)\Blender
Foundation\Blender\2.59\scripts\modules\console_python.py'>
But when I change banner, say by making it return return {'FINISHED2'}
instead of return {'FINISHED'}, the result is still return
{'FINISHED'}
This is totally weird. Deleting the __pycache__ directory has no
obvious effect.
Edward
Edward K. Ream
> When I import console_python, the console reports:
>
> <module 'console_python' from 'C:\Program Files (x86)\Blender
> Foundation\Blender\2.59\scripts\modules\console_python.py'>
>
> But when I change banner, say by making it return return {'FINISHED2'}
> instead of return {'FINISHED'}, the result is still return
> {'FINISHED'}
>
> This is totally weird. Deleting the __pycache__ directory has no
> obvious effect.
From the console:
for z in sys.path: print(z)
yields:
C:\Program Files (x86)\Blender Foundation\Blender\2.59\scripts\addons
C:\Program Files (x86)\Blender Foundation\Blender\2.59\scripts\startup
C:\Program Files (x86)\Blender Foundation\Blender\2.59\scripts\modules
C:\Program Files (x86)\Blender Foundation\Blender\2.59\python
C:\Program Files (x86)\Blender Foundation\Blender\python32.zip
C:\Program Files (x86)\Blender Foundation\Blender\2.59\python\DLLs
C:\Program Files (x86)\Blender Foundation\Blender\2.59\python\lib
C:\Program Files (x86)\Blender Foundation\Blender
C:\Program Files (x86)\Blender Foundation\Blender\2.59\scripts\addons\modules
There are no .pyc, pyo files in these locations, and there no cache
file corresponding to console_python.py in any __pycache__ directories
in these locations.
EKR
Edward K. Ream
On Sep 6, 7:04 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> > This is totally weird.
Another very weird thing. It seems to be impossible on my Windows 7
system to turn off the "read only" bits on various files.
EKR
Edward K. Ream
On Sep 6, 7:12 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> Another very weird thing. It seems to be impossible on my Windows 7
> system to turn off the "read only" bits on various files.
modification date of the file didn't change!!!!! Reloading the file
verifies that its contents *did* change.
This would explain a lot ;-)
EKR
Edward K. Ream
On Sep 6, 7:18 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> The weirdest thing of all. I just changed console_python.py, but the
> modification date of the file didn't change!!!!! Reloading the file
> verifies that its contents *did* change.
>
> This would explain a lot ;-)
I checked the disk for errors. There were none.
I have finally been able to change the file. To do this, I moved the
file out of the blender tree entirely(!!)
Amazingly, what I saw was the *unchanged* (original) file. I changed
the file outside the blender tree, then moved the file back into the
blender tree. Now the change "took".
What I don't understand is where the new versions were stored!!! This
may be some kind of deep Windows mystery, possibly abetted by Blenders
caching mechanisms.
Anyway, I can now add something to the blender signon, which means,
presumably, that I can patch any blender Python code. Hooray.
Note that there was a longish delay on blender startup after the
change, but later startups went very quickly.
Edward
vitalije
HTH
Vitalije
vitalije
Vitalije
Edward K. Ream
> I am not sure about Windows 7, but I have noticed in Windows Vista that
> Program Files folder doesn't accept changes unless you are running program
> as administrator. All changes that program make in subtree of C:\Program
> Files\ are stored in subfolder of C:\Documents and
> Settings\username\AppData\Roaming\...
Thanks for this. I had searched for the changed files, but not there.
That's why I used to install almost
> all programs not in default location C:\Program Files\ but in some other
> like C:\myprograms\ .
Just reinstalled in c:\blender
Edward
Matt Wilkie
> That's why I used to install almost
> all programs not in default location C:\Program Files\ but in some other
> like C:\myprograms\ .
for what it's worth, I install self contained programs to c:\apps,
have c:\bin in %path%, and put junction links or batch files in c:\bin
that point to the relevant apps folder. This lets me keep %path%
relatively short and reduces the number of files searched when looking
for commands (and dropped my encounters with dll-hell to manageable
background noise!).
>... username\AppData\Roaming\.
For stuff that's truly "roaming" I have B:\bin and B:\apps, where B:
is mapped to a dropbox folder tree that is automatically synchronized
across all my computers. I used to use the SUBST command but ran into
problems with that a few months ago and am now using NET:
net use B: \\localhost\c$\users\%username%\dropbox
This leo+blender integration work sounds really exciting. Blender is
one of the programs I keep looking at every so often, simply because
it's so cool and such a vibrant community, but have never actually
used.
cheers,
-matt
Edward K. Ream
> for what it's worth, I install self contained programs to c:\apps,
> have c:\bin in %path%, and put junction links or batch files in c:\bin
> that point to the relevant apps folder. This lets me keep %path%
> relatively short and reduces the number of files searched when looking
> for commands (and dropped my encounters with dll-hell to manageable
> background noise!).
Thanks for these tips. I have c:\scripts for too much. Having c:\bin
and c:\apps is an elegant solution. And I had not considered that
c:\bin would dramatically shorten the path.
Edward
Edward K. Ream
> This leo+blender integration work sounds really exciting. Blender is
> one of the programs I keep looking at every so often, simply because
> it's so cool and such a vibrant community, but have never actually
> used.
My initial enthusiasm is wearing off a bit.
The blender api and docs are difficult. This seems like a serious hurdle.
It would be good to have a proper bridge between Leo and blender, as
with vim and xemacs. Not sure whether it is possible.
The alternative is creating a blender gui so that Leo becomes a part
of blender. That's a major project, perhaps justified.
Edward