 test scene, because what we're going to be doing is demonstrating something that we've been working on since about 2013 that's to do with improving productivity, especially when you're experimenting on stuff. So we're just going to start doing a test render of a test scene we've got here. This is actually a short film, which is being made in Blender right now called Luke's Escape, and this is going to give you an idea of the kind of stuff that we're using this on. So good question. Why are we here? So, look, we love learning about Blender. We've been using it since about 2009, but we're certainly not experts in it, and one of the things that we've really has driven the development of this is doing experimentation or learning new techniques, trying stuff out and trying to get things to work. That takes a lot of time. It's quite frustrating, and so for us, getting to the point where we've got that epiphany, I don't know if anyone's here for Andrew Price's presentation. Seven Habits Effective Artists if you were here. Really believe in that, you know, practicing a lot and doing a lot of volume is a great way to learn, and so we wanted to learn Blender, and so we were doing a lot of tests and a lot of experimentation just to get techniques down, and that took a lot of time because we were doing things like this. So we found there was a problem with learning how to do stuff, which was there's a lot of computationally expensive tasks. Let's just say you want to test or debug a scene, you might do a few renders just to check that everything's working out, or if you're doing compositing, you might do a lot of work in the compositor, or if you're doing physics simulations for animation, you might be doing a lot of tests on generating the cache files to do animation, and this just really does take quite a while, and so we look, originally we didn't want to build, and we just wanted to learn Blender and get better at it, but we found that the problem couldn't really be solved. We did see that there were some solutions out there, so we thought maybe we'd try a render farm, so cloud power, maybe we look at doing network rendering, just get some machines together and use net render or something like that, because predominantly we're rendering, or maybe crowd power, I don't know. Has anyone heard of Burp and render farm.fi, Sheepit, things like that? Yep, so we looked at those kinds of things. We might just flip for a second to see if this scene is done. Okay, so brief context change, oh, it's almost done? Almost. Almost, we'll come back to it in a second. So if you don't want to just bring the presentation back up again, cool. So look, for us, we noticed that these solutions were out there, but they weren't quite perfect. There was always a little something that meant it wasn't really suitable for what we're doing, so in one case, cloud power is great, but it's expensive for dedicated resources, because you've got to obviously pay for it. Network rendering was also really cool, but we realized that we've only got a few machines between us, and it sort of helped, but not really enough. And lastly, the crowd sourcing platforms were kind of cool, but they're only really for enthusiasts, which meant you load up your project, and you wait for it to find some machines that someone's donated in, and then render might happen eventually. But there was no real sure way of determining when that might happen. So we kind of abandoned using that. And okay, so I'm just taking note. What we've done here is we've done a test render, and it's taken about two minutes something, two minutes 20. And now what we're gonna do is we're gonna enable our add-on. And we're just gonna re-render this, cuz what we're actually gonna do is we're gonna team these two computers here. We've got a Mac laptop, sorry, Mac laptop and a Windows laptop. And just redo it, cuz that's kind of the add-on we've built does. It basically teams machines together. Is that going? So that's connected. Sorry you can't see this machine, but we can only really plug one in at once, and it'd be clunky swapping them over. So just trust me, it's working so far. Things crossed. Okay, all right, that looks like it's ready to go. So we're just gonna re-render the scene now using the crowd render engine, and see how much faster it is. Cuz remember, we just got two machines here. So we're just sort of demonstrating what the bare minimum performance improvement you can get. Cuz we use this for debugging stuff cuz it's faster, it's at least twice as fast as doing it just with one machine. And we happen to have two with us, so we thought we'd demonstrate that. So if we just go back to the presentation for a tick, all of these solutions had their kind of little things that were wrong with them. But the really big problem that we found was, go to the next slide. They all focus on kind of the final result. So render farms, the model is send us your file, we'll render it. Same thing with net render, it just loads up the file at the start, and then that's it, and then we'll render it. And if you make any changes, if you wanna do experimentation, you've gotta go through this whole process of uploading the file and managing that all over again. So for us doing short little tests, we had this whole of a convoluted route to go through to actually get the machine, sorry, the render farm or the net render stuff ready to go. So what we did is we built a system which does something a little bit different. We might just check if that render's done. Yep, took one minute instead of two minutes, 25. It's a little bit better than half, and Jeremy's gonna show you the reason why. So we're actually gonna look at the different parts of the image that each of those two machines just did. Just to show you a bit more about how this works. And all of the exciting things that you can do with my eyes. Okay, it's a little bit dark, but that's one half, well it's not really half, it's probably about two thirds, and that's the other. So sorry you can't really see that very well, it's quite a dark scene. But if you can just about make out sort of, this was the Mac laptop. And the reason the scene is a little bit bigger on this side and that side is cuz this is a little bit faster. So we wanted to make sure that we were optimizing the hardware that we had. So we have a way of basically apportioning the size of the tiles based on how fast relatively the computers are. So that you roughly finish it about the same time, which means you're maximizing your efficiency. Cuz it kind of be inefficient if one machine finished ahead of the other. But that's not the real novel thing about this. I mean, you've probably all seen bucket rendering and tile rendering. And there's a lot of stuff about. And that doesn't really solve the problem that we wanted to solve, which was I want to iterate really, really quickly. Or as quickly as I can, because the finish line is over here. And I need to test a lot to get there. So thinking about experimentation, learning two new techniques, or doing that kind of stuff. What we decide to do is build a system where, instead of having to upload your file every time you make a change, you could just do something like, are we ready to go? I'll just check, cuz my machine just went to sleep. Okay, it's just logging back in. Sorry, brief pause. That's for dramatic effect. Okay, we're ready to go. So we thought we'd do something like this. So similar situation, we're just gonna do another test render. It's the same situation, both machines actually built that image. It's a simple one because we had to do something that was quite quick. We only got about 20 minutes. So we just thought we'd do the basic default cube scene because that renders quite fast and we can show you what we can do with it. So Jeremy's just showing you again, like my machine did that half. Lucky Jeremy's machine hardly had to do any work at all. That's a work in progress to actually get that splitting to be more intelligent. At the moment, it's just pretty much split the screen based on the relative power, not the complexity of the scene, which is future feature we're gonna add. But the really interesting thing about what we're doing here, I think, is the fact that Jeremy can now go ahead and just change the scene. And just do kind of things that you might do if you're testing composition. You might want to move things around. And you don't have to re-upload all of your data to the cloud or to computers that your friends have or on your network. You can actually do all of that in real time and you don't have to bother with that whole tedious phase of now I have to send all of my files again. You might have noticed there that James has actually did all of the important parts of the scene that time. But we can change that. It was interesting, the look development, did anyone go to that one? Look development, they were talking about how you can do kind of stuff like this in the compositor. So a good use case for a system like CrowdRender is if the client asks you to change the shot or change a model, you can't get around that using layers and passes, you have to actually re-render the physical model. And we've been in that situation and this helps immensely. So, yeah, Jeremy's just playing around. Does anyone have a favorite color? Because Jeremy was going to ask if anyone wanted it. He just likes blue, sorry, we missed that opportunity. Okay, so basically what we're demonstrating here is real time updates. And you probably noticed that Jeremy hasn't had to do anything particularly difficult to get this to work. It's just connect the machines together and then just use Blender as normal. So there's no management of the machines that you have to do. It's just basically use Blender and enjoy the fact that it's a lot faster at doing renders. Cool, that was an interesting one. Okay, so we'll go back to the presentation now and just talk about what we want to do with it. Because this is where we're at. We can use two machines or more over a local network. Sorry, yes, there's a question? Yes, but only once. Unless they update, if you change the textures, it has to transfer them again. Yeah, but it's an intelligent transfer. It only transfers the BEM minimum of data to do it. We can have a chat later if you're interested. In fact, that's going to be part of the session is actually a bit of a Q&A at the end and hopefully if people are interested in learning more, we'd really like to reach out. But let's just get to the, because that's only in two slides time. So we can get there pretty quick. Okay, so what do we want to do with this? We actually want to be able to solve these iterative problems. But using computing power from anywhere. I mean, the situation that me and Jeremy were in is his house, I'm at mine, so we don't have a common subnet. We don't have one different network devices. So one of the things that we're doing right now is working on connecting our machines over the internet so we can team things together. And that sort of plays into what we're using this for. So we're actually using this for projects like Luke's Escape, which you saw, this is a more updated version of the scene that we were testing with. This situation is a group of artists from all over the world, if you haven't heard of it, basically elaborated online to build this open movie. And they got into a situation where they can't actually finish it because they don't have money for a render farm. And so what we're helping them out with is, well, we can use this to connect the machines they do have to actually finish the movie a bit faster. Tricky is, when we asked them how many computers they had, they said about 20, and I thought, well, that's great, you know, it's going to give you a lot more speed than just the one or two you have in the office. Where are they? And they said, Chile, Pakistan, Spain, just kept going. And we're like, okay, so what you need to do is actually have a system where you can combine them online over the internet and that's a big challenge. And so that's kind of the vision of where we're heading is people can actually group machines no matter where they are and what they're doing. And that includes cloud as well. So we treat cloud as just another machine you can connect to. So the ultimate goal for us is a system where you can basically source computing power as you need it from anywhere in the world. So you're not tied down to either having to buy more machines or go and basically use render farms. Okay, so we've talked about one project which is Luke's Escape, which demonstrates kind of the online version. We're also working with a university in Australia to help them with their visualization issues because they create quite enormous data sets. They're a microscopy lab, so they generate point clouds, which are basically atoms, and then they need to visualize that and show people their research. And one scene that they showed me, which was in Blender, because they use Blender, had about 200,000 objects in it. And that wasn't even the meshes, that was just the objects, because each of these is basically an atom inside a very dense material. And we're helping them, because they have computers in their office, but there's no meaningful way that they can connect them together to actually do anything useful. And so what we wanted to do is help them connect those machines together so they can actually do their visualizations and actually get the work done. Okay, so how you can help if you're interested in helping at all. Let us know what you think. We've been working on this pretty much in isolation since about 2013, because we were interested in it. And then we decided, wow, we should probably tell others what we're doing and see if other people want it. Partly because we love building stuff like this, and we'd like to quit our day jobs and do it full time. And I guess we're just curious as to what do people need this for? Do people find this useful, interesting? Could it help? Do you have situations you can think of where you think, wow, if I could get a system like that, that would really help. And there's a couple of ways you can get in touch with us. Come talk to us, we're here. We'll be around for the rest of the day. I fly home tomorrow though, so it's a long way to. We've also got a website and we put a survey up there just to, I suppose, gather responses from people that will help us shape what we're doing. And it's kind of the information we need to decide, do we keep doing this as a kind of a part time startup slash hobby thing? Or do we actually go, right, enough people want it, so let's do it as a full time entrepreneurial kind of thing. So if you can fill out that survey, it takes about five to ten minutes. That would really help us sort of decide, okay, what should we do about it? And it just means that if we can go full time in it, it would be a reality much faster. I mean, you've seen we've got a prototype that works and there's a little bit more work on it before it's something that we can release and it'll help people to download. And that's pretty much it. So I think we've got, how much time do we have? I haven't been paying attention, sorry, I should have done that. Good presenters always know when their thing finishes. So look, I know there was a question up the back. Is there any other questions that people would like to ask, yeah? Basically because you have to set one up. I don't want to sort of put the burden on artists of having to know how to set up a VPN. It's supposed to be as easy as possible. Like if you saw, I don't sure, not sure if you saw what Jeremy was doing, but he just put in one IP address and clicked go. We're actually going to remove that in the production version where it's just basically type in your account and go connect and that's it. And then you can manage basically how much computing power you need. I'm a programmer and I find setting up network stuff challenging as it is. For someone who's not really familiar with networks and how they operate to set up a VPN might be a bit onerous. And it would kind of make it the privileged few who knew how to do it would be able to get there, but others might not. So yeah, you can do it on a VPN and if you want to, there's nothing stopping you. But I'd prefer it to be open to as many people as possible, which means we're putting in the hard effort to do that just so that people who are not gifted with network stuff can do it. Sorry, can I come down? Yeah, hi, I'm Julius, I used to run RenderFirm.fi actually for, yeah, yeah, yeah. So I'm just curious, one of the biggest issues with that site was the concept was always security, if you're doing a movie project, if you're doing a serious movie project that you don't want to release prior to the movie actually going to film, what's your kind of take on this? How do you come up with any solution regarding that? I mean, if you're having to transfer the files to the people that are actually doing the rendering, then you're basically compromising the images and so forth, so. So, similar situation with Luke's Escape, in that case, first kind of solution is we're only inviting trusting friends that know work. That obviously doesn't work for people who are basically just sharing their computers with goodness knows who. There are ways of doing it, but they're quite complicated because they involve basically splitting up the data so that no one person has the whole piece of the puzzle, but that's going to be the, I think, the far-flung production version. So we're focusing more on what can we do right now, which is a bit limiting, but we'd rather sort of get going now with stuff that we can do and help people out who've got short films before we sort of develop those techniques. They do exist though, there's actually no people who've got the software that can do that. So it's another issue with security, so we had to always turn off Python in order to provide a secure network for what people do. So that's another issue, do you have any ideas on that or do you actually turn off Python when you're doing the renderings? Yeah, look, it's a good question. So I guess for the rest of you, you might not be sort of developers. I think what you're talking about is if you're allowing people to access Blender on other machines, you have the opportunity to basically execute arbitrary code on their machines, which means you could do other stuff other than render, you could perhaps make that Blender session send stuff through the internet, which you wouldn't do if you're a nice person. So absolutely turning off the ability to access the internet full stop is what we more want to look at. Rather than turning off access to Python, which would actually allow you to do cool stuff, we'd rather just say, well, you're not going to access a network from another machine. You can access the machine, but not its network interfaces. Because we don't want to stop people from using Python because one of the things that we're passionate about is there are other problems that this thing could solve, not just rendering or compositing. Like I work a lot with physicists and engineers and they have problems which this technique could also solve. And we're quite keen in helping them do that as well. It might not be rendering, maybe it might be doing a finite element analysis where you determine stresses and strains and materials and buildings and structures. And if we take Python away from them, then it's not clear how they would actually use it. The big risk is... What's your plan? What's my plan? True. Look, the thing about security is that they're always determined for you who will probably circumvent every barrier you put up in front of them. I guess we've been asked the question about security an awful lot and we have been thinking about it. The issue is, though, drop... Sorry, is that me? Okay. Right, well, I might just go back up here in case it stops working. Not squeeze the microphone so hard. So, yep, issues around security. Dropbox. Everyone uses that. You're exposed to the internet through that because you're allowing people to use your file system. BitTorrent, same thing. So, this is always going to come up and people will always ask those thorny questions. And I'm glad you do, but I don't want people to sort of paint us with this brush that were a special case. We're not. We're doing very similar things. In fact, we're probably about the same risk level as BitTorrent. And a lot of people use that and they accept that risk. Jobs as coders for us is to make sure the risk is as low as possible. But, yeah. It is a tricky issue, and yet you're right to bring it up. OK, Kajetan, thank you. Hi. I don't remember if I already told you when we met earlier, but Shippit users like me recently received a mail saying there was a new feature for encryption so that blend files are now encrypted so that you can't, when you render for others. And I also think Burp does use that. You can't download the blend file unless the user puts a Creative Commons license on it. So I don't know if maybe you can get in touch with developers of those render farms, but maybe. So encryption, it's certainly one way to do it. I favor the other method of splitting up the data, which we're currently researching and looking into. Purely because if you do that, no one person has access to the whole data set, so they can't really tell what it is. Whereas with encryption, you've got all the data there. You've got an exact copy of it. So this, again, is something that's probably not going to be released by us anytime soon, but it's certainly the favored method that we would choose. We can do encryption. That could be probably a stepping stone for us, in terms of at least you cannot look at the files. But from a risk point of view, they've got it all. You say, OK, they have to be able to break encryption, so that's pretty unlikely. But I'm of the opinion that if you can make it really, really, really hard for someone, you should do it if not impossible. And if you imagine splitting up, I mean, this is probably not exactly how it would work technically, but it's probably an example that everyone could understand. If you have a scene with a cube, a camera, and a light in it, it's something where you would split it up so that no one person has the whole scene, but they might have a part of it. And so they really can't tell what it is. If you imagine the next Marvel movie, and someone's just got a bolt from Iron Man's foot, they'd be just like, well, I've been able to decrypt this thing, and it's just a bolt, so I don't really know what it is. And it's not really a scoop, so I can't really do anything of that, whereas if they break an entire file and they get the whole scene, they've got all the assets then. So yeah, I prefer the sort of the distributed method. But yeah, encryption's an easy first step, because it's very easy to do. There's lots of tools there. And we'd probably look at that as the first stage, but then look to moving to more advanced splitting of databases up at the later date. OK, hang on. I'll come back. Is that OK? We've just got three minutes. Am I right from what I've seen of it so far? This is both friends sharing computing power, rather than like a, hey, world, let's all share power together kind of thing. Well, I guess it's all like renders. Yeah, right, but that'd be like way down the pipeline. Yeah, because there's always challenges. This like question is, say I've got a 30 gigabyte video texture, is it going to distribute 30 gigabytes to every computer on the network, or will it only share the one frame that's needed for the particular frame that I'm rendering? If I've got to say I'm working on a project which has a video texture, it's an animated texture that's, say, 30 gigabytes long. I'm only rendering one frame of my final output thing. Do I need to this copy the 30 gigabyte entire video everywhere? That's where we're going. We've got to develop it today. To be honest, we're not really artists, let's say. We're enthusiasts. And in mind that we're not the people with the arbiter of fact as to what's important. I mean, that's what we've come here to do that. Murray, I will tell them what I mean. We'll start to come back and say, if you like it, tell us what you like about it, and tell us what you think. OK, thanks. Can I use the Blender versions that render for me in a headless mode? So they are running in a background, for example. So without a GUI, just in headless mode. So this means I can render a machine on Amazon, et2. And can I hot plug machine? So when the rendering is in process, then I will just go to Amazon, hire 100 cores, and add them to my network. Is it? Yeah. You're really near as much as my country. Sorry. Sorry, Nordy. Apologies for that. OK, so yeah, there was just a question there about hot plugging. And the answer for that is, look, right now, that's not in the build that you just saw. But in the future, really, the way that we want to work this is basically say, yeah, if you want that, just let us know. And that's where we'll work on it. OK. I think we're out. Oh, you want to know? OK, good. Well, great. We have that survey. If you want to put the survey link just quickly, just before we finish, there's a website. You can let us know. There's a place where you can either give us suggestions or register and tell us what you think and tell us where you think we should focus. Thanks. That's it. Thank you.