|Remove||Item||Quantity × Price|
|Your cart is empty|
On the 15th of September 2009 a tool by the name of “RenderFlow Beta” was officially made available to the 3dsMax community. It introduced a “node based” approach to render management. But how did it come about?
I was working on a project and needed to do lot’s of iterations fast (as always). But submitting renders was slowing me down. It was a slow, frustrating, error prone process. It wasn’t difficult but there were many steps, turning layers on/off, assigning materials, changing some setting here or there. The steps were easy, but for a tired mind that just wanted to go home small mistakes were frequent and renders would come out wrong. So I made a checklist, then gradually the checklist was turned into a maxscript that would take care of the entire submission process. Suddenly productivity rose and time could be spent on the things that mattered, how things moved and what they looked like. In other words Animation, Shading and Lighting. But writing a maxscript and keeping track of it for every scene is a massive pain and is about as flexible as a rock. Being a fan of Shake and seeing rendering as a part of the compositing process, a node based UI was inevitable. Thanks to Helium (by Lumonix) being made freely available around that time it was also made possible to implement in MaxScript.
The first version was hacked toghether for that project in a few hours, it just had RenderNodes and LayerNodes. Layers would be turned on if they were plugged into a RenderNode and off if they weren’t. RenderNodes simply represented views in the batchrender dialog. Very primitive but surprisingly useful. But the design led to an immediate problem. I wanted to add a MaterialNode, and for that to work the flow needed to change.
The idea was instead to let objects be the base units and let them “flow” through the nodegraph (much like particles or images do in similar systems). The “nodes” would represent operations that could act on the objects plugged into them, for example by assigning materials. The endpoint of the flow would be the RenderNode and any objects passed into it would be visible and the others hidden. There was also one other feature put in and it turned out to be the most important of them all. Since I like scripts, I put in a hack called a ScriptNode that would simply execute a script, any script. It was very easy to implement and thought of as a fallback, a kind of “when all else fails” solution. But it had a tremendous impact on the way I’ve worked ever since. The ScriptNode can do virtually anything, so every single node implemented since then has started as a few lines in a ScriptNode. It’s nice to have a pretty ui but the functionality was already there and being used long before any node was created. And similarly any future node is already here in the form of the ScriptNode ;)
RenderFlow Beta is born
Being young and eager to give back to the 3dsMax community I cleaned it up threw in some more nodes and released it on September 15th 2009, as “RenderFlow Beta”. Free for anyone who requested it. I got a barrage of e-mails in just the first week. I tried to reply to all of them sending the installer to anyone who asked for it, and trying to answer all of their questions. It was very exciting and rewarding. But I never imagined how much work was needed just to give something away for free. I put a donate button on the website but only a couple of people donated. To the few of you who did I am very grateful and sorry that I couldn’t keep up my end of the deal :/
The death of RenderFlow Beta
RenderFlow Beta died. Why? In order to be able to support it, money needed to come in. So in order to get a product to sell I decided to re-write it from scratch and make it better than ever. A few of the users of RenderFlow Beta got to try out this version called RenderFlow 2 (I think). I added a plugin system for making new nodes. I added “flashy” graphics to all the nodes and most importantly I put in a licensing system. That last item, the licensing system, was the final nail in the coffin. It made development hell. The user had to request an authorization key by e-mail and then I had to reply with that key (sound familiar?). It seems like a minor thing but all of a sudden there’s a ton of admin associated with every single user. And that will scale linearly! So with hundreds or thousands of users you have to build or buy a system to automate it. And that’s just a waste of resources, it gives the customer absolutely no added value, it’s not fun for anyone, and the honest users have to pay for it all! That in combination with a workload typical to this industry, no real experience and many other issues, RenderFlow Beta slowly fizzled out and died…
Rebirth, introducing Reindeer!
Earlier this year (2016) nearly seven years after the official release of RenderFlow Beta. Nothing had come along to replace it (officially). So I decided that I wanted to release the tool that had saved me so much time and boring work over the years. I’ve used it on almost every single project, it has evolved many new features over the years but the core idea is still valid. I’m finally in a much better situation to support and maintain it and with much more experience under my belt. And now it’s time to do it right! So on April 25th 2016 a pre-release version of this new tool, now called Reindeer, was announced. Development is going well and release is not far off :)