Wednesday, 31 March 2010

Bug fixing

In the last two days started fixing bugs. Put back on working state the 2D, 3D shapes tools, Cut and Extrude. Fixed bugs related to duplicate shape drawing and shape intersection on these tools.

Modified the Rectangle tool to draw rectangles instead of parallelograms, not enabled yet the latest implementation as it has some functionality conflicts with the constraints code. Will finalize it tomorrow.

Remained to put back in working state the translate, offset, mirror tools, some fixes at spline.

Tuesday, 30 March 2010

Vertical Line and Horizontal Line Constraints

As a part of the improving the Solver component, the horizontal line and vertical line should make a more precise draw. Because of this the solver was extended to support this new two shapes. There are also a lot of fixes and crashes.

The constraints of vertical and horizontal lines are two way: meaning that the horizontal/vertical lines themselves can be constrained by other shape like middle of edge. In this way hopefully the draw will be more precise.

Trying to draw the custom shape that was put as a sketch I found a selection bug that makes that if you draw a circle on top of rectangle and no face-split occurs, it will make that the first selected shape will be the rectangle, not the circle, which most probable is not the desirable effect (you will likely want to select the latest shape, not the first defined one).

As of today I will fix more bugs that appeared in this rewrite/refactor but as of today is a close to complete code.
The supported constraints:
- start of edge (meaning a point from shape's dependencies)
- middle of edge
- vertical/horizontal line that is integrated with the solver
- middle of rectangle/rectangle 2p

Monday, 29 March 2010

Squashing Bugs in Solver

There were some bugs in solver as most of constraints that were added can create crashes (like the middle of edge creates internally a wire check that makes that things to work nice for a line, but not that nice for a rectangles). On the same manner there was fixed the crash when setting up an axis coordinate based on a point coordinate given the fact that an axis and a point3D are different shapes even they can work on the same initial location.
Middle of face (for rectangle and rectangle2p) was also seem to work right now.
A design limitation I want to get it right is to apply more constraints on the same node that a small fix was done, but the code was not yet commited as need more testing. Also horizontal line and vertical line are just one way integrated, meaning that those lines are registered in solver and they can follow points from lines (in general) but they are not constraining none of the generated geometry (yet).

Sunday, 28 March 2010

Middle Edge Solver Constraint, Fallback Code

Middle of edge is eventually here. Also the code closes to get shape to the final code. There are fixes on crashes (sometimes you will get recursive call on stack and crashes, hope to target this bug). Also I found a limitation on design that I will try to fix it as I wanted to align to horizontal line/vertical line and this cannot be done both in case if you want to put a point just on the both intersections (probably an extra solver type should be added, like there is a SolverPoint).

This new Solver functionality enable adding constraints that make sense (like end of a line, middle of an edge, I will add very soon: middle of rectangle, middle of rectangle2p - the 2D rectangle) but in a lot of other cases, those constraints are not that important: for instance in case of spline's points, or in cases that the code gets complex on adding a constraint that rarely is needed (middle of base of the pyramid!?). For those cases the old solver code was added nicely in the current design as a fallback code.

Friday, 26 March 2010

Solver Code Review

I worked to make the mid-edge constraint available which will depend of the SubShape code and I had some small problems but I will fix them tomorrow. Easier to be done will be middle of rectangle that I will also do it today. There are still some remaining missing functionality and I hope that everything will be done over this weekend.
There is also an UI concept that will expose the solver sensitivity in status-bar for easier setup using a slider. This work is done by our contributor Cristian. We don't know if this is the best way, but at least we explore this area.

Tuesday, 23 March 2010

Point to Point Constrains Setup from Solver

The solver component do automatically make possible to link lines with their points and dragging first line will drag all linked edges. This is an important design milestone because this rethinking makes the solver component to reach more information which is used for providing more useful hints. Also there is much fewer intervention from the developer standpoint (meaning the old pattern: add shape, solver.generateInterestingGeometry(..), solver.AddGeometry(intersting geometry); was removed as is not needed.

Solver's interesting geometry is based right now by it's function name and also is solved by a factory.
I will work to add more constraints (middle of edge for example, end of edge), add it for more shapes (the canonical ones, also for helper geometry like: horizontal line, vertical line). And at last, but not at least: to find and fix crashes and bugs that appear on this features.

Improvements on Solver's Logic

Solver code was previously an external component from both model code (document) and also from the view code. The solver also creates points that have no meaning that coordinate. Work was done to clean the duplicate code and to make constructions only once.

The design was extended and work (only on line for now) to add extra information in solver points (like: EndPoint and the point index). Today I will work that this extra points to be integrated in MetaActions so clicking on an end point will add automatically a constraint so moving a line by editing them will make that lines to propagate the constrained changes forward.

If I will finish this faster and no bugs I will create more constraints that apply for rectangles (as for now the solver will use a factory to build that custom constraints based on shape type). At the end I hope to create much faster the sketch by improving the sketch.

Monday, 22 March 2010

Finalized offset

Made the offset tool final code. It can be applied on Faces, the result is another Face type shape.
Couldn't find a trick when generating bigger shapes with offset to make the join type to be other than circle, or at least to be a circle with radius 0. The offseting seems to work well only when starting from the biggest shape to the smallest one.

Will move to finish other tasks and keep this one in stand by thinking on how this tool might be improved further.

Friday, 19 March 2010

Offset integrated to command line

Finished porting the offset to meta tools to integrate it with command line. Currently the offset is enabled to work only on 2D closed shapes.
Line offset will be made using copy-paste-translate, translate is also integrated with command line for higher translation precision.

Will improve the offset tool to generate Faces and also make automatic intersections with other faces. When offsetting a shape to generate a bigger shape the open cascade available algorithm rounds the corners, will look also into this issue.

Wednesday, 17 March 2010

Offset merging

Ported a first version of Offset to meta tools so that it integrates with command line.
Not finished porting because encountered some issues at the existing offset tools.

Currently Naro has an Offset 2D tool used to offset wires (a connection of more than one segment, it doesn't work for a simple line) the result is a shape drawn around the original wire and a 3D offset tool using the 3D offsetting algorithm from OpenCascade for solids that gives some strange results.

The plan before finishing the port to command line is to merge all offsetting tools under one tool that detects the particular case and applies the appropriate offset algorithm. The functionality will be slightly changed as follows:
- if offset is applied for one line it will duplicate the line at the offset distance that will be useful for building helper drawing lines - the mouse location will be used to detect the offsetting direction,
- if the offset is applied on a wire built from more than one segment the offset will duplicate the wire at the offset distance - not sure that this will be implemented,
- if offset will be applied on a face like for example a rectangle, an offset algorithm will be applied and the result will be a smaller/bigger rectangle not a translated rectangle like in the case of a line,
- if offset will be applied on a solid will see if some good and quick results can be obtained with the OpenCascade algorithm. Will analyze here if offset on solids is used in industry and remove the functionality if it is not useful.

Will think for a consistent solution for all these situations (for lines the result is a translation for faces and solids it is an offset shape).

Applying Offset on a wire made from more than one line, lines selected with shift+click, generates another problem: it is quite difficult to know when the users finished selecting and started offsetting.

Tuesday, 16 March 2010

Solver Frozen for Some Days

I will be away for some days for family.

Yesterday I've reviewed the Solver's code (as was named, the solver for now is the guidelines component instead a full solver component) as some changes are needed to make it more intelligent. The biggest change from Solver side is that it will be integrated with Command Line (and meta-actions). To make this possible I was need to make it Document-aware to know which shapes are in scene. The previous design was that shapes register to solver the current "magic" points.

The newer design I work on will be the following: the solver will know the scene the user is working on. When a change occur in scene the solver will evaluate the shape and will extract automatically the useful geometry. Making solver aware of what is in scene will make possible to attach (the straight forward) constraints based on the click place that are logical. For example when you create a circle in the center of a rectangle, you will mostly like to remain there. And when you will resize the rectangle, the circle to still remain attached to the same very center.

Yesterday I've changed a lot of code that propagates the SolverPoint/gp_Pnt to NaroCAD codebase as SolverPoint was a duplicate code that there. Also writing skeleton code how the solver will scan the scene to create automatically the magic geometry.

The next changes in this area will mostly appear around Saturday.

Monday, 15 March 2010

Translate integrated with command line

Ported the Translate tool to meta actions. Now it is fully integrated with the command line, translations can be made with higher precision. Added also a drawing animation that displays the translation length while translating.
Will look also at the Offset tool to integrate it with command line and improve it for drawing helper lines.

Lua improvement

Lua is improved, a real model built with it: