 Hello, I'm going to talk now about cycles for animated feature film production So my name is Stefan van I'm a C++ developer most of the time. There's some Python thrown in and Maybe a bit new to Blender here. I've been working in the 3d industry for over 15 years I was one of the core developers on poser for many many years developed a whole bunch of render features That were quite our voc at the time and in 2015 I started building a path tracer for poser and we decided to actually end up using cycles and integrating it into poser Which was a good experience with it and it started submitting bug fixes and It's just in the beginning of this year. I started working as a freelancer and my current job is improving cycles for tangent animation So tangent animation if you have been here last year Just show of hands who has seen the talk making Aussie with Blender last year Okay, so the rest of you can catch up on YouTube. It's recorded But basically they can give a better introduction of tangent animation I possibly could so I'm not going to try But just in a nutshell tangent animation is an animation studio in Canada It's going to be around 150 people. I cannot say exactly and they're doing feature film production using Blender The first feature they released is called Aussie and it made it to theaters in several countries last or yeah last year Currently in production. It's a movie called next-gen. It has a budget of 30 million dollars and is scheduled to be released next year I know you're all excited to see something of it I can tell you all about Nothing. I wish I could I really wish I could show you anything about it, but I just do not have permission Next year I'm sure No, instead I'm going to talk about all the technical sites on the rendering Street, so if you've seen the talk from Francesco this morning We're running in some of the same issues as they were running into in the Asian 327 What is the one thing that's always too long? Render time As Francesco was always being asked like what is your render time? It's too long It is always too long render times too long your scenes are too big You cannot render on a GPU and you have over 100,000 frames to render each frame takes several hours if not days So why is rendering so hard Well, you have hundreds of millions of race a trace per frame you have hundreds of millions of triangles per frame and Main cost is always finding out which ray of these millions hits which of the million triangles and if you can make that faster You have made rendering faster So I was basically my first job was to make rendering faster So I look at who's to who's who's better at this than I am It turns out there's a library out there that does rate tracing on a CPU and it's highly optimized and it's really good It's called Embry Developed by people at Intel. They've published several papers about it and it's completely open source We can use it. It supports triangles quads subdivision displacements and all the features you would want And it's continuously being developed so we get free bug fixes from it all the time The only thing that's missing is GPU support Since it's Intel I guess But anyway, that looked very promising so I started integrating it into cycles And it's just used it as a drop-in replacement for what is already in cycles for doing those intersections So it's supporting all the primitives that cycle stuff through triangles. There's the hair And subdivision displacements are just treated the same way as they're treated in cycles already They all turn to little triangles and then we ray-trace them and the important part for production As they had in the agent as well motion blur is something you do not want to live without and it's always very costly So there was a few modifications to Embry not very much just to line up a few things couple hundred lines of cycles code All you see in the end. It's just a little check box So how does it perform? Do we actually gain anything from all the work that I did? First thing you run is a usual benchmark suite. You're all familiar with this these are numbers from an early version run on a standard laptop and Well, some of them are actually slower Some are faster some are a lot faster and the larger scenes also are faster But I was talking about tens of gigabytes of stuff to render So how does it look like the bigger scenes? Oh I skipped the memory Memory is also doing Roughly the same some that's better sometimes worse, but let's move on to the big stuff, right? agent so the agent scenes this is one of the stills I Wanted a more problematic ones from what I hear And just assuming on what the results were this is not my laptop. This is a bigger machine we're looking at render time of 14 minutes for a Very noisy frame and about five and a half gigabytes of memory being used Doing the same thing in Emory Gives you what looks like the same result if you do a pixel by pixel comparison. You see there's some differences in the air But if I hadn't told you you probably would not know that this is a different image And there well we saved two minutes and memory went up a little Now this is for motion blur Doing the same scene again with motion blur Which as you can see there's not a lot of motion in there, right? This is a head is moving a little the curling iron is moving a little But it's not one of those extreme motion across the screen and scenes, right? It's just a simple simple little motion frame So in standard cycles this goes from 14 minutes to an hour and your memory almost doubled It's the least what three gigabytes more than before Doing the same thing in cycles is the frame again Rendering this in 14 minutes memory went also up but not not far so 16 minutes to less than 15 minutes nine gigabytes of six gigabytes. It's it's four times faster Using two-thirds of the memory. So yeah, it turns out we can have both memory and speed Now a next-gen I'm not going to show you the frame, but I'm going to show you the render locks So the flat line here means We stopped the job because the weekend was over So we don't know how long these render they might be somewhere up there We I don't know but basically this line here is about 48 hours And this is got to be somewhere around four hours and The red line is using standard standard cycles right so some of these frames a lot of motion They're unpredictably high some of them are actually reasonable right just around four hours of frame But your average production manager would probably prefer having a flat line over here Rather than having something that jumps up and down because it's just unpredictable, right? You send the frames off for a weekend want to review them in the morning and half of them didn't even show up and Instead in using Embry we get a much nicer profile, right? So this is maybe around 10 hours May be bordering 14. I didn't do the exact math But it's just a lot more predictable right and so for for the individual frame Some of them actually got slower, but overall it's a lot of savings here So the future of this There's more things that I could support right now It's just supporting the basic level of what cycles was already but there's more time more memory and more performance to be gained from from Supporting quad meshes directly that could save just a quarter of memory right there And if it could handle subdivisions and displacements by itself then we could save time Not doing them in advance, but actually doing them when they're necessary, which is what Embry promises Also using the split kernel may or may not give a benefit using Embry It's hard to tell without trying it And there's one or two little things that are slightly better in cycles and there are an Embry and Why not it's open source. We're sharing for all friends take some cycles code given back to Embry so everybody else can use it and The final project would be of course if he could use the same acceleration for the GPU, right? Anyone that has a scene that actually renders on a GPU because it fits in memory, but has motion blur Sure, why not have it ten times faster? We'd be happy So that was the one thing we've had render time is a big problem and in cases we've got it to be ten times faster Sometimes equal but a good chunk of savings right there What's next? What is what is your other problem you always have? memory So looking at that Again a render log 100 megs right there, and it's still loading textures actually not started rendering it Where does all the memory go it goes through your textures textures are huge these days You have several material layers. You have albedo roughness material normal everywhere and your taxes are at least 4k Right if not 16k and every pebble has a texture and so you end up with tens of gigabytes And where do they go right? You're You're rendering a 4k image frame for a movie So every single texture has more pixels than the resulting frame Where do those pixels go? Well, most of them don't even show up on screen. They're behind the camera There's somewhere to the right on top or there's the huge texture and it shows up this big on screen So instead of loading all the textures before rendering We just load no texture before rendering and instead we just load the textures when we need them and what we need them and we take a fixed size of memory declare this to be our texture memory and With a bit of optimization we can save files to disk in a way that we can pick only a certain junk out of it And if you do map mapping we also solve the problem that if you're looking at this small You don't have to go all over the file to fix to find the individual pixels But actually have all of them in one place Now that is quite some work to actually figure out which pixel to pick when and where at what size you see it on screen So I'm not going to bother you with the full details But we just have to trace the footprint of array basically how big does the ray get through reflections and diffuse Bounds of sometimes it gets wider sometimes it gets narrower And for the actual management of the cache loading it loading the files evicting them keep making sure you're not exceeding memory It's also something already there and there's a library called in it open image IO And it turns out cycles is already using it Just not for a texture cache Or at least not an efficient way or some ways you could force it to use and so I just extended it based on that and The texture cache and open image has been production tested There's been a lot of Hollywood films already out that use it So we know it's working any bug that's in there is my bug and that theirs And putting it into cycles just like before it's just a little bit of UI you can pick your texture size and set a few options that Probably will stay on most of the time and You can use a memory right instead of loading tens of gigabytes of textures You just tell it how much you want to use I can tell it well use one gigabyte of memory and that's it And it'll just fill them up as needed and Empty it out when there's old textures and you know ones have to come in It does slow down rendering though, so we measured about 10% depending on the cache size if you use a really small cache size You can double or triple your render time if you make it really large It's almost the same It also requires you to pay some attention to the color space I think by now everyone is aware of color space is a topic But even more so as soon as you do mip mapping Setting the wrong color space becomes more apparent than before So it turns out we're not actually using this attention in production at this moment It's just not at the point yet where I think it's complete enough stable enough reliable enough and What I did not mention before about Embry is that switching to Embry Just like you saw in the ancient scene where it went from nine gigs to six gigs Equally the scenes went from 90 gigabytes to 60 gigabytes just by switching to Embry so so we also saved memory right there and Using texture caching just was not that important anymore. So it's something for the future and We just need to figure out now how to do proper map maps for normal maps and displacements Where to put those files on the file system? Just to make sure we actually have right permissions and we don't actually fill up your hard drive with useless textures all over the place And there's always some more performance using performance tuning we could do Again the CPU split kernel could help us maybe getting more better at cache performance out of it and Everybody's always asking about a GPU which which will be really hard for texture caching, but I'm not rolling out that it's impossible Now there's a third thing to talk about the third thing It's more important than render time and it's more important saving memory Who here wishes they had a 48 hour day? Use of time right you can always buy another computer you can always buy more memory But you cannot clone your best animator. You cannot clone your best render render those those people in your In your team, they're irreplaceable and you want to make sure they use your time efficiently so We could improve this everywhere right blender is good, but it's never perfect. You could always make things easier to use and The one thing I was working on for this time is making compositing easier Now if you want to create a mat for a certain object right now, what you have is ID mats in and blender So you give each object or material you give it as ID number And you get a false color image back that's basically has some number for each pixel Telling you what object is on this pixel But it's only one object Most of the things that are on screen actually more than one object Either there's a border and you get anti-aliasing or death of field you see a blurry image of one object and one behind it motion blur has several objects in one place and also transparency and The ID passes also requires a manual setup right you need to assign these numbers to these objects And you need to keep a table of actually which numbers which objects so you know it later on So you actually end up with a large extra sheets in production that is just numbers and names and numbers of names of objects Turns out again, I'm not the smart guy somebody else at the work already That's like something called crypto mat Which uses the name of the object or the object material as an identifier as opposed to a number and it turns that into a little Hash so it crunches it and stays it to a color channel The coverage of how much that object Takes in a pixel It's encoded the next color channel. So just using regular RGB a you can already store two layers of depth so transparency layers or anti-aliasing and If you take if you take three layers of RGB a data you already have six layers of depth for compositing for any number of materials requiring no setup other than just You know clicking the box So you click this box render the image and you have your your mats already set up In the compositor you have a new note Where you take those extra layers and put them in And you can type your name of what you want to select and not sure if you can see it from the back But I was typing window and lower intake actually see the lower intake being matted out and Very transparent very faintly the window because it's mostly transparent Or Instead of actually typing the name you have these color pickers And you just pick something from false color image You click the body of a car and you get the mat of the body of the car including the little part that's behind a transparent window And In action I did a little video of how this looks like when you're actually using it. So here's a little setup a well-known scene I think Just rendered all with a simple crypto mat layer and here's a little color correction being applied just to make sure You can see that I'm changing something So this is program or art. It's nothing fancy Um This here is a false color image that it can use to actually pick objects from from the scene with a color picker And let's see if the video is playing All right, just going quickly over it and next time going you just type the name of the jacket So the geometry name of the jacket And then it's gonna give us the color correction on the jacket So typing the name And here's a jacket Same thing again typing the body and here's the next one I could just go in and type and delete or I can actually use the color picker pick the body and It's gone same thing for this This is and now instead I decide well. I want to have the blades of grass here. I'll click them Here they are. I can add the rocks So these are coming up next this one has a death of feel on it Let's add in Frank the sheep and because it's still live we can actually edit and change the colors and everything Mind you the limitation is still the input is RGB a right. It's not deaf It's not multiple layers. So the color correction applied to the sheep just takes the The grass in front of it with it to a certain degree. So it's not deep compositing But it's a significant improvement where it's just your single layers, I think So and that concludes the three things I was supposed to present today. So Emory is running faster in cycles open image IO in cycles uses a lot less memory and Crypto mad makes compositing easier and the bonus features that does not just three cycles features It's actually a new compositor note as well How far are these things from master So I've talked to some people here. We're gonna make branches for crypto mad and Emory on get blender orc Open image. Oh, I think it's just not ready yet for master at all. It's just more work to be done But that doesn't mean we're keeping it from you Source code is public. This is The tangent internal repository. These are the branches for each feature based off of an older version of master But they will move to get blender orc really soon. All right, that's it. Thank you very much