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
Old 03 March 2014   #31
Originally Posted by knower: 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.


Most commercially available render engines offers some form of interactive preview these days. Ask yourself it you can use one of these and what that will mean for the company (cost of licences, training, pipelining, etc...)
Implement something in house only if nothing out there will serve the specific set of circumstances and requirements you face.

To implement a basic render engine is simple. To make it fast is hard. To make it production ready for high demanding large studios and big Hollywood production is really really really hard work.

Is in-house development more convenient that buying off the shelf products? (We are not talking about pipeline here). Most likely not, unless that development is part of a bigger picture and the "value" of the overall system is much bigger than the sum of the parts.
Also if development is worthwhile really depends on the skills of the R&D and who is leading it. When playing at this level, as I said before, it is a very delicate balance and there is an high risk associated with it. Only knowing your people very well will tell you if you can dare and if its worthwhile. It was for us.

Originally Posted by knower: 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?


To visualise the refinement in progress, interactive rendering tends to scan across the whole image many times. That is less than ideal because as you move from pixel to pixel, different geometry, different textures, different paths will require access to a wide amount of data which must be fetched from memory. Every time the renderer comes back to the same pixel, none of the data it need is in the CPU cache anymore. If you can sample one pixel at a time, the computation would be faster because of the improved cache affinity. Incoherent nature of path tracing makes it all harder and reduces the benefits of the approach. Still...
 
Old 03 March 2014   #32
Thanks a lot Max, much appreciated!

G.
__________________
Giuseppe Improta
Lead Lighting&Lookdev TD & Photographer
 
Old 03 March 2014   #33
Change of Date for Max Liani live Q & A

Hi all,

A note to let you know that the time for the live Q & A with Max Liani has changed. It's now next Tuesday 25th March at 6.00PM PST (LA Time). You can still sign up using the link here: https://attendee.gototraining.com/r/8091432869523882753

We all need to congratulate Max and his wife - as by the end of tomorrow they will be the proud parents of a baby girl! Best wishes Max to you and your family from all of us here at CGSociety.
 
Old 03 March 2014   #34
Good luck in your "nights-without-sleep".
__________________
My blog (fr)
 
Old 03 March 2014   #35
Thank you, Kirsti to reschedule. It would have been tricky otherwise.
 
Old 03 March 2014   #36
Originally Posted by Narann: Good luck in your "nights-without-sleep".


I know those nights very well this isn't the first time.
Thank you for the wishes and the patience.
 
Old 03 March 2014   #37
Hi Max,

I am hoping this meet the artist session is still open.

I've been involved with the artistic side of animation now for many years, but have always had a fascination in producing my own tools and understanding the technology I use on a daily basis.

Would you have any advice that you've learned over the years to pass on in regards to building a good foundation for developing rendering technologies; perhaps some good books that have helped you understand the theory and core mathematics (I am going through computer graphics - principles and practices and the pbrt book, but the latter can be a little overwhelming.)

Also, have you any thoughts on the rendering engine Cycles, and if so, do you see any major shortfalls in it compared to an engine such as Glimpse that would make it unsuitable of big productions. i.e. lack of any major technologies such as alembic, or ptex support?
__________________
I dabble...
 
Old 03 March 2014   #38
Originally Posted by DanielWray: I am hoping this meet the artist session is still open.


Up and kicking. Live webinar is this week.

Originally Posted by DanielWray: I've been involved with the artistic side of animation now for many years, but have always had a fascination in producing my own tools and understanding the technology I use on a daily basis.


That is excellent. Artists that understand the challenges of a technical medium tends to make better choices in his/her daily work.

Originally Posted by DanielWray: Would you have any advice that you've learned over the years to pass on in regards to building a good foundation for developing rendering technologies; perhaps some good books that have helped you understand the theory and core mathematics (I am going through computer graphics - principles and practices and the pbrt book, but the latter can be a little overwhelming.)


If I would have to give you only one advice that would be to not feel overwhelmed or inadequate. Sure writing a compelling and competitive production renderer is not for everybody, but writing a renderer for educational purpose is most definitely achievable.
It is easy to feel overwhelmed reading a few pages of any good rendering book. There are so many systems and disciplines that comes into play.
I don't know what your background is. You need to have a solid base of a few subjects before you take on writing a rendering or other complex systems. If you skip this step, everything is going to be so much harder.
  • Learn a bit about math, trigonometry, matrices and calculus. You don't need to be able to solve indefinite integrals or differential equations, but at least be able to read and understand the formulas in a papers and books is much needed. There are some excellent free open university courses at MIT and Stanford (and certainly others). You might want to check that.
  • Software engineering... Need to know fluently how to read and write C++ code. If your experience is Phython scripting. Sorry but you might have to unlearn what you know. If you don't have a good base of C/C++, study that first and take on simpler projects, like simple animation tools, deformers, other plugins that Maya, 3dMax or your tool of choice allows you to implement. Write simple command line tools, like a tool to rename frames on a folder, or to fill missing frames by copying and/or interpolating from neighborhoods. Write a frame buffer to load a display images. If you find difficulties in these simple tasks you are not ready yet to take on a renderer. Writing a renderer will stress to the limit any foundation you have of software engineering and some times you will have to unlearn what you think you know and learn again (but unfortunately this is not a step that can be bypassed and still understand why you need to do it).
  • Optics and radiometric quantities. Can't leave without that. In particular geometric optics. You can find plenty of resources all over the web.
The fact is that most subjects look like voodoo magic when you know nothing about it.
Many will leave the learning path feeling overwhelmed. If you stick to it and persevere, one bit at a time the picture (or should I say potion) will become clearer.

PBRT book you have is excellent. One advice, you don't need to read its chapters in order. Read and have an overview here and there, then go back to which part you are ready to take on. Example, sampling and reconstruction might seem just nonsense pain when you don't know yet why you are going to desperately need that.

Originally Posted by DanielWray: Also, have you any thoughts on the rendering engine Cycles, and if so, do you see any major shortfalls in it compared to an engine such as Glimpse that would make it unsuitable of big productions. i.e. lack of any major technologies such as alembic, or ptex support?


Don't know almost anything about Cycles, apart that is opensource and connected to Blender so I can't help you with that. I read once that it used to be fast, then it went slower and slower as more features were added to it. In Glimpse lots of my time went into fighting that battle: adding features while not letting performance to deteriorate. It have been very challenging and that is a dark art even when you know how things work.

One thing worth saying, if it is hard to add support by yourself for something like Alembic in a renderer, then that renderer is not something worth using in production. Not because of Alembic itself, but because during production you will have to add supports for random things and you will have virtually no time to do it. This is the main difference between production renderers and the thousands of rendereres (either open or closed source) you find all over the world.
I hope this helps and motivates you.
 
Old 03 March 2014   #39
Thank you for your response Max, I appreciate it immensely

I shall keep focused on building my foundations.

I really like the suggestions for taking on smaller tasks, this is something I am actively pursuing and I believe will help me on a lot of levels later on when I get to the stage of implement more complex productions tools.

Currently I am using Python, of course I will need to take the dive into C/ C++ in the future, but I had thought developing advance skills in python would help me, as a lot of 3D applications can have complex add ons/ plug-ins developed purely in Python.
__________________
I dabble...
 
Old 03 March 2014   #40
Originally Posted by DanielWray: Currently I am using Python, of course I will need to take the dive into C/ C++ in the future, but I had thought developing advance skills in python would help me, as a lot of 3D applications can have complex add ons/ plug-ins developed purely in Python.


Technically you could cross the ocean with a kayak... The fact that most apps allows to write complex plugins in python doesn't mean that people should

Python is not the fastest or most efficient scripting language (far from it). Yes, as a scripting language is easy to write and it is versatile enough and for this reason people indulge and use it and abuse it for the wrong reasons... like writing complex plugins, modules or entire applications with it.

When you are about to implement something, ask yourself this question: how many times is this code going to run? Once per day, once per hour? Once per mouse click? Or once for each asset I load or visit? Is 1 millisecond per iteration fast enough? What if the code runs once per asset in a million asset at scene load? At 1ms That would be 17 minutes of wait... Don't have scenes that big... yet... If there is a chance, it will. Once the bad practice of abusing scripting languages is widespread it is very hard to profile what is slow in a pipeline and bring it back in control.

Second point about getting too familiar/skilled with python before getting comfortable with C++.
Python is too simple and it forces you to indulge in bad habits like abusing of object oriented design and ignore all together the implication of memory access patterns.
If high performance computing is you goal, then most of the "good practice" you learn as advanced python developer are pretty much useless and they might get in the way because on them you constructed the foundation of the way you think about software development (remember, sometimes you have to unlearn, which can be very hard thing to do).

Third point. I strongly argue writing python code is easier and faster than writing good C++ code, if you are organized. People often compares these 2 situations:
  1. well skilled and organized python development
  2. low skilled and disorganized C++ development.
You must compare apples with apples. Writing good C++ code is not slower than prototyping in Python.
 
Old 03 March 2014   #41
Recording of live Meet The Artist session with Max Liani

Hi all - here's a recording of this evening's live web Q & A with Max. it's mostly audio, so put your headphones on and listen while you work. There are a few images towards the end. Enjoy.

 
Old 03 March 2014   #42
Great session; thanks for taking the time to answer our questions Max.
 
Old 03 March 2014   #43
You are wellcome. Any other questions, ask them here
 
Old 03 March 2014   #44
Hello again Max (and thanks for the QA sessions, very interesting)!

I've hesitated to bounce on your last answer because I was thinking it was a bit technical but I think most basic questions has been asked so let's go!

I'm also not a big fan of "massive OOP" (when you spend time deriving a class of a derived class of a etc. And at the end it's a mess) so I share a lot of what you said.

Writing good C++ code is not slower than prototyping in Python.

This is true only if you are comfortable with both languages. C++ has a far more hardest curve than Python. You can easily be comfortable with Python if you are an experimented C++ developer but the invert is not true. That's why I encourage technical guys, specially young ones, to learn it as soon as they can, this is never lost.

There is my question:

As C++ is a huge language (biggest one?) that have multiple approaches, what are the key C++ concepts you (Glimpse) deeply rely on and what are those to tent to stay away from? It's not specially how Glimpse work under the hood but what C++ design choice you've made. Are you massively relying on templates? Are you massively relying on class derivations? Are you massively relying on data oriented coding? What is your opinion about stack call cost from a rendering side? etc.

This is a general question about your day to day coding approach when you are working on Glimpse.

Thanks in advance!

EDIT: I just love your dinosaur wall! Are they instances? Didn't get it.
__________________
My blog (fr)

Last edited by Narann : 03 March 2014 at 09:43 PM.
 
Old 03 March 2014   #45
Originally Posted by Narann: Hello again Max (and thanks for the QA sessions, very interesting)!


I hope I didn't speak too much. In trying to be informative I tend to over explain and repeat myself when I don't know my audience background.

Originally Posted by Narann: As C++ is a huge language (biggest one?) that have multiple approaches, what are the key C++ concepts you (Glimpse) deeply rely on and what are those to tent to stay away from? It's not specially how Glimpse work under the hood but what C++ design choice you've made. Are you massively relying on templates? Are you massively relying on class derivations? Are you massively relying on data oriented coding? What is your opinion about stack call cost from a rendering side? etc.


Yes, C++ is sophisticated. Probably what is hard for the novice is learning how to make good use of STL containers and algorithms. Template syntax is not the most friendly one, but when you bridge that gap, it is very very powerful. Something that makes C++ hard is the depth of it. In scripting languages the developer delegates to the runtime environment memory management and access altogether. If you want performant software, sorry bout you need to get your hands dirty.

What I use a lot in my daily coding (rendering or not) is inlining, templates, and well structured libraries and containers. Once you have good libraries you know well, writing solutions quickly is very easy.
The use of OOP or data oriented designs strongly depends on the task and the amount of data and the access pattern. Because I didn't have formal training in computer science I'm not fussy on formal coding, encapsulation, abstraction and the like. I'm pragmatic and I am not afraid to have a 1k lines of code function if that gives me substantial benefits.

I tend to stay away from multiple inheritance or deep nested inheritance. I use virtual methods as little as possible, and often the base class is pure virtual. Mainly for factories and other parts of the plugins system interface. I rarely use inheritance as a a pure way to reduce code duplication or to enforce structure. In performance critical sections I favor inline templates end function pointers interfaces to OOP.

I tend not to use intrinsics directly. They make code unreadable. I favor good inline libraries that provides a very thin wrap around intrinsics. Headers only libraries written the right way gives you very good readable code where all intermediates symbols disappear and resulting machine code is as good as it gets. I use inline assembly the same way.

Extremely important in performance software engineering is data alignment and the deep implications of data sharing.


Originally Posted by Narann: EDIT: I just love your dinosaur wall! Are they instances? Didn't get it.


Yes, a few different models, instanced to many. This is why I said it becomes almost nonsense to measure. It is important unique primitives to be as compact as possible, but instances don't come for free. Having very lightweight instances is important to be able to have a hundred millions of them trough which to compose extreme visual complexity (the wow factor in recent Whisky Tree Elisium and Athene demos, which, even if a lot more visually stunning than my examples, they weren't even close to have this much stuff on it).
 
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 10:48 PM.


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