Do you have an image of the reversing portion? Any examples of pitfalls?
On the face of it, it seems like you'd define paths and sweep profiles for the material to remove. Is the difficulty in defining the path of the reversing portion, where it's not a helix?
Threads have a range of properties, all of which must be supported, then it's generally the capacity to mirror a thread along the same face (exactly), and at either end add a transition zone that reverses, preferably with configurable characteristics (straight portion, rounding, etc.). Many approaches fail because the reversing transition zone is not readily aligned with the existing thread except through hacks or because reversing is incompatible with the programmatic approach used. Once that's all done, there are additional complexities for a captured element to ride in it which typically has a geometric relationship with the thread pitch, crossovers and transition zone. It's one of those "harder than it looks" problems, even for machinists. That's why, if the codebase can achieve it, I'd give it respect.
PS. I also use a lot of OpenSCAD. Liked your comment. I started in POVRay so it made a lot of sense after managing non-FOSS CAD people for years.
Despite being aware of its existence, I stuck with OpenSCAD out of habit. Only last week did I read through the documentation, and feel strongly that I've been missing out… it seems to solve all of my gripes with OpenSCAD. I'm excited to try it out!
Mainly OpenSCAD is not a BRep modeling tool! It is not on the same level of power as CAD tools with a BRep kernel and this especially shows when you want to do a fillet over an arbitrary edge. Unfortunately these kernels are hard to make and integrate and I only know of two open-source BRep kernels out there: OpenCASCADE (used by FreeCAD and build123) and truck (not sure what the status of it is).
I've been wanting to get into OpenScad. Wondering what you've identified as an issue. I dabbled a little and I think I remember wishing it was more object oriented to make it a bit easier to make reusable adjustable pieces and I had found a python library that does openscad conversions; Wondering what gripes it solves for you.
B-rep (boundary representation) modelers (like build123d via OpenCascade) represent solids using faces, edges, topology geometry
OpenSCAD uses Constructive Solid Geometry (CSG) which represents objects as boolean combinations of primitives (union, difference, intersection). It does not maintain an explicit boundary/face structure internally
As the sibling comment mentioned, the classic problem of chamfer/fillet. Inconvenient in OpenSCAD, trivial in build123d.
There are various features I've missed: polylines with rounded corners, extruding along a path, and more I can't recall.
As you mention: code organization. I didn't have the need early on, but over time I often wanted to do add custom things, for example my own hack of an implementation for extruding along a path. And passing data around is just painful and ugly... since you can't read any of your input shapes, you have to pass around all data explicitly -- alongside or instead of shapes -- and then only actually render them in the latest stage. Generally I found it hard to make reusable code, and generally it has to make many assumptions about the calling code.
The OpenSCAD editor is one big IDE, and it's not a great one. My workflow was to keep VSCodium on one side and OpenSCAD on the other, just to use a better editor. I actually thought to myself that a good project direction would be to make it more modular and focus on the unique parts rather than the IDE. And that's indeed how build123d does it: primary repo only handles the rendering, and then suggest compatible viewers, with one shipped as a VS Code extension being the primary suggestion.
Speaking of workflow, a huge difference is local coordinate systems: lacked in OpenSCAD and encouraged in build123d. It fits my brain really well. I just made a shape, now I want to make some holes in it. Previously I've often had to think about what global coordinates to put some volume, but now I'll just select that face and work with those local 2D coordinates.
And another workflow annoyance before is when I'm designing something to be printed in separate parts. First, meticulously fit things together in the global coordinate system so that I can see them in the assembled state. Then to allow printing, also conditionally move all parts to manually specified other coordinates. With build123d one can define the parts separately, place joints in desired locations, and have them automatically snap together for the assembled view. It looks useful for integrating third-party parts as well.
Minor thing, but I'm always slightly annoyed by the fact that a rectangle is called a square and a slab/box called a cube in OpenSCAD...
Oh, and it's often useful to use polar coordinates. More passing around custom data and manually calling your custom conversion function whenever passing to OpenSCAD. build123d has first-party suitable objects for it.
OpenSCAD development seems fairly dormant as well. Latest stable release was five (!) years ago, but by reading around you see that you're supposed to use the nightly version because it's superior. Not very friendly for newcomers. By contrast, build123d seems very active.
I should stop now, because this already got pretty long. As you can see, I had some bottled up though -- thanks for letting me vent!
The article says 2.6 gigabits/second which is 2,600,000,000 bits/second, 2,600,000,000b/s * 0.5s / 8 is 162,500,000 bytes, 162,500,000 / 1,000,000 is 162.5 megabytes
This is only the language for describing the volumes. That's not heavy, rather the importance is that you can express the ideas you want. The heavy lifting of rendering and computing how volumes interact etc is already implemented in native code.
That sounds like a nice improvement, just like many other aspects of jj!
Tools should adapt to us and not the other way around, but if you are stuck with git, there's a slightly different workflow that supports your use case: detached head. Whenever I check out branches that I don't intend on committing to directly, I checkout e.g. origin/main. This can be checked out in many worktrees. I actually find it more ergonomic and did this before using worktrees: there are no extra steps in keeping a local main pointer up to date.
The detached head is what I meant with keeping it on the branch while not keeping it on the branch.
The complication comes from trying to stay current. With a regular worktree I could just pull, but now I have to remember the branch, fetch all and reset hard to the remembered branch.
Especially with the recent extension of STS release support from 18 to 24 months [1]. Previously, upgrading from an LTS version to the next major (STS) version meant the support window decreased by half a year, while now it would stay the same.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.
The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
On the face of it, it seems like you'd define paths and sweep profiles for the material to remove. Is the difficulty in defining the path of the reversing portion, where it's not a helix?
reply