On TheTom’s llama-cpp fork, TurboQuant makes inference about five to ten times slower than vanilla (M1 Max, qwen3.6-35b-a3b). Seems like the productionization is still a ways away. Excited to see what we can get it down to though.
Do you have any MDM profiles installed? Go to Settings → General → VPN And Device Management. If you use your phone for work your employer may have asked you to install one, but check anyway. MDM profiles can specify apps to be installed automatically.
OpenSCAD is all triangles and vertices. Fillets are difficult to do. Outputting circles/spheres generally requires you to for-loop over vertices a lot.
Libraries like build123d and cadquery use OpenCASCADE, a boundary representation kernel. You think in terms of the enclosed solid and perform operations - boolean add/subtract, fillet/chamfer, stamp text, etc - that return a new solid.
I'm not sure I understand your comment; OpenSCAD has functions like sphere(), cylinder(), etc. Most OpenSCAD models I have seen are built up primarily from solid primitives combined using boolean operations, just as you describe for the other tools.
OpenSCAD works natively with triangle meshes. sphere() will create a spherical triangle mesh.
These libraries on the other hand can natively represent a sphere for instance. This means that during CAD-ing you don't need to worry about resolution, that's a consideration for export only.
Do you mean that OpenScad performs boolean/other operations on triangle meshes, but these libraries don't until output? So they might instead use curved surfaces/edges etc as outputs for operations and only convert to triangles for output or export at the very end?
It isn't even necessary to create triangle meshes during export. You can export as step files. It is a commonly used brep based file format supported by almost any "proper" CAD software. Triangle mesh based modelers can't easily export good step files because they don't operate at that level of abstraction.
In professional CAD systems, geometry is not stored as triangle meshes but as mathematically defined surfaces (such as parametric and NURBS surfaces).
Triangle meshes are only generated as approximations for rendering.
This is analogous to vector graphics (SVG/EPS) versus raster images (PNG/JPG).
Any serious manufacturing will work require a STEP (or something equivalent) which stores these parametric surfaces rather than a mesh.
1. put a sphere and a torus somewhat close to each other
2. find the shortest segment between the two surfaces
3. place an infinite cylinder whose axis is aligned with the segment you just found
4. fillet the cylinder with both the torus and the sphere along its intersection curve with each surface
While true your argument is weak, for example in pov-ray the shapes are pure exact mathematical concepts. But nobody is saying how great this is for 3d printing or general cad work because it's not. The real key benefit from these programs is the interchange format they can generate, something you can feed to a machine, this prevents it from ending up like pov-ray, a terminal process only fit for generating pictures. Fillets are difficult to do in openscsd because fillets are difficult to do in general. What your argument probably should have been is that if openscad had chosen a geometry kernel where fillets were already solved it could then do fillets. Which is the sort of obvious tautology that helps no one.
Now I am off to see if anyone has ever built an export plugin for pov-sdl, either a 3d rasterizer(g-code slicer) for 3d printing, or a boundary layer mesh generator for import into another program. language wise it is probably equivalent to or better than the openscad sdl,
One subtle advantage to using python as the sdl is that it gets access to the vast corpus of python modules out there. Most of which are probably useless. but one thing I want to try is to see if I can use sympy to define a more declarative style of constraint.
I recently used their sister library (build123d, same devs) to build a rotary slide rule bracelet for multiplying three-digit numbers. It was a great experience and wouldn't generally be easy to do with Fusion 360. My bracelet gets quite a lot of comments when I wear it in public. :-)
Nice model, but also a great notebook. Really like this "literal coding" style for CAD in a notebook. I still sometimes prefer GUI cad for simple stuff, CadQuery is not always that easy to write. But when iterating over something complicated, the notebook style development is really nice. And being to compose a model using functions and iterators instead of the clumsy GUI workflows is a godsend. Also time I tried Opus was more helpful and capable than I would have thought. Not good enough to one-shot yet, but it is very helpful nonetheless
Thanks for this! It's really fun. My older kid now has a vanilla sliderule bracelet. The younger is getting a smaller bracelet of the same design, but with dragons on it :-)
Happy to share source if you like, but it was nothing complicated:
- ask aistudio.google.com to draw a bunch of dragons
- trace one to svg
- make the bracelet a little smaller
Sure but like, that is specifically NOT easier if you need to iterate once initial implementation is complete. At least in my opinion as an industrial designer turned software engineer, which I only mention to assert I’m experienced in both sets of tools.
True, the logarithmic scale lends itself to programmatic creation. I just wanted to show that the wrapping part is easy. Actually much easier – that code looks non-trivial.
Are you asking how the bracelet multiplies two numbers? It's the same idea used by slide rules -- you take the logarithm of the two numbers, then add the logarithms instead of multiplying -- same result, with somewhat less accuracy depending on available decimal places.
This method was widely used in the pre-computer era to save time in calculations. Tables of logarithms (and slide rules) were a mathematician's best friend.
Think of it this way: the current change is like a staging area/index in git. Leave it without a a description while you're working (just like git's staging area). Rely on jj's auto-snapshotting to capture all your changes. Then, when you're ready to do something else, give it a description ("jj describe") and switch to a new blank change ("jj new"), and that becomes your new "staging area"/index.
reply