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
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)
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:
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
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.
Written Wednesday 3 Dec
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.
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:
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:
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!
Written Friday 4 Jul
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."
"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!"
Written Wednesday 28 May
This material uses the world-space normal and the curvature of the surface to simulate a sloppy paint job.
The world-space normal is used to simulate paint only sticking to the top and bottom facing surfaces.
The curvature is simulating paint sticking in crevices on the surface.
You can find the material in our material database.
Written Wednesday 26 Mar
The Indigo 3.6 competition concluded with some amazing entries, and a lifetime licence for first prize winner Oscar J! Congratulations again to Oscar and the other prizewinners.
Indigo 3.6's features were to be highlighted for this competition, and they were put to especially good use for an entry featured previously on this blog which unfortunately was too late for the deadline.
Thanks to all who entered, and we look forward to seeing you all again for the next competition!
Here are the winning images:
Be sure to check out all the entries in the final entries thread!