Log in or Register.
Download Trial Buy now

Indigo News


The sun sets a little

Written Thursday 18 Feb

Indigo user yonosoy has created a stunning image using Indigo's atmospheric rendering capabilities:

See more of his work in his forum thread.


Two moody architectural renders by Christian Behrendt

Written Friday 28 Aug

Two moody architectural renders by Christian Behrendt. To see more artwork by him and others, visit Indigo's "Finished Artwork" forum section:


Micro living concepts by sking

Written Tuesday 28 Jul

Indigo user sking posted some nice new work on the forum. Modeled with SketchUp.

Check out his thread here: http://www.indigorenderer.com/forum/viewtopic.php?f=4&t=13604


Fuzz Testing

Written Thursday 30 Apr

This is a technical blog post, probably only of interest if you are a programmer!

I have spent the last week or so fixing bugs in Winter (our programming language, originally ISL) found by our new fuzz testing code.

Fuzz testing is the process of sending lots of random input to a program, to try and uncover crashes or other undesirable behaviour from the program.

If you are writing a compiler, I highly recommend fuzz testing it, it seems like a very effective way of finding bugs.

Some more details about our fuzzing code:

It's an in-process fuzzer - random programs are generated, compiled, and run if compilation succeeded (e.g. if the program is valid), all in the same process.
Because it's in-process, as soon as a crash occurs, the fuzzing run is over. Each random program string is saved to disk before it is run, so to find the program that crashed the process, you just have to get the last line from the file on disk.

It's multithreaded, because you need all the power you can get to find any bugs as fast as possible.

The fuzzer runs through about 20,000 random programs per second per core, so running on 4 cores gives around 80,000 random programs per second.
This relatively fast speed is possible because invalid programs are rejected early before computationally intensive stuff like LLVM optimisation and codegen starts.

Valid programs only run at about 300 programs per second per core, but most random programs are invalid, so the average speed comes out to 20K/core/s

The random program generation strategy is something like:

Randomly pick a program from the unit test suite programs (several hundred covering all language features)

Then repeatedly mutate program randomly a few times by picking from among a few options:

1) Insert a random character at a random position in the program.

2) Delete a random chunk of characters from the program

3) Copy a chunk of the program to another random position in the program.

4) Read a section of a random other program from the test suite and insert into the program.

5) Insert a random language keyword or syntactical elements (square bracket pair etc..)

As mentioned I found this fuzzing code to be extremely effective in finding bugs. I found 40-50 crash bugs that took something like a week to fix, and triggered improvements and refactorings to avoid crashes. Our programming language Winter is a lot more robust now.

if you are wondering how there can be so many bugs in a language compiler/runtime, bear in mind that Winter is quite complex, with generic functions, operator overloading, function overloading, type coercion, JITing, higher order functions etc..

I also tried out American Fuzzy Lop (AFL). I ran it for 24 hours or so, in which time it got through 20% or so of the first pass. It didn't find any crashes.
I'm not sure if this is because it's not very good at finding crashes, or if I removed all the crash bugs :)
It's definitely a lot slower than our in-process multithreaded fuzzing though.

Note that in theory AFL uses a more powerful kind of fuzzing - coverage-guided fuzzing, which can be considered a white-box approach, since it uses knowledge of what code paths are taken for each input program.

Therefore I would highly recommend integrating an in-process fuzzer into your test suite, and after that maybe check out AFL or similar.

(If you want to know more about Winter there are some presentation slides in PDF format from a talk I gave a while ago here: Indigo Shader Language and Winter)


From pre-viz to final construction

Written Monday 9 Mar

Indigo user Nikolaj Knudsen has shared some fantastic images of contruction projects visualised with Indigo side by side with photographs of the final result! Be sure to check them out on the Forum: http://www.indigorenderer.com/forum/viewtopic.php?f=4&t=13461

We're really pleased to see Indigo being used like this, and many of the designed rooms look remarkably close to the pre-viz shots. The lighting and mood in particular is carried over well, and shows how useful pre-visualisation can be!

Here are a selection of images from the Forum post:


Indigo Renderer 3.8.25 Release

Written Monday 12 Jan

We have released an updated verison of Indigo 3.8 stable that fixes a couple of issues:

* Fixed bump mapping not working if 'smooth' was enabled for textures.
* Fixed occasional "Read failed" error when reading mesh files on OSX.

If you had problems with the "Read failed" error, download the new version here: http://www.indigorenderer.com/downloads


Indigo for Revit 2015

Written Tuesday 23 Dec

We're pleased to announce that we have released an updated version of Indigo for Revit that adds support for Revit 2015.

It has added support for fast architectural glass and comes bundled with the latest Indigo Renderer 3.8. Click here to find out more about what's new in Indigo 3.8.

You can download it here.


Indigo 3.8 Stable released

Written Wednesday 3 Dec

3.8 image

Glare Technologies is excited to announce the release of Indigo 3.8 Stable!

You can read about it here: http://www.indigorenderer.com/indigo3.8

We'll be running a 16% off sale until the 31st of December, during which Indigo Renderer will be priced at only €499 (normally €595), and Indigo RT only €119 (normally €145).

Customers purchasing Indigo 3.8 during this sale will receive a free upgrade to Indigo 4 immediately upon release!

Indigo 3.8 brings massive performance improvements - up to 2x faster rendering, and render restarts are up to 42x faster.

The new Architectural Glass feature greatly speeds up architectural visualisation, while capturing important optical effects such as reflection and absorption as light passes through the glass.

Indigo's new built-in object scattering allows millions of objects to be quickly scattered across a surface - perfect for realistic grass and forests.

The Coating and Double-sided Thin materials are more flexible than ever, allowing for advanced materials like special car paints and carbon fibre.

Our advanced sky model is now even more realistic than before, with refinements resulting in more accurate colours, especially at dawn and dusk.

Indigo's SketchUp plugin, SkIndigo, has been massively improved, resulting in much faster export times - up to 14x faster.

Indigo 4 development is also well underway, and we're excited to announce two extremely important feature additions: a totally new OpenCL-based rendering core, and photon mapping extensions for bidirectional path tracing.

Indigo 4's pure GPU rendering will use OpenCL to provide powerful multi-GPU support on Windows, Mac OS X and Linux.


Introducing Indigo's pure GPU rendering

Written Friday 1 Aug

One of the worst-kept secrets in the Indigo community is the forthcoming pure GPU rendering support, and today we'd like to show you some exciting first results!

Indigo's pure GPU rendering is based on OpenCL, a vendor-neutral standard for GPU computing that notably works on AMD GPUs (which don't support CUDA), and also both Intel and AMD CPUs besides NVIDIA GPUs. This means your CPU can contribute to GPU renders, and some newer CPUs even have built-in GPUs, which are also fully exploited; for example Intel's i7 "Haswell" processors have an excellent built-in GPU that is competitive with many mid-range stand-alone GPUs.

Here is an example render of a scene by Indigo forum user cotty from a Windows PC using only two mid-range GPUs, a GeForce GTX 750 Ti and an AMD FirePro W5000, along with the usual CPU cores:

Skipjack scene running on 2 GPUs plus CPU cores

Normal Indigo CPU rendering gets about 1.8 million samples per second on this scene with a very fast overclocked Intel Core i7 4770k CPU, so we see about a 7x performance improvement in this case! Keep in mind that these are mid-range GPUs, and higher end GPUs can perform much better.

We've also tested multi-GPU rendering on Apple's new Mac Pro running Mac OS X Yosemite, which features dual AMD D700 GPUs:

Toy bunny scene running on Mac Pro with dual D700 GPUs

Apple have been a great help in getting Indigo's GPU rendering working on Mac, and we're looking forward to posting more GPU rendering results on the Mac Pro soon.

Keep an eye out for development updates as Indigo's GPU rendering mode matures with more features and faster rendering!


Animations by Zom-B

Written Friday 4 Jul

Indigo user Arthur Liebnau (aka Zom-B), has posted two finished animation projects using Indigo. In his own words:

Victoria Camera Animation

"I'll start with a short 3D camera animation I did for a fashion show directed by a friend.
First time "organic" stuff from me, it was quite hard to get something with an dark mood and be convincing."

Cabin Design

"Here another animation aroject for a ship cabin design. The whole scene is rendered with Indigo, but the water was done in C4D and edited into the whole composition during post process. The whole Video has some explanation of the concept with a photo sideshow at the beginning, go to min 1 for the 3D!"