Until I saw that diff I could not understand what it was... of course it is the numbering of the constraints, so that the same as in master is kept... I was not giving this much attention, but it is true, I am integrating this in my branch. Additionally I will be numbering them (forcing them to take the right number), so that it is clear that order matters.ulrich1a wrote:Here is a small patch to fix the constraint incompatibility to the master branch.
It is correct!! The rank of the gradient matrix is the amount of degrees of freedom removed by the constraintsDeepSOIC wrote: I have a more human-readable way to tell this: addConstraintXXX is supposed to remove exactly one degree of freedom. UI constraint "coincident" has to remove two degrees of freedom, so has two addConstraintXXX calls. Correct?
Conclustion: a tangent constraint must be a single new row into the matrix, since it removes only one degree of freedom.
Or no? More rows can be added if we introduce additional degrees of freedom.
I agree.DevJohan wrote:Numeric derivatives should be avoided whenever possible. And it is possible to get code that is much more efficient. A quartic equation has algebraic solutions you just have to choose the right one.
I will look at the code later. Just a clarification t is the "eccentric anomaly" as in: http://en.wikipedia.org/wiki/Eccentric_anomaly. I have not used theta because IMO it induces to error with the elevation angle of the point of the ellipse, which is not. Also in wikipedia, t was used.DevJohan wrote:I have actually done some computations these last couple of days to visualize the solutions. Assuming A is the major axis the following code produce the image of the theta-angle (named t by abdullah I think) of the closest point on the ellipse.
Please, folks, stop referring to the 600 kb. That was only a test in full cartesian. When I wrote that, it was only to illustrate how "complex" this can get in full cartesian non-parametric. No part of the code of any branch of my repository has a 600 kb partial, and no gcc compilers were killed in the testsDevJohan wrote:Getting the partials from this code is quite straightforward and doesn't require 600kb of code.
I think it is a possibility. If we do not manage to get better, it may be the solution. If we manage to get better, it is an overcomplicated solution...DeepSOIC wrote:This is brilliant! Here's how I see it:DevJohan wrote:To avoid the solution jumping from one point on the ellipse and circle to another point on the ellipse and circle I think some kind of extra data is required. An intermediate line is one possibility where you constrain one end of the line to the ellipse and circle curves and add tangency constraints ellipse-line and circle-line.
This tangency point does not necessarily have to be visible, but it can be quite useful if it is.
A user selects two curves and a point and hits "tangent" button (if no point is supplied, one is created).
The point is constrained onto two objects (two point-on-object constraints, already done). And the final constraint uses the point in calculation of a new, much simpler error function, assuming that the point is the point of tangency. I can take care for making such function, for line, circle and possibly even second ellipse, I feel it's easy! It's just calculating tangent vectors to the curves at the point and F=length of vector product of those two vectors.
If the user deletes the point, it will automatically kill the constraint since it will be associated with the constraint.
What do you think?
It makes a lot of sense.marktaff wrote: Any point or equation can be translated back and forth between coord systems; my approach would be to use whatever coord system was easiest for the task at hand.
We will have a way to represent the foci in the UI, like, for sure. It won't be basic subelement of the ellipse (like the center), but it will be possible to constrain one or both foci, as needed.marktaff wrote:I will say that I would find constraint(s) on F to be very useful (the focus of my parabolic reflector must be 'here' relative to this feature).
Probably having no knowledge of the FC codebase is at this stage an advantage for this discussion, as you are not limited by possible coding constraints. I very much appreciate you introducing us to the perifocal equations. I am quite sure it will change our approach to the maths. Your comments are very much welcome.marktaff wrote:Anyhow, like I said, I still have no knowledge of the FC codebase yet, I was just wondering about the approach being taken with the math here.
So your proposal:DeepSOIC wrote: So, my suggestion is to internally represent ellipse, as well as any conic by:
1. vector to a focus point F1, which defines the position of the conic as a whole
2. vector from F1 to point A (as denoted by d1 on picture, but a vector value). The vector portion of this value sets the orientation of the ellipse, while its length, coupled with...
3. ...the eccentricity e (any positive value) defines the size and shape of the ellipse,
UI staff is a totally separate topic. One way or the other, at the end, the user will have accessible anything that can reasonably be expected. Right now I am most insterested in a solver representation that does not produce convergence problems and that is stable (does not jump to the sides when dragging it). It seems that a source of those problems is when one of the parameters is an angle (I have seen that at the end of the convergence it is not strange to arrive to things like 1000 radians). So it keeps rolling while converging. This is IMHO unwanted behaviour and should be out (and I thank again Ulrich for pointing this out).DeepSOIC wrote:From the user's point of view, this is not acceptable (i.e. if we expose only points A and F1 - no access to the center of ellipse), so UI stuff needs to be tailored separately for each conic case. But at least this approach will hopefully keep the math consistent and unified.
What do you think?
[/quote]DeepSOIC wrote:BTW. Shame, but I have never looked into sketcher code. I just help with math here, but for some stupid reason I also insist on ways to implement stuff