6 ms·

> That's the beauty of constraint-based parametric modeling as opposed to, say, modeling in Blender. I was thinking the same thing. This looks more like an API

> That's the beauty of constraint-based parametric modeling as opposed to, say, modeling in Blender. I was thinking the same thing. This looks more like an API that makes 3d modeling look closer to CAD, but without realizing that CAD is about constraints, parametrizing, and far more.

throwup238 8mo ago
> but without realizing that CAD is about constraints, parametrizing, and far more Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code, the MINPACK/SolveSpace test suite, and OpenCascade as an oracle. The hard part is a geometric kernel that can express boundary representations for complex shapes (sketches, chamfers, fillets, etc) and boolean operations while somewhat handling the topographical naming problem without driving the user insane (which existing kernels are still all shit at).
- cindyllm 8mo ago
  [dead]
- delusional 8mo ago
  > Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code You go ahead and try that.
  - throwup238 8mo ago
    ;) Keywords: Jacobian, Newton-Raphson, Levenberg-Marquardt, Powell dog leg, Schur complements, sparse QR/Cholesky, and so on. The LLM can figure the rest out. Try it yourself! I recommend Rust because the methods are old and most of the algorithms are already implemented by crates, you just have to wire them together. Like I said the hard part is the b-rep: you’re not going to find anything equivalent to Parasolid or ACIS in the literature or open source.
    - dymk 8mo ago
      Yeah but have you tried it? You can throw as many keywords as you want into Claude but it does get things wrong in sometimes subtle ways. I’ve tried it, I know.
    - imtringued 8mo ago
      Look, I'm not trying to decimate you here but your list of keywords is wrong and I know it because I explored that list last month for a completely different application. The Jacobian is the first order derivative for a function that accepts a vector as an input and produces a vector as an output, hence it must be a matrix. Newton-Raphson is an algorithm for finding the roots(=zeroes) of a function. Since the derivative of the minimum of a function is zero, it can be used for solving convex optimization problems. Levenberg-Marquardt is another way to solve optimization problems. The Powell dog leg method is new to me, but it is just an extension of Gauss-Newton which you could think of a special casing of Newton-Raphson where the objective function is quadratic (useful for objectives with vector norms aka distances between positions). Most of the algorithms require solving a linear system for finding the zero of the derivative. The Schur complement is a way to factor the linear system into a bunch of smaller linear systems and sparse QR/Cholesky are an implementation detail of solving linear systems. Now that we got the buzzwords out of the way I will tell you the problem with your buzzwords. Constraint solving algorithms are SAT or SMT based and generally not optimization based. Consider the humble circle constraint: a^2 + b^2 = c^2. If you have two circles with differing centers and radii, they may intersect and if they do, they will intersect at two points and this is readily apparent in the equations since c = sqrt(a^2 + b^2) has two solutions. This means you will need some sort of branching inside your algorithm and the optimization algorithms you listed are terrible at this.
      - tomcur 8mo ago
        Optimization can work well for interactive CAD usage, because geometric sketches tend to be close to the intended solution, and it's fast. It also has the nice property of stability (i.e., with optimization, small changes in parameters tend not to cause large perturbations in the solution). Doing more gets into what you mentioned, and is called chirality or root identification in the literature. That's much more intense computationally, but could be useful especially if cheaper approaches like optimization failed.
imtringued 8mo ago
This is something I don't get about the code-based CAD tools. They don't let you specify declarative geometric constraints. Constraints are useful beyond just designing parts. If you have a parallel mechanism there are only two ways to solve the kinematics/dynamics for it: Constraint solving for rigid contacts or iterative solving by approximating the model with non-rigid contacts via internal springs.
- WillAdams 8mo ago
  Could you mock up some code to describe which you feel would be suitable to describing such a thing?
tomcur 8mo ago
We've started a 2D geometric constraint solver at https://github.com/endoli/fiksi https://github.com/endoli/fiksi doing the constraint part of this in Rust. We're using it internally and so far it works well, though it's still experimental. More constraints and especially better behavior around failure are needed. The latter will likely entail at least doing more with degree of freedom counting, though there's some of that already. A C++-library to be aware of is SolveSpace's slvs: https://github.com/solvespace/solvespace/tree/e74c2eae54fdd981211f51021ac4592792e1f499/src/slvs https://github.com/solvespace/solvespace/tree/e74c2eae54fdd9....

throwup238 8mo ago

> but without realizing that CAD is about constraints, parametrizing, and far more Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code, the MINPACK/SolveSpace test suite, and OpenCascade as an oracle. The hard part is a geometric kernel that can express boundary representations for complex shapes (sketches, chamfers, fillets, etc) and boolean operations while somewhat handling the topographical naming problem without driving the user insane (which existing kernels are still all shit at).

cindyllm 8mo ago
[dead]
delusional 8mo ago
> Constraints and parametrizing are the trivial parts of CAD, something you can now implement in a weekend with Claude Code You go ahead and try that.
- throwup238 8mo ago
  ;) Keywords: Jacobian, Newton-Raphson, Levenberg-Marquardt, Powell dog leg, Schur complements, sparse QR/Cholesky, and so on. The LLM can figure the rest out. Try it yourself! I recommend Rust because the methods are old and most of the algorithms are already implemented by crates, you just have to wire them together. Like I said the hard part is the b-rep: you’re not going to find anything equivalent to Parasolid or ACIS in the literature or open source.
  - dymk 8mo ago
    Yeah but have you tried it? You can throw as many keywords as you want into Claude but it does get things wrong in sometimes subtle ways. I’ve tried it, I know.
  - imtringued 8mo ago
    Look, I'm not trying to decimate you here but your list of keywords is wrong and I know it because I explored that list last month for a completely different application. The Jacobian is the first order derivative for a function that accepts a vector as an input and produces a vector as an output, hence it must be a matrix. Newton-Raphson is an algorithm for finding the roots(=zeroes) of a function. Since the derivative of the minimum of a function is zero, it can be used for solving convex optimization problems. Levenberg-Marquardt is another way to solve optimization problems. The Powell dog leg method is new to me, but it is just an extension of Gauss-Newton which you could think of a special casing of Newton-Raphson where the objective function is quadratic (useful for objectives with vector norms aka distances between positions). Most of the algorithms require solving a linear system for finding the zero of the derivative. The Schur complement is a way to factor the linear system into a bunch of smaller linear systems and sparse QR/Cholesky are an implementation detail of solving linear systems. Now that we got the buzzwords out of the way I will tell you the problem with your buzzwords. Constraint solving algorithms are SAT or SMT based and generally not optimization based. Consider the humble circle constraint: a^2 + b^2 = c^2. If you have two circles with differing centers and radii, they may intersect and if they do, they will intersect at two points and this is readily apparent in the equations since c = sqrt(a^2 + b^2) has two solutions. This means you will need some sort of branching inside your algorithm and the optimization algorithms you listed are terrible at this.
    - tomcur 8mo ago
      Optimization can work well for interactive CAD usage, because geometric sketches tend to be close to the intended solution, and it's fast. It also has the nice property of stability (i.e., with optimization, small changes in parameters tend not to cause large perturbations in the solution). Doing more gets into what you mentioned, and is called chirality or root identification in the literature. That's much more intense computationally, but could be useful especially if cheaper approaches like optimization failed.

imtringued 8mo ago

This is something I don't get about the code-based CAD tools. They don't let you specify declarative geometric constraints. Constraints are useful beyond just designing parts. If you have a parallel mechanism there are only two ways to solve the kinematics/dynamics for it: Constraint solving for rigid contacts or iterative solving by approximating the model with non-rigid contacts via internal springs.

WillAdams 8mo ago
Could you mock up some code to describe which you feel would be suitable to describing such a thing?

tomcur 8mo ago

We've started a 2D geometric constraint solver at https://github.com/endoli/fiksi https://github.com/endoli/fiksi doing the constraint part of this in Rust. We're using it internally and so far it works well, though it's still experimental. More constraints and especially better behavior around failure are needed. The latter will likely entail at least doing more with degree of freedom counting, though there's some of that already. A C++-library to be aware of is SolveSpace's slvs: https://github.com/solvespace/solvespace/tree/e74c2eae54fdd981211f51021ac4592792e1f499/src/slvs https://github.com/solvespace/solvespace/tree/e74c2eae54fdd9....