 Okay, I want to get started because there's a lot of slides to go through. I'm Howard, and here with Inric, we're going to talk about a new bevel node that I've been working on. So this is a completely new from scratch bevel. I didn't just wrap the old bevel code. There's a reason why, several reasons why it's completely no code, and a lot of this talk is going to be about that. But as a teaser, here's the main thing that got me going on bevel v2, as we're calling it. Any of you who've used bevel before, I'm certain, have run into this problem that if you bevel something like a character with serifs on it, pretty soon you get a mess on the right. In detail, what happens is here, because you've got a lot of really close points together on the edges of the serif, they soon overlap. Once they've overlapped, you get overlapping triangles, sometimes reverse triangles. It's a big mess that really is unusable in a render. You kind of have to fix it by hand. Normally there's this clamp overlap thing that stops you from going too far, but sometimes I really want to go further, right? So how do you deal with that? What we're working on, we'll fix this problem, because this is what we really want. We really want the edges, when they meet, not to start overlapping, but to merge into a vertex and then another line to continue from that point onward. There's an algorithm called the straight skeleton algorithm that we've long known would do this, but it's hard to implement correctly and it's hard to implement inside of a bevel, but we've been doing this work. I'm not going to talk about this whole slide, but this is mainly to let you know that there's a lot of work that's gone into bevel over 10 years of me working on this and Han's worked on it for a while, too. There's currently about 9,000 lines of code that is dense and hard to understand and see. It's kind of scary for anybody else to try to contribute to this code. So that was another big motivation. Let's rewrite this in C++, use modern data structures, split it into files somewhat, and hopefully end up with something that we can then extend and maintain better into the future. So here are the goals of this bevel v2 project. First of all, let's take a look at the specifications. What does bevel actually mean? Which turns out to be surprisingly hard and a lot of this talk is just going to be about that, righted in C++ as I said before. And then because it's a node, we can give a lot more control on the inputs to users. We can, right now there's this hacky way of saying I want these edges between two nodes of a vertex map to be beveled, which doesn't always work. Now with a bevel node, you can actually directly select the edges that will get beveled and we also want to give control over each of the widths of the four corners of an edge. I mean, internally it'll actually be a different control that doesn't have redundancy, but something like that. So you'll be able to get edges that taper inwards on the bevel and things like effects like that. Also the output, all of the different parts of the bevel will be available as outputs so that you can use them in further nodes to do things like set the material the way you want it or whatever you want to do with those things. There's some algorithms that we want to improve. Henrich initially came to me working on bevel because he was annoyed by the curve continuity that we'll get to later. And so we want to fix that. I've been continually annoyed about how hard UV handling is and I want to really do a completely different algorithm. And there's a bunch of special cases in the code right now like two corners are handled completely separately from other things. The big new feature is this overlap merge handling that I talked about, but also because the same problem of that collision and overlapping happens when you do a face inset, the same code will fix that. And so there will be a face mode as well as an edge and vertex mode in the bevel node that will do a face inset. Henrich and I have been arguing over whether this actually should be a separate node called face inset or whether people would naturally regard this as a face bevel. We'd like some feedback on that particular point. And then there's some performance things. The old code loops over the whole mesh in lots of places. And I kept that for backward compatibility rather than improvement, but now starting from scratch, I don't have to do that. And now that many people have multiple cores on their machines, we want to use parallelization as much as possible. So here's the status. Those of you that saw Lucas's talk just now had him say he thought he would be done by now. When he proposed the talk six months ago, I'm in exactly the same position. I thought it would be done by now. Real life, day job, remodeling our house, all kind of interfered with it. But we do have something. There's a V2 branch. I've written about 5,000 lines of code so far. It has vertex edge and face modes. The edge one doesn't do anything yet, but the face one is connected up to this straight skeleton algorithm that handles the collision. It's a bit buggy, but it is there. Attribute propagation will happen later. One big thing that we're doing is working directly on mesh rather than convert into B mesh, operate there, and convert back. That required a whole bunch of code bases to get that to work. And that is there. The straight skeleton add-on was initially done by Henrik in Python. And you can use that as an add-on right now. But then I copied this Python code into C++ blend live function called mesh inset that is being used as a subroutine in this node. And Henrik has also done a Python prototype for smoothing that he'll talk about when he gets to his part of the talk. So on the right is a screenshot to show there actually is a node. It does a face inset. You won't be seeing many more diagrams of what it's doing right now. And this is mainly a technical talk about why bevel is hard. So why is it hard? I mean, conceptually it's this simple woodworking thing, right? You take a tool and shave a little bit off an edge and you're done. That's a bevel. And if you convert that into a polygon mesh mode, it means something like this. You take some edges, an edge that you want to bevel. You put some offset edges, a set distance away from that original edge. Then you remove all the material in the hole between those edges. And then you fill them up. That's a bevel. Now there are a whole bunch of issues that I learned over the years is doing them. Some of them were immediately obvious. Some of them I only learned, you know, through many bug reports. But I'm going to spend a lot of time now talking about these so that you can see that there's a lot of choices you have to make when implementing bevel. The first one is clear. You know, people have multiple edges that intersect. So when you remove the material now you've got, it's unclear exactly how you fill this up, especially at that corner. The next one is a little less obvious when you first think about it. It's just, you know, you don't bevel all the edges. There's non-beveled edges in between the beveled ones. And if they aren't in the same plane as those beveled edges, then when you do that edge offsetting, they don't match. They don't intersect. They cross skew in 3D. So there's no intersection point that's obvious to make for the bevel. You can do various things. What bevel currently does is a compromise. It takes the closest point of approach to those two lines. The midpoint, that's going to be the intersection point. It kind of works, but it's not ideal. And there's a particular case that people want, which violates that, which is the edge slide mode. So, you know, you can also decide to move the intersection point along one of those existing non-beveled edges. And people like that because it looks cool when you're beveling. This point is just sliding along an edge, but it also maintains the silhouette of the object. If you rotate an object around, you don't get a distortion of the broad shape of the thing. But it causes lots of complications. You know, now, the loop slide is shown on the bottom right. When you have loop slide on, the bevel widths are no longer what the user specified. They're different. And, you know, you kind of have to compromise exactly where this intersection point is. And it gets really hairy if you've got a closed loop of edges, all of which are beveled and loop-slided. When you come back, they don't match. So there's actually an optimization call inside of bevel to solve the best compromise of dealing with loop slides. Next issue is multiple segments on edges. Of course, we wanted this almost from the beginning of bevel, not just a single cut-off piece, but rather rounded edges. And, you know, the obvious thing to do is say, oh, well, I'll take a quarter circle, divide it up into even cords, and that's the profile. First question that comes after that is, okay, what if we don't have edges meeting at a 90-degree angle? What bevel currently does is takes that corner of angles that meet at 90 degrees and figures out the transformation matrix that maps it into this distorted corner where the edges are actually meeting at an angle and then transforms that profile, that half circle into the place in there. That kind of works. People haven't really complained about that too much, but people have asked for this other option, which is I would like a constant radius circle just sort of jammed into the corner and use whatever section of the arc you happen to get there. So I intend to give that option in WB2. I haven't done it yet, but it'll be there. Next sort of variation on this issue is profiles that aren't just circles. You know, there's these superlips profiles. And, you know, once you do this, you realize there's another math problem, which is how do I get even cord lengths on the superlips? There's no real easy formula to do that, I finally discovered. And so there's actually an iterative optimization in Bevel to do that to figure out how do I get equal cord lengths along the superlips arc. And then there's a whole set of other issues to deal with custom profiles, which Hans could tell you about. I'm not going to get into them today. But the biggest issue probably at the beginning of doing Bevel was this whole filling problem. If you bevel these five edges that are going into the center in this object and then give it a five-segment edge, you get this funny pentagon with curved edges thing that you have to fill in somehow. How do you do that? I mean, if you go back to the principle of, oh, this is woodworking, you would try to maybe extend the edges along and intersect them. It's a horrible, horrible mess if you try to do that. You get gaps. I mean, you could probably use Boolean and get something that looked like something, but it would have weird, hard edges in it be a mess that nobody would really want, except in very special circumstances. I'm a PhD computer scientist, so I go off and read academic papers if I can, and believe it or not, there's a whole PhD thesis on how to do hole filling. And it seems like all the other DCC content have sort of discovered the same basic principle of how to fill more than three-sided holes, which is based on subdivision. The tricky part is, you have to match the curvature of those edges. Normally, subdivision would shrink inside if you did it. And the second tricky part is, subdivision only gives you power of two number of segments, and we need arbitrary number of segments. So here's an illustration of what the algorithm currently is in Bebel. It starts off with that end-gone for one segment. It puts a point in the middle and points along each of the edges and joins them up. That's the first level of subdivision. And then it repeats that process. It's going to put a point in each of these things, divide each of the edges in two, and then there's some fiddly bits around the boundaries to try to match the curvature. That's the hard part here, and why somebody wrote a thesis about this. And so you get that one, and now you get that one, which is eight. But now we only wanted five. What do you do? So you can overlay the five pattern on top of this and that's what you do. So this is all kind of expensive to compute. Bebel precomputes this at the beginning and then uses that computation over and over again. So next. The next super hairy issue, and this is probably spent most of my development time on Bebel over the years, is UVs. There have been so many UV bug reports. Look at this case here. We have a square, a cube. The top face is a UV island shown on the left. Now, Bebel is going to put new points in that face. I've shown one here, and I've shown where in UV space you would interpolate that. So that's the obvious thing to do. Every time you create a new face, see what face it's over, interpolate on that face in UV space. Unfortunately, this is what happens if you just use that algorithm. Every time you're crossing an island in UV space, the algorithm doesn't know you've crossed an island. It just draws these edges. You get this horrible mess. There may be some textures that would be okay with this mess, but I can assure you most users would file a bug report immediately if this is what we got out of the UV algorithm. So you can't do this. The same problem happens not just crossing islands, but even crossing seams within the same island. So this is what the current Bebel looks like. The problem really only happens when you have an odd number of segments in that middle segment, where do you put it? When you have an even number of segments, you just kind of evenly divide them in the two sides. It works okay. But that odd segment is the killer. What do you do about that? So I try to figure out consistently, okay, this is the island, I got to put the middle segment on, and I put that around. And then when I would want to have interpolated in a face in a completely different island or a different part of this island, I just snapped to one of the edges and interpolated along that edge. So this is a prone code that makes the correct snapping so that the previous thing doesn't happen again. But it still has problems. There's open bug reports right now saying Bebel is broken with UVs. And it's stuff like this. One of them is, you know, these segments that you produce, depending on whether they were within the same island or across the seam, will have different widths. The same thing within the object space will have different width than UV space. And it's distorted to users. And then these corner polygons, because of the way I'm snapping to edges, will sometimes snap into the middle of an edge rather than what seems natural to people that it would be connected up to the other side. So these are long-standing problems that I don't really know how to fix with the current method of interpolating and snapping to edges. It feels to me like, if I just look at the problem in UV space, I can do a better job. I haven't started on this yet, but I plan to do this. Then there's the issue of curvature matching. So, you know, that super ellipse formula, if you look at the math of what it's going to do to the second derivative, you can show that you're guaranteed not to get continuity. So you see these visible artifacts here where the face is joined. No matter how many segments you put in this thing, there will be this visible line there. Really that line wouldn't be there. Henrik has an idea that he'll talk about later to solve that problem. Then finally, just coming back to collisions, I teased about this at the beginning, but I just wanted to give another motivation, which is bevel after Boolean. A lot of people would like bevel after Boolean because after you Boolean, in real life there's often a fillet around where the join happens, and you'd like the bevel to make that fillet apparent. But in our world of mesh, soon what happens is that nasty clamp thing says, I can't bevel anymore. And often it's a really tiny amount that you can bevel before that happens. If you try to bevel over that, you get an unholy mess that nobody wants. So I've been promising for two years to fix this problem. There's an add-on that kind of does bevel after Boolean, but it does it by intersecting a pipe around this. It has only limited application. It won't work for more than two edges into a seam. Anyway, the straight-edge skeleton algorithm will solve this problem if we work on it hard enough. You have to be careful about what happens as it flows over existing geometry, but I'm sure we can make this work. The solution is this straight skeleton algorithm, and I'm now going to pass over the second half of this talk to Henrik. I'm going to start and encourage you to imagine. Yeah, thanks. So to fix this mess, we looked at two solutions, and the best one was the straight skeleton. So to do that, let's look at the bevel process again. So this is the basic process. We start at some mesh, like a cube here. Then we split up all the edges, which we want to bevel. Then we also keep in mind which vertices go together. Then we do some post-processing for the meters. Then we add the profiles, and then we close the vertex holes. So the problem with bevel after boolean appears directly in the first step. So these first polygons, they often self-intersect and are not simple polygons anymore. So that's the step where we want to introduce our new algorithm. So this is an example of what should happen. So we are beveling these top edges around the top face, not the inner one. And for small bevels, this is what the current bevel produces, what the thing you would expect. And then for larger bevels, it's a little bit more difficult to think about what we would expect. So one thing we might expect is this thing where basically if you think about this woodworking, you are taking off this one edge and then you are taking off it from a different angle and then it cuts into this one edge. So you get this little dip there. So the top face would not be one face, but now two faces. So this could be one expected result. So how would we do that? This is exactly the straight skeleton and nature has a solution for that as well. So this is the crystal or mineral, I don't really know geology. You know, I thought it looked pretty and basically it grows from the outside. So that's exactly what we want in bevel as well. And then you get all these intricate patterns and so let's look a little bit more into crystal growth. So here I've just done some crystals from a circle and now let's have a think about how we would grow them. How we would make an animation of how they grow. So the first thing you can think of is obviously just take the crystals and scale them up. Just animate the scale and then look like it was growing. But then we get to this point and you can see that at this point the scaling would not because of these points, their intersections and if one crystal crashes into the other then the one which was at the intersection point first will just keep growing and the other one is blocked. So if you just would scale the crystals then it would point through. That would not work. Also one thing which is not shown here but if they arrive at the point at the same time they would actually create a new direction of growth. So that's another complication in the algorithm and it's actually causing big trouble. And then it would keep growing and at some point be like this. So no more changes when it keeps growing just keeps growing out of this dish. And this is actually the only geometry which I've shown you in this past three slides. It's just I take this geometry, put a plane through it and move it. That's a crystal growth. I can just go back again. Okay. So now back to here. This is exactly what I have done here to the right large bevel. I've just used this crystal growth algorithm and just didn't fully grow it, cut it off at some point and that is what you get. Of course if you do very large bevels, so at some point these phases would become point and then if you increase the bevel even more it would just shrink. It would just shrink this whole object. Just cut it off more and more. So if you think about wood cutting it's just cutting it off. So that might be what we want. It might not be. Let's look at a different case. Because what we have seen in the previous slide was really a special case. We have all edges which were convex. So here we have the same shape but two of the edges are concave and two of them are convex. And for small bevels again this is just the current bevel. It works. But then for large bevels at some point we have to somehow handle it. So the most reasonable way I thought of is to just stop the vertex when it hits the other one. Just stop it there and not handle it anymore. So that gets us this right result there. But it's of course very different from the thing on the previous slide here. So we need to think about it again. So the next thing is segments. So you can add segments to that and it works here because it's still just quads and you can just put the segments in there. But note that we have this edge here a component like this and it is really what's making this possible. So if we remove that edge then we get this result. So it still works for the small bevel but for the large bevel we get these edges here which just don't care about this indent here. So we get this overlapping geometry again which we try to avoid. So we need to address that as well by adding segments like this and that can be done with a straight skeleton but it will not always work. It will probably work for all cases which you will ever try but yeah. So that can be done and we'll need to be done. And now the issue is we have these two approaches so one of them is for beveling these convex geometry and one of them is for beveling the surface the thing you would encounter in real life. And now we need to find some kind of compromise or something which works for all cases, right? So my solution was to just say we always use the second approach so that would make this geometry look like this. So basically just if it hits stop it there and move down and that will cause these a little bit weird geometry but I mean you can think of it as some variable with bevels so just clamping but not with one value but for every point different value. Then there's of course the issue of non-planar cases these straight skeleton algorithms which are online available as papers they all work in 2D and it's very difficult to extend that to the 3D case. So this is what it currently looks like I've just implemented this as think about it as 2D locally and then this happens which is fine I guess but you would probably want to have something better and it's probably possible to improve it but it's very very difficult. Then the next issue which I wanted to talk about is vertex hole filling and specifically it's about the vertex holes so the profiles their continuity it will always be set by the profile so if you have a circular profile it will always be only a jump in curvature because one is the circle and one is a flat plane so different curvature that's not the problem here the problem is the continuity here at this edge and then inside here we want to have something as smooth as possible we don't want to have it stick out somehow all these issues and so we know what we want we know we want curvature continuity we want that it is smooth but it's very difficult to find a formula for that so you can't just have a single formula which says this is the surface, this is the points where you should put the points so to solve this we use optimizers because we know what we want so using optimizers we find that solution this can be slow, can be fast we don't know yet if it will be fast enough but maybe because we can do it with a linear optimizer so basically just inverting a matrix and these are the results so on the left we can see the current results, this is here a patch and here's another patch and at the borders we can see with this matcap that there is these weird corners and stuff so to have curvature continuity it should look like this here inside and then of course at the boundary here it's again circle to plane so there will be no curvature continuity there but this is the result we get and what I've used for this is take the second Laplacian of the surface and then just set that to zero and that's the linear equation that you can solve yeah in solving it gives you all the positions so we don't even need to start at a good initial condition it just calculates the inverse of a matrix and here are some examples so this is the outward vertex hole filling and then if you apply the smoothing then this is how it looks so in the old one you can obviously see the corners the edges and in the new one it's very smooth it doesn't carry the profile through it that's a little bit of an issue I guess for some special cases we could carry the profile through it but that would be not solvable like this so that would need a special case handling here's another application of this same thing so we can just change a few vertices and then get an area and smooth it and it will have all the boundary continuity so it will make a surface which very well fits the original mesh so basically I just pulled with editing on the monkey and then applied this and it's very close to the original actually and the reason why we are using this optimizer instead of some formulas well of course we don't know the formulas but maybe for the square case there could be formulas but we have actually poles inside so that makes it much more difficult and the optimizer works so this is one example of the straight skeleton now applied to text so this is the inset and this is the second mode so we have the bevel with the straight skeleton which will use it to clamp but we also want to use it for the inset and then you can do this stuff with the inset instead of the bevel so that would be possible and this worked right away but often times there is epsilons in this algorithm and sometimes it still doesn't work so there is still work to be done it's similar to boolean in some way so yeah but here it worked so and this is another example so we have this straight skeleton inset and it's lifted as well so I can use a height for a color ramp and then I recreated the crystal somewhat there's just one more example for me that thing that I showed at the very beginning the piece of the Sarah on the A the node will do this you try to go a little bit further if it's a bug it's definitely not ready for use yet but it's advancing and that's it for our talk thank you very much time for questions you mentioned this like healing susan thing the part like the code to do this boundary condition solving like plan to be a separate node as well I think it's useful maybe a tool in edit mode I would think it's just a python script so I can just run it see the result but it also currently doesn't work for all patches so it needs certain topology it's a boundary so maybe that needs to be improved is it a classy and smooth modifier that I did this summer of code mentoring for we should look to see if that's the similar thing and whether we should merge this but you can show that two examples one with collapsing to the edge and then there's the second one where we can overlap the edges together what are the expectations for the speed of that would it be much slower or would it be similar to what we have currently with modifiers I think it'll be slower but we'll have to see whether it's so slow that I have to actually kind of implement the old way too and switch only when there's a collision or whether this will be faster now I mean we're trying I'm trying to use algorithms that are not quadratic but setting up the data structures takes some time my hope is it's going to be fast enough but we won't know until it's completely implemented depends on just how huge your model is and how many things you're above are you envisaging for having a usable product in the master project realistically this is probably another six months of work I'm afraid I have a day job and so this is quite complicated there's still some big unknowns especially in the UV handling and especially as Henry was talking about the actual adapting this to multi-segment edges we know this in principle the straight algorithm skeleton algorithm does what we want but then turning that into practice I think it's going to be a bunch of work profile performance of this different kind of algorithm say if you want to try something out how do you get a sense of what they can see so what I typically do on a complicated algorithm is that I do this on Boolean is I make a programmatic test case that I can make bigger and bigger and bigger and bigger maybe I'll take two UV spheres and intersect them and I can do something similar here something that will have a scalable number of vertices and then I can run profile timing on it to see how it's doing of course I'm paying big attention to what algorithms I'm using in the first place to make sure that in no case am I really having an algorithm that goes over say all the vertices of a face over and over again in case you had a huge face yeah the UVs and artist connection is something I hadn't paid enough attention to when I originally did it I had made this assumption that the way you use UVs is you have say a painting that you've done inside the UV lines in the UV space and that it was imperative to stay inside the existing lines so all the code is trying very hard to stay inside the existing usage of the UV space and not have them overlap each other that is important for one use case of artists but there's other use cases of artists where that isn't important at all it's like when you have a general texture covering the whole area maybe the orientation of the UVs matters but the actual overlapping doesn't really matter and so I think there may have to be options to account for these different ways that people care about what happens in UV space because there's compromises that get made like if you stay inside the lines maybe you can't avoid distortion whereas if you go outside the lines maybe you think that's a lot closer maybe more important than the others I certainly welcome more feedback on that particular point I don't really know what people want to have happen it is a big messy thing and obviously because this is a node nobody wants to have to manually fix the UVs after the bevel that sort of makes this a no go use so it really has to work automatically and do what people want and that's another thing that makes it really hard a lot of the bugs have been in the form of oh you chose the wrong islands for these two pieces and now if I look at I've used it for colors this segment is blue and the next one is red they don't match up it doesn't look aesthetically nice so there's a lot of tie-breaking rules in the code right now to try to make it so that it'll look kind of uniform the choice of the island but maybe those tie-breaking rules are wrong there's assumptions you prefer the islands to be at the top of the bottom rather than on the sides it's not easy speaking about UVs you also mentioned that when the number of segments is even it's kind of the lesser problem if you cross the UVC or UV island I'm thinking couldn't it also be like an option if you specify an odd number of segments but if these happen to cross a seam then it automatically picks the next even number of segments so it's very hard to do this I mean this feels like a user choice that isn't too hard if they know it, it's messy with odd I mean maybe, yeah, users who don't know very much about what's going on inside and don't know that odd thing that would be a sort of dumb user kind of a facility that could be enabled by but unless you're talking about something more sophisticated where you use the number you use the even thing and then try to fix the UV space based on what happens on the I'm thinking only promote the number of segments to even if you cross the UVC oh I see so have a variable number of segments depending on what's happening it's interesting idea what do people think about that I don't know, okay but it feels non-uniformity I'm looking at your model where the number of segments is varying, if it's a small a large number of segments you certainly wouldn't notice generally you would try to avoid UVC in the best place so hopefully that wouldn't be as far as they know people you know, artists tend to avoid UVC or put them into less visible places of the modern way because of all the issues that note for what segments you could do the best solution but you could do another cut in the middle for odd segments to keep the UVs at the original borders that's kind of what he's talking about there are also problems with that as well so if you shrink your bevel into the face then maybe you cross a UVC as well and then it doesn't work as well yeah the bevel after boolean thing is now going to have these things going over multiple faces and you'll be in a whole different area of UV space just stop using UV space somewhere where they had a class yes I have noticed that the general approach of getting the bevel work is to perform an exploit and then dealing with the stink of glitches and creating some curve in the middle are there any alternative approaches to this like maybe creating a new segment of edge loops and just changing the position of the current geometry instead of creating new one I think you'd have to show me in a diagram what you're talking about I don't really know there's a big paradigm shift to using edge skeleton that's going to happen which is right now you kind of bevel each edge independently or only with its neighbor whereas what's happening with this new thing is that you have to the contours of edges that go around in a closed loop and join up to each other that then forms a wave front that you expand until they hit other wave fronts and so this is going to be in a different organization of the code it's also going to make it harder to parallelize because you don't really know the extent of the globality of the islands that you all have to consider together because they might bash into each other another thing that we didn't have time actually looks like we did have time but the show that gets complicated is you know one big benefit of straight skeleton is that it joins those, merges those edges as they come together but there's another thing that happens which is if you have a reflex edge a reflex corner it'll eventually hit the advancing opposite edge and sort of you know it'll actually hit that other edge and what happens it splits into two separate faces and he had an example that you may not have noticed but it splits into two separate faces and you get you know this is ideal for things like if you're trying to raise roofs and have a nice corner and have the right thing happen if two peaks should form it's a pretty cool thing but it means the algorithm is kind of complicated the biggest complications of the algorithm honestly though are all the special cases that happen when things happen simultaneously if you only ever have one collision happen at a time it's all easy you can write the code it's when you take a square and inset them simultaneously all of a sudden you get like several things happen at once and the algorithm work properly there is hairy yes using John Schindler is a lot of where currently we're feeling an edge weight specifically for is that how are you using edge weights or other results I mean I have to talk more with these guys over here about how exactly I want to have the inputs control when I've been doing my tests right now I just take an index an index node and then a comparison node against a particular value so that I can bevel the thing I want to bevel you can imagine formulaic ways of doing that same thing the selection input into the node is going to give a per element if you're an edge motor per edge boolean saying I want this one bevel I want that one bevel whatever also be a field called weight that can either leave and then it will be the same weight for all the edges or it can be a per edge of the whole mesh field that then lets you feed in whatever weight you want per edge in the node I mean I kind of hinted at this but there's a redundancy when you do that especially if you want to allow each corner to have its own width because then you get conflicts like you can't have this corner on the adjacent corner have these two widths and have them meet so the non redundant way of specifying this would be to say at each corner you say okay here's a vector that I want the intersection point to move along and here's a length I want it to move along with that's sort of the internal way where we would like to represent things in a very unartistic way to have as an input into this node and we've been discussing some possibilities of making that the node and then having another node that prepares a more artistic friendly way of specifying a bevel into that node at the moment I'm leaning more towards just having both of those possibilities in the code I think vertex sorry edge weights from the values anyway so just having that would be fantastic bevel weights both on vertices and edges are these weird extra attributes of mesh that don't really belong where they are they were added in in some weird way as first class citizens of those elements in no way should ever have been that and I know Hans has been working on rationalizing how attributes are stored on meshes and I'm sure he would like those to go away and that the way you would control bevel is you make up your own custom attribute that you then assign somehow to edges that would be the equivalent of bevel weights yes what are the areas that this problem can be paralyzed because there are a lot of overlapping subproblems so the first and easiest thing to parallelize is there's a place where at the beginning you have to figure out what is the ordering of edges and faces around each vertex that's involved in a bevel because that isn't naturally part of the mesh data structure you can trivially parallelize that work across all vertices together if you're doing a vertex bevel the whole vertex bevel can probably be done if you're not worrying about letting it expand over adjacent edges and I'm not sure I'm going to allow that or not yet for edge bevel it gets harder if you assume that things aren't going to crash and do each other you can kind of parallelize a lot of things but there may have to be the stage where I make clusters of stuff that I think are independent problems and then parallelize over those independent problems it's not going to be easy if you're doing a bit like for boolean there's like a fast one and a slow one if you're doing a switch where if you wanted a simple case this is a very bevel case that it can process a separate thing if you want to do the more advanced then you'd happily pay for that that's possible you may have to do that at the speed that the other one is too slow I really hope to avoid that I mean it seems like an annoying thing to worry about I mean the more ideal thing if it comes to that is the calculation to figure out where the things are going to intersect is not too hard the current code does that in the clamp bevel mode so I could I haven't done it yet but I could put that calculation back in there and then first do a global evaluation are there any intersections at all if not then use the old method so then use this new method but maybe if they do overlap I don't think there's much use in allowing people to use the old method it's so icky the results the only reason I could see you doing that is if you're willing then to manually clean it up because it's basically unusable in most cases when that overlap starts happening and also the straight skeleton only computes the stuff that you actually want in the end so it doesn't compute the complete straight skeleton but just the stuff where the collisions happen so in case you don't have collisions then it doesn't do much so actually performance wise it's quite fine then I guess we're out of time now thank you for listening to us