Meet Max Liani from Animal Logic and his renderer, Glimpse.

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

REPLY TO THREAD
 
Thread Tools Search this Thread Display Modes
  03 March 2014
Originally Posted by Rebelismo: Thanks for answering my question, and I understand that you can't mention too much. Glimpse still sounds instantaneous, especially with such incredibly short translation times.


That's the idea, yes. If I render for 60 minutes I can afford to wait 2 for frame translation. But if a meaningful render (preview quality) takes 1 second and translation still takes 2 minutes, then it is pointless.

Problem of data translation if that it is often a serial process. If you can parallelize that, you get bis step forward.

We run in this problem during production. Glimpse was extractig data from Maya very fast. At some point we added support for procedurals in Glimpse. We wanted to bypass Maya and read models directly from our cache files. We quickly got confirmation how slow these were. They were old designs, not supporting multiple threads, not scaling well. This sparked a whole lot of work in most parts of the pipeline. Sure R&D hates me by now

Originally Posted by Rebelismo: It seems like it would be quite disruptive to all the technology that's currently out there, if you were to release it as a product .


I hope no! I hope it would be stimulating! I give you a fact. I was testing a commercial rendered (won't say which, but one of the major). Using the very same mid size scene, Glimpse was taking 2 seconds to get the data out of Maya, translator of the other product was spending 2 minutes alone. I reported the problem back to the developers, at first I got told Maya slow API was to blame. Then I said how quickly I could get the same data out. They spent several days profiling and working hard. They got their translator down to 6 seconds I think, for the enjoyment of their customers.
Sometimes you need an example on how fast something could be to motivate you to push further.

Originally Posted by Rebelismo: As a side question, I was wondering if you could talk about the average render times per frame. When you began to build Glimpse, was the main goal to accelerate both preview and final frame rendering?


Glimpse average render time for LEGO large shots final frames was around 10-30 minutes (a lot longer when in the hybrid mode with Prman). Rendering hardware was 16 cores sandy-bridge (32 virtual cores).

My original goal was educational, I wanted to understand more. Then I saw the potential and wanted to have a sophisticated interactive preview render. But I was also gazing at making a full render engine, so when I saw the opportunities lining up along the years, I worked very hard get there.

Originally Posted by Rebelismo: It seems that with the ever increasing complexity and advancement in technology, render times have been stable at about 30 hours per frame.


The reason of the constant amount of time along the years is simply because that is what is deemed "acceptable" by production. If it renders faster more will get pushed inside each single shot, or less optimizations will be done because optimizing is time consuming (both from an content and technology point of view).
 
  03 March 2014
Hey Max,

Its seems there are alot of renderers now competing and there is no magic bullet. Aside from glimpse what is most exciting you about the current rendering solutions/tech?

Where do you see rendering software/tech/raytracing going commercially in the next 10-20 years?
__________________

 
  03 March 2014
Originally Posted by patrickrowan: Its seems there are alot of renderers now competing and there is no magic bullet.


Magic bullet=monopoly, monopoly ~ evil. I'm glad there is no such thing as magic bullet.

Consider that there is a very wide range of users. From the preset drag&drop one, to the script everything one. Each one don't like the workflow of the other. It is very unlikely one production would serve everyone well.

Originally Posted by patrickrowan: Aside from glimpse what is most exciting you about the current rendering solutions/tech?


I'm very satisfied in seeing the movie industry recognizing raytracing as the most appropriate solution these days. Up to 3-4 years ago you could get in trouble by just pronouncing that word in some places...
I'm very excited about how GPUs are evolving from realtime graphics to supercomputing. Massive parallel architectures are changing how we think and write mainstream software.

Originally Posted by patrickrowan: Where do you see rendering software/tech/raytracing going commercially in the next 10-20 years?


Ouch, this is a really though question. I'm certainly going to disappoint in the answer because either being too conservative or to be proven wrong by time. 10-20 years ago nobody knew we would have walked around with supercomputers in our pockets. Now we have smart phones that run full HD 3d graphics.

I can see how CPU and GPU are going to merge into a unique heterogeneous architecture. This would define new standards for computing and establish new rendering architectures that could take advantage of that.

Some says point rendering will gain momentum, some says voxels... I'm not leaning in that discussion. There are some other exotic form of rendering like pencil tracing and cone tracing. You never know if they are going to become popular at some point... see what happened with subdivision surfaces that got deemed exotic for nearly two decades since late 70' before becoming the most common form of modeling.

I will state the obvious in saying rendering will get faster and simpler to operate. In the last decade I saw a proliferation of lighting/rendering TDs, some with little to no artistic talent, building their career on technical understanding of overly complicated products and architectures, while some fine artists were left to struggle. If rendering gets simple, those TDs will be of little help in a production which will favor people that can create beautiful work of art instead. If the reader identifies himself/herself in that I would strongly advise them to rethink their area of interests:
  1. become more of a pipeline TD.
  2. learn a great deal about art and cinematography.
  3. toughen up further and become a render engineer.

Last edited by MaxL : 03 March 2014 at 09:37 AM.
 
  03 March 2014
Originally Posted by MaxL: For the better or the worse, and in respect to which tool?


For the better in respect to coding for Arnold. The "everything is a node" concept is great and the C++ you need to know generally isn't much more than for RSL. But when you need it you have the tools and libraries from C++ in a much more accessible form (rather than going through DSO's).

Being able to run C++ debugger and profiling tools to debug shader code is definitely a great step forwards.

Simon
__________________
http://www.rendermania.com/
 
  03 March 2014
Originally Posted by rendermaniac: For the better in respect to coding for Arnold. The "everything is a node" concept is great and the C++ you need to know generally isn't much more than for RSL. But when you need it you have the tools and libraries from C++ in a much more accessible form (rather than going through DSO's).

Being able to run C++ debugger and profiling tools to debug shader code is definitely a great step forwards.

Simon


In general I agree with that.

But let's consider how a traditional C++ shading system will scale. Let's take a 16 cores sandy-bridge with 8 lanes vector instructions. It is somehow a 128 ways parallel computer. The shading API is generally using only 16 out of the 128. The math library can be written to compute color and vector operations using SSE instructions (4 lanes) but a large chunk of the code is still scalar (int, float, conditional logic). So that API will use between 1/4 and 1/8 of the theoretical throughput.

Intel released last year Xeon-phi which have 16 lanes vector instructions, it won't be long before those instructions will become part of main stream CPUs. At which point the shader is using 1/8 to 1/16 of the computing power. Ok, my calculations are a bit wonky, but you can see where I am going.

Vectorized code that would take full advantage of the computing power is not simple to write in C++. So when you ask me if C++ is the future of shading I'd say no, it's the present.

What is your opinion about this?
 
  03 March 2014
Good point. I'm not even going to pretend that I know enough about that sort of thing yet!

I can see why something like ispc would interest you. I guess this is also why frameworks like Fabric Engine have decided to create their own language to handle this sort of thing. http://fabricengine.com/splice/kernel-language-kl/

I know of one renderer - Spectral Studio http://www.spectralpixel.com/ - which has implemented their own version of OSL so that may be a way to go. But obviously that's a lot of work! At least you get the benefits of shaders developed for other renderers - eg Cycles and Vray.

Can you think of any other options?

Simon
__________________
http://www.rendermania.com/
 
  03 March 2014
Originally Posted by rendermaniac: I can see why something like ispc would interest you. I guess this is also why frameworks like Fabric Engine have decided to create their own language to handle this sort of thing. http://fabricengine.com/splice/kernel-language-kl/

[...]

Can you think of any other options?

Simon


Well you have C++ networks of shading nodes (very traditional) and monolitic shading language like RSL (also very traditional). Then you have OSL that sits somehow in the middle but not really. It is a shading language where you write nodes, but then it compiles the network down to a single piece of code. Code is then given to a JIT compiler to make it run fast.

I can see a number of permutations of those elements. Sometimes a great recipe comes down just on how you mix the ingredients.
 
  03 March 2014
Hello Max and congrat everybody at Animal Logic for the great work on TLM.

Thanks also for your answers above, very insteresting discussing!

Quote: Glimpse average render time for LEGO large shots final frames was around 10-30 minutes (a lot longer when in the hybrid mode with Prman). Rendering hardware was 16 cores sandy-bridge (32 virtual cores).


I'm Sorry, I just block on this: I can't believe you had such low render times for TLM (with dof and motion blur?). So my question is: How many percent (averagely) of the shots was rendered in "hybrid mode"?
__________________
My blog (fr)
 
  03 March 2014
Originally Posted by Narann: Hello Max and congrat everybody at Animal Logic for the great work on TLM.

Thanks also for your answers above, very insteresting discussing!

I'm Sorry, I just block on this: I can't believe you had such low render times for TLM (with dof and motion blur?). So my question is: How many percent (averagely) of the shots was rendered in "hybrid mode"?


Thank you for the nice comments.

Because tech was constantly evolving and getting faster and more features reach, I don't have precise data. So I report my very rough projection of render times based on the tech we had a the very end. One thing I must apologise for is that I don't remember if those 30 minutes were for a stereo or a mono render. So let's double that up to be conservative.

If I remember right, rendering in "hybrid mode" were around 5-7 hours wallclock per frame (in stereo), time including all render passes that contributes to the frame.
I would say than 95% or more of the movie was rendered in "hybrid mode". I think only a handful of shots were rendered in Prman alone at the very beginning and a handful rendered in pure Glimpse at the very end.

Only a few shots had motionblur. Motionblur in Glimpse adds around 8-15% to render time. DOF comes almost for free thanks to the nature of sampling in a path tracer. But we rendered without DOF and applied it in Nuke because of the need to tune it in stereo right a the last minute.
 
  03 March 2014
Thanks for the explaination! This seems more "common" production render times.

I will bounce on another question; Renderman seems to still be used in many productions while it's considered as slow and/or less efficient for raytracing stuff. From your point of view, why is there still a need to use Renderman? What are the features you can't have in Glimpse and that make Renderman use still relevant?

Thanks in advance!
__________________
My blog (fr)
 
  03 March 2014
Originally Posted by Narann: Thanks for the explaination! This seems more "common" production render times.

I will bounce on another question; Renderman seems to still be used in many productions while it's considered as slow and/or less efficient for raytracing stuff. From your point of view, why is there still a need to use Renderman? What are the features you can't have in Glimpse and that make Renderman use still relevant?

Thanks in advance!


It's a tricky question and I can't speak for everybody. I'm confident some studios are using it because they know the engine very well and they have tools and pipeline that is bound to it.

It is not about the features, rather how the computation is carried that can make the difference.
Pixar showcased a production at last year Siggraph where they had to render lots of soap foam. I have to agree that some effects like that are much more difficult to render in a raytracer. Traditional cheating you can do in REYES can still be compelling in those cases. But for the regular production, people want a simpler and more predictable renderer.
Renderman is changing too. It's becoming a pure raytracer... Only time will tell.
 
  03 March 2014
Ciao Max! (we are both italians )

First of all congratulations for the great work on the movie. It really was awesome. Everything, is awesome.

Having tried many render engines in the years doing this job, I have always thought that the real difference to speed up the lighting workflow in an effective way would be to have a realtime preview, cutting out the translation time and having a rough/noisy preview frame that gets progressively refined but that already gives a good "glimpse" of what lighting is all about: values.
I remember the Worley FPrime on Lightwave 3D years ago, how revolutionary that was!

I think as for now most of the engines have a "interactive preview" but they don't really have a full interactive rendering.
Modo I think is the only one that has a full quality realtime progressive refinement and I love it because everything gets updated instantly and there is basically no waiting time to have a quick frame good enough for lighting evaluation.

Maybe you already said that, but does Glimpse actually render the final version of the frame right away, progressively refining it, or does it have a close enough preview that the artists use to light?

How much has this approach speeded up the lighting team productivity?
I don't just mean in terms of final rendering time, but in terms of iterations that the artist were able to reach with this way of rendering.
I imagine having something that is noisy but meaningful lets you iterate through shot notes very quickly and the whole lighting approach becomes way more organic.
Or at least this is how it is using Modo, where you can continuously change lights transforms and values getting instant results.

Do you think that this is a real value in a production and do R&D departments focus more on that, or is it just good enough to wait for frame translation and full quality rendering (talking about VFX and CGI movie production)?


Was Glimpse used also as Lookdev realtime rendering tool? I found very valuable to have a fast shading iteration when lookdeving characters.

Thanks a lot for your time!
G.
__________________
Giuseppe Improta
Lead Lighting&Lookdev TD & Photographer

Last edited by knower : 03 March 2014 at 10:39 PM.
 
  03 March 2014
Thank you, Giuseppe.

Originally Posted by knower: Maybe you already said that, but does Glimpse actually render the final version of the frame right away, progressively refining it, or does it have a close enough preview that the artists use to light?


Yes, the only difference between preview and final rendering in Glimpse is the amount of samples used and the order in which they fire. To me this is a very desirable property.

Originally Posted by knower: How much has this approach speeded up the lighting team productivity?
I don't just mean in terms of final rendering time, but in terms of iterations that the artist were able to reach with this way of rendering.


It depends how technical and organised the production is. I know that in some companies Lighters are left to do quality control in place of other departments, to debug assets and versions and to verify if the scene contains everything that is supposed to. That can pose nasty obstacles in the benefits you can get because majority of the time is spent troubleshooting rather than lighting.
You need good artists too. If you have that type of technical but not artistic lighter I was referred in a previous post, they will spend long time poking the lights around without understanding if the result they are producing looks good or not and you will have little improved productivity out of them.

Originally Posted by knower: Do you think that this is a real value in a production and do R&D departments focus more on that, or is it just good enough to wait for frame translation and full quality rendering (talking about VFX and CGI movie production)?


I am not sure I understand the question. If you are asking if R&D within a company should spend time in making the work simpler for the departments... well, that is by definition the purpose of R&D. The challenge is to hit the narrow optimal spot between the cost of R&D and cost of running the departments. If you want to revolutionise you need really good engineers and transformational leaders, otherwise you get average solutions.

Originally Posted by knower: Was Glimpse used also as Lookdev realtime rendering tool? I found very valuable to have a fast shading iteration when lookdeving characters.


No. Lookdev was almost complete when I joined Lego crew. But we can now! Next production

Last edited by MaxL : 03 March 2014 at 11:59 PM.
 
  03 March 2014
Originally Posted by knower: [...] gives a good "glimpse" of what lighting is all about: values.


I know you didn't mean it this way, but lighting is so not about values! Many in the industry actually think that way and it is so far from the truth.

Lighting and camera work are the essence of cinematography. Cinematography is the essence of story telling in moving pictures and photography (cinematography is a superset of photography). In moving pictures, story telling is everything.

If you want to put it down to the mechanics of lights being stored as values, then everything digitally created is stored as, and manipulated through, values, including, models, animation, textures, FXs...
 
  03 March 2014
Hi Max,

Thanks for the answers.

Sorry if I wasn't clear, what I meant regarding R&D is if you think developing a progressive refinement render gives an effective boost in production to justify the investments (in terms of time and resources) required to pursue that road and so if it makes a real difference in production compared to the standard solutions available at the moment.

Can you please expand on the difference between the order in which the samples are fired in the final vs the "preview" mode in Glimpse?

I intended values not in a mathematical sense, but as the tones any image is made of.
I was referring exactly to cinematography or photography (A.Adams zone system for example) but also painting or other visual arts where the harmony of the tones define an image that would otherwise just be a visual noise.

To define the lighting of a shot a good artist (not just technical) usually need to be able to quickly define where to put the lights and to see how they affect shadowing in order to quickly match a shot lighting or to setup a mood and this is way quicker and more organic when using a progressive refinement render than a traditional one where placing a light, wait for the translation, see the render, and start all over again is a tedious and in my opinion not-really-productive process.

Thanks again
G.
__________________
Giuseppe Improta
Lead Lighting&Lookdev TD & Photographer
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 07:31 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.