 Last year we have done a huge project for us, for us it's Monique de Vachant and me myself Jeroen Bakker. It's the OpenCL compositor and the compositor redesign. Last year during the conference we did an OpenCL test and basically the outcome of the OpenCL test is fun. Het werkt, maar we moeten veel dingen doen in het kernel van Blender in order dat het echt stabiel is. En last jaar was dat project de stabiele kernel gecreëerd in order voor OpenCL te werken in het compositor. Documentation kan worden ontdekend en, well, let's see. Dit is de compositor. Als ik de compositor opende, zag je dat het in intuilen was gebouwd. Dit is vooral omdat van de behoorlijkheid die je hebt wanneer je het OpenCL gebruikt. Ik kan de renderer loaden, en je ziet dat de image geïnteresseerd is. Dit is de final compositor. Je kunt de settings veranderen en je ziet dat de compositor direct interact en veranderen. Je kunt de kleuren veranderen en je ziet dat het interactief veranderen is. Elke pixel die gecalculated is geïnteresseerd op het scherm. Als we naar de behoorlijkheid gaan. Als ik de behoorlijkheid selecteer, dan zie je een heel grote cross. Dit cross veranderen de pixel die eerst gecalculated zal zijn. Je kunt dat veranderen, als je dat wilt, omdat het zou zijn dat je op de houten werkt. En of naar de tie veranderen. Deze veranderen starten gecalculated daar. Maar je kunt ook zeggen, ik ben niet echt in een specifieke deel. Alleen random dials van een compositor. Je kunt het veranderen en het veranderen. Oeps, oké. Deze image is niet zo groot, het is een 1k image. En je ziet het direct veranderen. Oké, laten we de volgende openen. De volgende ik wil laten zien is een centrale image. En we gaan er wat op doen. Dit is een centrale image. En op het achtergrond zie je het. Een deel dat is heel moeilijk in Blender is om de kleursetting te veranderen. Nou, we hebben nu een kleurcorrectie note. Het is een heel groot note. Maar je kunt het veranderen en het veranderen. Je kunt het veranderen van de hele image veranderen. En het is direct veranderd. Maar je kunt ook zeggen, ik wil alleen de zettingen van de kleursettings veranderen. En het zal bevindigd worden. Je kunt de zettingen van de kleursettings veranderen. Maar om heel moeilijk te zijn, het zou mooi zijn om wat moskeer te hebben. We kunnen wat moskeer gebruiken. Ik heb de moskeer note geëerd en je zal direct zien dat een square is geëerd naar het achtergrond. Deze square kun je veranderen. En je kunt de zettingen veranderen. En dan kun je die moskeer aan de note veranderen. En je zal zien dat alleen direct de effect zal gebeuren op dat deel van de image. Maar om een meer complex moskeer te creëren, kun je de moskeer veranderen. Zoals ik ook een bocksmask heb geëerd. En dat bocksmask roteer ik een beetje. Ik ben sorry? Ja. Ja, we kunnen ook de moskeer veranderen. Dan de square moskeer is veranderd van de ellips. Maar het is alleen gebruik voor simpel moskeer. Maar om te zijn, ja. Dit moskeer heeft een heel sterk lijn. Je kunt ook een blok gebruiken om dat lijn te maken. We kunnen dat moskeer veranderen of erot veranderen. En als we het doen, hebben we nu nog meer verschillende opties. We kunnen de deel van die erotie veranderen. Maar ook de inzet. Hoeveel pixel is gebruikt om minder sterk lijn te maken? Oké. Nee, je kunt alles als moskeer veranderen. Het is niet limiter aan deze noten. Het is gewoon, deze noten kunnen simpeliseren wat tasken. Black and white image. Just the same as you create moskeer. De systeem zelf konfers het als de noten wil het. Dus je moet er niet voor zorgen. En andere dingen die mensen zorgen over, is de resizing van image's. Zoals ik deze image heb. En ik wil dat mixen met een ander image. En dat image is een vuil. Ik open de vuil logo.png En ik mixe die twee samen. Wat we zien is dat het logo zelf is niet volledig. Het is in het centrum van de laatste image. Maar soms soms is dit niet goed genoeg. Je wilt om het hele image te voelen. Als je de renderseis veranderd bent dat de imageseis ook veranderd is. Met de user interface is het niet mogelijk, maar in het framework is het daar al. En met een Python kun je dat deel accessen. Ik ga naar mijn mixnode. Het is code mix. Ik ga naar mijn input. Ik selecteer de tweede input. Dat is de tweede image. En ik kijk naar de resize mode. Als ik het zie, is het centrum. En ik kan het opzetten om het fit met. En dan de renderseis. Het is nog steeds experimentaal. Maar op dit systeem. Ik heb het vandaag gewoon testen. Maar misschien is het een noon boek. Of een unknown. Let's try it again. Ik render de cube. En de image is daar. Ik kan de alpha weer veranderen. Try it again. Als het voelt, ga ik continu met de volgende context. Inputs. Met de typo. En je ziet dat de image fitst tot de width. Als ik de resolutie veranderd ben. En ik render de image weer. Het zal stik tot de width. Of de render image. Wel, basically, you see that the system builds up. But you get faster feedback of what's going on. What will the final image look like. This makes the workflow of the compositor much more interactive. And you will get more speed. That's at least what we want. But that speed can also be used to make more complex nodes. I will do a different node set up. I will get an image. Of London Bridge. Not London Bridge, but another one. And you will see London Bridge. This is a 2K image. And now I can try to do a real boke blur on it. Now I disabled it. And you will see that boke is rendered. And the boke is a square. And you will see that it's not real time. It's just, it's not real time. But you can also change the settings. We can say, well, I'm editing right now. I don't need the final quality of the image. And I change it. And it looks almost the same. You will get the quality, but it's much faster, as you'll see. This calculation takes normally four times more than the other one I did. But having a real boke blur has some advantages. You can change how the camera look, the internals of the camera look like. And you can apply it. You can change the angle of the boke image. And it rotates. And it rotates. But also the rounding of the boke image of the camera internals. Alt, the defocus nodes we have in blender. It only has straight lens flaps. We can now have round lens flaps. But also lenses, the internal part of the lenses, can shift colors. We can also shift colors. And it is effected to the final result. To have more degree of freedom, you can also add a custom boke blur image to it. So it doesn't have to be that one. We can add hearts to it. Much better, yes. I did it with blender image editor. I'm not that good at it. But also I have another input image of a city view of Bangkok. And you will, this is really demonstrating the power of a real boke blur image. If I don't exaggerate that much. I have some other examples. I have a Synto file. And this is one of the files that's, well, not secret. But it's not that visible. It's the file that creates the lens flare in the temple scene. As people might know that it uses a really large node setup of a lot of different render layers. But it also uses a blur node that's quite, here it is, it's a Gaussian blur. A Gaussian blur, which uses 65% on the X axis and 84% on the I axis. It uses a lot of information in order to get it calculated. Finished, it's finished, yes, it's done. This one, I'm not sure, but on my system it took a very long time. I can try to find Blender. This one? Okay, thank you. I will go to home. Venom apps. Open cl. The flare rig. Rendering is done in no time, but compositing takes a very long time. It's it's working. It's doing something. I'm sorry. Yes, yes, yes. I think that the project is going well, I would say. I haven't seen any result yet. Yes, it's here right now. This is going to take a while. Yes. And basically this is all done only using the CPU. The framework is ready for the OpenCL. En we are currently in the testing phase to implement notice on the OpenCL version. But everything you saw today, it was on the CPU. I'm sorry? Yes. I did in the beginning of this year did a test using the firmyship of NVIDIA. En I did Bokeblur creating a full image into a single color by using extreme settings. And it took 34 seconds in order to do a 2K image. And on the normal CPU it would, I'm not sure, hours perhaps. So, yeah. No, no. En I'm not sure this is to, let's go back to the system. Ah, yeah, we can zoom out. We also have some, as the whole system is determined its output based on the pixel user wants to see. We can also do some tricks. Like what I did here was to have a node called the switch node. The switch node, if the current frame number is less than 50, it will take the input image of that part of the tree. And does not calculate the other part. If it is 50 or above, it will use the other one. So, if you have an effect that doesn't display at a certain range of frames, you can bypass that whole subsection of the tree. It is also possible to do, well, we really have to see how the final nodes will look like. I'm thinking about a checkbox or a drop down list, what you can animate, that that would be much better than having a start frame or an end frame. Let's have the cube. I'm always starting with the cube. If I composite this cube and I use a blur in it, let's start to use this one. You will see that only the cube part is calculated, but every pixel here outside in the gray area is also calculated. You can set a bounding box on the area where that effect has to be calculated. And then you will see that only that part is calculating inside this node en everything is passed through and that takes no performance at all. Well, this is the end of the presentation. Are there any questions? Oh, let's start there. I see that you've lost the number of controls, is it possible or is it too much? That are the ideas to have handles, but there wasn't the discussion about it if it should fit in the image editor or in the backdrop of the nodes editor. But it can be done. It's not that much of work, but I didn't take any attention to it yet. Yes, we can change that settings and then it will use, it's a fine tune setting. It will, larger chunks will be calculated faster than more smaller chunks, but a larger chunk uses more memory, so it's a tradeoff. And this is more for fine tuning and knowing the system. Currently I'm using the chunk size default of 1208, but it could be every value you like. So if I, well, delete. If I use an HSV, then you will see the difference. And then I need to have, yes, you will see the size of the tiles and we can change it, but you will see that it will be slower. 16 is the last one. Every tile is calculated by itself, and it could be dependent on a much other size. So you're making the problem much bigger, and that's why it's slower. If you use a larger one, it's finished in no time, if it is finished at all. You see that the outer tiles are calculating much faster than the inner tiles, because only the inner tiles, the bokeblur, applies to. The outer side doesn't have any effect. Yes, in the start of the project, color management, that's a very important part of a compositor. We implemented the open color IO library during Blender Day, I showed it. But after Blender Day, there was a decision make made that open color IO problems should be part of the image loading and saving. So it was on technical level, we still needed and we still need to get it. But another developer is working on it during image loading and saving. Stop teasing, I can tease a lot more. We are finished for, we have three phases. First phase is finished, that's the CPU implementation. Second phase, the OpenCL implementation. We are testing it, coding has been done. Third phase is that all the nodes needs to be re-implemented into the new compositor. That takes time and that part hasn't been planned yet. So afterwards, you will get it. We had 34 nodes, everybody got one and then we had to fix it and now we have finished. So let's say November 20th, I don't keep track of it. But not in one or two months, but probably four hours. I think that phase 2 is the only part that we are doing and the phase afterwards should be a community project.