I assume anyone who has used Indigo from iClone knows how long renders can take. Those who have top end machines are indeed blessed but I would bet even on those Indigo just about eats it alive. Here are some general observations about Indigo that may help someone or may not. Some I am not entirely sure about so anyone with better understanding of Indigo and IClone are welcome to add to this conversation.

1. Number Uno. Use Compositing. Never has film compositing been so important as with iClone-Indigo (if you're rendering animations, otherwise not I guess). It takes planning for such things but it can save a lot of grief if you can break a scene into one or more separate renders, which we can call "passes" just for convenience.

For example, let's assume there is a scene with a man going up to a door and ringing the doorbell. This is mid-distance with perhaps a few quick close-ups. The surroundings are objects from whatever source you derive scene decorations and maybe a few SpeedTrees (house front, sidewalk, grass, etc etc). This might not seem like a heavy scene load but it sure is when passed to Indigo. This scene amounts to, say, 15 seconds of film, or 450 frames. Give Indigo 2 mins per frame (1 min as suggested in one of Reallusion's tutorials is ok but not very good, why go to the effort if you can't shoot for better?).  Plan on having nothing else running on your PC. Go play solitaire or take that walk you need because it is going to take a really long time. 

If the scene is pretty static except for the man walking you can break this into two passes. In the first pass, you simply take the necessary "still" shots from every angle needed then use that as a backdrop when compositing. If there are realism tokens, like moving curtains or swaying trees or flickering lights, it may be necessary to pass those elements on with the render of the animated man, or if you're really good you can render such elements as a group in another pass. Once the background scenery has been taken care of, you can hide everything else in the scene except the man (if an object is required for his interaction, a dummy object could be used instead) and pass that along to Indigo. Here I recommend breaking the action into shorter segments -- it won't necessarily render faster but it will make compositing a little easier. Of course, check "make background transparent" in this latter pass. If everything has been handled correctly, which is why planning ahead is very important with this and isolating the right elements into the proper "pass", you can then composite the resulting renders into a whole clip. In this case, the animation of the man walking would be composited on the background stills. Note this still takes 900 minutes (plus overhead) to render, plus whatever is required for the stills, but the load on your PC will not be worrisome. I have tried this in an experimental way and it really does help. Passing a heavy scene to Indigo, even if short, brings my PC to its knees and at that point it all becomes vulnerable to a crash. Things seemed to go smoother using this technique.

I hope I'm not rushing in yelling "Hey, guys, the sky is BLUE!"  I never really did much compositing until these new render engines came in.

Perhaps Indigo should lease Blender's Cycle Render Engine technology -- if you haven't seen it work lately you will be blown away. I'd use Cycles for most rendering if it were more convenient to access through iClone. In terms of quality and speed of render, nothing out there can touch Cycles now.

I guess the main thrust of this is that you have to get smart when facing render times of days and find ways to 1) reduce the load; 2) reduce the complexity; 3) reduce recovery time in the event of an abnormal termination. While compositing may add some complexity, it can help with 1 and 3. There are many "movie" effects that depend on compositing and that can open a whole new area (which, of course, is why there are products like After Effects).

2. Test Render. I ran into some geometry issues with Indigo a while back in which models I brought in from elsewhere rendered horribly in Indigo. What was puzzling about it was the same scene rendered fine in iClone's native render engine. I spent (wasted) time trying to figure this one out and it appeared to be coming from some combination of bad normals or bad materials. Take your pick. I found a way around it but it is advisable even with iClone's native objects to do a test render before going to a lot trouble only to find Indigo trashes your centerpiece in the scene.


More later. Anyone interested in this is welcome to jump right in. I doubt I will ever be more than a student in this stuff.

 

I think this is very helpful information for those that still want to do something with Indigo and animation.

No improvements of the plugin have been announced for iClone 7 and Indigo 4 seems to still be in Beta, so any optimization tips are welcome.

You are indeed right about SpeedTrees; they are efficient in iClone but not at all in Indigo, as I found out one time. The tip of using short sequences is a sensible one. There is a memory leak in either the plugin or Indigo when rendering a sequence, which of course gets worse the longer the sequence.

---

Thank you, animagic. I'm sure it's something obvious to anyone with experience rendering animations. It would be good, of course, if one could settle a long sequence into a final format within iClone then render that in a reasonable time. But one reason old movies adopted the "cutaway" was for more than just the fact it made the movie more interesting. Humans tend to lose interest in a single shot that lasts for long periods. Not in all cases but in many. The reason the scenes were also cut into smaller segments was because film canisters of old could only take so much and that had to be dealt with in the editing process. So shorter takes were done to ease that problem. In the process, directors got creative with the cutaways, including the technique of doing with only one or two cameras. 

In the process of cutting a "clip" into sequences I found it was not difficult to do so and the results seemed, to me, more professional or like a "real" movie. You don't want to get carried away with it but when you can chop a scene into a few short sequences then edit them into the final product, the Indigo render times begin to resemble something like normal.

I'm not sure yet about Indigo. It does seem to have some problems but when it works well it does produce some remarkable output. One of the worst problems I have had with Indigo is on a "heavy" animation that I should've shortened ... I used GPU acceleration which always seemed to work well on my system but this time something went catastrophically wrong. The screen went away and I could not get it back. I had to reboot. I did not try to render that sequence again. It rendered well in the iClone native renderer so it could be the video card simply couldn't handle it, I do not know. Could also be a problem within Indigo.

I have gotten the impression from reading through the forum that Indigo has caused a lot of grief for people and I assume many now avoid it. 

You know the guy who does most of the iClone tutorials?  I wonder why he never has a crash when he's doing the videos?  Everything just works dandy for him. (just joking).
Someone ask him what sort of PC he uses. Maybe it's time to go for the real power in a PC. I don't see the demand on CPU/RAM/GPU getting smaller over time.

A lot of the disappointment was a result of incorrect expectations.  And a lot of that was based on a lack of solid information about a tool most of us had never used before.  I don't think many people expected it to render at the same speed as iClone, but the extreme slowness (relative to iClone) caught a lot of us off guard.  That, compounded with difficulty in exporting many frames from iClone, and the learning curve of getting the desired look in Indigo, caused most of us to abandon it as an animation tool.

The consensus here is that Indigo has a place for rendering individual images, but is not a viable animation tool at this time.  Of course there's always room for an exception or two.

Beyond Indigo, I was hopeful that once they had the architecture in place for a 3rd-party renderer, that at least one or two others would follow, such as Arnold, Octane, V-ray, etc.  But my dreams of that have evaporated.

---

iClone 7... Character Creator... Substance Designer/Painter... Blender... Audacity...
Desktop (homebuilt) - Windows 10, Ryzen 9 3900x CPU, GTX 1080 GPU (8GB), 32GB RAM, Asus X570 Pro motherboard, 2TB SSD, terabytes of disk space, dual  monitors.
Laptop - Windows 10, MSI GS63VR STEALTH-252, 16GB RAM, GTX 1060 (6GB), 256GB SSD and 1TB HDD

The more open architecture promised for iClone 7 may revive that hope again...:w00t:

From what I've read, those that develop the renderers are not always that interested in developing interfaces to other systems apart from a handful, so it is up to outside developers to do that.

---

Good point, Animagic.
I should say my hopes of Reallusion doing it have evaporated.

It will be really interesting to see what people can do with the API tools.  I'm consciously working toconstrain my expectations, and am assuming the first release will not expose everything, but that it will grow and evolve over time.  Still, it is an exciting thing to think about.

---

iClone 7... Character Creator... Substance Designer/Painter... Blender... Audacity...
Desktop (homebuilt) - Windows 10, Ryzen 9 3900x CPU, GTX 1080 GPU (8GB), 32GB RAM, Asus X570 Pro motherboard, 2TB SSD, terabytes of disk space, dual  monitors.
Laptop - Windows 10, MSI GS63VR STEALTH-252, 16GB RAM, GTX 1060 (6GB), 256GB SSD and 1TB HDD

Have any of you checked out the new Cycles render engine in Blender?  It is very fast and produces renders at least equal to any render engine I've seen, including Indigo. I recall but can't remember the name of a company that has licensed the Cycles technology for their render engine. If Reallusion can find some time, perhaps they could provide an entry way into the Cycles render engine. It's probably not feasible but Cycles also has alembic support. 

I'm glad someone mentioned the problem of getting Indigo renders to "look" like we expect. In many cases, the colors are simply incorrect in the Indigo render. The OpenGL and iClone native render produce the expected results but Indigo produces a result that, for lack of a better term, has "washed out" colors. It may be due to the lighting or the intensity of the light but it seems there is a lot of tweaking one has to do to get it right. I played with the white balance but it did not correct the problem. For example, if an object is a deep red in the iClone render and the OpenGL render, it is a light pink in Indigo. Same with most other colors. A "light" variation of the expected color (or the color iClone says it is). Since it seems to affect all colors uniformly, it indicated to me the lighting was not right in Indigo. I tweaked it but did not have time to run a whole suite of tests. It is a shame, though, but as you all mentioned the very long render times and the inconsistent results make Indigo pretty much unusable for animation of any size.

They should take a look at Cycles in Blender then see about licensing that product. I don't expect that to happen, though.

A lot of effort has gone into the new PBR rendering engine for iClone 7, and I have high hopes for that. I'm personally not very interested in hyper-realism, and I prefer an iClone native solution.

In my mind, external render engines are a last resort. Because of DRM content concerns, either a special plugin is required, which in the case of Indigo recreates the iClone scene as an Indigo scene, or you when using Alembic you need export licenses for all content that is not Base. Piracy is a serious issue, and applications can therefore not always be as open as desirable from a software development perspective.

---

I believe Blender also has some requirements regarding "open source" and it is difficult to legally interface with it while guarding proprietary intellectual property.  That can be a real issue for a company like Reallusion.

---

iClone 7... Character Creator... Substance Designer/Painter... Blender... Audacity...
Desktop (homebuilt) - Windows 10, Ryzen 9 3900x CPU, GTX 1080 GPU (8GB), 32GB RAM, Asus X570 Pro motherboard, 2TB SSD, terabytes of disk space, dual  monitors.
Laptop - Windows 10, MSI GS63VR STEALTH-252, 16GB RAM, GTX 1060 (6GB), 256GB SSD and 1TB HDD