Tuesday 21 Mar
Indigo 4.0.48 Beta Release
We have been working hard on a new beta release, which brings many new and useful features to Indigo. Here are a selected few:
Light layers - GPU support and UI updates
We implemented complete light layer support for OpenCL (GPU) rendering, which allows quick and easy balancing of light sources during or after rendering using your GPU.
A nifty new feature is the thumbnail to each light layer, making it easier to find that particular layer you're looking for in the stack. Other additions include the possibility to assign a light source to a light layer directly in Indigo GUI, as well as adding new layers.
GPU - adaptive resolution for greater responsiveness
To ensure good responsiveness and frame rate even at higher resolutions, the resolution now dynamically adapts when doing realtime camera or material changes.
Adjustable light sampling
In some lighting scenarios, and especially using less sophisticated render modes such as normal path-tracing, some light sources can become more noise prone than others. That's now easily adjusted using the emission sampling multiplier. Higher values means more processing power dedicated to that particular light source.
Full changelog and download links here:
Tuesday 8 Nov
Indigo 4.0.46 Beta Release
We have released a new beta of Indigo Renderer, which adds a lot of improvements to realtime material editing during OpenCL rendering, and greatly reduces the amount of OpenCL rebuilds needed.
Watch Indigo user Oscar J use the latest beta:
Many other important features has been added since our previous blog post, in particular to our OpenCL rendering core:
* The material system is pretty much complete, except for SSS and some minor features.
* Camera and object motion blur is now supported.
* Network rendering works with OpenCL rendering.
Features such as colour curves, trackball navigation and a much improved dark theme have been added. The addition of queue overrides is very useful to apply changes of render settings across your entire animation.
Download link and full changelog for Indigo 4.0.46:
Thursday 4 Aug
Animation feature - Recreational Vehicle
Senior 3D artist David Gudelius and his company Michel De Vries have created this beautiful, cinematic CGI trailer for the launch of Niesmann+Bischoff's new RV, "Smove".
Thanks for agreeing to do this feature with us David! Could you tell us something about the background of the project?
Under the creative direction of Linde and Oliver Starke from Mooi we decided to create an emotional, easy and natural environment with a vacational feeling which fits the new Smove perfectly. Our company was responsible for the CGI.
© Fotostudios Mooi. All rights reserved.
The environment and lighting work is certainly impressive. What 3D modelling package did you use?
Our host 3D application was Cinema 4D with Cindigo, and everything was rendered on CPU in Indigo 4.0.37.
Our render times were about 10-18 minutes per frame, in 1080p resolution. We rendered the whole animation on our internal render farm with 20 machines, using a custom network manager to render one frame on each node.
Why did you choose Indigo for this project?
To ensure the most realistic rendering possible of our detailed 3D nature environment, to have great technical shading possibilities and a naturally photographic look to the car footage, we decided to use Indigo Renderer to keep compositing complexity as small as possible.
© Fotostudios Mooi. All rights reserved.
© Fotostudios Mooi. All rights reserved.
© Fotostudios Mooi. All rights reserved.
Thursday 30 Jun
We're hiring plugin developers!
Glare Technologies is looking to hire new developers to work on our 3D application plugins, to ensure an efficient and production ready workflow for Indigo 4 and beyond.
We are primarily looking for a SketchUp plugin developer and a 3ds Max plugin developer, initially. However plugin development for Blender and Maya is likely to follow, so don't hesitate to get in touch if you're interested in working with those - or perhaps on a brand new plugin?
We have a new jobs page up with more details and contact information:
Friday 17 Jun
Indigo 4.0.38 Beta Release
We have been working hard on a new beta release, which brings quite a few long-awaited features to Indigo and its new OpenCL rendering core!
Download links on the forum: http://www.indigorenderer.com/forum/viewtopic.php?f=1&t=14024
Here's a quick overview of some of the new features:
This feature can be used to reduce unwanted bright dots in a render, so called "fireflies", by limiting the maximum contribution of image samples. The maximum contribution is user-controlled, where a lower value means stronger firefly reduction. Please note that this feature introduces bias into the rendering - the lower the max contribution, the more bias.
We want Indigo to be unbiased by default, so clamping is disabled by default, and we recommend not using stronger clamping than necessary, as this may lead to unrealistic results. However, the tool is an effective and artist friendly way to remove fireflies from an image.
Here is an example of how clamping can be used to reduce fireflies in difficult lighting situations (click for full resolution):
Broader material support for GPU Rendering
Architectural glass (for fast rendering of flat glass panels in archviz), Double sided thin (for realistic leaves and other vegetation) and Glossy transparent have been added, along with support for step blend in blend materials.
General speed improvements
Many optimisations have been made to improve rendering speed. This includes general speed-ups in the CPU core, as well as optimisation of many of our material models, including Phong, Double Sided Thin, Coating and Glossy Transparent materials. The viewport performance is significantly faster when using GPU rendering, and more improvements in this area can be expected in later beta releases.
Full changelog and download links here: http://www.indigorenderer.com/forum/viewtopic.php?f=1&t=14024
Sunday 21 Feb
The Nefertiti bust
Two German artists covertly scanned the bust of Nefertiti, which is located in the Neues Mueseum in Berlin, and posted the scanned data online: http://nefertitihack.alloversky.com/. The quality is quite impressive given that this was apparently scanned with a Kinect sensor surreptitiously!
The format of the data is STL, which is a common format for models for 3d-printing. It's also actually very simple - so I added native STL support for Indigo so I could load the Nefertiti data directly.
I made these renders using the data, which illustrate some of the strengths of the upcoming Indigo 4 - the pure GPU rendering renders these 2000x2000 images in one or two minutes. Additionally the improved Oren-Nayar material gives a convincing clay look to the bust.
Click the images for full resolution!
Thursday 18 Feb
Friday 28 Aug
Two moody architectural renders by Christian Behrendt
Two moody architectural renders by Christian Behrendt. To see more artwork by him and others, visit Indigo's "Finished Artwork" forum section:
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)
Wednesday 3 Dec
Indigo 3.8 Stable released
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.