Extrude tool

Today I started working on the extrude tool, which will be affecting all the closed shapes on a sketch:



For now this works only on rectangles, so the next step is to make it work on all the closed shapes in a sketch.

Trimming tests

Today I cleaned up the trimming code and added tests for the new trimming algorithm, checking that the resulting shapes are what's expected for the four 'known' shapes:
- line
- circle
- SER arc
- CSE arc

The changes are here

Trimming ellipses

For now trimming an ellipse creates a generic wire, because we haven't implemented ellipse arcs (yet). The resulting wire can be changed by moving the object that created the trim (the movement of the object triggers the original trim to be recalculated on the base ellipse and the wire to be re-drawn).



Next I'll update the unit tests, clean up the code and commit all the trimming tool changes.

Trimming a SER arc

For the SER arc trim we calculate the centre of the existing arc and then using this and the calculated intersection points we create one or two CSE arcs. In the video you can notice that the new arcs reference three points and can be edited like any CSE arc:

Trimming tool shapes

I've updated the trimming to remove not only the shape that was clicked, but also any points that were used by it and aren't referenced by another shape, and the tree view is updated now after each trimming action, to reflect the current shape list.

In the video you can see that the circles become arcs after the trim tool is used, and the Point nodes are added and then removed:



I've commited the hinter changes and what I have so far for the trim tool here.

Improvements for the trimming tool

Today I worked on improving the Trimming tool so that when we want to trim something, we only need to click on the wire to be deleted.
Until now, trimming created a new node that was a generic trimmed wire, regardless of the shape that was trimmed and how many resulting wires we had. That wire was defined by several u-values which are now transformed in points and used to build new nodes for the resulting shapes: trimmed lines always result in lines, circles and arcs result in arcs.



The lines changes were pretty easy, but things were a bit more complicated for circles and arcs. When trimming a circle, we need to know which one it is, the minor or the major arc, and that is determined by the position of the mouse click. There was also a special case caused by the way the circle's curve is stored: an auxiliary axis is used for each circle, with the origin in the center and the first and last point on its oX. When trimming on this axis, we need to make sure that the point on oX is associated with the u-values of 0 and 2*Pi.



CSE arcs can be drawn clockwise or counterclockwise, and this affects the u-values of the extremities. When drawing clockwise, the u-values corresponding to the start and end points have an extra 2*Pi added to them, while the intersection points and mouse click don't. This led to wrong intervals and caused strange arcs to be drawn.



I will continue working on the SER arcs, see what can be done to improve spline and ellipse trimming and update the trimming unit tests.

Update

Did some improvements on the hinter so instead of looking for solutions on the entire scene it uses the axes and the last selected shape. You can see in the video that the line isn't snapping to the line parallel to the rotated triangle until we pass over it. After that, hinter lines are shown for the line parallel to the rectangle, as well as the lines parallel to the axes.



We're still working on the installation problem: the issue is not caused by missing dlls, but by the way the occ wrappers and the way they are built.
We're also working on the trim to tool, to improve the way the parts to be trimmed are selected and to return known shapes instead of a generic shape for all trimmed wires.

Hinter changes

We're currently working on fixing the installer issues and updating the hinter to find a common point if there is more than one solution.

For the hinter, we need to show all the hinter lines for a certain position and then find the common point for all the lines in the area. The mouse point will snap to that position, as it does now for parallel or perpendicular lines:

NaroCAD 1.6.3 and 1.6.4 dll problems

There are some cases where versions 1.6.3 and 1.6.4 don't work because of some missing dlls. I'm investigating the issue and will update the installers as soon as I find the cause.

Released NaroCAD 1.6.4 Alpha

The big feature delivered on this new version is the Solver. The line tool uses a new Solver that started to work properly at an acceptable speed.
Replaced Rectangle tool with a rectangle having different constraints on it. The Solver can modify it now.
The new Solver supports: parallel, perpendicular, horizontal, vertical, point on  point and point on line constraints.
The new constraints are covered with unit tests, these can be used as coding samples.

You can download the new version here.

Next iteration the focus will be on improving the solver, making more fixes at the spline tool and if there is time maybe also enhance the trim tool. With these the 2D tools will be stabilized and we'll move on stabilizing the 3D ones.

Solver changes commited

I finished updating the constraint tests for the new solver and commited the changes. The current revision, which contains the solver changes and a few release fixes, is here.

Until all the constraints will be ported to the new structure, the old ones will remain and all the new classes will have an added 'Ref' to differentiate them from the old ones and the tests are only for the constraints that are currently implemented for the new solver:
- horizontal line
- vertical line
- parallel lines
- perpendicular lines
- point on point
- point on line

Aside from the constraints that I've showed here and here, the solver works on more complicated shapes:



Here we have three rectangles that have common corners. When one of the points is dragged, the constraints and related shapes lists are loaded - in this case, all the points are related to the point being dragged, but they are sorted according to their level and only the minimum number of points is changed.

Changes to the Solver

As I've mentioned in the previous post, the Solver used global objects to keep the references to the shapes that it was using in the solver method, updating them on the fly and sometimes leaving there NaN values.

I've modified the solver to use only the data that was passed in the parameters, fixing two issues this way: the points don't get to have NaN values for the coordinates and subsequent calls to Solve don't influence each other.

The new parameters list contains double values, which are the coordinates of the points and the constraints list contains the indexes in the parameters list, instead of actual values. Let's say we have two parallel lines, with the node indexes as shown:

The paramaters list will contain the coordinates for nodes 1,2,4 and 5:

parameters content: [ 3.0   6.0   1.0   1.0   8.0   5.0   5.0   0.0 ]
                    [ P1.x  P1.y  P2.x  P2.y  P4.x  P4.y  P5.x  P5.y]
indexes:            [  0     1     2     3     4     5     6     7  ]

The indexes will be used in the constraints list. To define that the line P1P2 is parallel to P4P5 we add a new constraint wich has two lines, defined by the point indexes:

L1 = new Line { P1 = new Point(0,1), P2 = new Point(2,3) }
L2 = new Line { P1 = new Point(4,5), P2 = new Point(6,7) }

When the constraint is calculated, the parameters list is passed - this makes it easier to debug and test the constraints code.

Using this structure, whenever the point position changes, the parameters value is changed, but the constraint stays the same and will always use the updated version of the coordinate.

If a solutions is found, the coordinates are automatically updated by updating the node, using an additional mapping between the parameters indexes and the shape index.

This new implementation replaces the old populate methods which were called for each free points number with one loading of the parameters and constraint build per action and doesn't require unmaping.

I'm testing this for parallel and perpendicular constraints on lines and updating the unit tests. As soon as I'm finished I'll commit the changes.

Solver issues

Over the last few days I've worked with the Solver and the helpers that are calling it from LineEditingHandler to get it to work correctly on several consecutive calls. For example, if we call the solver on a four line rectangle with two free points, we always get a solution. If we call it with no free points and immediately after that with 2 free points, we don't get a solution, because the global objects that are used to store the point references weren't properly re-initialized and no solution is found.

Re-initializing them for every call causes the solver to become too slow and there are some cases where the references are not properly updated, resulting in NaN values for the point coordinates.

I'm trying to change the Solver so that the global objects won't be changed and the results returned by it will be used to update the references only when a solution is found. This way the initializers wouldn't be called multiple times and we would avoid the NaN problem.