 Actually, thank you for to have come to this presentation. And Arjen, Janti, and I, Dominique Coco, are 3D software developers at French Computing, a render farm based in Paris. And today we want to talk about rendering on the cloud and share some concerns we have about rendering projects to meet on the farm. So I will begin to this talk, and Arjen will finish it. So the presentation is divided in four parts. So presenting what we know about user on the farm, presenting us, we want to explain all concerns about the rendering projects to meet on the farm. And AO and O, we handle them. And last to discuss the possible solutions for rendering projects for portability. So the user that comes from a very large diversity of fields has frequencies, VFX and 3D studios, graphic design agencies, and architect industries, universities, and animation schools. They have different ways to use the farm. Most of the time, smart entities submit their job via web interface and our sites are directly from the plugins installed in Blender. Medium to big studios have all these possibilities, but generally, they prefer to run servers and install on them their own custom pipeline for rendering. This is to illustrate some examples of rendering projects on the farm. A lot of architectures, product presentation, VFX and animation, but a lot of usage coming from fields using 3D. So who are we? Who are we? Sorry. Ranch Computing is a French render farm based in Paris. We offer high-quality rendering services. It exists since 2006. And our main goal is to be able to accept any projects, 3D projects, coming from any kind of structure and pipeline. To make the solution straightforward and to help them the better we can to meet their deadline and stay within their budget. To save time and delegate rendering are the main user concerns. These two examples are comparing on a heavy complex scene the rendering duration on a simple workstation or just on the farm. So as you can see, with a local machine you have almost three days and 13 hours of rendering. And on the farm, you can reduce the time to only one hour and 20 minutes, approximately, I'm promissively sorry. Since 2006, the farm is specialized in 3D rendering with a good team of specialists and including technical artists and 3D software developers. That's why we can provide 3D support, advise or develop custom tools and solutions. Concerning Blender, on the farm, it had been supported since a while now. But at the end of 2021, we decided to make special efforts on our tools and pipeline. Our tools involve a validation process and we decided to use the metrics to observe where we were and how to improve. This figure shows the evolution of a rejected project versus finalized projects on the farm during 2022. When we organize the code and pipeline, rejection can be caused by insufficient functionalities supported, bad formatted projects, or user misunderstanding of usage on the farm. From month to month, this proportion could be very variable, but the goal was to reduce the number of invalid projects. Now I will let Arianne talk more about the developer. So as Dominique has shown in the President's slide figure, we rework our Blender tools, development pipeline, and delivering of new releases. Well, we first analyzed where we were, the code, and it was all code and don't touch since a while. So there were some work to do. And the first step has been to refactor the code, fix bugs, add functionalities, and follow the Blender release policies. And at the same time, we took the time to automate our pipeline, our development pipeline, adding gate workers for non-regression testings, and automation for delivering new releases. The second phase has been to rethink our development philosophy, because why reinventing the wheel? I think it's difficult to maintain. So we had to support our environment. It was an agreement with Pixar, and we wanted to have it on the farm. So we developed the tool around Runderman. As Runderman for Blender was open source, we integrated it. We used a packer, and we discussed with the development on this tool via Git, via pull requested on GitHub. So we saw that for Blender, the same tool was already existing, and it was a Blender Asset Tracer. So we did the same thing. We integrated, and it's just done as a beta test in our code. We integrated the module in our code, and the rest of our code is still in use for other render engines, and for adding functionalities, and so on. So the other thing that we began to think about was to open the code and to add the GPL license, because it was logical to do so since we had integrated open source code. So we did this, and anyway, this tool precisely was freely downloadable from outside. So the problem was, what will we do next? So the rendering concerns, from a render farm point of view, the project arrived at the very end of the user pipeline. So we need to retrieve the user pipeline data for rendering in a transparent and automated process, considering that render farm services are requested in the last stage of the user pipeline. So we most likely need to retrieve data and references coming from every other stage. We need to cover this set in a logical and autonomous one independent of the platform. So these external references we need to package are tied to all kinds of data manipulated in the scene. And from the Blender user point of view, this figure shows the process for submitting a project on the farm. On the left, the Blender scene opens with the farm plugin loaded and activated and tied to all external references they need on their working pipeline. So the farm plugin package this project with, in fact, three types of data, the project files, which are the main scene and all the external references that we have together on the workstation or on the pipeline of the user. And the farm, what we call farm information general, because it's not precisely to us, it's for every farm, I think, every farm will need it. That means, for instance, the render engine, CPU or GPU for the render engine, the output names, and so on. And there are also information that are farm specific, which is most likely all about prices policy and deployment policy on this pipeline. So once it's done, the user can submit the project and then there is a validation checking. And the project is deployed on the farm and the user can retrieve the images at the end of the process. So diving in the farm plugin, the structure I described earlier, is today the following for us. We integrate two sub modules that are the Blender Asset Tracer and the Undermap Packer. The Blender Asset Tracer is in alpha testing for now. And we maintain our own code to add the metadata for the farm to add a new render engine and functionality not handled by the two sub modules. And we contribute via pull request on GitHub on these open source tools. So on the farm, we are DCC and render engine agnostics. We like to support a lot of them. It generates a lot of complexity, integration, dedicated DCC management of different formats. We must develop and maintain dedicated tools. And the consultation is there is a lack of unification in the processes and a lack of standards. So what are the solutions for us? But not only. So we think it's a general problem for us now. The goal is to simplify and standardize the pipeline for rendering. So in short time, we will contribute to the two tools we integrated recently. But for the middle and long term, we suppose, but this is a community that will tell us that it's about USD that we have to go, in fact. So what do we do? So this is a complete invention. What would be, and it's for discussion, in fact, what would be the pipeline for us in the middle and long term if we integrate the USD API? So we worked already on USD for supporting you, Dini, and Solaris on the farm. So there is a lot in the USD API that we can use. And there are some lacks. What we can use already, maybe contribute to add functionality or fix boxes, are the USD render nodes that allow us to have a transparent way to address a lot of different renderers. And the USD resolver to access together all the external files that are needed plus the principal scene to package the project. But we don't think there is, right now, USD Farm Generic or a way to store this information that we need especially for a renderer farm for a sending project on the farm. And there is a need also of farm metadata that are more specific. And the way to use this as we work with Blender Asset Tracer, our render man right now, is to fix to send pull requests on the European USD GitHub repository. So that's just a proposition. And so we have a booth at the Blender Market. And we are open for discussion on this subject or any other that you want to discuss with us. So you can come. We are most happy to talk with you. This is just to show how the plugin is integrated in Blender, our plugin for this packaging. So there are the preferences. And you can check a button for activating the Blender Asset Tracer for now. And it's situated in the 3D viewport on the right of the 3D viewport. So maybe we have some time for a question if you have some. I saw a small section on add-ons. Are they packaged when the project is uploaded? Or do you have a range of popular add-ons installed on the render farm? For add-ons, we just support the add-ons that are integrated in Blender right now. And we are trying to make the list of the most popular add-ons we need to install and support on the farm, yes. And can the checker verify if I've used an add-on that's not supported? It depends anyway if the add-on is needed for the rendering. Yes, because there are a few that are really necessary to be installed on the farm for the rendering time. So I don't see. OK, so just thanks. Thank you to coming again. And see you at the booth, if you want. Thank you.