USER FORUM
(you are viewing a thread; or go back to list of threads)
2D/3D Different? (by Charles Bradshaw)
I have another technical problem.
I'm working with an old version of the python bindings to the 'exposed' version of solvespace. I have all constraints working correctly in 2D, but when I try to work in 3D there is some strange behaviour.
I have 2 arc constraints: SLVS_C_WHERE_DRAGGED constraining the centre point and SLVS_C_DIAMETER constraining the diameter. This works fine in 2D, both end points change to reflect the diameter constraint.
But the same in 3D only changes the start point when the diameter constraint is solved. Now obviously both start and end points must change.
My question is; 'am I doing something wrong when setting up my 3D system?',/ or is this expected behaviour? (possibley a phenomenon of the way arcs are drawn in the Solvespace app?)
My set-up is: work plane in group 1 and all other points in group 2. The work plane is defined with Quaternion = (1.0, 0, 0, 0) and my 3D geometry is on the XY plane, ie the Z components are 0.0 (all params 3d x y and z=0)
Thanks. Charles Bradshaw
I'm working with an old version of the python bindings to the 'exposed' version of solvespace. I have all constraints working correctly in 2D, but when I try to work in 3D there is some strange behaviour.
I have 2 arc constraints: SLVS_C_WHERE_DRAGGED constraining the centre point and SLVS_C_DIAMETER constraining the diameter. This works fine in 2D, both end points change to reflect the diameter constraint.
But the same in 3D only changes the start point when the diameter constraint is solved. Now obviously both start and end points must change.
My question is; 'am I doing something wrong when setting up my 3D system?',/ or is this expected behaviour? (possibley a phenomenon of the way arcs are drawn in the Solvespace app?)
My set-up is: work plane in group 1 and all other points in group 2. The work plane is defined with Quaternion = (1.0, 0, 0, 0) and my 3D geometry is on the XY plane, ie the Z components are 0.0 (all params 3d x y and z=0)
Thanks. Charles Bradshaw
(no subject) (by Andrew)
I don't use the python bindings, but will note that when in 2D the arc is constrained to a plane, while in 3D it is not. Therefor your 3D constraint need to define the plane on which the arc is drawn. That is in 2D the endpoints can move around the diameter, while in 3D the arc its self can rotate in 3d space, and contravening the center limits those rotation to axes through that point. Constraining one end in 3D as well, limits that rotation to the radius passing through that point.
Hope this helps you figure things out.
Hope this helps you figure things out.
2D/3D Different? (by Charles Bradshaw)
Andrew said: "note that when in 2D the arc is constrained to a plane, while in 3D it is not." also "Therefore your 3D constraint need to define the plane on which the arc is drawn." Well of course, A solvespace arc is defined by 3 points which by definition must lie in a plane.
After a diameter solve, at the very least the following must be true:
First, the arc defining points are on a common plane.
Second, the linear distance (radius) at the start and end points are equal.
The second is NOT true in my 3D example. This must be an initialisation, or some subtle SWIG problem. Assuming, that is, there is no bug in Jonathans 2013 code.
After a diameter solve, at the very least the following must be true:
First, the arc defining points are on a common plane.
Second, the linear distance (radius) at the start and end points are equal.
The second is NOT true in my 3D example. This must be an initialisation, or some subtle SWIG problem. Assuming, that is, there is no bug in Jonathans 2013 code.
(no subject) (by Andrew)
>A solvespace arc is defined by 3 points which by definition must lie in a plane.
Except for the edge case where all three lie on the same diameter. Also, if any of the points have a degree of freedom other than along the arc, the plane can tilted by movement of those points..
My approach to 2d dimension figures in 3d space would be to define the plane on which to draw the figures, and the draw in 2d on that plane.
Except for the edge case where all three lie on the same diameter. Also, if any of the points have a degree of freedom other than along the arc, the plane can tilted by movement of those points..
My approach to 2d dimension figures in 3d space would be to define the plane on which to draw the figures, and the draw in 2d on that plane.
2D/3D Different? (by Charles Bradshaw)
"Except for the edge case where all three lie on the same diameter. Also, if any of the points have a degree of freedom other than along the arc, the plane can tilted by movement of those points." In that case, wouldn't you expect the Z components to reflect a tilted plane? Mine do not, the Z components remain zero.
As stated before the radii at the start and end ( as defined by | Pstart - Pcenter | and | Pend - Pcenter | are NOT equal. No matter if other constraints are applied or not.
As stated before the radii at the start and end ( as defined by | Pstart - Pcenter | and | Pend - Pcenter | are NOT equal. No matter if other constraints are applied or not.
(no subject) (by Andrew)
While I don't know the python interface, but I have one question, are you using a vector difference between the points, or an actual distance function. The vector difference will be different for non coincident point pairs. I read | Pstart - Pcenter | and | Pend - Pcenter | as vector differences, and they would not be equal.
Also I do think that defining a plane, and drawing a 2d arc on that plane is the best way to go, as defining the ends of the arc is usually much simpler than the 3d cases.
Also I do think that defining a plane, and drawing a 2d arc on that plane is the best way to go, as defining the ends of the arc is usually much simpler than the 3d cases.
2D/3D Different? (by Charles Bradshaw)
"as vector differences, and they would not be equal". Er.. obviously vector difference is a vector and radius vectors would be in different directions (except in the full circle case)
|V| is modulus of V, the scalar length of V. sqrt(x*x+y*y+z*z) In the case under discussion the radii at the start and end.
"Also I do think that defining a plane, and drawing a 2d arc on that plane is the best way to go, as defining the ends of the arc is usually much simpler than the 3d cases. " Not just much simpler but the only way in solvespace.
Yes I have already stated that I get correct results using 2D, however I want to know WHY the 3D case does not work.
The code difference in is almost trivial. Just using Slvs_MakePoint3d instead of Slvs_MakePoint2d to define parameters.
|V| is modulus of V, the scalar length of V. sqrt(x*x+y*y+z*z) In the case under discussion the radii at the start and end.
"Also I do think that defining a plane, and drawing a 2d arc on that plane is the best way to go, as defining the ends of the arc is usually much simpler than the 3d cases. " Not just much simpler but the only way in solvespace.
Yes I have already stated that I get correct results using 2D, however I want to know WHY the 3D case does not work.
The code difference in is almost trivial. Just using Slvs_MakePoint3d instead of Slvs_MakePoint2d to define parameters.
(no subject) (by Paul)
Is it possible that the point with incorrect radius is correct if it's using the point projected onto some plane? I'm not sure which plane.
Post a reply to this comment: