Multicore Rendering

[SpaceToast]

Sorry for the novel here. My team is nearing the end of post on our current film, and A:M's renderer has been on my mind a lot recently. I'd like to frame these notes as constructively as possible.

 

Since it's gotten so long, I'll throw in some Big Headings for readability--and in hopes of making myself feel really important.

The Bottleneck

All of my films and many of my illustrations have featured A:M in one form or another. It's my utility knife app. I continue to find it an extremely powerful, user-friendly full stack modeling/rendering/animation package at an admirable price.

It's beginning to show its age though. A 3D package is only as good as its output options. Moore's Law is dead. We're not going back to ever-faster single core CPUs. Absent third-party renderer support, everything we do in A:M has to go through the bottleneck of a raytracer that can only utilize one processor core. When Netrender was included with the base package (in v16, six years ago) I took it as a stopgap solution and admission that the single-thread renderer was becoming a problem. Looking at the v19 roadmap, I still see nothing about multicore rendering. According to Activity Monitor, raytracing in A:M launches one additional thread, with a negligible increase in memory usage. My current production machine, a laptop, has 8 cores.

Netrender, with respect, was never intended to be an artist's tool--which A:M always has been. It's a TD tool for idle overnight labs and rackservers: overly complex, crash-prone, difficult to use, and less convenient than the multiple applications of the Playmation era. I personally have never even gotten it to work.

Third party renderer support is attractive in some ways, but aside from introducing many of the same pain points as Netrender, it would mean writing translation code for all of A:M's output options--not only Hash patches, but procedural textures, hair, volumetrics, soft reflections, IBL, ambient occlusion, etc. etc. etc. As much as I'd love to see COLLADA import/export eventually, we're talking about a very large undertaking, better implemented piecemeal over a longer period of time.

Keeping it Realistic

It's been my observation that an A:M window at render is basically a "state" machine--anything that changes between frames or render passes is applied to the world state and then read back into the renderer. (You'll see soft lights literally shift position between antialiasing passes, for instance.) As such, simultaneous rendering of different frames/passes becomes a slow, crash-prone and inefficient process of repeatedly loading multiple, near-duplicate instances of the same scene.

More realistic would be to render a single pass at a time as now, but split it into tiles (say 128x128). A separate rendering thread is spun up for each 128x128 square and fed into a queuing/load-balancing library like OpenMP. The world state is maintained by the main thread. The queue completes (with an acceptable bottleneck at the last thread rendering), the tiles are assembled in a new thread while the main thread is allowed to advance, and a new queue is spun up for the next render pass.

I notice that some great work has already been done in v18 at handing off render pass reassembly and other post effects to the GPU. (Today even a netbook's integrated graphics will composite faster than a single CPU thread in most cases.) Pass compositing, post effects, and file I/O should be able to manage without reference to the main thread, so need not hold up work on the next pass/frame.

Digging through the forums, I see that a multithreaded renderer was attempted in v14--splitting the image into horizontal strips in that case--but was abandoned because it produced render artifacts in complex scenes. I can only go by my own war stories to guess what might have caused them; many of you will remember the memory-limited old days when illustration-quality renders required "scanning" across the image with a zoomed in camera or obstructing different parts of the scene sequentially, rendering multiple frames, and reassembling the pieces in Photoshop. Post effects like glow and lens flares were obvious snags with these methods--but again, post effects are better handled on the fully reassembled image, preferably in a separate thread. Single-pass antialiasing, especially at the frame edges, could occasionally be a troublemaker, but overlapping the render tile edges a few pixels fixed this. Single-pass motion blur and depth of field rarely produced good results; the time savings of saturating more than one core (even on a low end system) would to my mind argue for their potential retirement if need be. Phong soft shadows were always a little finicky--they saved me on "Marboxian" with a 500Mhz PowerPC, but I'm not convinced retiring them would cause much pain today. I have very little experience with the toon renderer, so I can't even attempt to comment on how well it might parallelize.

2001 Miles to Futureburg

With a multithreaded renderer, A:M's biggest bottleneck is ameliorated. The power available to users increases immediately, and begins to scale again with each hardware generation. Tile size and priority optimization can be tweaked in subsequent releases. More tasks that are suitable to be handed off to the GPU, like Perlin noise, can be experimented with in their own time. With all the work that's been done to date on control point weighting, COLLADA import/export of rigged, animatable polygon models becomes more and more realistic (bare bones and incomplete at first, but with plenty of time to improve). With effortless boolean animation, riggable resolution-independent curved surfaces, hassle-free texture mapping, particle/hair/cloth/flock/physics sim, volumetrics, image-based lighting, AO, radiosity, 32bit OpenEXR rendering and much more, A:M becomes an app indy filmakers and small shops can't afford not to plug into their pipelines.

[Roger]

I agree with you, but if you want all this stuff then you need to find some way to raise $1-$5 million to hand to Hash Inc. so that this stuff can be implemented. I believe that there is only one programmer working on AM at this point, and AM is very much in maintenance mode, although we do get some major new features from time to time. And this is not in any way a criticism of what is going on with AM, but when you only have one guy actively working on it, there are only so many features you can spend time on.

[pixelplucker]

I thought that Netrender was included, No?

I do agree that the rendering in AM is a little slow but in comparison to many packages in it's price class (not quality of application) it is far faster and better. With that being said I do most of my work not as animations but more for conceptual mockups for customers and typically use 4x4 aa which can be a killer when the clock is ticking. It would be nice to be able to port out to other programs for rendering but would the expense for development be realized with the current users? More customers = more revenue and faster, better development. AM shows it's age where cpu's and machines in general have become blazingly fast to the point that poly bloated sub-d modelers have gained traction. Splines aren't for everyone and can be a tough sell to prospective new users and even tougher to convert those that have used Sub-D surfaces. Where AM is strong is it's simplicity in rigging, texturing and animation. It is most vulnerable when it comes to spline modeling and rendering speed.

I have suggested to Hash to do a Steam distribution which would certainly gain an audience. Maybe toss a trial version out there? Not sure what kinds of terms Steam has but the audience is massive and the price is good in that marketplace especially with all the Indy developers and the ability to port much of the content to Unity and others.

[Rodney]

Over all I enjoyed your novel.

I'm a fan of your work.and (I believe) have been since your release of 'Aesop's Fables'.

 

I'm resisting the urge to cherry pick a few items you've written in response because inevitably the focus of such turns negative. Some have (to me) obvious solutions while others (slightly?) miss their mark.

Mostly, I'd find myself defending some decisions made on our behalf that have greatly benefited A:M Users.

 

How then to proceed...

 

I think the best approach would be to examine your workflow/pipeline in detail to truly identify the bottlenecks and formulate solutions for those.

I know that workflow/pipeline changes a bit from project to project but the idea is to identify the core elements that need attention.

 

I'll cherry pick two statements that need some more immediate attention because I believe addressing them can pay off the biggest dividends and set the stage for greater successes.

 

I personally have never even gotten (Netrender) to work.

 

 

Let's address/remedy this and get you running Netrender.

Every A:M User has access to Netrender... few take advantage of it.

And because so few use it less emphasis is placed on its enhancement/improvement.

I believe a law of sorts is forming here... if we want to see something improved we must first use it.

 

a very large undertaking, better implemented piecemeal over a longer period of time.

 

 

This is exactly what is happening now.

The problem with incremental change is that it's more of a natural process and most of us don't like the waiting inherent in that process.

Seeds are sown... the sun rises and sets... flowers blossom.

 

One question I would ask to gain a better view from your perspective: What are you currently using for compositing?

 

 

Bottom line: I'm confident there are solutions for these concerns that don't require raising a lot of money.

The use of money would be toward mathematically de-picting reality. Not something people... and especially artists... generally want.

.

[robcat2075]

If NetRender is crashing that's should be an easy bug to document, report and solve.

 

You've never gotten it to work? We need to figure out what you are doing different because other people are having success making big use of it and you should have that too.

[Fuchur]

Concerning netrenderer:

Let us know where you would need help there... I have used it many times very successfully on my own computer and on several in my home and on our business network without much of a problem.

 

And while it is not as speedy as a GPU-render solution, it actually makes rendering MUCH faster.

OpenMP is already included in some of A:Ms tools, but with rendering it has been a problem that the renderings of certain areas of the image where a little different if done on different cores and while that is not a problem with whole images (where this only results in an unnoticeable screenflickering), it is different if you compose those parts together afterwards. Then you will see tiny lines in your renderings.

 

I am not sure if that was a problem with the old version of OpenMP or if it would still be the case, but that made the renderings useless. (but this information is a few years ago)