For what it's worth I've been using FreeCad 1.1RC2 lately, and for me it's the first FreeCad version worth bothering with. It's now a tool I actively reach for over OpenSCAD and Blender for various projects. Previously I couldn't make the simplest part with it.
I can't wait for the release proper, but I can heartily recommend everyone try the release candidates as well. I've got a feeling this is the tipping point for FreeCad like 2.5 was for blender.
I mean I'll be honest, it's still a car crash of a program, but at least it's now a usable car crash. I've found the following workflow to be pretty good, using the part design workbench:
- create a part
- create a body
- create a sketch
- pad/pocket/revolve/etc
- repeat with additional sketches to taste
I've also been using the proxy object thing, I forget the name, the button is a green blob, to "import" geometry from a master sketch into more specific sketches.
> I mean I'll be honest, it's still a car crash of a program
I'm glad you said that so I feel a little less mean...
I gave it another try but it still feels pretty dire. FPS is bad on a macbook pro with a 120Hz screen on simple models and sketches. I explicitly selected "touchpad" as the navigation scheme, but I still can't figure out how to rotate, and even figuring out panning took me longer than almost every other 3D program out there (blender, PrusaSlicer, macos quick look STL viewer, solvespace).
It still has a splash screen and takes quite a long time to load, like an application from the 90s.
Buttons and actions that are completely irrelevant to me are shown, but disabled, which gives a really cluttered feel.
There's still "part design" and "part" benches. No idea what distinction is being drawn there.
Obviously part of this is from me being inexperienced with the tool, but as a new user all these issues add up to something that doesn't feel approachable or enjoyable to use.
Solvespace has its own issues, but at least it opens instantly and is generally a joy to use.
I'll watch some others slog through FreeCAD 1.1 though so I don't have to, and maybe I'll learn something.
You definitely need to use a mouse with a middle button/scroll wheel, IME. With this, there are presets which work just like other CAD programs e.g. Solidworks. Without it, it’s very difficult to use, but that’s not unique to FreeCAD.
The base UI is quite bad but there are ways to improve it - either through settings and better organisation [0] or via plugins.
I’d suggest to watch a couple of tutorials specifically on 1.1 ([1] was my entry point) as every CAD program had quirks and frustrations at first. I’d say that for hobby-level creations, 1.1 now has ~80% of the usability of Solidworks, once you figure out how.
I’m not sure what’s going on with the performance on your system; I’ve used various 1.1 versions on a Windows laptop and a MacBook Pro and they’re both sufficiently performant. (I usually use a development or RC build from GitHub [2])
Thanks for the links, especially [0]. That one was the most compelling for showing how an experienced user actually models a part. It's a shame that the UI defaults need to be tweaked so much to make things usable but I know there's no single UI that works for everyone.
> It still has a splash screen and takes quite a long time to load, like an application from the 90s.
The splash screen can be disabled and it takes 3 seconds to start on my mac. Fusion however has two splash screens (first a regular one, then one that covers the whole app window) and it takes 32 seconds to load! (to be fair, once loaded it's much better than FreeCAD).
Oh yeah, you won't find me defending Fusion. I can understand when you're loading a heavy scene or recomputing _everything_ in a complicated model, but I can't understand multi-second loading times and splash screens for loading...the start screen.
> It still has a splash screen and takes quite a long time to load, like an application from the 90s.
Lots of it is single-threaded, which is an endless frustration on a machine with umpteen cores. Especially frustrating given that it means compute happens on the UI thread.
The trouble with Solvespace is that using it quickly turns into randomly nudging points in hope to avoid kernel failures. Lately I have been using Dune 3D which uses much more reliable kernel.
Thanks, I eventually discovered it after a ton of trial and error. It's a shame though because the whole point of a touchpad is multitouch gestures which actually make navigating CAD applications pretty nice. I'll use a touchpad or a combination of touchpad and mouse in other apps like KiCad and it works quite well. Seems to me like all these open source programs should be stealing/sharing the best implementations of some of these basic things like 2D/3D input controls with each other.
No, because the former definition is still something you can rely on given a specific compiler and a specific machine. Hell a bunch of UB was pretty much universal anyway. Compilers would usually still emit sensible code for UB.
UB just ment "the spec doesn't define what happens". It didn't use to mean "the compiler can just decide to do any wild thing if your program touches UB anywhere at anytime". Hell, with the modern definition UB can aparantly time travel. you don't even need to execute UB code for it to start doing weird shit in some cases.
UB went from "whatever happens when your compiler/hardware runs this is what happens" to "Once a program contains UB the compiler doesn't need to conform to the rest of the spec anymore."
>the former definition is still something you can rely on given a specific compiler and a specific machine.
>UB just ment "the spec doesn't define what happens"
What comes to mind is that then the written code is operating on a subspec, one that is probably undocumented and maybe even unintended by the specifics of that version and platform.
It sounds like it could create a ton of issues, from code that can’t be ported to difficulty in other person grokking the undocumented behavior that is being used.
In this regard, as someone that could potentially inherit this code I’d actually want the compiler to stop this potential behavior. Am I missing something? Is the spec not functional enough on its own to rely just on that?
int handle_untrusted_numbers(int a, int b) {
if (a < 0) return ERROR_EXPECTED_NON_NEGATIVE;
if (b < 0) return ERROR_EXPECTED_NON_NEGATIVE;
int sum = a + b;
if (sum < 0) {
return ERROR_INTEGER_OVERFLOW;
}
return do_something_important_with(sum);
}
Every computer you will ever use has two's complement for signed integers, and the standard recently recognized and codified this fact. However, the UB fanatics (heretics) insisted that not allowing signed overflow is an important opportunity for optimizations, so that last if-statement can be deleted by the compiler and your code quietly doesn't check for overflow any more.
There are plenty more examples, but I think this is one of the simplest.
I'm not opposed to compilers erroring out on UB. But that's not what happens. Instead of choosing to either proceed and hope all is well, or choosing to stop and error out, compilers instead take the secret third option of breaking your code even more and telling no one.
One thing you need to add is that UB can be incredibly subtle and almost impossible to spot even by people with decades of programming experience. However, the compiler - and we're talking almost exclusively gcc here - will spot it and silently break your code. It won't warn "hey, I've spotted UB here!" even with every possible warning enabled, it will just quietly break your code without giving you any indication that it's done so.
It's some of the most user-hostile behavior I've ever encountered in an application.
It should be mentioned that as far as I can tell pretty much no one is selling pure PLA filament. They all have additives, so who knows what the actual glass transition temperature is for any random given filament. This has been true for a while too. Pure PLA has some properly awful properties, among which is it having pretty much no elastic deformation. Any amount of force will introduce microscopic cracks. The various additives reduce these kinds of issues and are therefore not really optional.
Roughly no one already says GSM. When talking about paper you'll hear people say things like "That's a sheet of 120 gram"
GSM basically only ever appears in print. If someone DOES ask "what does 120 gram mean here?" the clarification is going to be "Oh that's grams per square meter" and not "Oh that's gee es em"
I should mention GSM is also probably an americanism. I'm in the EU and out of the five packs of different kinds of art paper four are labeled in g/m2, and one has no labeled weight at all. None of them are marked in GSM as that abbreviation only works in english, while g/m2 works in all languages.
In the UK, "gee es em" was the usual term I heard at the local paper merchants when I was a regular customer in the late 90s - early 2000s.
Of the four reams of paper/card I have at home, two are labelled in "gsm", one is "g.m⁻²", and one uses both "g/m²" and "gsm" in different places. Weirdly, it seems that the specialist stuff is more likely to use "gsm" than the everyday 80 g/m² A4.
> Doing anything usually involves prep work. Want to take a step? First put on your shoes (literally or figuratively, depending). If your attempted habit is 70% prep, your brain will somewhat rightfully conclude "this is stupid" fairly quickly.
Note that this is also something that can be weaponized. Recently I've learned to draw and I found I kept having great difficulty just starting. To get over that I made the agreement with myself that at least once every two days, I would grab a pencil and page through my sketchbook. I'd find myself on the first blank page holding a pencil.
Turns out your brain thinking prep work without actual work is stupid really helps here. Once you've tricked yourself into doing the prep work, you might as well do the work-work.
e.g. for distance running: just make the deal with yourself that putting on your running clothes/shoes/etc and taking one step outside counts as having ran that day. You'll find yourself going for a run anyways once you get outside, because you might as well.
> "Just do X every day for [long time period]" has an inherent falsification problem
Very true, but unfortunately a lot of things worth doing require that sort of investment. When learning to draw I hated every single second for the first ~two months or so. And then like a switch getting flipped I started having fun.
> You can actually make steps so small that they're useless.
You should take the biggest steps you can actually keep yourself to. Maybe that leads to steps that are sub-optimally small, but taking useless steps is still doing more than taking no steps.
> Doing something daily for a long time is extremely hard to achieve
Oh for real, especially once you factor in force majeure. Hence why I went with "draw at least once every two days". That gives you wiggle room to plan around life events.
Turns out building habits is incredibly hard and no amount of seeking advise will do it for you. It's a slog and you gotta overcome that yourself one way or another.
I can't wait for the release proper, but I can heartily recommend everyone try the release candidates as well. I've got a feeling this is the tipping point for FreeCad like 2.5 was for blender.
reply