Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple Constraint/Relation API #193

Open
pca006132 opened this issue Sep 4, 2022 · 10 comments
Open

Simple Constraint/Relation API #193

pca006132 opened this issue Sep 4, 2022 · 10 comments
Labels
enhancement New feature or request

Comments

@pca006132
Copy link
Collaborator

A simple relation API might serve as an alternative to translate and rotate. For example, one may specify two circles of two different meshes to be concentric with other additional constraints. As the intention of this is to substitute things like translate and rotate, we don't need to store the relations, i.e. we only compute the required transformation immediately and apply it. If the set of constraints do not yield a unique solution, we can give any valid solution or return an error (when the user expects to fully define the object). The problem is that future transformations may violate old constraints.

The API I'm thinking about is something like this:

a_tran = place([a]).such_that([a.hole1.concentric(b.hole1)])[0]

where the place([a]) specifies the objects we want to move (a in this case), and the such_that clause specifies the set of constraints. The function will return a list of rigid transformations, or return an error if there is no solution.

@pca006132 pca006132 added the enhancement New feature or request label Sep 4, 2022
@pentacular
Copy link

It sounds technically interesting, but I think I'd start by considering the kinds of problem you see this approach solving, and the potential impact.

@pca006132
Copy link
Collaborator Author

The idea is to add some simple constraint solving without making the system too complicated (#118). This also keeps the reasoning local, previous constraints will not affect future operations. The use case for this (only considering rigid transformation) is mainly for assembly and making joints, which I have to calculate the required transformation manually.

@elalish
Copy link
Owner

elalish commented Sep 4, 2022

I'm not sure there's such thing as "simple" constraint solving; it's all pretty nonlinear and commonly results in no solution. This is the basis of any CAD program, but they mostly get around this by giving immediate UX feedback when the solution doesn't exist so it can be immediately fixed by the user. I'm not sure how to make it work in a "headless" library like manifold. I think this is why @rsaccon suggested integrating an existing constraint engine, probably along with a UI.

Basically, is there an advantage to having a constraint engine integrated into our internals, over just having one above us handing down the appropriate transforms? I'd still love to work on it though - now that the manifold library is looking pretty stable I'd love to play with building higher-level and user-facing abstractions on top. Especially now that we have a WASM build, it would be great to link up with other JS projects to build some powerful web apps.

@pca006132
Copy link
Collaborator Author

is there an advantage to having a constraint engine integrated into our internals, over just having one above us handing down the appropriate transforms

Probably no. The idea of this issue is to compute the transform by solving a simple linear system, but perhaps this is a bit too naive.

I am interestes in linking up with other JS projects, do you know if there is any JS projects that does constraint solving?

@pentacular
Copy link

I'm interested in the use-cases for automatic constraint solving for code-based systems.

I think that the main challenge here is that a shift from sufficiently to insufficiently constrained system may come from potentially very many, potentially quite remote changes to a system, making parametric design much less reliable, and generally would force significant over-constraint.

So I've been working on simpler approaches, such as generating a hinge assembly along a geometric edge of an existing shape, or placing one object at a specific position in the local frame of reference of another so that they mate correctly.

I'd try to come up with 4-5 examples of problems that you think would be best solved by the proposed constraint resolution system.

@pca006132
Copy link
Collaborator Author

So I've been working on simpler approaches, such as generating a hinge assembly along a geometric edge of an existing shape, or placing one object at a specific position in the local frame of reference of another so that they mate correctly.

Yeah, I'm thinking about something similar to this, ideally users can use this to mate parts with minimal constraint rules.

@pentacular
Copy link

Note that this doesn't involve any constraint solution -- just the ability to organize things with respect to one another.

So I'd think more about the problems that do require constraint solution. :)

@NodeGuy
Copy link
Contributor

NodeGuy commented Apr 2, 2023

I am interestes in linking up with other JS projects, do you know if there is any JS projects that does constraint solving?

Hey look at this: https://www.npmjs.com/package/slvs/v/3.1.0-dev.22

@elalish
Copy link
Owner

elalish commented Apr 3, 2023

@NodeGuy Cool! We can't incorporate them here since they're non-commercial, but others could certainly use these libraries together. Looks like their C code is more stable than the npm version too.

@fire
Copy link
Contributor

fire commented May 11, 2024

I had a lot of fun using Dag Amendment in Blender and with csg https://github.com/eliemichel/DagAmendment and it seems to approach it from a solver point of view. Might be a cool rainy day task to make it in a Manifold app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants