The bad part is that it's all Python, while QC uses Cocoa. smokris has had success using C++ inside some plugins (though C++, C, and Cocoa are all closely related), so maybe Python is possible too (I've not used it, but I've heard it's pretty flexible). I'll try to figure out feasibility shortly (need to get structure tools beta 4 out first...)
[p.s. it's all MIT licensed, how cool is that?!]
[p.p.s looks like PyObjc should make this fairly painless. Nice.]
it would be interesting to evaluate what the options are for 2D work, and the feasibilities of them.
at the basic end i guess you have a simple 2Dtools set of nodes, then you have something like a SVGtools set of nodes that deal with importing, modifying and displaying the SVG format, then you have something crazy like a wrapper for nodebox code, with its fanciness such as importing illustrator files.
hey Chris, thanks for the link. That R seems really promising, esp the time-series analysis.... Looking forward into seeing this implemented into some sort of gesture analysis plug...
We actually use R with some custom processing here at work to make pretty charts and tables with stats. Not as interesting as QC stuff, and no real-time constraints, but from what I've seen it's a pretty useful library (smokris fixed a bug or two last fall, so he's much more familiar with actually using it than I am)
ok, so I was talking to stefan of neongolden earlier today, and he dropped some links to some more nodebox internals.
About a month or two ago, I was talking to Yanomano about programmable patches (there's probably a topic around here somewhere on that). These are very complex in QC, so we'd probably make a very limited programmable patch at first, until we know what we're doing.
Being slow sometimes, I've just now connected the dots: An embedded python path with OpenGL, NodeBox, and other bindings (maybe opencv? these aren't stable from my experience..). We'll have to have a red patch (for ogl stuff) and a blue/green patch (for generative image/value stuff).
Ok, so, Python is pretty cool. I totally have no idea what I'm doing yet, so it's pretty crazy, but here's a screenie of python + PyOpenGL bindings:
This isn't even touching Nodebox yet (that should be simple once I figure out what I'm doing).
[Edit: I had the framerate limited to 10fps for some testing on another patch. It's not really that slow ;) -- and, obviously, the "Suspend Execution" checkbox doesn't do anything ;)]
[Edit 2: Actually, python isn't really that cool. I like the concepts, but the implementation leaves a bit to be desired... Objective-C has more introspection capabilities, which is necessary for dynamic port stuff.... it's getting a bit messy now...]
That explains why Leopard was delayed, why CoreImage still doesn't quite work correctly, why GLSL is broken, and why Vista took 6 years... we're taking all the coders for ourselves ;)
Here's some more, just for fun. I've added a simple init-detection system for simple animation (this could have been done before by getting the system time or something... I don't know enough python to do that). This keeps us from loading the pymodules every frame (~1.5-2x faster, 240fps->470fps)
Next up, adding number and string inputs. these will be key/value pairs, so you'll actually be setting variables via dynamically-generated python code; this seems much simpler than the Tuple/Arg/Keyword parsing stuff that they don't document well (I've not been able to get these to do anything but crash or stall execution... not useful). Maybe outputs will be from input strings too (it'll query variables when it's done executing?). If there are any python hackers in the audience, speaking up now will save a lot of hair-pulling for everyone ;)
Images are another matter... I can do input images for use with GL (I'll just load the image as normal before entering the python code, so it's all ready to go), but output images appear to be more difficult.
Sorry for learning as I go on this... it'll probably be a really ugly ride for a while due to that :/
Python dev's apparently don't speak or use C, so there's a huge language barrier when trying to get things done ("Why not just rewrite the whole app in Python, so you don't have to deal with this hard stuff?" ... haha :)
Another bad turn: Mac OS X's built-in Python framework is standard python, and we need Stackless Python (otherwise, when one python patch generates an error, all the others stop functioning as well... could hack around this, but I'd rather each just have its own state. Honestly; who decides to write an object-oriented interpreter that itself isn't object oriented? global variables... meh.)
[EDIT: as a side effect of Not using stackless, each patch can share variables... this might be a useful feature to keep in, with the caveat that crashing one patch will reset the others.. thoughts?]
I just want to stick up for Python. I've been using it for many years and I really love it.
Earlier you mention that Python doesn't have enough introspection to do dynamic stuff. This is absolutely not true. I'd be happy to work with you to help you get this working.
Also I'm not sure why you think you need stackless. There are many reasonable ways to keep one stopped task from impeding others without using stackless.
Please don't give up on Python. As I said I'd be happy to do what I can to help you with any problems you run into.
Thank you amos :) I have no doubt that it's good (there's a considerable amount of well-written software that uses it, and it's simple to whip up not-so-well-written proof-of-concept stuff with it as well). It's not my intention to start a flamewar or badmouth python.
However, putting stuff into QC does stress the design of many libraries (only OpenGL has held up without issue. OpenCV has quite a list of 'hates' after fitting the half-dozen functions into QC, and that's the simple stuff).
I may be using "introspection" in a way different from most programmers: I have a PyCodeObject (in C), I want to get the number of functions, their names, and their parameter count. Bonus points if it's possible to tell if a parameter is a number rather than a string. All sources I have indicate that this is Not Possible without considerable hacking. Unfortunately, this is necessary for the patch to create input ports that drive Python functions. (without using the dynamic code hack I mentioned).
How does one keep a stopped task from halting the interpreter? If I do a "x = 1 + X", and X is undefined, it parses and compiles just fine, but executing it causes all subsequent calls to PyEval_EvalCodeEx to do nothing. clearing the error doesn't seem to correct it, so the next best thing is to close the (global!) interpreter, create a new one, and tell all the other Python patches to recompile (since their compiled objects are invalidated when the first interpreter was closed). Stackless solves this "The Correct Way" in my opinion: independent interpreters rather than a single global one, so only the crashed interpreter needs to get restarted, all the others don't care. Threads are not a solution to this problem since QC is serially executed. If there's a way to do this without using stackless, I'd love to do that (mostly because stackless will make the plugin an additional 10MB, compared to its current few hundred KB).
I'm sure many of these issues are simply because I don't know Python all that well yet.
I have no intention of giving up (at least, not yet). I'm just frustrated that all the feedback I've received so far in trying to solve these problems is in the form of "ZOMG, LOL. Write all your codes in teh Python!" ;)
Please e-mail me and we'll discuss this more. I'm quite interested to know what provisions I should make to help native python developers enjoy the environment, and work around these basic interface issues.
A python patch would be excellent. Especially combined with opengl! I don't know how this would work with QC though, and how the output would be mixed in, but I guess it should be possible.
I've not used nodebox, so I can't really comment on that.
It is evident that we need something to generate a lot of animable shapes in one pass. (a la "processing" )
We need two types of "vector shapes" : 2D and 3D.
We have a cool patch to do this : "iterator", but it is soo slow because there are lot of redundancy in code with the patches you put on it, and lot of math inside to animate each layer.
If the iterator should analyse these redundancies and should keep just the code needed it could be very fast.
It could generate more iteration with less GPU consuming. For the math that are computed inside, perhaps there is a way do puts them outside and just pass a structure of data.
My idea is : a "supa iterator" patch that could analyse redundancy and keep his power just for DRAW not "glQuad..., gl end. glQuad...,glend.glQuad...,glend.glQuad...,glend." just to draw 4 quad...:)
As strange as it sounds, I think the way iterators work currently is "the right way" for them to work. Analyzing patch code live to cut out redundant GL state transitions is Impossibly difficult to do (in fact, it might be impossible period; the Halting Problem and all).
A faster "Right Way" that I've been thinking about is something a cross between QC's structures and VVVV's "spreads" (arrays). If the GLTools patches are modified to accept structure inputs, they can skip the redundancy themselves and draw multiple objects. This could also be the case for Kineme3D (structure of objects).
I've not done anything to actually use this, but after 10 seconds of thinking about it, it seems like a more promising route (and, it doesn't require writing an interpreter/parser for PPC, PPC64, x86, and x86_64, which is an incomprehensible amount of work ;)
So patches should "autoclone" their entity themselves !...:)
Spreads principes seems to be cools :
linear, circular, random, etc...
It make me think the way After Effects can animate typography :
You define the properties to animate ex: position, then you enter a X,Y position Offset.
After, with a "selector" you define where the offset is acting in the "array of letters" with start and end point.This selection is animable and it can be also offset (+-) or if you prefer :You can animate the range that affects the propertie...
interpolations are done between the last and the new values...
I you can put this principe to modify strutures on the fly it
could be awsome !
yanomano: that's exactly how my scroller composition works, using iterator, so things like this are already possible.
You just animate the object using an LFO connected to the x/y/whatever input, and use iterator variables to modify the phase of the LFO. That offsets each letter. It's possible to use count or whatever else too, and just offset with a math patch. Animating the offset is easy once you do that.
Modifying structures on the fly is probably possible using queue and a feedback loop too, although I've not tried it. I have noticed that once a queue is full, it shifts it's contents to make space for the next entry, so you could (ab)use that to make an alternative to iterator with a bit of thinking.
GLTools that accepts structures would definitely be great, but it instantly made me think that a structure of structures is necessary (say for groups of custom objects). I'd guess it's already there, but I've not had reason to test it yet, so anyone know if it works?
Don't know if you now this app : Context free
but it is very cool to generate image from instructions...
http://www.contextfreeart.org/
It can generate more than 200000 shapes a second...:)
this looks like an interesting app, but since it's an application (not a library), it would be a bit trickier to embed into qc.
I looked over the page, but couldn't find anything that indicated it handling animation. does it do animation, or just static images? If it's static images, it wouldn't be too useful (except for 64k demos, where the instructions would save a lot of space over a bitmap :)
It is not doing animation.
But it can render "construction" on Quicktime.
The link was just to give ideas...:)
The way this app generate his image with simple code is awsome...
Some more 'idea material', more visual programming based like QC, but both adaptable for programmable style generation too.
Werkkzeug, again. This is the texture generator from v3 (which isn't released other than the texture generator). This is amazingly powerful, and all built from small steps. It's also windows only unfortunately. It's what they did the textures for kkrieger (the 96k game) and debris (the 170k demo) with, both available here (both well worth watching if you have windows and have any interest in graphics + programming).
Toolbox, a mac app that works similarly to werkzeug TE, but in a more apple kind of way, and I guess using CI stuff.
A couple of screenshots from some parts of toolbox that are under development at the moment:
Polygon editor - this looks great. You build up a chain of processors much like qc, then draw in the editor, it generates the polygons and shows it with the applied processing in realtime.
Supershapes - this would also be VERY handy in QC.
These looks like they'd be way handy for geometry generation in QC (more kineme3d ideas, heh heh). It's difficult to tell where polys begin and textures end though. All of those could be just textures with nice filters to give them apparent depth.
Neoneye finished up a new public release of toolbox, including lots of vector stuff. I'm too busy getting my demo finished off to play with it, but from the videos + screenshots i've seen it looks brilliant - you hand-draw vectors, and then you can smooth, quantize etc., and apply loads of filters QC style.
A short way off topic here, but could be handy to know. QC already supports vector art "a bit". I had some vector art that I need to use in my current project, so just as an experiment I tried it with image downloader. It outputs it as a pixel image, nicely anti-aliased :)
That art was in .pdf format - I have the original .eps file I think, so I'll try that too. There is, naturally a catch... there's no way to set the output image size within QC. I guess by the random-looking size I got that it renders according to the pdf document size, at say 72dpi (and hopefully not the screen dpi, which could be variable!)
Hi together, just wanted to let you know that there is now a branch of nodebox around which has already Open-GL-Bindings and renders in an Open-GL-Context. Maybe thats even easier to connect. Is basicly a command-line version with a small framework code.
maybe someone here is able and interessted to put that into a plugin :-)
best, stefan
-- the readme.txt
NodeBox is a framework that lets you create interactive 2D visuals using OpenGL.
Documentation is still a bit lacking, but you can run python generate_epydoc.py to
generate API documentation (using Epydoc: http://epydoc.sourceforge.net/).
All the bezier math is included. There is text support as well, as well as an offscreen renderer and the start of some shaders (blur, colorize, gradient). There are also some powerful classes that are not in NodeBox:
- Transition: for motion tweening
- Layer: variable origin point, tweened group of shapes
- Animation: slideshow of images.
There is no documentation, so you will have to dig into the source. If you fix bugs along the way, please keep a list of where you found them, as there is no version control yet.
Importing libraries may or may not work out of the box, I haven't tested it yet.
REQUIREMENTS
You'll need:
- Python 2.5
- Pyglet: http://www.pyglet.org/
- at the command line in the nodebox folder, type: python -O example.py
Their stuff looks really good.
The bad part is that it's all Python, while QC uses Cocoa. smokris has had success using C++ inside some plugins (though C++, C, and Cocoa are all closely related), so maybe Python is possible too (I've not used it, but I've heard it's pretty flexible). I'll try to figure out feasibility shortly (need to get structure tools beta 4 out first...)
[p.s. it's all MIT licensed, how cool is that?!]
[p.p.s looks like PyObjc should make this fairly painless. Nice.]
it would be interesting to evaluate what the options are for 2D work, and the feasibilities of them.
at the basic end i guess you have a simple 2Dtools set of nodes, then you have something like a SVGtools set of nodes that deal with importing, modifying and displaying the SVG format, then you have something crazy like a wrapper for nodebox code, with its fanciness such as importing illustrator files.
need to include an r-project.org wrapper too, while we're at it.
hey Chris, thanks for the link. That R seems really promising, esp the time-series analysis.... Looking forward into seeing this implemented into some sort of gesture analysis plug...
We actually use R with some custom processing here at work to make pretty charts and tables with stats. Not as interesting as QC stuff, and no real-time constraints, but from what I've seen it's a pretty useful library (smokris fixed a bug or two last fall, so he's much more familiar with actually using it than I am)
No, at Yon Reptile Campaign we've actually been using RLIB, not r-project (confusingly similar). But r-project looks pretty useful too.
oops, I thought rlib was the core of the r-project. My mistake :)
Smorkis and cwright : you are brillant !
yanomano.
ok, so I was talking to stefan of neongolden earlier today, and he dropped some links to some more nodebox internals.
About a month or two ago, I was talking to Yanomano about programmable patches (there's probably a topic around here somewhere on that). These are very complex in QC, so we'd probably make a very limited programmable patch at first, until we know what we're doing.
Being slow sometimes, I've just now connected the dots: An embedded python path with OpenGL, NodeBox, and other bindings (maybe opencv? these aren't stable from my experience..). We'll have to have a red patch (for ogl stuff) and a blue/green patch (for generative image/value stuff).
Is this sane? or is this the stupidest idea ever?
yeah yeah yeah
Ok, so, Python is pretty cool. I totally have no idea what I'm doing yet, so it's pretty crazy, but here's a screenie of python + PyOpenGL bindings:
This isn't even touching Nodebox yet (that should be simple once I figure out what I'm doing).
[Edit: I had the framerate limited to 10fps for some testing on another patch. It's not really that slow ;) -- and, obviously, the "Suspend Execution" checkbox doesn't do anything ;)]
[Edit 2: Actually, python isn't really that cool. I like the concepts, but the implementation leaves a bit to be desired... Objective-C has more introspection capabilities, which is necessary for dynamic port stuff.... it's getting a bit messy now...]
it's smelling good....I love when you start to post screencapture....:)
yanomano.
Seriously, have you got a sweatshop in India or something working on all this stuff?! =)
Kineme secretly developed a brain controller, and now they can tele-drive half of indian devs to code QC plugs.
That explains why Leopard was delayed, why CoreImage still doesn't quite work correctly, why GLSL is broken, and why Vista took 6 years... we're taking all the coders for ourselves ;)
i can't believe how fast you got the first results :-)
would be such a powerful tool if we could feed values from qc into python/nodebox and get back an image for further processing in qc ...
that stuff makes me happy...
Here's some more, just for fun. I've added a simple init-detection system for simple animation (this could have been done before by getting the system time or something... I don't know enough python to do that). This keeps us from loading the pymodules every frame (~1.5-2x faster, 240fps->470fps)
Next up, adding number and string inputs. these will be key/value pairs, so you'll actually be setting variables via dynamically-generated python code; this seems much simpler than the Tuple/Arg/Keyword parsing stuff that they don't document well (I've not been able to get these to do anything but crash or stall execution... not useful). Maybe outputs will be from input strings too (it'll query variables when it's done executing?). If there are any python hackers in the audience, speaking up now will save a lot of hair-pulling for everyone ;)
Images are another matter... I can do input images for use with GL (I'll just load the image as normal before entering the python code, so it's all ready to go), but output images appear to be more difficult.
Sorry for learning as I go on this... it'll probably be a really ugly ride for a while due to that :/
Are you building the Transamerica tower ?...:)
yanomano.
Python dev's apparently don't speak or use C, so there's a huge language barrier when trying to get things done ("Why not just rewrite the whole app in Python, so you don't have to deal with this hard stuff?" ... haha :)
Another bad turn: Mac OS X's built-in Python framework is standard python, and we need Stackless Python (otherwise, when one python patch generates an error, all the others stop functioning as well... could hack around this, but I'd rather each just have its own state. Honestly; who decides to write an object-oriented interpreter that itself isn't object oriented? global variables... meh.)
[EDIT: as a side effect of Not using stackless, each patch can share variables... this might be a useful feature to keep in, with the caveat that crashing one patch will reset the others.. thoughts?]
I just want to stick up for Python. I've been using it for many years and I really love it.
Earlier you mention that Python doesn't have enough introspection to do dynamic stuff. This is absolutely not true. I'd be happy to work with you to help you get this working.
Also I'm not sure why you think you need stackless. There are many reasonable ways to keep one stopped task from impeding others without using stackless.
Please don't give up on Python. As I said I'd be happy to do what I can to help you with any problems you run into.
Thank you amos :) I have no doubt that it's good (there's a considerable amount of well-written software that uses it, and it's simple to whip up not-so-well-written proof-of-concept stuff with it as well). It's not my intention to start a flamewar or badmouth python.
However, putting stuff into QC does stress the design of many libraries (only OpenGL has held up without issue. OpenCV has quite a list of 'hates' after fitting the half-dozen functions into QC, and that's the simple stuff).
I may be using "introspection" in a way different from most programmers: I have a PyCodeObject (in C), I want to get the number of functions, their names, and their parameter count. Bonus points if it's possible to tell if a parameter is a number rather than a string. All sources I have indicate that this is Not Possible without considerable hacking. Unfortunately, this is necessary for the patch to create input ports that drive Python functions. (without using the dynamic code hack I mentioned).
How does one keep a stopped task from halting the interpreter? If I do a "x = 1 + X", and X is undefined, it parses and compiles just fine, but executing it causes all subsequent calls to PyEval_EvalCodeEx to do nothing. clearing the error doesn't seem to correct it, so the next best thing is to close the (global!) interpreter, create a new one, and tell all the other Python patches to recompile (since their compiled objects are invalidated when the first interpreter was closed). Stackless solves this "The Correct Way" in my opinion: independent interpreters rather than a single global one, so only the crashed interpreter needs to get restarted, all the others don't care. Threads are not a solution to this problem since QC is serially executed. If there's a way to do this without using stackless, I'd love to do that (mostly because stackless will make the plugin an additional 10MB, compared to its current few hundred KB).
I'm sure many of these issues are simply because I don't know Python all that well yet.
I have no intention of giving up (at least, not yet). I'm just frustrated that all the feedback I've received so far in trying to solve these problems is in the form of "ZOMG, LOL. Write all your codes in teh Python!" ;)
Please e-mail me and we'll discuss this more. I'm quite interested to know what provisions I should make to help native python developers enjoy the environment, and work around these basic interface issues.
A python patch would be excellent. Especially combined with opengl! I don't know how this would work with QC though, and how the output would be mixed in, but I guess it should be possible.
I've not used nodebox, so I can't really comment on that.
Good luck with it!
It is evident that we need something to generate a lot of animable shapes in one pass. (a la "processing" ) We need two types of "vector shapes" : 2D and 3D. We have a cool patch to do this : "iterator", but it is soo slow because there are lot of redundancy in code with the patches you put on it, and lot of math inside to animate each layer. If the iterator should analyse these redundancies and should keep just the code needed it could be very fast. It could generate more iteration with less GPU consuming. For the math that are computed inside, perhaps there is a way do puts them outside and just pass a structure of data. My idea is : a "supa iterator" patch that could analyse redundancy and keep his power just for DRAW not "glQuad..., gl end. glQuad...,glend.glQuad...,glend.glQuad...,glend." just to draw 4 quad...:)
As strange as it sounds, I think the way iterators work currently is "the right way" for them to work. Analyzing patch code live to cut out redundant GL state transitions is Impossibly difficult to do (in fact, it might be impossible period; the Halting Problem and all).
A faster "Right Way" that I've been thinking about is something a cross between QC's structures and VVVV's "spreads" (arrays). If the GLTools patches are modified to accept structure inputs, they can skip the redundancy themselves and draw multiple objects. This could also be the case for Kineme3D (structure of objects).
I've not done anything to actually use this, but after 10 seconds of thinking about it, it seems like a more promising route (and, it doesn't require writing an interpreter/parser for PPC, PPC64, x86, and x86_64, which is an incomprehensible amount of work ;)
So patches should "autoclone" their entity themselves !...:) Spreads principes seems to be cools : linear, circular, random, etc... It make me think the way After Effects can animate typography : You define the properties to animate ex: position, then you enter a X,Y position Offset. After, with a "selector" you define where the offset is acting in the "array of letters" with start and end point.This selection is animable and it can be also offset (+-) or if you prefer :You can animate the range that affects the propertie... interpolations are done between the last and the new values...
I you can put this principe to modify strutures on the fly it could be awsome !
yanomano.
Imagine a structure with : position, rotation, scale ,argb color, etc...members.
See the file.
yanomano: that's exactly how my scroller composition works, using iterator, so things like this are already possible.
You just animate the object using an LFO connected to the x/y/whatever input, and use iterator variables to modify the phase of the LFO. That offsets each letter. It's possible to use count or whatever else too, and just offset with a math patch. Animating the offset is easy once you do that.
Modifying structures on the fly is probably possible using queue and a feedback loop too, although I've not tried it. I have noticed that once a queue is full, it shifts it's contents to make space for the next entry, so you could (ab)use that to make an alternative to iterator with a bit of thinking.
GLTools that accepts structures would definitely be great, but it instantly made me think that a structure of structures is necessary (say for groups of custom objects). I'd guess it's already there, but I've not had reason to test it yet, so anyone know if it works?
you're able to put structures in structures. Directory Scanner is a built-in patch that does just this (it outputs a structure of file structures)
[StructureMaker supports this too; it's used in the opencv videotrack demo]
Don't know if you now this app : Context free but it is very cool to generate image from instructions... http://www.contextfreeart.org/ It can generate more than 200000 shapes a second...:)
yanomano.
this looks like an interesting app, but since it's an application (not a library), it would be a bit trickier to embed into qc.
I looked over the page, but couldn't find anything that indicated it handling animation. does it do animation, or just static images? If it's static images, it wouldn't be too useful (except for 64k demos, where the instructions would save a lot of space over a bitmap :)
It is not doing animation. But it can render "construction" on Quicktime. The link was just to give ideas...:) The way this app generate his image with simple code is awsome...
yanomano.
Some more 'idea material', more visual programming based like QC, but both adaptable for programmable style generation too.
Werkkzeug, again. This is the texture generator from v3 (which isn't released other than the texture generator). This is amazingly powerful, and all built from small steps. It's also windows only unfortunately. It's what they did the textures for kkrieger (the 96k game) and debris (the 170k demo) with, both available here (both well worth watching if you have windows and have any interest in graphics + programming).
Toolbox, a mac app that works similarly to werkzeug TE, but in a more apple kind of way, and I guess using CI stuff.
A couple of screenshots from some parts of toolbox that are under development at the moment:
Polygon editor - this looks great. You build up a chain of processors much like qc, then draw in the editor, it generates the polygons and shows it with the applied processing in realtime.
Supershapes - this would also be VERY handy in QC.
These looks like they'd be way handy for geometry generation in QC (more kineme3d ideas, heh heh). It's difficult to tell where polys begin and textures end though. All of those could be just textures with nice filters to give them apparent depth.
Thanks for the links :)
Here's a video showing the spline tools in action, I guess the polygons work the same way: http://www.youtube.com/watch?v=dRpzKAYuOt8
I talk to the developer most days on IRC, he's doing some really interesting stuff with it :)
Neoneye finished up a new public release of toolbox, including lots of vector stuff. I'm too busy getting my demo finished off to play with it, but from the videos + screenshots i've seen it looks brilliant - you hand-draw vectors, and then you can smooth, quantize etc., and apply loads of filters QC style.
http://www.toolboxapp.com
I have been playing around with NodeBox for awhile and loading that stuff into qc, so this would be amazing.
A short way off topic here, but could be handy to know. QC already supports vector art "a bit". I had some vector art that I need to use in my current project, so just as an experiment I tried it with image downloader. It outputs it as a pixel image, nicely anti-aliased :)
That art was in .pdf format - I have the original .eps file I think, so I'll try that too. There is, naturally a catch... there's no way to set the output image size within QC. I guess by the random-looking size I got that it renders according to the pdf document size, at say 72dpi (and hopefully not the screen dpi, which could be variable!)
Hi together, just wanted to let you know that there is now a branch of nodebox around which has already Open-GL-Bindings and renders in an Open-GL-Context. Maybe thats even easier to connect. Is basicly a command-line version with a small framework code.
you can get it here via subversion
http://dev.nodebox.net/browser/nodebox-gl/trunk
maybe someone here is able and interessted to put that into a plugin :-)
best, stefan
-- the readme.txt
NodeBox is a framework that lets you create interactive 2D visuals using OpenGL.
Documentation is still a bit lacking, but you can run python generate_epydoc.py to generate API documentation (using Epydoc: http://epydoc.sourceforge.net/).
All the bezier math is included. There is text support as well, as well as an offscreen renderer and the start of some shaders (blur, colorize, gradient). There are also some powerful classes that are not in NodeBox: - Transition: for motion tweening - Layer: variable origin point, tweened group of shapes - Animation: slideshow of images.
There is no documentation, so you will have to dig into the source. If you fix bugs along the way, please keep a list of where you found them, as there is no version control yet.
Importing libraries may or may not work out of the box, I haven't tested it yet.
REQUIREMENTS
You'll need: - Python 2.5 - Pyglet: http://www.pyglet.org/ - at the command line in the nodebox folder, type: python -O example.py
python in QC doesn't work so well (this has been discussed into the ground -- no execution context etc).
pyglet also doesn't work (or, at least, didn't work so well last time) -- http://kineme.net/FeatureRequests/particlesystems#comment-1043
Thanks for the update stefan