Reindeer 2020 Released

· 36 words · less than a minute

Merry Christmas everyone!

Reindeer 2020 is officially released. As a thank you to all customers the price has been cut. But also to show certain other companies how it's done :)

Thanks for supporting Reindeer everybody.

Reindeer 2019 Released

· 53 words · less than a minute

Reindeer 2019 has just been uploaded to the site. Big thanks to all the customers using Reindeer all over the world. It's been sold to users from at least 24 different countries this far! Incredible :)

There have been bug and usability updates throughout 2018. There will be more interesting updates later in 2019.

​Reindeer Launch

· 79 words · less than a minute

Reindeer is successfully launched and AnimaThings welcomes all the new users. The launch offer has officially ended (It actually lasted a bit longer than expected). But don’t worry there may be discounts offered in the future. So check back every now and then. Also stay tuned for an upcoming Demo release as well as other good things to come in 2017 ;)

Relax, recharge and enjoy your time off. 2017 will be a good year! Happy Holidays to all!

Reindeer Officially Released!

· 91 words · less than a minute

Dec 4th 2016

AnimaThings is proud to introduce Reindeer! The friendly node based Render Manager and Scene Automator for 3dsMax.

From it’s humble beginnings 7 years ago it has evolved into your new favorite timesaver, a tool that will pay for itself. Easily submit multiple render setups to BackBurner, Deadline or render locally. With Reindeer it’s all just one push of a button. Keep it simple or build advanced setups, it’s your choice. Reindeer let’s you automate the boring stuff so you can focus on what matters, Animation, Shading and Lighting.

The Story of Reindeer

· 998 words · about 5 minutes

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?

The Need

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.

Alpha 1

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.

Alpha 2

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 :)

25th April 2016

· 58 words · less than a minute

A pre-release version of Reindeer is made available. Interest is high with lot’s of questions, feedback and customers :) The interest fuels development and sparks a substantial overhaul of Reindeer’s code. A decision is made to delay the official release of Reindeer to incorporate features requested by the users as well as extending it’s use beyond render management.