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…
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.
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.
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…
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.
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?
That is excellent. Artists that understand the challenges of a technical medium tends to make better choices in his/her daily work.
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.
[ul]
[li]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.[/li][li]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).[/li][li]Optics and radiometric quantities. Can’t leave without that. In particular geometric optics. You can find plenty of resources all over the web.[/li][/ul]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.
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.
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.
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:
[ol]
[li]well skilled and organized python development[/li][li]low skilled and disorganized C++ development.[/li][/ol]You must compare apples with apples. Writing good C++ code is not slower than prototyping in Python.
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.
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.
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.
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.
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).
No, there was good examples (really like your three images about why “caching is not enough”) and it was actually interesting to listen how you work with your team, how you choose to add something or not. You also go through few technical aspect (memory access) so there was room for everybody.
Thanks a lot for your technical explanations! They are extremely valuable as C++ is something I continue to learn smoothly but it’s hard to know what are the part of the language you should spend time on as you can read many different things about “how it should be used” (OOP vs DOP). This also make me confident actually!
Latest question (after I stop I promise!): Do you massively use STL containers or you prefer have your owns, even for things already provided (like vectors I guess)?
STL containers are well designed and generally speaking highly efficient. Make them your friends. There are some cases were I create a thin wrap around STL containers just to simplify common complex operations. In some other cases I have my custom containers because of specific requirements… i.e. an empty std::vector is 24 bytes, for certain applications it might be too much.
