Through the years, one of the most difficult challenges in the VFX world has been the integration of CG generated creatures in the real world. The desired result of these efforts is to make them look as much realistic as possible and produce a uniform and well assembled scene.
Comparing the very first attempts of mixing CG elements and reality with the latest productions, it is clear how the development of new technologies and specific software has led to a very detailed result in terms of physical accuracy.
We have decided to focus our attention on a tricky and interesting aspect of this scenario: furry creatures. Luckly we found experts, whom, due to their role and experience, have managed different issues with completely opposite approaches and have then shown us.
We want to introduce you Francesco Giordana!
With Francesco Giordana we focused on the technical side of the matter, he is the lead of creatures Research and Development for Double Negative (the winning company in the vfx category at the 87th Academy Awards). After four years at Guerrilla Games he joined the studio to develop and implement a whole new framework for the realization of fur using the most recent GPU technology.
He worked in the R&D department of Dneg in many famous recent productions like Thor: The Dark World, Hercules, Jupiter Ascending and the upcoming In the Heart of the Sea; showing us the point of view of a young passionate and talented developer. Moreover he was enthusiastic in answering all our questions in a detailed and professional way.
Us: What is your background? And what was your first experience in the CG world?
Giordana: I achieved a Master degree in Computer Science at the University of Turin, with a specialisation in Virtual Reality and Multimedia. I started my studies at the Polytechnic of Turin, but soon realised that I was more attracted by computer graphics rather than antennae.
Even though I started learning programming in elementary school from my parents, my first real experience in computer graphics was my internship for my Bachelor degree. At that time a new group was taking shape at the Virtual Reality and MultiMedia Park in Turin and I joined them for some months to collaborate on the writing of a real time rendering engine. My task was to write a Maya plugin for importing/exporting scenes for the rendering engine.
That was the first time I opened Maya, or heard of a Scene Graph, or looked at a shader’s code.
Us: What are the most useful learnings from your past university studies? What is your advice to young students who want to approach your field?
Giordana: One topic that is often neglected when studying programming is Mathematics. In CG, mathematics are the key ingredient for understanding the algorithms and techniques applied in generating the pretty pictures. The more advanced your math knowledge is the more interesting and innovative projects you will get to work on.
Since the aim of CG is to simulate real world physical phenomena, in general having a solid scientific background will enable you to understand advanced topics like fluid simulation, light transport or tissue deformation much better.
Another subject that is very important to learn is Software Engineering.
It is quite common to be asked in an interview what kind of C++ (or python) libraries you know, what design patterns you use, what open source projects you have looked at and so on.
My adviceph is to choose one or two open source projects and try to get involved with them. This is one of the best ways to make an impression for someone fresh out of university. For me it was the OGRE rendering engine project, I wrote the Maya exporter for it when I was studying and that really helped me in getting a job.
It seems like a lot to learn, and most of it can be acquired on the job, but a strong preparation in scientific areas will definitely give you a head start.
One recurring problem in the CG industry is that, at some point, we all chose this path imagining that we would spend most of our time writing some amazing new technology for the next generation of spectacular movies, or video games. The reality is that you spend most of your time doing software engineering. For this reason any extra knowledge that you might possess can enable you to jump onto advanced and interesting projects when you suddenly get a chance to do it. And it doesn’t happen that often.
One more tip, try to fit in your studies (at university or even outside in your spare time) some artistic education of sorts. It doesn’t mean to start sculpting characters like crazy, but rather to start understanding what makes certain images pretty, how colour contributes to the aesthetics, how you can draw the same thing in different styles and achieve different effects.
It is some sort of scientific approach to art, but it will prove very useful when you will be asked to write technology to create pretty artistic images.
Us: You have been working in the UK since 2011. How did your life change when you moved abroad? Did you find any difference between working in Italy and England?
Giordana: I left Italy in 2007, then worked in Amsterdam until 2011 when I indeed moved to London.
The first major difference was the attitude of the potential employers at job interviews. In Italy it always felt like a job interview was some kind of favour granted by the company. Instead in the UK, and also in the Netherlands, it always felt very much like a discussion between equals. While testing me for my skills, the employer would also try to convince me that their company had a lot to offer and it was a good working environment for me.
Another major difference is that here seniority is awarded not by age but by skill. If you are young but you are talented you can very quickly be regarded as an expert or lead in your field. Most seniors in the CG industry are actually in their late 20’s or 30’s.
Another small detail, which I think is quite representative, is that abroad “recommendations” for a job are considered a very good thing. This is because you usually recommend someone that you consider talented. In Italy the word “recommendation” has a negative connotation, most likely because of its abuse.
Us: What are the similarities and differences between movies and videogames industries? Did your tasks change? What are the new skills that you acquired?
Giordana: While the technologies are quite similar, and some of the development efforts overlap, each industry offers its own specific set of challenges.
In both cases there is the need to push for performance, but while for games that is essential (or you won’t have a real-time game), for VFX it is something that saves you money but doesn’t stop you from delivering a movie.
In games you are often forced to sacrifice artistic quality in exchange for real-time performance, in film that is not an option. You just cannot deliver anything that looks below standard, or it will be very hard to get more work.
On the other hand, if it takes 24 hours to render a shot, and you have no other solution, you can still pull it off.
Simulation techniques in film tend to be more advanced and computationally expensive, while in games the engineering effort is usually bigger. This usually translates into very creative uses of technology in games in order to approximate something that is considered too expensive. In films instead, the same problem would be solved in a more physically accurate but expensive way.
Games definitely forced me to improve my programming skills, slow and dirty code is simply not accepted. You also learn to come up with unorthodox solutions to work around the heavy constraints that the technology imposes on you.
In VFX instead, I ended up going back to my old math book quite often, in general I felt like I had more room to try out different algorithms and technologies.
It’s hard to tell exactly what the differences are between the two industries, since each company is different and so much depends on personal experiences. No matter what, switching between the two is fairly easy, there are lots of opportunities to do it, so I suggest to try both.
Us: What is Research and Development in movie field about? What is your typical workflow?
Giordana: Big part of it is writing plugins and extra tools for third party software bought off the shelf. Writing internal technology is getting more and more expensive, so only very few big studios can actually afford to write innovative new software in-house. Luckily Dneg is one of those companies so I had a chance to design and write a whole new fur system there.
Most of the R&D efforts go towards making the “pipeline” work seamlessly, which translates into writing a series of tools and processes to carry the assets through the various stages, from modelling all the way to lighting and rendering, in the shortest possible time.
Sometimes a specific need arises in production for some technology that is not available commercially, or is too expensive or not good enough. That is when you get your chance to write your own solutions and the exciting work begins.
Usually it all starts with some documents with specifications put together in production, which should describe what is it that they would like to be able to do and how.
After we get the specs, and after quite a few discussions with the production team, we start the design and then the development of the new tool. We set milestones with demos to show our progress and gradually we put together a new piece of software.
At some point we feel that the tool satisfies the requirements so we organise a company wide tech demo and then release it to any production team that might request it.
At that point, we switch to maintenance mode until we decide that a new development cycle is needed or we switch to a different project. From that moment on we will keep receiving requests of support for the new piece of software.
Some companies have two separate teams for support and development, while many others try to get a reasonable balance between the two across the same R&D team.
Furball is a GPU-Accelerated node-based framework for hair simulation and rendering that you developed for Double Negative. The framework is hybrid and it is capable of falling back automatically to CPU computation at any point of the graph.
Yes, this means that we try to use the GPU as much as possible. When some things just cannot be carried out on the GPU, either because we need too much memory, or the algorithm doesn’t perform well on the GPU, or we simply didn’t have time for a GPU implementation of some features, then we switch back to using the CPU just for that portion of the code.
Being the framework node-based, this translates into having each node run either on the CPU or the GPU.
Us: So Furball guarantees to save computational time (but the price to pay is to have a dual implementation, one for the CPU and one for the GPU), how did you manage the resources consumption issue? What is more important in your field, time or space?
Giordana: You have touched the two biggest issues in GPU computing: writing good code and using memory efficiently.
There is one major way to avoid code duplication: compile the same code for multiple targets. To do this you need to use a specific language, whether it is a c++ library like Thrust or OpenCL or a completely new language compiled directly with LLVM, like Fabric Engine’s KL.
Programming at such high level has its advantages, it lets you focus on the overall strategy, but it doesn’t give you the full performance boost that you would get writing GPU specific code with something like NVidia’s CUDA.
For Furball, we decided to write two different implementations: a heavily multi-threaded one for the CPU with TBB and a GPU specific one with CUDA.
To avoid excessive code duplication, we kept the high level logic, which was shared between CPU and GPU, separate from the computation kernels, which were written twice, once for each architecture. Only the basic operations (like sum the length of all segments of a curve) have dual implementations, but because we were able to keep the same algorithms for CPU and GPU, they are quite easy to maintain nevertheless.
The problem with memory utilisation is twofold:
1) there isn’t much memory on the graphics card
2) it’s slow to transfer data back and forth between main RAM and GPU RAM
To avoid constant transfers of lots of data, in Furball we keep the memory on the graphics card for as long as we can and only when we are forced to compute something on the CPU we move the data back. The biggest effort was to make this process completely transparent to both the user and the programmer. The system is designed in such a way that it will automatically activate the memory transfer only when needed.
To avoid the problem of running out of memory we force a partition of the data into partial subsets.
To answer your question, both time and space are important. Running out of memory might make your computer crash and force you to try a different approach, while having a process that is too slow will frustrate the artists and lower the quality of their results.
Us: Does DNEG exclusively own it? How does it work if another company wants to use it for another production?
Giordana: Dneg is the exclusive owner of Furball right now. Some other studios have expressed interest in using it, but in order for that to happen a complete restructuring of the code base should happen. There are so many dependencies on Dneg’s internal software that it would be a project of its own just to make Furball deliverable externally.
A very popular strategy in these cases is to open source the software, in order to build a community and get some help in supporting it.
Edgar Pironti, Chiara Sapio
Front Effects - VFX curiosities and Making of 
Reblogged this on 3D artist to be.