WEBVTT 00:00.000 --> 00:10.240 All right. Good morning. Welcome back to the open hardware and CAD-CAM Devroom. It 00:10.240 --> 00:15.880 falls down to 26. Our next speaker is Lucas, the author of the Doom 3D Mechanical 00:15.880 --> 00:18.160 CAD package. 00:18.160 --> 00:27.520 So, hi everyone. Thanks for the intro. Today I'm going to talk about my 3D CAD 00:27.520 --> 00:35.200 package, doing 3D. So, first of all, a quick intro about me. There's a third of 00:35.200 --> 00:41.560 course. So, I didn't start writing heads-off there because I thought like it. It came 00:41.560 --> 00:48.360 out of a personal lead. Need like it with many open source projects. So, my real hobby 00:48.360 --> 00:53.880 is writing heads-off with my real hobby is like doing other projects like shown here. And 00:53.880 --> 01:01.640 like they are pretty much these days converged on PCB in a 3D plastic shell. And one thing 01:01.640 --> 01:07.200 that getting Bob's made and 3D printing have been common, that they pretty much require you 01:07.200 --> 01:12.280 to use CAD. When making things out of wood or metal with machining or so, CAD is somewhat 01:12.280 --> 01:15.560 optional. So, if you need a whole somewhere, you could just take out the drill or the 01:15.560 --> 01:20.240 hole that you're done. But if you're making a board made, everything that has to be on the 01:20.240 --> 01:27.040 board has to be in the CAD. And with the same drill, you can file things off or so, but 01:27.040 --> 01:32.680 it will it won't look nice. So, basically with 3D printing, you're effectively trading 01:32.680 --> 01:41.760 your handyworks skills for CAD skills. So, CAD is really important to do of those. So, a couple 01:41.760 --> 01:47.240 of years ago, I wasn't quite satisfied with the site of a state of Kai CAD back then. 01:47.240 --> 01:54.920 So, I started developing Horizon EDA, which fixed the CAD problem in the electrical rod 01:54.920 --> 02:01.080 for me. And, but then there was still the issue of the mechanical world. I said all of 02:01.080 --> 02:07.680 these projects require some 2D exposure of some sort, and I found myself oscillating between 02:07.680 --> 02:14.240 3K and whole space. Like, either of them, like, had their ups and downs, but for some projects 02:14.240 --> 02:18.280 I used 3K, for some projects I was also based, but wasn't quite satisfied with either 02:18.280 --> 02:25.080 of them. So, they mixed in why exactly that was. So, 3K that, like, some important things 02:25.080 --> 02:29.880 right, that is mostly that important export, that is the important importance to import 02:29.880 --> 02:36.920 the PCB from Horizon EDA, and export being there. So, you can have, like, an accurate 02:36.920 --> 02:40.120 export that isn't just a triangle mesh like STL. 02:40.120 --> 02:44.960 And, for instance, our importance to make the part look nice in an easy way without having 02:44.960 --> 02:54.920 to manually do hacky things with sketches to get the edges tempered or fillet it. But, 02:54.920 --> 02:58.680 what didn't work out nice in 3K was the referencing due to, like, the topological 02:58.680 --> 03:02.720 naming things, and the sketch of being model, always made things a bit irritating to 03:02.720 --> 03:08.400 use. And, also, what's other, didn't quite like is that you can't, don't really have 03:08.400 --> 03:12.840 constraints in 3D, so if you want to extrude something, well, you can either say it's 03:12.840 --> 03:18.920 up to a phase or up to certain lengths, but then that's it. On the other hand, salt space, 03:18.920 --> 03:24.600 was pretty much job with it. It didn't have that import, it had that export, but that 03:24.600 --> 03:31.600 was a bit janky. So, that import, I somehow worked around importing the PCB as an STL, 03:31.600 --> 03:36.440 but yeah, that made it all of a feature this blob with no real way of referencing it. 03:36.440 --> 03:40.480 And, it also didn't have time for the fillets, but it showed me that, like, CAD could 03:40.480 --> 03:46.000 be, like, easy and fun. Like, referencing, you could just reference everything throughout 03:46.000 --> 03:53.080 your model, and it just worked without any issues with topological naming. And, it also 03:53.080 --> 03:56.960 had, doesn't have, like, a separate sketch of work bench, you can just draw and work 03:56.960 --> 04:04.040 paint all in 3D and it'll work. And, also, constraints in salt space, they apply in both 04:04.040 --> 04:10.000 2D and 3D, so you can use constraints to do basically everything. So, don't have 04:10.000 --> 04:14.000 thought, well, wouldn't it be nice if there was something that could, like, take all 04:14.000 --> 04:19.160 of the boxes? So, well, I thought, then I thought, well, I managed to pull off if the 04:19.160 --> 04:25.520 lot of thing horizon EDA as a PCB CAD software and it worked out pretty well for me, so 04:25.520 --> 04:31.120 could I pull off the same thing for 3D CAD package? So, how does one develop a 3D CAD application? 04:31.120 --> 04:35.680 So, step one, make a PCB CAD application. And, then, realize that you'll have the way 04:35.680 --> 04:42.000 there, the Ling3D CAD application is a trans-out, like, there's some similarities between 04:42.000 --> 04:48.840 the two. One of them, being the 3D view, that means that, like, horizon EDA has a 3D 04:48.840 --> 04:55.760 preview that you just open GL to render the board and you can rotate it, but you can't really 04:55.760 --> 05:02.040 manipulate it in any way, but still. And, you know, how to, like, use OpenGL, import step, 05:02.040 --> 05:08.920 render it, and basically, you know, like, how to make, how to make things render in 3D. 05:08.920 --> 05:15.400 And, yeah, the importing step part, and all the exporting step, was managed by OpenCastate. 05:15.400 --> 05:21.560 So, like, that's the, to my best most, the only real game in town, if you want to deal 05:21.560 --> 05:30.000 with step in a playable way. For example, for exporting the PCB, I construct the wires 05:30.000 --> 05:34.640 that make up the outline, and then extrude them by the 15th of the board. So, well, that's 05:34.640 --> 05:42.080 already the cooperation of any 3D CAD making solid, so I thought, well, that's already there. 05:42.080 --> 05:51.520 The only part that was then missing in the building blocks was a solver, since, like, horizon 05:51.520 --> 05:56.520 EDA, like with many other PCB tools, you move things, and then this day where they are, 05:56.520 --> 06:02.080 but that's not the way people commonly use a 3D CAD, that they want to use constraints, 06:02.080 --> 06:08.800 that define the relationship between entities, and then these done result in equations 06:08.800 --> 06:14.400 that get solved by the solver. And, luckily, the solder part of the solver space is available 06:14.400 --> 06:19.320 as a library. So, the library, the library back where it's held, isn't quite useful for any 06:19.320 --> 06:24.440 serious work. So, ended up basically ignoring that, and directly using this solver put into 06:24.440 --> 06:30.000 the solver space and submitting my own equations to it. So, it's all over, it's a bit weird 06:30.000 --> 06:35.240 in some places in a way it's written, but it works reasonably well, and it's easy to integrate 06:35.240 --> 06:43.160 into any, any other project. So, that's basically how Unity came to be. It's the use interface 06:43.160 --> 06:49.760 and basically overall design of a rise in EDA, with, let's say, the dormitory corner from 06:49.760 --> 06:57.000 freecat open cascade, and it's all over, and workflow from solfspace. So, as some people describe 06:57.000 --> 07:03.760 a Unity as, like, a spiritual successor to solfspace, since it works for pretty much the same. 07:03.760 --> 07:08.840 Yeah, and it's, like, still different from full space in the way that it uses open cascade 07:08.840 --> 07:22.880 as a geometry corner. So, some quick facts about Unity. It's written in C++20, and it's about 07:22.880 --> 07:29.160 50,000 lines of code, when it initially released about two years back, it was 32K lines 07:29.160 --> 07:36.600 of code. So, it obviously grew a bit, but not beyond any bounds. The user interface is written 07:36.600 --> 07:43.800 in GTK MM4. So, back, when I started the project, I had a choice, well, through the 07:43.800 --> 07:49.400 still continue using GTK3, like I did with rise in EDA, or should I pick GTK4. Then, 07:49.400 --> 07:57.440 well, technically, there's nothing that I'm missing from GTK3, so I could have very well 07:57.440 --> 08:04.640 used GTK3 onwards. Well, as we've toolkited, like, they evolved over time, and at some 08:04.640 --> 08:10.800 point in time, they're, like, obsolete. So, as mostly went with GTK4, to have a longer time 08:10.800 --> 08:18.400 until it eventually gets obsolete. And, like, from the developers point of view, I wouldn't 08:18.400 --> 08:23.360 say that it's, like, significantly better than GTK3. There were even some features, like, 08:23.360 --> 08:33.440 menus, where GTK4 made things, substantially harder than they were in GTK3. The data format is 08:33.440 --> 08:40.400 just JSON. Like, it is in a Horizon EDA, since that makes, like, writing out the internal 08:40.400 --> 08:48.320 object representation quite easy, and it's also easy to inspect and manipulate with other tools 08:48.320 --> 08:54.400 if strictly needed. And, also, as same as Horizon EDA, it internally uses UIDs for everything. 08:56.400 --> 09:03.600 And, like, about two and a half years after the initial, like, alpha error, alpha, 09:03.600 --> 09:08.560 like, not the least, after I pushed it first to GitHub, I estimated it's got about, like, 09:08.560 --> 09:14.480 more than 10, but less than 100 users. And, I think, like, that's what I'm quite happy with, 09:14.480 --> 09:19.040 like, if it were, like, many more users, and just me as a developer, it will get 09:19.040 --> 09:24.960 overwhelming with issues and back reports, and whatnot. Like, right now, it's in a pretty good shape. 09:24.960 --> 09:29.360 There are, like, people, like, many of my friends are using it, all the people that I don't 09:29.360 --> 09:33.680 know personally are using it. And, it's very, very important, as a community that has 09:33.680 --> 09:40.720 formed around it. So, and, we've had five releases now, with the latest release, being version 09:40.800 --> 09:49.680 1.4, that I released early this week. Yeah, it has some new features and many and thousands 09:49.680 --> 10:00.480 of tons of bug fixes. The most important features being the FX port. And, some enhancements to 10:00.480 --> 10:05.760 the array groups that are a bit like completed to explain. So, best we did documentation on that. 10:06.640 --> 10:12.480 So, let's now go into the main part of the presentation. So, what's changed since version 1.0, 10:12.480 --> 10:19.920 that I gave you to talk about two years back. So, like, the main purpose of any cats-off 10:19.920 --> 10:28.320 fair is making solid objects. So, initially, in version 1.0, the only way of making solid objects, 10:28.320 --> 10:35.360 either extrusion or lates, with lates being, you take, like, outline and we take it around the line. 10:35.760 --> 10:43.600 And, then, gets, like, a shape, like, you would make it on a lathe. And, later on, we got a revolve, 10:43.600 --> 10:49.280 which is basically, like, lathe, but not over a full circle, but over just an arc with an angle that 10:49.280 --> 10:58.080 can be constrained. And, then, also, loft, which is something that force-based didn't support. 10:58.800 --> 11:04.720 Since it can be quite challenging to them incorrectly in the 3D space. Since what it does, 11:04.720 --> 11:11.680 it takes two or more sketches and generate the solid by interpolating between them. 11:13.280 --> 11:17.200 And, so, in June for the, you just make multiple sketches and multiple work planes. 11:17.760 --> 11:23.680 And, then, at a loft group. And, then, that basically just takes everything, like, 11:23.680 --> 11:28.560 just takes the old geometry in these groups and submits them to open cat cage to make this 11:28.560 --> 11:35.200 solid out of it. So, the pipe groups are a bit like the extrude group. Like, in the extrude group, 11:35.200 --> 11:43.600 you just interpolate along a linear path. But, in the pipe group, you can specify the path 11:43.600 --> 11:52.800 arbitrarily by means of lines, circle segments or arcs or basic curves. And, you can then make 11:52.800 --> 11:57.360 arbitrary shapes like that thing that looks a bit like a long either. 11:58.880 --> 12:06.800 And, all of these were enabled by open cascade. Since, yeah, all I had to do is take my take the 12:06.800 --> 12:11.760 entities from June 3D and convert them to something that open cascades understand, which is basically 12:11.760 --> 12:17.200 the same logic for any for any solid group. And, then, just take open cascade, well, now, 12:17.200 --> 12:22.720 make it solid out of it. So, I really can't overstate, like, how important open cascade is 12:22.720 --> 12:29.280 to do in 3D since, like, that part is the really hard stuff in 3D cat and open cascade does it 12:29.280 --> 12:36.480 all for me. And, that was, like, one of the things why I started doing 3D since, like, 12:36.480 --> 12:42.000 whole space is pretty much, like, the sum of that, but since it has its own geometry kernel, 12:42.000 --> 12:46.000 it could really tap into the power of open cascade. So, I thought, well, how about making, 12:46.000 --> 12:49.680 like, a whole space, like, thing with open cascade, yeah, that's how it really came to be. 12:50.640 --> 13:00.080 So, next to making solids, another important part is constraining. So, and then constraining is 13:00.080 --> 13:06.080 something that you do all the time when working on a model, the workflow is quite important there. 13:06.080 --> 13:11.120 So, initially, when you place distance distance constraint, you select to constrain distance, 13:11.120 --> 13:14.800 and you then you got just the constraint distance line sitting directly on the object that you 13:14.800 --> 13:19.200 were concentrating, and then that was, so manually had to grab the thing, move it where you wanted 13:19.200 --> 13:24.400 to be, then double clickers to enter the value. Yes, since these are pretty much the steps that you always 13:24.400 --> 13:31.520 do, it's now integrated, so you select constrain distance. Then, afterwards, you still have the 13:31.520 --> 13:36.000 constrain, you put your mouse, then you place it, and then you get the pop up for entering the distance. 13:36.720 --> 13:42.800 And in addition to that, there's now a live preview. So, if you look at the top screen shot, 13:43.440 --> 13:48.720 there you see the menu is slightly transparent. So, as you hover over these constraints, 13:48.720 --> 13:53.760 with a live preview of what a constraint will do to your document. So, no one may ask well, 13:53.760 --> 13:58.960 that's a pretty obvious thing to do to make that thing do all of these steps at once, 13:59.520 --> 14:06.720 but yeah, initially developing VIN3D, I just wanted to get anything done. So, at least, 14:07.280 --> 14:10.960 so as soon as it was functional, I thought, well, it's good enough for like the initial release, 14:11.920 --> 14:16.960 and then I can go on like working on something else that was more important than like getting the 14:16.960 --> 14:23.600 workflow part right. Another part that also goes a bit in workflow direction is the constraint menu. 14:24.240 --> 14:29.120 So, in some cases, there's only one constraint that applies, but still you have to open the menu 14:29.120 --> 14:37.920 and select the constraint from there, or type in the key sequence to use that constraint. 14:38.880 --> 14:44.000 So, to make that easier, there's now the constraint menu that can be opened by pressing the Z key, 14:44.560 --> 14:50.560 and if there's only one constraint, the menu doesn't open, and you just get that constraint applied. 14:52.160 --> 14:58.000 And the menu also got a result of an update recently in the way that it has that in 3Ds thing there, 14:58.560 --> 15:05.440 since doing 3D supports constraints both in workflow and in 3D, they can apply leader of them. 15:05.520 --> 15:09.200 In a way that was selected before, by like unseeking the work plane, checkbox, 15:09.200 --> 15:16.240 a very button of the viewport, it can be a bit hard to find. So, now there's that in 3D in the menu, 15:16.800 --> 15:22.480 so you can select right away if a constraint should apply in 3D or in the work plane. 15:24.240 --> 15:29.040 Another thing that pretty much every other cat package with constraint supports are measurements. 15:29.600 --> 15:34.240 So, in those places, they were called reference dimensions, new 3D they're called measurements, 15:34.880 --> 15:38.880 and what they do is they basically like a constraint with a datum, 15:40.240 --> 15:47.040 and what they do instead is they don't apply constraint, they just measure the distance angle also. 15:49.360 --> 15:54.960 Apart from these enhancements to the core functionality, there are also some UI enhancements, 15:56.960 --> 16:00.320 where a lot of them actually, so let's start with one of the other. 16:00.960 --> 16:07.200 So, when deleting things in flow space, you got the popup that says, well, if you deleted, 16:07.200 --> 16:12.720 let's say an entity in the first group, and that, but entity was referenced by constraint, 16:14.720 --> 16:19.920 you got the popup that, well, that constraint also got deleted, 16:20.480 --> 16:23.840 since it was referenced by since reference and entity that's no gun, 16:24.800 --> 16:30.080 and that thing can also happen in other ways, like you will delete some entity and the whole group is appears, 16:30.160 --> 16:36.480 since the group was relying on that, for example, work plane to define the plane that it operates in. 16:37.040 --> 16:40.560 So, in flow space, there was that model popup that you had to like explicitly dismiss, 16:41.120 --> 16:47.440 in Unity, it's somewhat similar, but without the annoyance of the popup being model, 16:47.440 --> 16:50.560 instead you get that toast message appearing at the bottom of the viewport, 16:51.360 --> 16:58.800 and with a nodule here, it has a timeout, so when you don't interact with it for like five seconds or so, 16:58.880 --> 17:03.360 it goes away automatically and provides, so it's, you can just ignore it if you don't want it. 17:06.000 --> 17:10.320 Another thing that you do quite often is basically all the time, it's selecting things. 17:11.040 --> 17:17.040 So initially, it just selected whatever was visible on top, since the section used for the works 17:17.040 --> 17:23.360 the way that it basically renders to a second invisible buffer, and just instead of rendering things in 17:23.360 --> 17:28.880 colors, it renders things by the object ID, and then it just looks at that buffer and 17:29.600 --> 17:33.200 sees like what pixel values in there and then translate that back to which object it is. 17:34.960 --> 17:40.320 So to like give make it possible to select things that are underneath the current thing, 17:41.760 --> 17:48.400 it does something that I call selection peeling with a similar to the rendering technique that's peeling, 17:48.400 --> 17:53.760 so it first renders something and then when you click on it, then it renders everything, 17:53.760 --> 17:59.200 but the thing that was selected and then does the thing up to eight times, so you get the menu 17:59.200 --> 18:04.000 of all the things that are underneath what your current thing is clicking on. Sounds a bit blank, 18:04.000 --> 18:10.480 but works well. So another thing, right to section is the section filter you can just select 18:10.480 --> 18:15.040 if you want only one entities or constraints or just things in the current group. 18:15.280 --> 18:21.280 Yeah, and also going in the way in the way of selection, so if you have a complex 18:21.280 --> 18:25.920 document, it sometimes may not be quite easy to tell like what you're actually looking at, 18:25.920 --> 18:29.520 that's why there are tool tips that appear when you hover over things in document, 18:30.320 --> 18:34.160 and it tells you what you're looking at, and which work pain there in and so forth. 18:35.920 --> 18:41.040 And also think that makes that easier in complex document as body colors, initially everything 18:41.120 --> 18:46.640 was just like solid gray, and now you can assign individual colors to individual bodies 18:47.680 --> 18:54.320 to make it easier to tell a part. And last but not least, here's a contribution by like someone 18:54.320 --> 19:02.320 who wasn't me, and unfortunately for what the name right now, what they added is the thing that 19:02.320 --> 19:07.920 also wanted to add for quite some time, so I'm really thankful for that contribution, 19:08.000 --> 19:12.960 what it is, it's basically the same thing that you have in frequent or other cat packages, 19:12.960 --> 19:17.840 it's a cube that you can click on to align the view to the side of the cube. Before that, 19:17.840 --> 19:23.280 it was just like a lowly pop style thing was just an indicating which way each access goes. 19:26.000 --> 19:29.920 So, and apart from like UI enhancement, there are all the new entities, since version one 19:29.920 --> 19:37.360 patio, the most notable of them being basic curves, initially it only supported arcs and lines, 19:38.000 --> 19:44.480 and it was a bit hesitant to add bigger curves instead, I didn't quite understand the most behind them 19:44.480 --> 19:51.840 back then, but after after watching some videos, by especially if I had called me around that, 19:51.840 --> 19:56.960 I really started to like fancy implementing this year, and they're well there we are. 19:57.840 --> 20:04.080 They're actually in some ways easier to deal with than the arcs, and adding basic curves, 20:04.080 --> 20:09.360 enable the whole lot of other features, one of them being curvature curves, curvature curves are 20:09.360 --> 20:17.440 a tool that basically indicates how much a line is covering, so it's basically the inverse of the 20:17.440 --> 20:26.400 arc radius, and it's commonly used to ensure continuous curvature, so you have edges or corners, 20:26.400 --> 20:34.560 where things don't just transition from like a set line to arc, and that you can use 20:34.560 --> 20:39.680 basis to smooth a transition and they object nicer to look at. What goes in the same way is to 20:39.680 --> 20:44.400 constraints for saying curvature, these were like mathematically quite challenging to get them 20:44.400 --> 20:49.920 right, since if you don't get them right, you'll just end up with something that isn't 20:49.920 --> 20:53.360 continuous in curvature, and it's quite hard to debug, but eventually I got it right, 20:53.440 --> 20:59.680 now they're constraints to constraint, curvature to be continuous between 20:59.680 --> 21:06.800 either two basis or an arc and then the basic curves. Another thing that was enabled by 21:06.800 --> 21:13.280 basic curves was text entities with full support for open-type text. The way that works is 21:14.240 --> 21:20.720 the text is rendered using the typical text, text rendering stack consisting of half-glass 21:20.720 --> 21:25.440 and free-type, half-glass is the important part here, simply just using free-type, you just 21:26.480 --> 21:31.200 basically have to do the translation of a character of codepoint to clear yourself, 21:31.200 --> 21:38.400 you don't get nice things like shown here like, um, ligatures or support of open-type figures, 21:38.400 --> 21:43.680 but since I'm using a half-glass for the purpose, you get all of the nice type-setting things like 21:43.680 --> 21:50.000 ligatures, uh, curling, and open-type features features basically for free, which so as far as I can tell 21:50.080 --> 21:56.560 is quite unique among text support and cat packages. So while it's quite nice that you can 21:56.560 --> 22:02.800 draw basic curves and so on yourself, you can also import them, and for import there's the XFM 22:02.800 --> 22:06.320 port which initially added for the different could import a logo for a project they were 22:06.320 --> 22:14.640 working on, and when with the XF order done SVG, since I already had experience with the XFM port 22:14.640 --> 22:22.640 from Horizon DA and DXF is a bit simpler than SVG for that. A thing is if you import a logo 22:22.640 --> 22:28.400 that's quite complex for example, like the UV logo here, we end up with a bunch of entities that 22:28.400 --> 22:34.560 are at best constrained to be a coincidence at the end point, but you still have lots of free-to-free 22:34.560 --> 22:39.440 them that will dramatically slow down the solver, even though you're not really wanting to 22:39.440 --> 22:45.200 solve that in any way. So to fix that, there are these things called cluster entities, 22:45.200 --> 22:49.520 they're not called groups, since groups are already different concept in human 3D, 22:49.520 --> 22:54.560 so they're called cluster, so that's basically a summoning for that, and what they do is they take 22:54.560 --> 23:00.560 multiple entities, and then allowed it to be treated as one entity that can be like scaled and 23:00.560 --> 23:05.760 rotated to fit what you wanted to do, and you can also place anchors there to scale it as you wanted. 23:06.640 --> 23:13.520 And bitna pictures then work somewhat similar, like cluster entities, you can just import a picture 23:13.520 --> 23:21.760 for example, like a photo of a hook for a bike bag that then I lost, so I basically took a photo, 23:21.760 --> 23:30.240 and then use reference points in there to scale it to the right dimensions, and then use that photo 23:30.240 --> 23:41.520 to another photo to recreate that I took that I lost. So but not only import, got some enhancements, 23:41.520 --> 23:48.800 also export, most notably of that step export, so step export was there from day one, 23:48.800 --> 23:58.160 but it only exported the body, like the one body at a time, and it didn't export the whole 23:59.040 --> 24:04.560 document, but then puricust came along from someone else that had that in the way that there's 24:04.560 --> 24:11.200 no way to export the whole document, and it has shown there, and it's been shot from a freecat, 24:11.200 --> 24:19.120 it also retains the body colors and body names, what's still missing is exporting import 24:19.120 --> 24:23.840 step models, but it's something that all of the kind of later if someone beats it. 24:24.240 --> 24:32.720 So when I was working on a recent project, that involved making also, also involved making a PCB 24:32.720 --> 24:37.920 with Horizon Media, I first did some sketches in June 3D to make up the initial board shape, 24:37.920 --> 24:44.000 then I was liking a way to get that into Horizon Media, so that the easiest thing, and implemented 24:44.000 --> 24:50.560 the XFX port, like it's the bare minimum of EKAT MCAT integration, but it did the job for me, 24:51.200 --> 24:56.080 and the XFX port is also useful if you want to laser cut parts also. 24:58.080 --> 25:04.240 So that's basically everything that happened since the 1.0 overlays, so what's next? 25:05.840 --> 25:14.240 So while, as a disc with these softwares, the stuff that people do with it grows over time, 25:15.200 --> 25:21.360 and one thing that also I have run into, every now and then, was that it gets quite slow 25:21.360 --> 25:26.320 and if you have larger and more complex models, and one reason for that slowness is the 25:26.320 --> 25:33.840 is generating the solid model with open cascade, so it don't want to, like, thank an open cascade 25:33.840 --> 25:42.880 here so much the job it has to do is quite complex, so it, so it does no really way to speed it up, 25:43.440 --> 25:48.160 so the way that the algorithm set is to make the solid model up as in front of us, 25:49.760 --> 25:54.800 so it will synchronously collect all of your things, it needs to make the solid model up 25:54.800 --> 25:59.040 it happen in the background, then it just wants an background that means you won't get to see 25:59.040 --> 26:03.120 the solid model change right away, but you still can continue working on the document 26:03.120 --> 26:05.920 with always waiting for the things that you might not even teach to update. 26:06.720 --> 26:10.640 Another thing that will then soon are racial constraints, there's a podcast open, 26:10.720 --> 26:17.680 someone else that I bought pretty much ready to be merged, but I didn't watch a couple of weeks ago 26:17.680 --> 26:25.440 since I didn't want to put, like, features that didn't seem artistic into the release that 26:25.440 --> 26:32.560 had just happened this week, and so while I used it, it used to deal with the media people 26:32.560 --> 26:39.840 to do it, it used to support it on Windows and on Windows, it's somewhat usual that up the 26:40.000 --> 26:44.640 apps implement update checks themselves, so one typically way to do that is to ask 26:44.640 --> 26:49.760 some server for latest version, but then a friend of mine suggested well, you could do that using 26:49.760 --> 26:54.960 a DNS and a TXT record, and as it's happened, while bought in forced-end schedule, I also 26:54.960 --> 26:58.960 found a plug, I think it was in the go-dove room, about just that topic, about implementing 26:58.960 --> 27:04.000 update checks using TXT records in DNS, so I think it's a two people that came up with that 27:04.000 --> 27:08.560 probably independently, then it's probably good that year, and compared to like typing for 27:08.560 --> 27:13.600 it at some URL, it has the advantage that it's like the most privacy, it's one of the things 27:13.600 --> 27:18.080 that you can do, since like you only link it to your resolver that you'll ask for updates, 27:18.080 --> 27:26.560 but then it's just DNS, and in terms of actual features, what is missing right now are 27:26.560 --> 27:34.800 helix groups, and there's no way, no good way to do them right now, so then it was one of the 27:34.800 --> 27:40.720 few things that solves based tasks that don't really doesn't do yet, but luckily there's code 27:40.720 --> 27:46.160 and freecat for helix groups with open cascade, that I look at and it seems like it's something 27:46.160 --> 27:54.400 it's code that I can reuse in new 3D, so and there are like these features that are already 27:54.400 --> 27:58.560 quite thought out, there are some ideas that have been floating around every now and then, 27:58.560 --> 28:02.960 one of them, you can use it to find out the parameters and the questions, since the resolver 28:02.960 --> 28:06.960 basically just operates on symbolic equations that they give it, and it then solves 28:06.960 --> 28:11.840 numerically, some users were asking for well-economic parameters and equations, 28:11.840 --> 28:16.480 right now there's no way to do it other than like, simply translating your equations to constraints, 28:18.160 --> 28:22.800 yeah what there is to some, I still haven't quite thought out how the UI should look like for that, 28:22.800 --> 28:27.120 another thing that goes into making things more user-defined groups for user-defined arrays, 28:27.760 --> 28:37.920 so people sometimes like cat as code programs like opmascat, since they can just write things 28:37.920 --> 28:42.400 in for loops and so on, for well that would be quite useful, either to make some nice patterns 28:42.400 --> 28:48.640 also, so I had a thought of integrating some small scripting language, like a duct tape JavaScript 28:48.640 --> 28:55.120 or micro Python, introduce 3D to allow making scripted groups where you can then just place things 28:55.440 --> 29:01.040 in a fall loop to make them look nice without having to think of using constraints for that, 29:02.080 --> 29:07.680 and with that, that's it, and now there's the like a screenshot of 3D since I didn't find 29:07.680 --> 29:11.760 like a good way to put it anywhere in the application and the presentation and think 29:11.760 --> 29:15.520 wouldn't be quite complete without showing at least how the whole thing looks like, so now that's it. 29:25.840 --> 29:36.000 Thanks a lot for me, it was something very necessary for Linux, basically for my Linux work flow 29:36.000 --> 29:46.720 to have a catch-off tour that works more intuitively than Africa, and as I've been trying 29:46.720 --> 29:53.920 multiple times between 3D and 3D advancements, thank you, and maybe for the ideas for the next 29:54.000 --> 30:02.320 future, how do you call that, when you want to, how do you call it, sorry, offsets, yes, the offsets 30:02.320 --> 30:09.440 function, so you can select edges and offset them, it's something I use all the time in CAD, 30:09.440 --> 30:19.360 I use on shape right now because I'm obligated to, so, and if you, you can do offsets and you know 30:19.440 --> 30:25.760 what it is, and you can, you offset a shape, and then you can apply a function to it, like extrude, 30:27.280 --> 30:34.000 it's very useful for example, if you do a PCB, if you import a PCB from KK, you click on the edge 30:34.000 --> 30:39.360 of the sketch, and then you can make an enclosure using enough set function to have to add some 30:39.360 --> 30:44.400 tolerances, probably into the right. Okay, yeah, I think I got for a toolman, 30:44.400 --> 30:49.040 the thing one way that could be implemented is as a separate offset group, that's like take 30:49.040 --> 30:55.600 the lines from one group and then apply the offset to them, the problem, like the challenge with that 30:55.600 --> 31:02.560 is maintaining the relation like which, like whether I think come from, since two 3D references 31:02.560 --> 31:09.760 all things by U-IDs, in U-IDs, or basically, if you have some extrude group, the, the 31:09.760 --> 31:16.320 IDs of the extrude lines are linked back by hash to the ID of the line that came from, 31:16.320 --> 31:21.440 so when having something that does the offset, it has to like know what that thing originated 31:21.440 --> 31:27.600 from that line, and it also has to deal with things like arbs, I think there's a library that can 31:27.600 --> 31:32.400 do that, but the problem is with basic curves, and if you also also the basic curve, the offset 31:32.400 --> 31:35.840 isn't a basic curve anymore, so you have to do some like approximation type of who make things 31:35.840 --> 31:40.720 quite complex, but it's one of the things if there's a library that does it for me, well, 31:40.720 --> 32:01.440 that's probably it, thanks for us, I think if you're talking, does the intrudio do you plan to 32:01.440 --> 32:07.200 support cam integration, some sort of past generation for cam, right, or if you just made it? 32:07.200 --> 32:13.120 Okay, so unfortunately, that's completely out of my wheelhouse, since the only thing that I do 32:13.120 --> 32:18.080 mechanically is a 3D printing, and I don't think that I can continue with anything we need, 32:18.080 --> 32:23.200 we need for there, so right now I just say like export a step and go into your favorite camps 32:23.200 --> 32:49.680 of there, other questions, thank you for a talk, what about unit testing, or testing in general? 32:50.560 --> 32:57.840 So right now, there's basically no unit testing at all, yeah, that's the state of things, 32:57.840 --> 33:05.840 so and the things, and I thought it was a couple of times, but couldn't quite come up with 33:05.840 --> 33:11.280 a good way how to like test the way that things still are the way they should see, and many things 33:11.280 --> 33:18.080 are like, you are things that are quite hard to unit test, but I see well, something internally 33:18.160 --> 33:23.680 could be unit testers, but I haven't really found a good way to make that yet, thanks. 33:30.000 --> 33:44.320 Of course, someone in the middle of the room, sorry about the hassle, what about assemblies? 33:44.320 --> 33:55.920 Well, assemblies are so to be fair, assemblies are supported in some way in the way that you 33:55.920 --> 34:02.080 have multiple bodies, but the thing is these bodies themselves can't be moved independently, 34:02.080 --> 34:07.120 so what I thought about that is that well maybe you could have some like exploit feature to 34:07.120 --> 34:14.560 move things independently, and what's also supported is that you can have, that's what already, 34:14.560 --> 34:20.320 is these things for document entities, that means that you can have a separate document, 34:20.320 --> 34:27.520 and include that in another document as an entity, so you could then like edit, edit the document 34:27.520 --> 34:33.840 in another tab, and then it updates in the thing where things will basically automatically 34:33.840 --> 34:40.320 and you can then move and constrain that document in the document where I think you did, 34:41.040 --> 34:46.400 there are still some limitations in that approach, most notably that the only thing that you can 34:46.400 --> 34:52.480 basically constrain is the origin, but yeah, that's feature is not quite as developed as a 34:52.480 --> 34:57.600 probably should be, but edit it to get the software architecture in place for that, but so far I 34:57.600 --> 35:02.320 haven't found much use for it, so if someone really needs it, I think that something that 35:02.320 --> 35:11.600 definitely can be done in the future, all right, thank you Lucas.