Sender | Message | Time |
---|---|---|
30 Jan 2023 | ||
Would intersect work instead? | 00:22:44 | |
into this: | 00:23:07 | |
Download image.png | 00:23:10 | |
(surfaces would be significantly more complex, this is a mock example) | 00:23:32 | |
(and those two areas are two different solids, to be clear) | 00:24:13 | |
* (and those two differently colored areas are two different solids, to be clear) | 00:24:25 | |
i don't think so | 00:24:50 | |
not for ma application, anyway | 00:25:00 | |
* not for my application, anyway | 00:25:06 | |
Compounds of Faces or Shells might help. Compound.makeCompound(faces) results in a Shape which could potentially be used as described. | 00:29:01 | |
Seems like a good start! I'm not familiar with the Compound class yet, still very much a beginner in cq, I'll have to read through some docs | 00:31:07 | |
thank you! | 00:31:10 | |
Thanks a lot for your 1st class support, Roger! Passing vertices to edges to Fillet was the key. It makes sense that, being given we're dimensionally one level below, filetting edges in a 2d shape does not work. I thought I had tried it but did not. My remark would be to perhaps save beginners from shooting themselves in the foot if possible : I noticed that , when filleting edges, the vertices_in_face never contains anything. Maybe display a warning that "warning: 0 vertices have been processed?" or sth like that? I am not sure, though. Another note that I have with the implicit way of storing the context through BuildPart() : in my design, I first wanted to build a basic enclosure, then work on some accessories (buttons, wheels..) At some point in the code I need to work on the enclosure again to drill holes etc. The only way I have found to do this was this:
Wouldn't it be a good idea to be able to "reactivate" a part builder on an existing part? To re-wrap the previous oshell.part in a new variable ? (and I would call it oshell , so that the builder always has the same name, and I can easily insert new manipulations while keeping show_object(oshell.part) at the end of the code.Maybe that would make operations on several different parts easier. I honestly have no other reservations about build123d at this stage and I really enjoy it better than the implicit CQ api. I am a Python dev and was really uncomfortable with the chaining of api calls and the Workplane god object that CQ featured. I will make sure to give you my comments about the API as I progress with my appliance enclosure design. | 06:19:22 | |
* Thanks a lot for your 1st class support, Roger! Passing vertices to edges to Fillet was the key. It makes sense that, being given we're dimensionally one level below, filetting edges in a 2d shape does not work. I thought I had tried it but did not. My remark would be to perhaps save beginners from shooting themselves in the foot if possible : I noticed that , when filleting edges, the vertices_in_face that contains the intersection of the object vertices and what the user has requests to fillet is always empty. Maybe display a warning at the end of filleting that says something along the lines of "warning: 0 vertices have been processed." or sth like that would be a good idea? I am not so sure, though (I tend to like systems that help avoiding basic errors, like the C++ compilers that complain when you write if (a = 3) even though it's a valid construct)Another note that I have with the implicit way of storing the context through BuildPart() : in my design, I first wanted to build a basic enclosure, then work on some accessories (buttons, wheels..)At some point in the code I need to work on the enclosure again to drill holes etc. The only way I have found to do this was this: | 06:21:49 | |
Wouldn't it be a good idea to be able to "reactivate" a part builder on an existing part? To re-wrap the previous oshell.part in a new variable ? (and I would call it oshell , so that the builder always has the same name, and I can easily insert new manipulations while keeping show_object(oshell.part) at the end of the code.Maybe that would make operations on several different parts easier. I honestly have no other reservations about build123d at this stage and I really enjoy it better than the implicit CQ api. I am a Python dev and was really uncomfortable with the chaining of api calls and the Workplane god object that CQ featured. I will make sure to give you my comments about the API as I progress with my appliance enclosure design. | 06:21:49 | |
* Wouldn't it be a good idea to be able to "reactivate" a part builder on an existing part? To re-wrap the previous oshell.part in a new variable ? (and I would call it oshell , so that the builder always has the same name, and I can easily insert new manipulations while keeping show_object(oshell.part) at the end of the code.Maybe that would make operations on several different parts easier. I honestly have no other reservations about build123d at this stage and I really enjoy it better than the implicit CQ api. As a Python dev (my day job) , I was not comfortable with the chaining of api calls and the Workplane "god object" that CQ uses. I will make sure to give you my comments about the API as I progress with my appliance enclosure design. | 06:28:40 | |
07:21:25 | ||
07:21:40 | ||
There is some level of logging info in build123d you can raise the log level to get more data (that would provide more context on what's happening under the hood) | 08:56:42 | |
Download image.png | 14:51:39 | |
If you use cq-editor, just click on the "Log Viewer" tab - attached are some logs for the above design. If you'd like to log to a file, here is how I configure that:
which produces (discord wrapping is going to make this hard to read): | 14:51:39 | |
I've thought about this and I do think it's possible although I haven't tried it. Would you mind creating an Issue on GitHub for this? | 14:53:18 | |
Doing this now. Thanks! | 14:56:26 | |
* Done (https://github.com/gumyr/build123d/issues/108) | 15:02:58 | |
Excellent! I didn't know about that. I really need to take some time to learn the toolset. I am trying to learn both CAD, build123d, Blender and its API at the same time (as well as think about the product I want to create, too :p ) and it makes me overlook some important info 😄 | 15:04:29 | |
* Excellent! I Thanks! didn't know about that. I really need to take some time to learn the toolset. I am trying to learn both CAD, build123d, Blender and its API at the same time (as well as think about the product I want to create, too :p ) and it makes me overlook some important info 😄e | 15:04:37 | |
* Excellent! I Thanks! didn't know about that. I really need to take some time to learn the toolset. I am trying to learn both CAD, build123d, Blender and its API at the same time (as well as think about the product I want to create, too :p ) and it makes me overlook some important info 😄 | 15:04:39 | |
Better error handling is always a good thing. It can be very frustrating when the API is not doing what the user wants but there is no indication of why. So, I've just pushed changes to Fillet and Chamfer to detect this - here is an example:
generates (one at a time):
Thanks for pointing this out. | 15:12:46 | |
Please note that in that case, the error wouldn't have been caught because Fillet works in both contexts : BuildSketch and BuildPart so it must accept both edges and vertices. | 16:16:54 | |
It was not even a typing error in my case. | 16:17:01 |