Home → NodeBox 3 →

CPU or GPU

• Edit

isg

15 Mar, 2019 09:37 PM

Hi NodeBox 3 forum. I'm new her. I'm an artist working mainly in 2d generative arts. I used to work with processing and touch designer but just got into Nodebox 3 and I love it. Simple. Node based and open as for me a perfect mix between touch designer and processing.

I just have one problem. I am working of a 17000x11000px big size work. And this is pretty slow, as the work gets more complex.
I have a i3 intel CPU, 8gb ram and a GTX 960 GPU. I am wondering if I should update my cpu, gpu or ram if I want to work smoother with this sizes. Or is this intrinsic with programming at these sizes anyways?

Another question, is there any tutorial or most used workflow for more deconstructive builds? Like glitch types.

Thanks!

1. Support Staff 1 Posted by john on 15 Mar, 2019 10:29 PM

   

   Hi Faberdahl87! Welcome to the NodeBox community.

   Adding ram or updating CPU/GPU might help a bit (I'm not sure how much). But I'm afraid working at big size can be slow on NodeBox.

   Since NodeBox is entirely vector-based the number of pixels shouldn't matter per se - until you render an animation (at which point those vectors get turned into pixels). You can scale down animation canvas size to help there. If I am doing a lot of complex animation renders I sometimes reduce complexity while working on it, then ramp things up for the final render.

   But usually, of course, you end up using big pixel canvas size because you have a lot of complex content. For me, if I am importing data in CSV files, things start to bog down around 100,000 rows or so (half a million rows will usually bring things to a halt). Things will also bog down if I have 1000s of characters of text. Each character is a fairly elaborate text path and those vectors add up.

   There are a number of things you can do to combat this, short of upgrading your machine.

   First, look for performance bugs. A "performance bug" is a node which apparently producers the correct result, but takes much longer to do than it should. This can easily happen with subnetworks when you set incoming ports to value instead of list.

   This happened to me yesterday. I had a subnetwork node which (I thought) was taking in 500 values of one type, 500 values of a second type, and choosing between them to produce 500 outputs. The outputs looked OK, but the node was actually overlaying 500 copies of each vector, a quarter million vectors in all. When I changed the ports from value to list I saw a dramatic speedup.

   Another source of slowness is building 50 nodes to do something that can be done with only 2 or 3 nodes. If ever you find yourself laying the same pattern of nodes over and over again like bricks in a long wall, chances are there is a better way of doing things. Typically this will involve replacing that wall of bricks with a single subnetwork.

   To check for these things render one node at time and see how long it takes to refresh that node when there is an upstream change. Look at the little red light in the upper right corner. If your node is fast it will barely blink. But if the red light stays on for a full second or more, you might have a slow node.

   It's also a good habit to constantly check the data view of your output to see how many paths each node is producing. I could have spotted my example above sooner if I had switched to data view for that node and noticed there were a quarter million paths when I expected only 500.

   One final trick. If you are using large input files which you need to filter and manipulate in order to draw things, do as much of your filtering and number crunching as you can upstream. Then use the make_table node to make your own smaller table (or tables) which can drive everything else. THEN save those small tables as CSV files and import them directly instead of the original massive files. Huge time savings for every node thereafter (and for render time of each frame in a movie).

   All of this comes with experience and becomes second nature. If you have a project which seems much slower to you than it should be, and if you are willing to share it, post it with a cry for help. I can have a look at it and see if there are any obvious changes that would speed things up. This is especially helpful when you are first starting out.

   And if you make something cool or odd or even an interesting disaster please consider sharing it in the "Show Your Work" forum. It's endlessly fascinating to see what others are doing with NodeBox.

   Happy creating!

   John

   • Edit

2. 2 Posted by isg on 16 Mar, 2019 12:09 AM

   

   Hi John.

   Thanks a lot for the tips on workflow and performance! I will consider those things and workin smaller while enlarging for exports.

   I attach a granular build I'm working on, I actually found the base of this build here on forum.
   I'm trying to colorize randomly within some parameters and also generate line or random other than the rectangle generation you see in the middle.

   • PIXELDRIFT.ndbx.zip 1.33 KB
   • Edit

3. 3 Posted by isg on 16 Mar, 2019 12:17 AM

   

   This is one of my earlier work I try to make somethink similar in Nodebox 3. Where I can change parameters of square/angular - shape/color, animate, randomize ect.

   https://imgur.com/mwT6ukC

   • Edit

4. Support Staff 4 Posted by john on 17 Mar, 2019 08:27 AM

   

   Hi isg,

   I really like the piece you posted on Imgur. I can see why you may be experiencing performance issues. This piece feels more like a painting than vector art - which means it will require a lot of fine details. If you have to place 50,000 small rectangles to simulate individual pixels things may start to slow down.

   You have just under 50,000 rectangles in the granular build you sent. Your network is superimposing 50 randomly-sized grids on top of each other to create a random scattering. I thought this might be inefficient and tested it. To my surprise it's actually slightly more efficient than simply placing 50,000 rectangles with a scatter node. (It creates a less even pattern, but I'm guessing that's what you intended.)

   The nodes you have so far are fine. As I said above you can try things on a much smaller canvas and then scale up when you're near the end.

   I think it will be challenging to replicate that painting effect in NodeBox - not impossible but it will require some experimentation. As an alternative to lines you might also try thin, overlapping rectangles with reduced alpha; this can create an anti-aliasing effect for more feathered edges. (But you probably already knew that.)

   Good luck! I am really curious to see what you will come up with.

   John

   • Edit

5. 5 Posted by isg on 17 Mar, 2019 10:13 PM

   

   Thanks John and for the suggestions! Yes that piece is very different and made by a different approach and programs but the source was illustrator. Now I'm using nodebox instead of illustrator.

   I took notes and started a new build from using many layers of different smaller scattered poly and geometric forms on top of each other. It's a start but I like this! Also its a not as heavy computation as one big/full screen grid or scatter with loads of randoms. Even at full size animates fine on my computer.

   You can see here. All I need to do from here is add more to get more dense, but like the minimal and granular. :)

   • granular_poly.ndbx.zip 3.9 KB
   • Edit