2 ms·
A thing that can understand "sphere of radius R has its bottom at center of box.top" is exactly a constraint solver, so I'm not sure what you mean by saying it'
by dTal 5y ago
A thing that can understand "sphere of radius R has its bottom at center of box.top" is exactly a constraint solver, so I'm not sure what you mean by saying it's not necessary for that to work. You have constrained R, and the location of a particular point, and the free parameter - the center point of the sphere - must be calculated from those constraints. And if you don't want the sphere to be exactly in the center? Suddenly you have only constrained 1 out of the 3 axes of the centerpoint, and will need additional constraints to disambiguate the shape. Or what if you want to fix the centerpoint and have the radius vary?
- _flux 5y agoBoth objects would have certain fixed hook points, such as bottom/right/center/etc and then the equation is as equality of exactly two of those points (new points could be derived from the existing ones, to express "1 mm Z from top"). So yes it is a constraint solver, but a very simple one, as you can constrain only one parameter, but all others would need to be provided; I meant R to be such a provided value (can of course be a parameter to the function creating the object). Perhaps you could also implement is in a way that R can be provided but expect the code to provide all others. A more general solver would be nice, but they don't seem trouble-free either. But sure, the syntax could be geared towards future development of such a solver. Maybe there could be a particular syntax for invoking such a solver that would fit well with the existing system, e.g. an "object" that only has hook points that could be constrained in various manners, and then actual objects would use them as input coordinates.