Hacker News
points by WillAdams 1 day ago | 0 comments
The thing is, there are already some notable projects:

- FreeCAD --- exactly what it says on the tin, and making huge improvements, so that I am quite hopeful of 26.3

- SolveSpace --- surprisingly capable/nimble/lightweight

- Dune 3D --- the new kid on the block, it is quite workable, and has quite good documentation: https://docs.dune3d.org/en/latest/simple-part.html

(and for the hardcore programmers there are OpenSCAD and derivatives such as PythonSCAD)

Wouldn't the compute from the tokens for these projects be better used improving existing projects? (there are more of these new 3D CAD tools than I can count: Cadivari, Layerling, OpenSketch, &c.)

[–] YuechenLi 1 day ago
FreeCAD and Dune3D are both OpenCascade based, so they are limited by OpenCascade's architecture (For example, OpenCascade uses per-entity tolerances, which means it is more bad geometry import tolerant, but if every face and edge has its own tolerance value in the kernel representation, then it creates a great amount of hidden tolerance drift.)

SolveSpace is still fairly limited on what it can do in terms of features such as fillet/chamfers, so it's not really suitable for pro work right now

For projects like SolidCraft, the SMLib kernel they are currently porting to Rust from Nvidia is currently about a decade behind OpenCascade, nevermind Parasolid/ACIS as they are still converting all geometry to NURBS instead of preserving analytical geometry, which means that their initial development is easier but it creates a near infinite amount of edge cases once they start going heavy into booleans and fillet/chamfers.

[–] tixylix 1 day ago
> the SMLib kernel they are currently porting to Rust from Nvidia is currently about a decade behind OpenCascade, nevermind Parasolid/ACIS as they are still converting all geometry to NURBS instead of preserving analytical geometry , which means that their initial development is easier but it creates a near infinite amount of edge cases once they start going heavy into booleans and fillet/chamfers.

Where are you getting this information from? Booleans and fillets at least use analytic geometry:

Analytic fillets:

https://gitlab-master.nvidia.com/omniverse/solidmodeling/-/b...

Analytic surface intersection (example of sphere/cone) used by booleans:

https://gitlab-master.nvidia.com/omniverse/solidmodeling/-/b...

[–] YuechenLi 1 day ago
Ok, I think I oversimplified it too much previously, the more accurate way to word the difference is that in OCCT/ACIS/Parasolid, NURBS and analytical surfaces are separate entities altogether, whereas SMLib, due to its heritage, uses NURBS as the underlying representation of everything and only use analytical surfaces as shortcuts, and even their analytical surfaces are built on top of NURBS.
[–] aothms 1 day ago
Can't comment on the fillet/chamfers but for boolean operations I didn't find it to be a decade behind at all https://github.com/IfcOpenShell/IfcOpenShell/pull/9958
[–] YuechenLi 1 day ago
Hmmm. Have you tested the hard case, surface/surface intersections between cylinders yet?

For your application in IFC, the architecture difference between OpenCascade and SMLib doesn't matter as much, but a geometric modeling kernel for mechanical CAD has much stricter requirements in terms of geometric correctness, which is the reason that Rhino, despite being BRep and widely used in architecture, isn't used very much in mechanical CAD at all.

[–] aothms 1 day ago
I agree, and I haven't tested more. Fully agree on the differences with true mcad and most implementations for IFC viewing aren't even BRep based, but mesh / polyhedral.
[–] WillAdams 1 day ago
Does Moment of Inspiration have that same lack of suitability? (I've long meant to try it)
[–] YuechenLi 1 day ago
MoL seems to be more of a Rhino alternative than it is a mCAD application, so, yes, the architecture that makes it good for freeform surface modeling is what makes it less good for mechanical engineering applications.