![]() Interestingly, it was implemented using an inefficient intermediate class ( BezierPath) instead of directly in OpenGL, like the other primitives. My rendered output is here (I used ImageMagick to stitch the frames together – it’s a ~9 MB animated gif)Ĭlick the photo above to open the animationĭespite its performance problems, NodeBox does have a primitive that Processing is lacking: the star. That’s a hell of a performance price to pay. BoxyLady2, a 72-line sketch by analogpixel became 20 lines shorter (yay!), but also 11x slower (.375 fps for NodeBox, 4.4 fps for Processing v2.0b9). Once that was out of the way, I decided the most instructive thing to do was to port an existing Processing sketch to NodeBox. If you have mercurial, git, and pip installed, it’s not too bad (on OSX, you need to install pyglet from HEAD because version 1.2, which switches from using Carbon to Quartz, has not yet been released): So, I decided to give it a whirl and installed NodeBox-OpenGL (hereafter referred to as “NodeBox”). And although NodeBox lacks Processing’s vibrant community of developers and rich ecosystem (including geomerative and toxiclibs), NodeBox comes with a lot built-in ( flocking, particle systems, graphs), plus easy access to all the goodies you could ever want in Python. ![]() NodeBox lets you code in Python instead of Java. Lynn Cherny’s talk, Data Visualization with NodeBox ( Slides, Video) made an excellent case for using NodeBox as a framework for creative data visualization instead of Processing. The good news is: there’s lots of low-hanging fruit. TL DR: NodeBox-OpenGL gives you the sugar and power of Python and the ease of Processing, but with a significant speed penalty. This project is maintained by jsundram NodeBox vs Processing
0 Comments
Leave a Reply. |