 Is this working? Yes. Okay, we'll go and get started. So just real quick, so John Denning and myself, I'm Jonathan Williamson, are going to just talk a little bit about building tools of sorts. We're not going to get too technical or talk about specific workflows or anything like that, more as kind of a broad overview of some things that we have discovered and just kind of general guidelines of sorts for not only building quality tools, but also basically making sure that your tools still work. So when I talk about tools, really what I'm talking about are third-party add-ons, although they could be integrated core tools that you have built as, you know, to release either to the community, to sell, you know, whatever it is, basically building tools for other people to use. So if this works, maybe, wait, backwards, okay, I can't use my presenter. Let's try that again. Okay, so some very quick background. So we're going to base this on the experience that we've had through building what are called contours and polystrips, which are two add-ons that we've built over the last year and a half, two years, I think, that are actually, they're retopology add-ons for Blender. So if you don't know what retopology is, don't worry. Basically recreating a mesh surface for clean, optimal mesh flow. And with these two tools, they're pretty advanced of sorts. They do a lot of heavy lifting. They do a lot of things that Blender doesn't necessarily allow you to do by default, such as like always ensuring that your mesh is snapped to the surface, kind of like shrink wrap, but it's just always working. It does a lot of things like mesh preview visualization, which Blender does not do by default. So there's a lot of things that we've kind of, we've built a lot of custom stuff to basically fit what we wanted to do and to fit how we wanted the tools to work. So with everything that we talk about, keep in mind it's just very, very general. And if you want specific examples or want to look at something, feel free to catch us after the talk anytime throughout the next few days. We'll be happy to show you whatever. And so everything that we talk about is not related to modeling tools. These are just the tools we'll use as the examples. So first and foremost, if you want to build a really, yeah. Oh, hey, my title's gone. If you want to build something that's compelling and easy to use, build it for yourself. Build something that you want to use that fits your workflow. Because at the end of the day, if you don't know how to do what you're going to do, you can't build a tool for it. Not very well, not as the designer, the developer, and whatever. So as an example, I'm a modeler. I am not an animator or a VFX artist. I can't build a good animation tool or design a good animation tool because I don't know what the workflow is. That's not to say that John here, who is not a modeler, by the way, John is one of the primary developers along with Patrick Moore, who unfortunately was not able to make it. One of the developers of contours and poly strips. John can absolutely code the tool, but then I'm designing the tool. So if you are creating a tool that you want to use, scratch your own itch. As a few examples of people that are doing awesome stuff, scratching their own itches, you, Bartek Skaropa, Andreas, Greg Zaw, Cogimilo Softworks, all of these things are tools that have been built for people's particular workflows. Since Bartek is right in front of me, I'm going to pick on him. His and Greg Zaw's tool, Node Wrangler, is badass. It's awesome. It's also really complicated and really comprehensive because it fits their workflows. It does a lot of things that you wouldn't necessarily think of. And for me, not being a shading artist, not being a compositor, I don't use a lot of nodes. But then I start looking at Node Wrangler and I realize, wow, they're doing some really cool stuff that I never would have thought of, but it works really well. And actually, I'm going to show a screenshot of one of those in a second, which is the lazy connect tool. It's awesome. And so the other thing that kind of relates to that is polish it. So when we think of tool design and building tools, there's a lot of different stages to it. First and foremost is making something that works. If it doesn't work, it's not worth using and it doesn't work. So first, make it work. Get something functional. Build a prototype. Get something that actually accomplishes the task that you're trying to do. But if you actually want people to use the tool, such as if you were releasing it, and as an example, Todd talked about it a little bit, but the blender market. If you want to release a tool on the blender market or if you want to release a tool that might get included in Blender someday, polish it. Make it, you know, not only make it look good, make it really intuitive and friendly to use. And some of the ways that I think that people can do that is realize that people do different things well. A really good artist knows how to use their tools and they use their tools in ways that maybe you wouldn't think of. Particularly they use tools in ways that maybe a developer wouldn't think of from a technical standpoint. But an artist does not necessarily know how to actually build something that is modular, that works well, that is efficient. Play to your strengths. In the case of contours and polystrips, what we did is we brought in, well, a total of four people. So I designed the tools because these were tools that I wanted. They were tools that I wanted to use in my modeling workflow. I had no idea how to build it. So I talked to Patrick and John here who are both developers to actually build the tools. But even beyond that, I'm a technical artist. I'm not really good at making things look good. So then we decided to bring in one more person who was, I'm gonna slaughter your name, I'm sorry if you're watching, but Pavel Lychowsky. He's doing a lot of Blender UI designs and such, does some really cool modeling stuff. And so we brought him in to do some kind of UI UX design on it as far as what should the tool actually look like. And just as a very quick example, this is the difference between left and right. So the left one was the original prototype. It worked, it didn't look really good. It actually looks better in that screenshot than it actually does when you're using it because the handles are very different. And then the one on the right is the actual finished one. Are there things that we could do differently? Absolutely, but the point is, which one looks more easy to use and more friendly to actually work with? I mean, you might say the left, but I might disagree with you, but. So as an example that I mentioned earlier, another one as far as polishing goes is the Lazy Connect from Node Wrangler with Bartek and Greg Zall. This is something that is really, really cool. And my screenshot does not give it justice for one because the display is dark, but also because it's such a simple node setup. But basically it's a tool that allows you to just control, click and drag from one node to any other node and automatically connect it to the appropriate input as best it can. And what's really cool about it is it's an extra level of polish not only in the functionality, but also in the drawing code in actually highlighting the node that you're working on to then extending it to the next node and where it becomes really useful if you wanna try it out. By the way, Node Wrangler is included in Blender by default now. It's if you have a really big expansive node, if you've ever tried to grab that little, little tiny dot that's actually the node output and drag it all the way across the screen, perhaps over the screen and connect it. You do a lot of zooming in, selecting, zooming out, trying to find it. So Lazy Connect is really cool because it's just done. So that's kind of an example of polishing a tool beyond what you might normally do. I mean, to kind of step back from it for Node Wrangler is the default functionality is that if you select a node and select another node, you can hit F to connect it. How often does it actually work to do what you want it to do? A bartack shaking his head. So polishing it, but beyond that, maintaining it. How many people, and please do go ahead and raise your hands, have used an add-on that didn't work in the next version of Blender? Yeah. So, this is kind of a blessing and a curse within Blender is that our development is really, really freaking fast. I mean, how many other softwares release of this complexity within 3D animation such, release a new version basically every two months? I don't know of any personally, maybe like little libraries or add-ons and whatnot, but in the entire software, updates really, really fast and does a lot. So we have to continue to maintain it because change and API changes and things like that are expected. I mean, John here can tell you that anytime you're working on your software, the first implementation is not, the perfect one, actually, what did you say the other day last night about? Oh, just that, my rule of thumb is whenever you're developing, I have my own. So in general, when I'm developing something, I typically develop it three times. The first time is just try to figure out what you're working on, figure out all the ins and outs, figure out where the holes are, just make something that works, test it out, then completely scrap it, start all over again, write it once more, your code will be a lot more robust, it'll be a lot more sustainable. You realize, oh, I copied this function three times throughout when I could just generalize it, make it a lot easier to maintain, make it future robust, and the third time is even more polished, but typically two, at least two times re-write your code. So I mean, I think that really applies very well to Blender development as well, because we see these things like API changes, and the number of times a kind of a poke at the community of sorts is people really like to blame developers, like why do you keep changing it? Quit breaking the API. The API is no different than any other feature. It's gonna get polished, it's gonna be improved, it's okay to have changes. That does put a little extra burden on people that are making add-ons and such to actually maintain it. Who would have thought that you would have to maintain something that you build, but it happens all the time, unfortunately, that we see a lot of add-ons get released, and this is not really a poke at people building add-ons, but if you are building something that you actually want people to use or you want it to be shared and contributed in Blender or perhaps included with Blender even, it needs to be maintained. And that means not only knowing when things change, but checking it. If you haven't tried your own tool in six months, chances are it doesn't work. And this is even more true. If you are selling that tool or people are paying you for your time or whatever it is, I hope it still works. One other thing, anytime there's a new version of the program that your tool is running in, make sure you test it out. If in doubt it doesn't work, yes. So, I mean, oh, I just talked about that. So along with maintaining it, something else to really consider is how are you constantly improving it? You may not need to actually improve it, but little incremental changes can make a really big difference. So if you're able to not only maintain it, make sure that it keeps working, but slowly hack away to make small improvements over time can make a really big difference. Particularly if you're making a tool designed for specific workflow. So in our case, we're building retopology tools. The retopology workflow has changed. It changes a lot. I mean, six years ago or 10 years ago when I was learning to model, we basically didn't have digital sculpting. Retopology basically didn't exist. We didn't need it. As sculpting was introduced, the workflow for creating models completely changed. I mean, it's not, yes, you can still do it the old way, but it's completely different as far as the way that most people approach the subject. So if you're building something, or design something, because this is, by the way, this is not just to develop them. This is to anyone that has some kind of involvement in creating custom tools for accomplishing a task. Has the workflow that you are trying to improve, has it changed? That's not only has it changed for you as an artist, but what about for the people that are actually using your tool for the people that either are using it within Blender or people that are buying it, people that are, whatever it is, is it still relevant? Because even though we like to say that the things that we learned 10 years ago were still relevant, they aren't necessarily, not within workflows. They might be, but oftentimes not. So, which moves on to kind of sustainability. How can you, as a developer, as an artist, as a designer, whatever it is you're doing, how can you allow yourself to continue doing it? There's no simple answer, but there's a lot of different answers. You could sell a tool, you could run donations for the tool, you could give the tool away, you could have an insane amount of free time that we're all really jealous of to just work on your pet projects. Whatever it is, find a way to constantly be working on it, whether that's an hour a day, an hour a week, a couple hours a month, doesn't really matter and that's gonna change drastically with the project. For us, for our project, we need minimum a few hours a month or more, I mean, we could absolutely do it full time, basically at this point. There's enough things that we would like to do and or need to do, but bare minimum a few hours a month to make sure that it's still working with current versions of Blender to hack away at some of the speech requests. Time is money. If you've got the free time, fantastic. Most of us have bills to pay, so if you can find a way to actually sustain the development cost, fantastic, which I'm not gonna get into it, but that's basically the whole point of the Blender market. If anyone's not aware, I run the Blender market, so if you don't like it, you can buy me. So, whether you're selling it, whether you're getting donations, whether you're working in your free time, having a way to make it sustainable is really important. Okay, now I don't know how much time do we have, my timer is not working, or I said, oh, no, I set it to 29 hours. We're gonna be here a really long time. I think we've got like 15 minutes left, 10 minutes. I'm gonna pass it over to John for a little bit to talk on some of the technical challenges. So this is gonna be a little bit more specific to Blender as far rather than being more of an overview, but just as an introduction, within polystrips and contours, we really kind of approach them as an open slate. So every software, whether it's Blender, 3dsrc.max, Maya, Photoshop, you name it, has ways that it likes to work, or that the developers that made it and the designers designed it to work. So we decided with polystrips and contours, with the way that we built them, we kind of approached it as an open slate, so we do a lot of things that are most definitely not the Blender way, but it's been great because it's a chance to explore different routes, different workflows and different techniques. With that, we've had some technical challenges that are challenging. But just as an overview, John, if you wanna talk about some of the, the kind of the specifics of sorts. Hi. Okay. So with contours and with polystrips, like Jonathan had said, and Tom had alluded to, about different people have different workflows, and this is also true with development. One of the few interesting things that we ran into was how do we allow customization for the user and the tool to know what the user is expecting? Prime example, left and right click. Maybe I shouldn't have said that. With selection, so how do you give that power to the user, but in a way that is not gonna break your code or be hard to manage? And I actually was not heavily involved with the keymaps. That was mostly Patrick Moore. So I was hoping that he could be here to talk a little bit about this, but basically just how do you get the information out of Blender about what keymappings is used is really difficult, borderline impossible at the moment. Patrick's not had a very fun time. And the other thing was undue stack. So our two tools, so our two tools, they are not actually operators. So like if you select a face and you extruded it out, this is an operation that happens and it gets written into the undue stack. So if you extrude a whole bunch at different times and realize, oh no, I made a mistake, you can undo a bunch. Well, our tool is actually runs separately. It's a modal operator. It's the only thing that's running. Yes, you can kind of control the viewport, but we're just passing that information down to the Blender to update. But because we run our operator and that's the only thing that's running, we had to handle our own undue stack, which unfortunately meant that we were doing deep copies on big objects and if you're a developer, this is a bad thing. So I guess the point is we had to write a lot of our own stuff. Another thing would be surface snapping widgets. So all of the widget tree, when you select an item, to be able to move it about, we had to write all of this because we basically took over the operating system. We're doing a lot of things we shouldn't do and we got too excited to do it the way that we wanted to, which means we had to start from scratch on a lot of things. But the nice thing about this is we've, Jonathan in particular has been talking with some of the Blender devs and these are common problems that, well, as the tools become more sophisticated, some of the other tools that Jonathan mentioned earlier, as they get more sophisticated, they need these widget trees, they need these capabilities. So we're trying to provide some feedback to the Blender developers, to the community as a whole, to try to generalize some of this stuff. This is a computer scientist speaking here. Generalize as much as you can so that more people can take advantage of it. But it is a change in workflow. The way that we generate the mesh, we're not actually creating the mesh. We're creating a visualization of some metadata and then finally they go in to commit it. But this is slightly different from Blender, but that was the approach that we had to take to be able to tackle some of the challenges that Jonathan's having. But the other thing that I'd like to just kind of point out is there's a lot of functionality that is available. So maybe some of the key mapping information is, apparently it is available. And a lot of the other air quote hacks that we did to make certain things work, like which parts of the visualization of the mesh is actually visible or not. This functionality may well be available in Blender through the Python API, but we just were not aware of it. The documentation is getting better, but it's still kind of hard to find this information out the, I was trying to think, there was something else I was gonna say, I can't think of anything. Oh, just as far as like digging into, I mean, not pointing fingers at anybody, but if anybody thinks that the user documentation is hard for Blender, try the developer documentation. We have some work to do, particularly, and I think this is one of the things that John is alluding to a lot, is since we're kind of pushing the banners as far as how we design the tool, how we design the workflow, and kind of getting out of Blender's way, we have a lot of chances to experiment with things, but that also means that things aren't documented as far as how many add-ons you know that built their own widget system for modifying a pre-visualized mesh, well, most of them don't have pre-visualized meshes. So these were all things that we had to kind of explore and dig around with, but that give a perfect opportunity to see where we need to improve documentation, where we need to improve the core API, or how we might do it. There's a lot of things that we've probably done in these tools that Tom and Campbell would probably just look at like, why are you doing that? Undoubtedly, there is. But it's a really good way to see where our weak points are in Blender. Particularly, there's probably more developers in Blender now, whether it's in Python and C, doing small add-ons, doing big projects, there's probably more now than there's ever been, and there's definitely a lot of interest. I mean, on my site BlenderCookie, we're starting to do more Python scripting tutorials, and we're really seeing a lot more people interested in it, because in the past, I mean, this is not because in the past, but in the past it's been really difficult to get into Blender as a scripter, as a developer, whatever you want to do, that was tough. I mean, learning Blender is hard, learning the development of Blender is even harder. Particularly, there's just not a lot of content out there. It's also a very small user base. If you have two million Blender users approximately, how many people do you have that are actually interested in the development of Blender, whether that's on Python or on C site? It's a lot smaller. There's a lot less need for the documentation and for the learning material, but there is a need for it. So through building these through the technical challenges, like John was talking about with the key maps, the key maps are an interesting thing, because if anyone's ever used a modal operator, say, just for example, the knife tool in Blender, which most people have probably used, or the circle select, or the box select, these are all modals. They're tools that are persistent to a degree, and they kind of have their own mini mode that you can then use to achieve the tool or achieve the task, but they kind of block everything else of sorts. The way that Blender's key map works doesn't really play very nice with modals. So if you have a tool that selects something, like for example, if you use the circle select, you might by default select with right mouse button, or maybe you've chosen left mouse button. That changing that in your preferences doesn't affect the circle select tool or the box select tool, because they don't use the same system. It's hard coded as opposed to coded through the key maps. So that was something that we ran into a lot with contours and polyserves, because they're modal and they're very flexible and user, I mean, well, I think they're user-friendly. Those are some things that are tough. So if you're building your own tools and you want to build something that does a lot more complexity, so like with ours, I can just jump back a couple of slides here. Not that one. There we go. There, I can't get it. So there. So all of this, the mesh visualization that you see here on the right, that's all within the modal. So if you're normally modeling and say you extrude, that's one step. Extrude, that's one step. With this as a modal, the whole process is one step, as far as Blender's concerned. So working with something like that is very, very different than a step-by-step workflow. They both have their pros and cons, but I guess that's what, I guess they kind of wrap that up. Modals present certain challenges, particularly from the development side as far as our current capabilities, because they're not honestly used very often. As far as the modeling tools go, we've got knife tool, bisect, and I think that's about it as far as edge-slide. Yeah, loop cut kind of for a moment. So it can be a little bit interesting. I think that's pretty much it as far as we've got. We've got just a couple minutes left. If anybody has any questions, if you want to see a very quick demo, hit us. Demo? We're topo demo, but just to kind of show you, so that you'll have a little bit more context, if anybody's sitting here really confused, what are these guys talking about? Well, now you'll maybe understand. So there's two tools that we built that are used for retopology. Retopology just a reminder is the recreation of an existing surface with new mesh topology. So if I have this high-resolution sculpt, oh, you can't say anything. So we have a high-resolution dynamic topology sculpt. You can't animate that. You can try, you can have some fun. It's not gonna be very fun. So we would retopologize it. So normally the way that you would do this, I'm not gonna show the whole thing just because it's out of time. Normally you would create, at least within Blender's existing tools, you would create the vertices either one by one, extruding edges, using shrink wrap. It's, they're decent, but they've got a ways to go. But what we wanted to do is build two tools, and there's a couple more coming that allow you to just very quickly generate the whole thing. And of course, now it breaks. It knows I'm demoing. Okay, we'll try this again using a, there we go. There we go. Okay, so if I wanted to say, retopo the neck really quick, using this we would just drag a stroke, drag a stroke, and our mesh is automatically generated. As soon as I'm done, if, it's a terrible angle, so I can go in. So this is what I was referring to when it's a modal. No mesh has actually been created yet. It's all just pre-visualized. And this is one of the things that kind of is not the Blender way of sorts. And I don't mean that in a bad way or a good way. It's just that it's very different than Blender normally works. So since it's pre-visualized, it's nice because you know exactly what you're gonna get. But it's also bad because we don't actually have any mesh yet. But if I hit enter, then my mesh is actually created. And so we can see it here. I'll just, so then we have the actual mesh that perfectly mimics what we created earlier. So that tool, Contours, is designed for doing things like limbs. If you wanna quickly slice a limb up, using cylindrical shapes, very, very quick. Then Polystrips is the second one, and it allows you to do things like this. So it's basically a spline-based quadstrip generation tool. And it works, it's fun. But this is, again, it's all within a modal. So no mesh has been generated. It's purely a preview. I can select things. I've got a curve so you can go in and you can really fine-tune your topology any way that you want. But this is where, if you remember the initial screenshots, this is not what it always looked like. It used to be really, really rough and it worked, but that was our prototype. So then Powell was able to come in and redesign the visuals of it to make it a lot more friendly to use, a lot simpler. And he's also recently done the same thing with contours. So if you had used contours before and you thought it looked differently, it's because it does, as of this morning. It's now more consistent and clean, whereas it used to be a lot of contrasting colors and things like that. So that's Contours and Polystrips very, very quickly. If you wanna see more, catch me afterwards. I'll be happy to show you an actual demo. But yeah, so if you're building tools, build it, obviously, find a way to support it, maintain it, but fix bugs, make them actually work. There's some very sad examples of really, really wonderful tools that don't work anymore because either the developers disappear, the user disappeared. The other thing I was gonna add was, in addition to this, maybe I was gonna say this, but talk to the community, share your experience that if you're running into problems, if you're running into API problems or you feel like you're inventing the wheel, maybe there's other people that are doing the same thing, so make this community effort. We can get some really great tools out there. There's some really, I mean, we've had a couple of cases where things that we've run into have either since been fixed in Blender or have contributed to getting fixed. And that's the really nice thing about Blender being open source and the tools being open source is it really can be absolutely a community effort and you can really kind of lean on what people have already done and you don't have to reinvent the wheel every time. So I think we're out of time. Thank you, everyone. Thank you. Where is, what was the next talk again? Hello. We're gonna go back to them all. Yes. Can I have a drop? If there is a thing over there. Maclaptop is. And give me for me.