Why release yet another Open Source rendering toolkit?

Because ART has a few features which are still unique, and some others which are at least very uncommon, amongst OSS renderers: these are listed in the features section of the “About” page.

ART now sees the light of day so that graphics engineers can take inspiration from those parts of it which are innovative, and as a general resource for the rendering research community. However, due to its somewhat idiosyncratic design and its low rendering performance, we do not expect ART to see widespread use like Mitsuba or pbrt: these are Open Source renderers which are considerably more capable with regard to mainstream functionality.

But for some specialised research tasks in physically based rendering, ART might just be the thing you need. And if we manage to make your day better by providing it as Open Source software, mission accomplished.

Who is the target audience for ART?

At this stage, ART is probably only interesting for graphics researchers, and maybe also for a few dedicated graphics enthusiasts who want to experiment with spectral rendering, polarisation and fluorescence, and who are not afraid of command lines.

Unfortunately, in its current form, it is not going to be really useful for normal end users, i.e. 3D artists who are working on commercial projects. Due to primarily being a research effort, ART lacks a lot of features one takes for granted in a modern rendering system. A list of current shortcomings can be found here.

Why release ART now, after so many years?

Because it has only recently reached a certain level of minimal stability that might allow it to be useful to other graphics researchers, for some specialised tasks. Also, because Alban Fichet, a Ph.D. student from INRIA in France who was on a one year visit to our group in Prague, used it for a research project during his time here: and after having gotten to know it, he provided the needed initiative to finally, finally get our act together for a release.

Why is ART already at version 2.x? Where is ART 1.x?

ART versions 0.x and 1.x were never released to the public, and only used internally at several research institutions. The source of these earlier versions will not be released.

Why did development of ART take so long?

A more detailed answer is given in the handbook: but basically, it took decades because we first had to figure out how to properly do spectral rendering (and rendering in general, at that).

When we started, way back when, we actually thought that we knew how these things should be done. “Let’s start coding! How hard can it be, right?”

Well, that was a good one, is all we can say, so many years later. 🙂

Or put it this way: if getting non-trivial spectral rendering right was as easy as it now looks in hindsight (and we have to admit that it does look rather straightforward, now that we are done), shouldn’t there already be other polarisation-capable spectral renderers with fluorescence support out there? Given that we are still the first to release such a renderer, even with our bizarrely long development time, might be an indicator that this was not so easy as it looks after all. But as the developers who wrote the system, one probably can’t be an objective judge of this anymore.

What is the maturity level of the ART codebase?

Unfortunately, that is still rather mixed. Some of it works fairly well, and is properly documented. But there are also still plenty of bugs, missing features, undocumented subsystems, and stability issues. But the basic functionality showcased in the gallery scenes is reasonably stable, and should work. And the handbook documents at least part of the system. Which is at least something that others can build upon.

Why is ART being released under the GPLv3, of all licenses?

Because ART development was funded by the taxpayers in at least two countries: initially AT, and later CZ. Funding was supplied via research grants and university staff salaries: at least so far, all those involved were either university employees, or students. As the development of this software was entirely funded by the general public, the license it is released under should, at least in our opinion, be as free as possible.

Why is the ART source not hosted on GitHub, or some other public server?

It might actually end up on such a site, eventually. But at the moment, we have our own local git server here at our department in Prague: and so far, this is perfectly sufficient for our needs. And we can give external users access to our local repository here as well, if need be.

If there is a huge interest in ART (which we don’t really expect at the moment, given its rather specialist appeal), we might reconsider, and actually host the main repo in a public place.

I plan to use ART for some research work. How should I acknowledge the project?

For now, please simply state the version of ART which you based your work on, and provide a link to the project page at Charles University (i.e. these pages). We are working on a systems paper on ART, in order to provide a properly cite-able reference in publication form.

I want to use ART for some commercial purpose.

Be our guest - and good luck! (seriously - you will need it) This is what Open Source Software is about: you can do with it what you want. Please stay aware of the fact that ART is under the GPL, though: so the one thing you cannot use it for is to build a closed source product.

I have downloaded ART, gotten it to work, and have actually fixed a bug / developed a new feature. Do you accept patches?

We do, but please thoroughly test anything you come up with before submitting it. If your patch results in ART no longer passing the functionality test suite, we will certainly reject it.

Overall, patch generation for ART is broadly similar to what the gimp project has to say about the matter. Except that once you have the patch file, you should send it to the ART project e-mail address, along with a description of what the patch is all about (we don’t use bugzilla - yet). Also, please make sure to clean your ART/Source directory of all cmake-related temporary files before running the diff on it. In the future, we will modify our CMakeLists.txt so that it does not place anything in the source directory anymore: until then, these files have to be cleaned manually. Patch generation is likely not a very common operation, so we deem this to be an acceptable defect during initial release.

I’m a graphics researcher, and want to contribute. Can I have full r/w access to your git repository?

Contact us about that. Theoretically, we do give full git access to qualified researchers, under the condition that any generally useful improvements you make to the system are eventually released to the general public. But we reserve the right to decline any such request without giving any reasons for it.

Note that even if you do get full access to our git repository, the ART maintainers would not require co-authorship of any research publications which are based on you using ART iff you just quietly use ART for your own purposes, and do not cause us any overhead or extra work.

(that is, extra work beyond giving you git access, perhaps answering a few not too complicated questions here and there, and eventually assisting you with merging back any features you might have added)

I’m a graphics researcher, and I would need feature $foo for my work?

You can also contact us if you want us to be directly involved in what you are doing. We might be able to help with some things: there are quite a number of old ART 1.x modules which have not been ported yet still lying around in various states of disrepair. In some cases, re-activating those might be doable with quite reasonable effort. And even if we do not have any old code for a specific problem, we are probably in the best position to quickly say how something could and should be added to the system.

Be aware, however, that we would expect to be co-authors of whatever you are working on iff your questions and/or feature requests cause us significant amounts of extra work: in effect, once we can legitimately be considered collaborators because we actively worked on your experimental set-up, we expect to be on your paper.

I’m a graphics enthusiast / end user, and I would need feature $foo for my work?

You can contact us about that, and we will gladly give you an estimate how much the development of said feature would cost.

Yes, you read that right: we would expect you to pay for something like that. ART is of course Open Source, so it is free to use. But our time as developers is not free. For academic research purposes, we are - depending on the project - willing to invest time and energy into extending ART (see above). For non-research purposes, there is an hourly rate.

What is it with the unimaginative project name?

There is of course a story attached to the name of the project. “Advanced Rendering Toolkit” has a tendency to sound either bland or boastful, depending on one’s perspective: and we are well aware of that. Plus it is an expression which will, pretty much by definition, not age well. So it’s not really an optimal project name.

However, ART is just a working title which stuck: we never intended the renderer to be called like this when it eventually gets released. In 1996, when Robert F. Tobler started this project at the Institute of Computer Graphics in Vienna, there were multiple brainstorming sessions to find a proper name for the effort. Unfortunately, all really good acronyms which crossed our mind had already been taken, and we could not think of anything else. Eventually, we decided to “let’s go with a working title for now, and decide on a proper name later”.

Yeah, right. That was 22 years ago. So much for temporary solutions.

A technical reason why we did not even try to do a last minute name change to something more proper right before public release is that C and Objective-C lack namespaces. All data type and class names in ART have always had a prefix of Ar..., and changing that now would have been a nightmare. Better to live with a not-too-imaginative project name, than having to go through such a refactoring. Besides, without the ART project acronym, there would be no real reason to call the command line renderer artist. Which, together with its RPC control application impresario, makes for a neat pair of app names.