this post was submitted on 19 Nov 2024
436 points (99.5% liked)

Open Source

31292 readers
398 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 1 day ago (1 children)

No. The people who struggle with FreeCAD struggle because they leaned something else first. Its the same reason Photoshop trained users complain about GIMP while people who learned GIMP first dont complain.

Learn FreeCAD first, and you won't be handicapped

[–] [email protected] 1 points 1 day ago (1 children)

They struggle with FeeCAD for the same reason they struggle with ANY little change in software-- they simply don't want to be bothered to learn something new. It's called being lazy.

[–] KingRandomGuy 1 points 2 hours ago (1 children)

I think that's a little unfair. The bigger issue IMO is that FreeCAD doesn't quite share the same workflow as other (proprierary) CAD packages, so someone coming from proprietary CAD also needs to unlearn habits that were previously fine but now potentially harmful. For example, adding chamfers and fillets in FreeCAD pretty much should only be done at the end to avoid toponaming issues, which is less of an issue in other packages.

[–] [email protected] 1 points 1 hour ago

No it's not. Unlearning old habits and thought processes is always the first step in learning new things. But to be fair, it's also the most difficult part.

While other CAD packages do have a better failure path to follow, they still can fail at the same points as FreeCAD. And you still really should be following best practices for ANY CAD package to avoid failures. But people are nothing if not lazy. And fillets and chamfers just suck in any CAD package. It's always been my practice to never add them until I was done with the modeling. And if major changes where needed, I would remove them if I suspected they could even remotely cause an issue during a change to a model.