For those who model CAD models regularly, a pair of calipers is essential as it allows reasonably accurate measurements to fit a specific part. However, [Jason Harris] is taking that concept to the next level with a signed distance function-based CAD tool, SDFX.
For those who don’t know, Signed Distance Functions can tell you from a given point how close the nearest part of the model is. The model is represented as a single function that offers some exciting benefits. For instance, chamfering and fileting are often quite complex in traditional CAD programs and trivial in an SDF setting. SDFX is a golang library that allows you to write golang programs to describe the model. OpenSCAD is a favorite of Hackaday as it is a beautiful parametric code-first CAD package. But the syntax and language are somewhat cludgy, to say the best. The advantage of using golang rather than a DSL is that you can use all the niceties that a full-featured language brings. For example, you can export multiple objects, make network requests, and interface with GUI libraries to recreate something like the customizer for OpenSCAD.
Objects are rendered to STL using Marching squares. Then, they can be printed in whatever slicing software suits your fancy. It’s an excellent project with a great API and almost a hundred examples.
The code is available on GitHub under an MIT License.
I think it’d be better to link to the Github directly instead of the hackaday.io page; I just spent 5 mins looking for anything of substance on the .io page before resorting to Google. It was only after realising there was a Github that I twigged there was probably a link on the .io page.
Agreed, hackaday.io is an unpleasant mess, and in this case linking to it just discouraged me from looking at this interesting topic in more depth until Jake pointed out the GitHub page. Come on, just link to the project.
Imagine if either of you had tried actually reading the post, and saw the GitHub link at the bottom.
You don’t think that got edited in post-comment?
I often make mistakes but in this case, it was there when the article was published. I try to leave the GitHub at the bottom if applicable and point out the license.
Same here. I searched the project’s .io page for the Github link with zero results. Came back to this page.
Sort of surprised a project owner wouldn’t be making links to their stuff more clear.
So, as someone who knows nothing about Go I looked on there for a how-to for getting the thing up and going from scratch, nothing. Resorted to looking at some of the github code samples and thinking I’ll just stick with OpenSCAD.
Yikes, me too. This could make somethings like fillets “easier,” but at the cost of making everything much more difficult. The S in SCAD is Scripting… not Sobject-oriented-programming. That makefile is enough to keep me away as far as I can get. I HATE makefiles.
Hmm. It took me about 5 seconds of scrolling to see that big orange text of the Github address on the Hackaday.io page.
Odd that so many replied agreeing with you yet nobody posted that address here in the comments!
https://github.com/deadsy/sdfx
For god’s sake use sdf not sdfx
https://github.com/soypat/sdf
Project author has posted below that it _was_ an omission from the page, and has subsequently added it.
So not only could you not find the clearly indicated GitHub link on the IO page, but you couldn’t figure out where the “available on GitHub” link at the end of this post might take you?
Hate to tell you buddy, but I don’t think this site is the source of your problems.
The “clearly indicated” link on the IO page was not so clear when I posted, and the “available on GitHub” link is at the end of the article; the previously sparsely populated IO page is the first link. I posted a comment because, at the time, it was difficult to actually get to the project from the IO page. It was constructive criticism, and has since been agreed by many and addressed.
Suck it, Egotron.
Or, even better, one can use a eDSL on top of a full language with “all the niceties that a full-featured language”. Of course, hardly possible with Go, but very easy to do with better languages.
ImplicitCAD is a good example of the said approach.
The beauty of OpenSCAD is it’s simplicity. This sounds too complex. Something a SW programmer might come up with to guarantee job security.
Use the hull() method to make round objects from spheres and cylinders. Subtracting these objects creates fillets. Not as easy as selecting an edge in Inventor or F360 but you can make prettier objects in OpenSCAD with a little bit of effort.
OpenSCAD is too simple. It sacrifices too much in reusability and customizability. It tries too hard to be merely a descriptive language and not a programming language. It’s authors try to avoid scaring away the non-programmers. But if all one wants to do is describe a shape and they are not a programmer they are probably going to reach for a traditional mouse based CAD package anyway. The real beauty of using code comes when you view your goal as a program that generates objects based on the end-user’s input, not the final object itself. That and turning all your basic parts into re-usable libraries.
I could not disagree more. I guess I’m the ideal OpenSCAD user. I’m a self-taught programmer who likes the precise nature of typing in exact dimensions without having to do tons of clicks. OpenSCAD can make some relatively complex shapes in very little time. I can type cube(80); faster than anyone can make the same shape in any mouse clicking CAD. If you think OpenSCAD is too simple, maybe you just haven’t used it enough. I’d argue not having to add in error correction and a ton of includes is not sacrificing ANYthing. Certainly, not needing a freakin make file is a HUGE positive point for ANY programming language. Parametric parts is the raison d’etre for OpenSCAD. No on can force you to use variables and modules, but if you do, everything you make becomes a re-usable library without a ton of verbose garbage.
Some languages really are too verbose with their mile long namespaces but there is a lot of space between that and what little OpenSCAD provides.
And seriously, you don’t see any space between OpenSCAD’s level of simplification and writing make files? Is your water always either frozen or boiling?
Libraries become useless as soon as one wants to include libraries from multiple sources. All the modules definitions are in the global scope! Unless every module is named “my rediculous long library name”_common task_name() They are going to conflict!
Just adding basic classes and objects would be great. LibraryAName.rounded_cube() LibraryB.bezier() sounds great!
And all the repeat execution.. for example you have to draw “fastener(size)” over and over repeating all the dimension calculations and lookups that go on inside. Wouldn’t it be nice to say “bolt chassis_bolt = new bolt(bolt_size)”, have all calculations and lookups in the constructor then just call chassis_bolt.draw() in 100 places?
You mention variables but OpenSCAD doesn’t really have those, just constants and let{}. Imagine if it did! Some sort of collection could be implemented. What would you use that for? How about every time that bolt.draw() I mentioned gets called it also adds itself to a bom collection. Then at the end it echos a nice list!
You like the configurator. Me too. I wish it could be more dynamic though. Imagine selecting fastener size from a drop down. “M3, M4, #6, #8” but then the last option is “custom” select that one and a whole series of controls pop into existence; shaft, head, nut diameters, etc…
Ok, making one code a configurator screen every time would be too much complication. How about if OpenSCAD generated it’s own, static configurator the same as now but internally it was implemented as html. Then some magic variable could optionally be set by the programmer to a string containing html and JavaScript that would override it?
Here’s another project with a similar approach: https://libfive.com/
libfive can’t import STL or any other format.
Okay… So I set up that project page some time ago, and it’s been crickets but I guess It’s had a few more views in the last 24 hours.
So:
1) github link – sorry I’ve edited the project page to make it more obvious.
2) running go programs – yes, it’s not a go tutorial – but those are easy to find.
3) sdfx vs openscad – I’d claim that golang is a better language than openscad, and I think I have better rendering times for non text objects. The suprise to me was that I could recreate the functions of openscad with relatively little code by using signed distance fields.
I searched the original .io page for ‘github’ and got zero results. It wasn’t just less obvious, would I be right in saying it just wasn’t there at all. Anyway, a moot point now.
A tutorial or How-to would go a long way to garnering more interest in your work. If it’s all command line driven then a snippet code block of the commands scripted would be very useful.
Also a ‘Hello World’ example would twig people as being the simplest SDFX sample to start looking at.
Use SDF instead of SDFX FTW!
https://github.com/soypat/sdf
I can’t imagine any worse language for describing a part – perhaps assembly.
If you like the idea of OpenScad’s workflow with a proper language, it’s also worth looking into CadQuery and its Build123d library.
Edit in VS Code, run the CadQuery server in the background, render in a browser in a VS Code tab. It works nicely. Build123d is still under active development, so it’s a bit of a moving target, but it’s already quite usable and getting more refined over time. I’m a fan.
For those who prefer a more pythonic thing, I bring you a simple – with battery viewer included: https://github.com/juju2013/SDFIDE