Wednesday, December 30, 2009

All actions will be moved to a state-machine as presented before. All simple actions that require an axis, Point3d or a double value (like a circle require an axis that's the plane is on and the center and a range) will work. The actions that do use face/shape picking mostly crash. The reason is that there is not a simple step way to decide which shape/face is selected in current's Naro framework.Those states will be exposed as command line with a similar with Lua scripting.

So for now are tested to work the next actions: Circle, Line, Rectangle. Working but crashing randomly are: Boolean operations, Cylinder, Cone. And with not (known) reason: Extrude.

Anyway: those actions are not exposed yet in a easy way for user so you will not be affected. Just if you want to enable the actions for now you have to explicitly activate via Control-Space.

Wednesday, December 23, 2009

Do you remember NewShapeModifier? NaroCAD's View framework is created around Modifiers (also named Actions) like: View Actions (Top, Left, Reset), Shape(circle, rectangle), Tools (Extrude, Cut, Boolean operations). NewShapeModifier was an action which starting from a specific function, creates an already made action. But because it tried to solve too many problems in a generic way, the code always was need some patching and was hard to use. The big advantage was also that it starts from the shape's definition (like a line will require two points, so the action will query first point, second point, and that's all).

Some of it's ideas were really nice, but they could not work nice as it was either: too generic or either too specific. Also, in the quest of solving a command line completion, the actions have no exposed granularity to be used interleaved command line values and mouse clicks.

For now there is an action that can be started with Control+Space and can be used just to test this actions.

Those actions are named for now MetaActions (I did not found another proper name).

Which are the big differences from the NewShapeModifer (NSM)?

- NSM creates a build action only from function names and are fixed. MetaActions (MA) are getting a dependency object to be filled in by action. If the action will want to use the function's name, it can do it right away. But after this it can customize the dependency like it can remove some unused steps.

-NSM do not let customize the draw step, intermediary solve of dependencies. MA let you change dependencies (remove/add if you want), setup some values as defaults, let you customize even the final shape that is drawn. MA also uses the previous document refactorings, so it will be a smaller chance to remain artifacts by persons that draw custom code.

- NSM because was a monolith that cannot be changed, some operations like: AutoFace (when lines create a profile, a face is generated), CalculateIntersections (compute local areas on face shapes), could not be customized to not be computed when do not make sense (like: a sphere do not expose any face so why to calculate intersections on the same plane). AutoReset: if true will mean that action will continue to draw the same shape that was doing initially. (like when you draw a sphere, to continue to draw spheres with the subsequent clicks). Right now those are properties can be setup right away.

The code is subject of change but the code gets really better and is as follows:

The code is reduced for those shapes by 5-6 times also, because the modifiers' code is not exposed to those actions.

The following shapes work right now: all that are dependent of Point3D, Axis3D, Real (which can be computed as a distance of the last clicked point and the current click point). For now do not work Reference shapes and custom cases of Reference shapes (like Extrude) which should froze the plane.

I will try to continue porting and find issues of porting code of the actions to become metaactions, and at the end if there are no big issues, will wrap the steps to a command line interface.

Sketched a new layout for NaroCad with WPF that also supports docking. On the top it contains the Ribbon control. The project is made in parallel with the actual Windows Forms project, the current functionality is not affected by the GUI changes.The next steps will be to map OpenCascade to render on the WPF areas, then wire the events, put the grid and tree view list as controls and if not working replace them with WPF versions of them.

Friday, December 18, 2009

Didn't advance too much on the GUI restructuring.Decided to replace the main Form with a WPF one, for now the WPF form is built in parallel with the current form. Succeeded also to integrate the Weifen Luo docking control on it. Evaluating if there is any point on keeping the docking control and windows or to replace them with WPF versions together with the main form.After integrating all these elements the next step will be to map OpenCascade to render on the forms and also wire the toolbar events.

Thursday, December 17, 2009

Lua will need some improvements and I hope that today I've made a half of image what changes will be needed. I'm still not 100% sure what changes will be but at least I know what are the most facing problems I will encounter.

The other change done this days is about how attributes worked to be identified and what can be the problems that persons might get using the old code. The tree of nodes can get attributes of any given type as long as they are registered. In fact that can make to appear a class of problems. One of the problem is that the conflicting names. NaroCAD used Integer, Real and Color names for storing specific values that may be too generic. This is really great as long as other person wanting to add their custom type will not colide with already defined types. Right now, because we did not write in C++, but in C#, there is a very simple way to create a type that do not collide: use the Reflection .NET API and picking the name and hashing from there. In the past there was a probability (very small, but it could) make that even you had different strings, the generated hashes may collide.

Right now, Type.GetHashCode() have no coliding value as is unique for type IDs. Also is really great because the code will not make you define a custom constant and to write some "magic code".So to define in past your interpreter the code was like: public RealInterpreter() : base(nameId) { } static int nameId = AttributeInterpreterFactory.Register(InterpreterNames.Real);

Right now the code is:public RealInterpreter() : base() { }And the registering can be done anywhere else just in case of using deserialize/save to disk and no associated string constant (InterpreterNames.Real) needed.

Tuesday, December 15, 2009

Lua integration is not straight simple. Based on this, I've review again the code. By this I've did cleanup a bit a function's code. This change will mostly merge function shape dependencies code with function code. Also, the old name of OCAF was completely removed as we have for more of 6 months than we replaced the OCAF code with a C# implementation using the same principles.

Note: I'm on irc://irc.freenode.net at #narocad room for persons that wants to talk lively and don't use Skype or want for simple topics like install fails on your machine or setup the build environment. I will not be all time online but when I will be I will respond :)

Monday, December 14, 2009

NaroCAD have two level frameworks: model ones (high level functions to define shapes, tree of data interpreters/attributes, a document live-cycle with undo-redo) and a view one that is defined as a set of inputs/modifiers.Lua right now works at the model level, so to make better integration it should be made as a modifier. For this there are two options: make a Lua only action that is defined, or one more intrusive that all actions will give descriptions to Lua working. The second approach is tricky for actions like: extrude that at their selves depends on other shapes, or for shapes that are not right defined restrictions. An extrude in itself right now it asks for a shape to be extruded, but the modifier creates an face that was clicked. I will have to think more for a proper design/solution.

One note: I'm are really glad that on sourceforge page it shows positive thumbs. If you know something that do not make you happy, please point it out. We will be glad to get really positive reviews. So: if something goes great, say to anyone, if does not, say it (only) to us :)

Note: It may take some time until is uploaded as the uploaded archive did seem to not work. When I will upload it (again) this notice will be removed.

This week worked at stabilizing the application. It is not as stable as 1.2 version but the new tools added should compensate in value.

35 more bugs remained to be solved. The most important one that would be good to be solved on this week is Delete on intersected shapes. Currently after Delete the intersection is regenerated so the shape doesn't disappear.

Wednesday, December 9, 2009

Creating good user interfaces there is really a science in itself. The reason is that many programmmers (as myself) are focused on the engineer part and less on how things are accessible for user.

If you know Joel Spolsky, he presents very good reasons why user interfaces are complex. The quote that is the most important in my oppinion from all topic is this: "A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don't seem to care about the magnitude of the event, only the quality."

Using various interfaces, I am likely attracted with Mac OS X/GNOME interfaces: they stride to be minimalist at first and try to hide to user most of options. Also, they emphatize with automatically apply UI and the buttons are tend to be "reversed" compared with older applications on Windows. The reason that most persons are right-handed persons and they will more likely hit the right-most button if they will not look at what is it.

Some reasons of being minimalist as interface is to not overwhelm the user from one side, and picking defaults that (almost) always work on the other side. The reason of applying automatically the interface is great that you will mostly change your options and you will save a step by clicking again on OK (if you not click wrong on cancel and have a frustration). Another reason in NaroCAD at least is that some options are really frustrating when you pick a wrong checkbox and close. You will have to open again options, to go back to that specific Options' page, and uncheck your options. If you click a wrong option and you see the results right away, you don't lose the "context" by closing the dialog and move back.

So based with tha good faith and following the giants in UI design, I've applied most of that knowledge on NaroCAD. Today I've just finished an automatically applying non-modal Options dialog. In this way you can test if your Solver options (the component that is used for autoaligning your mouse point to various references like corner points, paralel lines, paralel planes) without going back and forth. Also the dialog have in bottom-left corner an Undo/Redo arrows pair, so if you get wrong some arguments and you just found that the defaults are better, you may use the defaults right away applying the Undo. Also the Undo will say which page was changed when the undo is applied.

The dialog of Cut Preview was also changed to be asynchronous also, so you can rotate right now the scene as much as you preview the cut.

Lua in case there was an incorrect command, even as simple as missing an argument, you the user was facing a Naro crash. This was addressed. Also there is a help button that is mapped over help() method in Lua which gives to you online help about which arguments you should provide for command line you want to execute.

Monday, December 7, 2009

Latest developments did make some shapes/tools to not work. Hopefully that problems were addressed today. Some testing may be still needed, but the code is really close to previous exposed functionality.

To speedup launching of visual tools, I've made a dialog to launch visual modifiers. To launch them, you should press Control + Space from the SVN version (or wait for the next version).

Also, it was setup a Mercurialsource tree for NaroCAD project in parallel with SVN. Using Mercurial may in future simplify cases like working in experimental features and branching. Mercurial is a distributed VCS which means that you can commit in your separate branch without depending on sourceforge for some time. To understand Mercurial, you may look to a very similar (but a bit more complex) system (Git) .

Among the new features added in the iteration 1.11:- AutoSave functionality - restoring in the case of a crash,- AutoUpdate functionality,- Added Torus solid,- Implemented a Direction tool - shows the direction of a Face,- Add/Remove nodes to spline tools,- Copy/Paste with Reference, the duplicated shapes are influenced by changes to original shapes,- Drawing of line parallel to face, Drawing of line normal to face,- Lua automatic tests, increased the number of commands exported,- Offset 2D and Offset 3D features,- Cleaned up and improved the Save/Open/Export/Import functionality,- Improved bug tracker to send more than one file at a time.

Sunday, December 6, 2009

When Cut Preview was shown as a usability feature, the first comment was to make Extrude previewable. So as the refactor of yesterday had some issues, going to address the extrude's ones, I found really easy to add preview code (with the same color theme). Right now it miss Dimension but it will be addressed in a day or two.

C# compiling note: To include various classes over the project, you can do it by "using" keyword and a namespace. Removing unused "using" in most files of the NaroCAD project reduces fairly significant the compiling time from around 8 seconds to 7 seconds in a 2.13 GHz dual-core machine (that may depend on your CPU speed, disk drive, cache sizes, how your sourcecode is organized, etc.) but in fact an improvement say just this: if you use Visual C# newer than 2005, always do a "Sort and Remove" refactor option as it will save later some of your time.

Saturday, December 5, 2009

Yesterday I've started a refactor to try to resolve a class of problems. Firstly, how is organized Naro code, and what is the relation with OpenCascade?

NaroCAD is built as MVC, in multiple levels, but in short, the primitives are stored persistently in a structure named Document. This document have a tree which is somehow similar with XML DOM (but indexed a bit differenly to have better access time), and livecycle (like Undo, Redo). The tree nodes can store arbitrary data, or as needed it can store shapes that based on that data, to builds visual OpenCascade shapes. Those high level shapes are stored in two ways: as model with specific OpenCascade code named Functions and as OpenCascade View, if a document have an attached OpenCascade Context the view show/hide, color, etc. is done automatically (using a custom attribute) based on propagation, changing in attributes that are on the node. So making those lines short, A document attached to OpenCascade, it will wrap it with high level primitives and tools (like Extrude, Circle, etc.)

To make them appear in the final document, users expect a preview, so for this there is a separate component that do only visual work (that at the end will create to you a shape like circle you wanted). This component describe actions that users do click that are named Modifiers. A modifier starts from the moment you click the button in toolbar and continues until user press escape or click on other toolbar button.

For some shapes it simply work as to create the shape in-place and to simply update the dependent data lively. For older code or for cases when the code was not thought as that way, the OpenCascade code was done by hand. So by this, some actions did use a AIS_Interactive visual shape that was updated as Circle first, Cylinder after and added/removed manually to OpenCascade's cotnext.

The refactor did start from observation that is much easier to use NaroCAD's framework to add a circle in Document (and document will do by itself the circle live-cycle) than to write it's OpenCascade code. Also we remove the copy/paste code of creating circle. In case that circle code will have a small issue, the fix should be done wherever the code was the same in preview. Want to clean your scene from when your action starts? Document.Revert(); is just enough in all cases. No if(TemporaryShape!=null){ Context.Remove(TemporaryShape, true); }

How many shapes are affected by this refactor? The code affects around 30 modifiers in code, but this new model in all cases reduce the code line count, make all code to not be OCC like but more C#/NaroCAD framework like. The other advantage is that if your final shape is not right defined, it can be reveted the code without having the possibility that by mistake some temporary shapes are remaining in OCC context.

Do you know that Internet Explorer is much more popular because is the default browser?This is said and is accepted as a fact. So persons took this as a way to justify that Microsoft should offer for alternate implementations in their operating system. This is for me unprecendented but for some (that have browsers) is a good thing. This piece of news is here.

I do agree that persons are not well educated and if I will say to someone: use Firefox (my choice) because is the best, and that person do not have as first concern which browser run on it's machine, will install Firefox regardless if is safer or not than IE.

The issue I want to talk at large is why NaroCAD do not support alternate OSes like Linux. Firstly NaroCAD as a project with a small team so only supporting the install script for any new platform will mean spend time without any result in a short term. Because of this, if we will want contributions Linux will be as good as we will get a win lately in our free time that we spend developing every new feature you met. If Linux in itself is good for servers, have a fairly good toolset for developping applications, including Mono (a free .NET implementation) and OpenCascade version of it, integrating all is not as a free lunch.

- First drawback are the wrappers, which we decide for shortening the time we will generate them (wrappers are a bridge between C++ world - where OpenCascade stands - and .NET world where NaroCAD is implemented). They use over 1000 classes and compilation of them take some time. We pick C++.NET for having only one wrapper. I've tried to spend some time developing a C++/C/C# wrapper but time spent on it do not result on a new wrapper and the time I have is not justifiable.

- The second problem is Windows.Forms GUI toolkit that we use. Mono's Windows Forms implementation is fairly good, but integrates bad with OpenGL at large and our bridge as we will use OpenCascade wrappers will need to get the Windows' X11 handle at the end or to create a separate package just for that. Or To use Qyoto wrappers of Qt (.NET wrappers) and to try to make a blackbox implementation of it. Which is not trivial again as we will have to reimplement all Windows.Forms in Qt.

The good part is that NaroCAD had separated OpenCascade code and probably if a company will want Naro ported to another GUI toolkit, excluding the OpenGL talked part, it can simply change some source-data classes that expose the same for Naro's framework.

Wrappers have still issues to the day (even we use C++.NET) but are much easier to address those than to create a completely new one. Also, the OS price is not relevant (excluding for a very poor country, but students get Windows for free from their university, or pirate it anyway).

We did try to optimize a lot of NaroCAD's code (or I personally did), so it should run on a netbook that do not cost more than 300 dollars in US, which includes Windows XP which runs Naro.

The easiest solution to make things working with Naro, is just to fix a small piece of code, or even contribute fixing the installer experience. If you have no PC experience, is also easy to submit a bug report, and your feedback can give for us cases when NaroCAD just did not work as you wish and when we have time, we will address those.

Friday, December 4, 2009

With some advices from my brother and with some fuzzy work, bug submiting was fixed. So by this we highly encourage you to use the latest nightly version from here. Is not a perfect version but at least your annoyances can be submited, reviewed and fixed.

Note: today I also reviewed and fixed an annoyance of deselecting on editing component. Cleanup a bit (I will try to do more tomorrow) on modifiers. This cleanup mostly reduce bigger code and OCC code like with NaroCAD version. At the end the same OpenCascade is runned but the code of OpenCascade should be removed (as much as possible) from modifiers (to be easier to be done the fixing). Lua was enriched with some extra commands that were not wrapped (like pipe and revolve).For example code in Arc action like: var centerCoord = new OCgp_Ax2(); centerCoord.SetAxis(_axis); var circle = new OCgp_Circ(centerCoord, radius); var edge = new OCBRepBuilderAPI_MakeEdge(circle).Edge(); OCTopoDS_Wire circleWire = new OCBRepBuilderAPI_MakeWire(edge).Wire(); TemporaryShape = new OCAIS_Shape(circleWire); TemporaryShape.SetColor(OCQuantity_NameOfColor.Quantity_NOC_RED);

Lua have been improved and crash unit'tests can be written completely in Lua without any C# specific code. Also an execute method is exposed that can run other lua scripts. It can be handy to create a specific setup in unit-tests but also in your NaroCAD test-drive.

Tuesday, December 1, 2009

Today I tried to upload and make it enable the upload code. This code is enabled but still experimental (it do not get last bxtrx changes but tomorrow's updates will go in as an update if everything will work right). Please download this update-enabled build from here.

Implemented offset on solids. There were at least two possibilities to offset solids one using BRepOffset_MakeOffset and one using BRepPrimAPI_MakeThickSolid. The implemented tool is using the first API and generates an offset duplicate after the selected solid. On next iterations will schedule also some offsetting that creates shells and other shelling tools (that wold be using the second API).The offset shape is parametrically influenced by the modifications on source objects. Implemented also descriptor for offset so that the offset can be changed in the property grid.

Monday, November 30, 2009

Continuing bxtrx work on usability, spline have a better/easier behavior on editing, adding points as follows: adding points, will be done by setting on the action of adding points to spline. Removing points from spline is just to press Control and click on the point you want to remove. Pressing Shift will show the old dialog though (without the Remove button in case of spline's points). Are some small issue but I hope to address them tomorrow.

Inherited copies are used in Repeat Pattern tool as default. The new behavior will create multiple small shapes that you can modify individually. If you will want the old behavior, that creates a monolithic shape, you will have to uncheck the "Reference Inherited Clone" check box when the setup dialog will appear.

Introduced an experimental feature at Extrude to display to the user the Extrusion height realtime while the user moves the mouse. This should improve the usability and probably will be improved and implemented at all drawing tools. To display the text used the same functionality as the one used for Dimension.

Implemented a tool that draws a line normal to the Face where the user clicked.

An encountered problem here is that our mouse point generator generates points on the faces over which the mouse passes so in this case it starts generating points on the clicked Face, in order to start drawing the line upwards the user must pass the mouse over some other Face in other plane that the one clicked. We should find a way to improve the point generating algorithm.

I eventually got (broadband) internet after three months of waiting. In the meantime I did wait a bureaucratic papers to make it their ways to break around 50 meters of wiring in a public section. In the meantime I used mobile internet. Jumping to mobile internet I found a lot of persons that really have not access to broadband internet and what it means. Not because I don't know it, but sometimes is simply not feasible to think on some procedures without thinking on that users.

Today I did did worked on update and seems to work but I will test it and I hope by tomorrow to make an nightly build with Update activated. By this it will be created most probably two builds: nightly build and a stable build. The nightly build will be updated nightly and the updates will make you to have a blog-to-date fixed version. Also, the updates will be changes day by day so you will not download all days the OCC distribution so it will be the recommended build for you if you care on your last features are on blog. But more on this when the nightly build will be posted.

Saturday, November 28, 2009

To Copy/Paste a shape a Control+C/Control+V sequence works as expected: your source copy and the destination shape are separate entities, and the destination is a clone of the source. This means that you can save a part of your work when you have shapes that are similar. This is good in your design work but there are some use-cases that this design is far from perfect.For those cases enters Inherited Copy. An inherited copy is shape that clones a source shape but all changed attribute are overridden to the source.

Let's expain with a simple case: lets take a shape S that have attributes: A, B, C (like color, transparency, transform, etc.). We clone with Reference Copy. Let's name this shape D (D comes from destination). When you change in S attributes A, B or C, they apply to shape D automatically. But if you change ever any of D attributes, like supposedly B, the following changes of S.B will not change D.B, only S.A and S.C.

Added code to generate interior offsets to shapes. Found a very interesting classifier class: IntTools_Context that among other methods has IsValidPointForFace that classifies the position of a point related to a face.

Tried also improving the external shape offset to generate the same shape and not rounded shape duplications but couldn't find a possibility to implement it. Some custom algorithm needs to be built.

On the screenshot an interior offset can be seen. It looks exactly like the external shape (a face was generated and then extruded). The exterior offset has rounded corners.

Lua code was moved to be accessible from other parts of the code like unit tests. By this will mean if you can have a Lua script that make Naro to fail, you can submit to our team and we can put that script in the unit tests to not happen that crash again.

For you as user will mean no visible change but for us will mean another way to reduce crashes and problems you may encounter.

Friday, November 27, 2009

Implemented a first version of offset that offsets Faces and Wires. It needs improvements to accept also negative values and also would like to change it to generate sharp corners not rounded ones. The 3D version of the offset will also be implemented and probably 2 tools will be created: offset that offsets the solid and offset that shells the solid.

A screenshot with the currently implemented functionality:

To implement this tool used BRepOffsetAPI_MakeOffset with GeomAbs_JoinType set as GeomAbs_Arc.

NaroCAD 1.2 release adds a nifty feature on 2D shapes. This is really important one meaning to drag&drop to edit points of a specific shape. The reason of this feature is that in most of cases mouse is imprecise. Another reason was that Spline have no proper way to edit it's points.

The solution was to create a custom dialog as the shown one. To edit it you just need to press Shift on the point you want to edit and this dialog appears. The Remove button appears for multipoints shapes. Hope you will enjoy using it...

Thursday, November 26, 2009

The last release included auto-save support enabled by default. For simplify developers work, this autosaved file was sent as a bug report. Even is great for developers that gets more information to reproduce your problem, you may have cases when your don't want to report what you work with Naro. Or another case, you want to show a specific screenshot or extra logging (a virus maybe :) ). For both of those cases it was implemented.

Step and Brep formats are setup out of Save/Open entries. Save to Step have the following behavior: if you have selected a shape, it will save only it to Step, elsewhere it will save the entire scene.

I will try to solve the issues of Updater to make easier to users to upgrade their machines. I will try to make also a nightly build repository that you can test all Blog/SVN builds and you can drive with your feedback as did murd the last day.

Wednesday, November 25, 2009

Exporting a specific shape to Step is supported right now. In this way the Step format is supported at the OpenCascade level of supporting of save/import. Combined with work of yesterday, you will be able to work with Step seamless.

I will work to improve the editing component to make possible to make precise point editing.

Implemented the Direction tool to work in Naro something like the "normals" command from Draw Test Harness. The normals on faces with orientation FORWARD are displayed with red and to the REVERSED ones with blue. Also at double click the face orientation is changed to the opposite value. This tool is mainly needed for development research more than for modeling. ex: This helped investigating on cases when the cut to depth generates nothing (because the Cut prism direction is not intersecting the solid and the cut height should be negative like -100 instead 100).

Today tried a cool way to check on Naro geometry:- export the Naro model to STEP- load on Draw Test Harness the geometry using a command like:stepread extrude.step ex2122230- apply commands to visualize normals and to check the model:checkshape ex_4bopcheck ex_4bopargcheck ex_4 -c // check if shape is a valid Cut argumentnormals ex_4 50

Tuesday, November 24, 2009

Naro had for some time the possibility to load external shapes in Step format. But the problem that Naro was not able to store it as it is because NaroCAD stores high level shapes. For counter this problem was created a shape that stores the shape as is. The single bad problem that this shape was not stored persistently in tree. That means that on operations like Undo/Redo will make Naro simply to crash if is involved an external shape that was not persistently stored. Right now is stored like a binary blob in Base64 format so it can get pretty big but at least solves the problem. One small optimization is that the binary blob is compressed to save space. So the 90k file representing the OpenCascande's sample "screw.step" is compressed to 50k internally (and is that large because Naro uses Unicode strings to save the diff data).

Implemented a direction tool that displays the normals on faces and their direction. This will be used to analyze geometry and research on the operation result in cases when faces have different orientations (like cut on extrude). Started analyzing in Draw Test Harness Cut on Extrude situations with different face normals.

If you don't want to auto-restore your scene, an empty scene was not loaded. This was fixed. Also a half of work was done regarding improve File->New->Part work. Naro for now is not multi-document aware architecture so it will replace your current part you work on. I will also focus on all document formats work.

Monday, November 23, 2009

Improved the magic points parallel line matching to detect if the mouse is on the OX, OY or OZ axis before looking for edge matching or parallelism matching. Refactored the the parallelism code to make it simpler and cleaner, made unit test codes for all magic points algorithms (point matching, plane matching, edge and parallelism matching).

Will continue implementing a Direction tool. This will be used to display the direction of a face allowing the user to change its direction. This will be also used to research on faces to see what causes some cuts through solids to generate shell like results.

- Working software is the primary measure of progress.- Continuous attention to technical excellence and good design enhances agility.- Simplicity - the art of maximizing the amount of work not done - is essential.- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Thursday, November 19, 2009

NaroCAD is a software product in intensive development, so many features may be experimental and you may be the unlucky person that Naro will crash in the middle of your work. We never want that but it will be great if you will have a previous state. Also, bug reporting can be enriched if you can send your document you worked on.

Auto saving your work is done at every step so you will have an autosave.naroxml file that store your entire scene, in your running Naro folder.

AutoSave makes possible to expose to user in bug reporting the document he worked on. This can be more intuitive for developers when we try to reproduce crashes/bugs. This feature will be enabled from the next release (1.2.1), so is just another reason to try the latest Naro and give your feedback.

Also the tools like NaroLinker, NaroUpdater were reviewed today. NaroLinker have a bug actually that do stop to add classes and I was not able yet to fix it.

The next days I will try to improve the update concept, can be improved to make a save only once at some minutes, also, some testing will not trouble anyone for this new code.

Wednesday, November 18, 2009

Uploaded on Sourceforge the NaroCAD 1.2 RC1 version. It can be downloaded from here.

Among the features added at the new version are:- Fixed around 40 bugs,- Added editing with Drag and drop for 2D shapes. When no tool activated when clicking Line, Circle, Ellipse, Rectangle, Arc, Spline marker points appear and can be dragged with the mouse,- Implemented Chamfer 3D to be applied on solids, Chamfer 2D to be applied on wires,- Implemented diameter and length Dimensions,- Implemented pattern repeat. A shape can be repeated and rotated a number of times having a guideline,- Implemented Mirror relative to a line and to a point,- Improved the error logging all errors are logged with log4net,- Stabilized the intersection algorithm and data tree structure. Undo, Redo, Save, Open are fixed.

Tuesday, November 17, 2009

Started to make a quick check on the current bug list and closed fixed bugs.

Fixed the majority of bugs related to Dimension. Closed bugs related to selection type closing when changing between tools or incorrect display in toolbar of active selection type. The bugs related to intersection algorithm were all closed.

Will work at bug fixing until the end of the week. At this moment 28 bugs remained to fix.

Monday, November 16, 2009

Cut operation is a very useful for engineers but sometimes gets tricky just because you don't know how much it will affect. One of the causes is that Cut Through All you are not certain of what it cuts. Another reason is that Cut to Depth is related with face orientation. Meaning that in case you want to have inverted Cut, you will not be able to see the result before you clicked OK on button. That can make really annoying to do Undo and dialog again until you got the "right values".

Right now Cut makes all scene semi-transparent and will explicitly show what the Cut will affect. Hope you will enjoy this way to work with cut operation.

- Added editing with Drag and drop for 2D shapes. When no tool activated when clicking Line, Circle, Ellipse, Rectangle, Arc, Spline marker points appear and can be dragged with the mouse,- Implemented Chamfer 3D to be applied on solids, Chamfer 2D to be applied on wires,- Implemented diameter and length Dimensions,- Implemented pattern repeat. A shape can be repeated and rotated a number of times having a guideline,- Implemented Mirror relative to a line and to a point,- Improved the error logging all errors are logged with log4net,- Stabilized the intersection algorithm and data tree structure. Undo, Redo, Save, Open are fixed.

Will continue with a week of bug fixing and if no major bugs found will make a release version or at least a build.

Saturday, November 14, 2009

Implemented the Dimension tool. It detects if a shape is circle and generates a DiameterDimension, if it is an edge it generates an EdgeDimension. Implemented also realtime drawing so that the dimension text moves after the mouse when drawn until a click shows the location. The text display the circle diameter value and the edge length.

On circle it seems to work well. On edges it still needs improvements as the dimension orientation is not properly detected.

For the graphical representation used the OpenCascade AIS_LengthDimension and AIS_DiameterDimension classes. In order to use this type of AIS objects in the data tree had to implement a new type of interpreter that holds and displays this type of objects.

Started working at implementing dimensions in Naro. Read all documentation related to it, studied the implementations from test harness, looked on forums.Succeeded to implement some prototype code that represents radius and diameter for a circle and length dimension for a segment.

Tomorrow will implement the dimension tool code to detect what type of geometry is selected and what is the dimension representation appropriate for it (ex: for circle - diameter, for edge - length). As graphical representation will use the OpenCascade interactive classes for dimensions but because they don't look very advanced and configurable probably in the future will implement also some custom graphical representation for dimensions.

Thursday, November 12, 2009

Was fixed an thrown exception on the yesterday's code. Editing for 2D shapes is reviewed and made more compact. By this all shapes excluding cerc and ellipse (which depends on non point editing). Cerc editor was implemented by bxtrx. As of next week we will target bugs, I will try to target bugs tomorrow too.

Wednesday, November 11, 2009

Two major bugs were addressed: the line/circular pattern have now a check box to not advance so makes possible to make circular pattern without making line advancing. The shape 2D editing changes were not commited.

Lua created lines right now do autogroup.

Also a small bug on help that do not show on patterns was also addressed.

NaroCad's internal data tree that holds info about the data, undo, redo and knows how to save, open is implemented in C# and has a similar structure with the OCAF package from OpenCascade. Being in C# and not wrapped it offers a lot of advantages like improved code readability, improved debugging and most important possibility to launch events (like when a node is modified it informs the view to redraw it - functionality not easily implementable with wrappers). Also it offers advantages when modifications propagate.

In the last 2 days worked at strengthening the unit tests for the data tree by implementing use cases and data integrity checks. With this occasion found and fixed some of the bugs that were affecting Undo/Redo. The problems were mainly created by the face intersection functionality integration with the data tree. Now the Undo, Redo, Save, Open should work better.Will continue reviewing the data tree code/architecture. If no major problems found will continue with implementing Dimensions and the Chamfer tool.

Editing for Line and spline are almost done. There are small issues though so I am gonna fix them. The actual design permit that you can add extra editor handlers for new shapes in future and when you click on a shape, it will show specific to that shape the list of the points that can be dragged.

I will work to fix those issues, a help related issue (that the mapping of help do not work just right) and after this I will continue with work. So today I will just work on polish and bug fixing of just implemented code.

Tuesday, November 10, 2009

Implemented a test unit with 2 rectangles that intersect and extrude on one of the intersection shapes. The unit test duplicates a bug that appears in Naro at Undo Redo.Succeed to find and fix the problem. After fixing it seems that Undo Redo started to work well.A problem that will be left for the bug fixing week (next week) will be to investigate the Delete crash. It might be related to this problem.Will continue with improving the unit tests and check if the data tree behaves well when using shape intersections and Undo Redo. If everything is ok will think how to refactor the code and improve the performance. One more day of work will be dedicated to this task, if needed will be extended to 2 days.

Removed all references and usage of Enterprise Library logging code. Now all logging output is routed to log4net. Improved the exception mechanism, more information like the crash call stack is logged.

Updated the unit test codes for the data tree and shape intersection algorithm, reviewed the new face splitter code. Will continue with making unit test cases for data tree that fail and solve bugs at it.

Friday, November 6, 2009

Mirroring against a point and a line seems working in the trunk version (I think it need some testing but the feeling is right here). Also the repeat line pattern.

How it work?- Pick your shape first- Pick the point (for Mirror Point) or line (for Mirror Line or Repeat Pattern)

In case of Repeat Pattern you are asked how many times to make a complete (360 degrees, 2*PI) rotations and in how many steps should translate the length of the whole line.

See screenshot for Repeat Pattern of one of the initial rectangles, 1 complete turn and 10 steps. If you simply want translated along with a line (to make stairs without rotation) you will need to put 0 (zero) for complete turns when the dialog will appear.

Thursday, November 5, 2009

I've start my day working on NaroLinker as I was need to add to wrappers some new classes. Right now NaroLinker have some bugs but I will not target them as was somehow easy to be added by hand the needed classes to the wrapper.

Right now there is mirroring up-and-running at model level so I will need to create the related visual code. It works against a point and a edge. So expect it to work it soon.

Wednesday, November 4, 2009

I start working on mirroring shapes. OpenCascade supports mirroring as a transform operation and can be done against a point, a line and a plane. I've added (there is no visual tool for this) a point shape to be tested against both: lines and points. Also I think that I can share the code with creating shapes using other transforms (like rotate, translate, etc.) but I still evaluate this.

An annoyance in NaroLinker that it makes you not be able to use too nice your machine was removed: all commands used in build are launched silently.

Windows 7 gets a fairly positive reviews all over the IT world. In fact, it's technology is Windows Vista SP2 with refinements. It's technology is similar with what was Windows 95 saga vs Windows 98. Even Windows 98 was somehow a bad operating system, and have a BSOD on it's first public presentation. But in years, after Windows 2000 appears, people don't want to get rid of Windows 95, or a bit later about Windows 98. But in fact Windows 95 and 98 were on the same family of products.

The same thing applies to Windows Vista compared with Windows 7. The backslash of public opinion of Vista, was the same backslash that Windows 95 has (it was considered bloated, slow). The improvements of hardware made the new Windows 98 (which in fact was Windows 95 with small updates on UI) to be more positive.

In some extend the same thing happens with Vista: it brings new technology, a bit incompatible with XP "old OS". Was a bit slow for it's start. Do you think anyway that Vista was ever considered a slow release? Or Windows 98, or XP, or any OS from Microsoft? Look in history of more or less independent reviewers that Vista do not perform so bad, if you don't believe me, look here.

The good think is that virtually all programs that run on Vista, run on Windows 7. If you do all upgrades to your Vista machine, you will have installed already .NET 3.5 (the same version as Windows 7 does), the same IE8. In fact NaroCAD never had more problems on Windows 7 than on Vista, and no crash was because was Windows 7.

This launch of Windows 7 will push much more people to leave the beloved XP away, and makes also Vista to be really a great deal. You can buy Vista Home Basic in OEM at really bargain prices. I found a shop (in Spain) that sells it as low as 30 euros (care that we talk about OEM, so you should buy a new hard drive or video card with it at least). This is incomparable with an OEM price of 90 euros of Windows 7 upgrade price (see here). And the good thing is that you get (almost) the same OS (that version do not have included SP1, so I had to wait a bit to apply all upgrades), but as of today all new hardware you buy is Windows Vista compatible.

If Windows7 +1 will be technology compatible with Windows 7, it will just mean that if you can wait another three years and buy at that time Windows7, at a very good price with no big compatibilities issues that Windows 8 will have at their prime time.

Tuesday, November 3, 2009

NaroCAD went a long way from the 1.0 version. The revision count doubled from 1000 to 2000.

There is a lot of new functionality that you needed and right now it is here. It covers all major tool functionality (like pipe, spline, cone, sphere, boolean operations), it got a lot of polish in UI and usability, lua scripting for generating scenes faster etc.

We, the NaroCAD team, really want you to try this new release version and give your mark on it. With your feedback, and who knows, your contributions we can make one of the best free-opensource CAD systems out there. Being written in C#/.NET makes the code easy to understand besides our team's willingness to help in all problems you may have with this codebase.

If you think that a new functionality is still needed, you may join the NaroCAD Feedback sessions or simply report a bug. We value your feedback and hope that you will like this release.

Sunday, November 1, 2009

More than a week I was targeting undo/redo bugs and the last big remaining bug was on face-splitting. Half of reasoning was that there were some quirks in current codebase (small issues but the code was stressed to show those problems) but face splitter in particular was a bit overwhelming (for me at least). The cause is just that cases where it does not work are only cases with spliter that works with more than three shapes, undo that applies out of order the items (the splitter itself required that references to be deserialized first), a lot of side-effects.

Splitter in itself was the first shape that creates other shapes, meaning small "pies" over an area that shapes actually intersect.The actual refactor targets just that issue, and gets out the splitter out of tree, as is much more a helper code. By doing this, the splitter will work more or less like the solver component (so as an scene utility). Because splitter required kinda big refactor, was a good reason to also cut out (some) parts of code in smaller pieces. The shapes are created right now in a separate assembly, and is not mixed with property grid assembly one. This will mean for anyone that will look to the code a bit more clear where to find stuff. This code moving does not change functionality more than the splitter related one.

An installer nice thing: NaroCad will use ngen at the end of instalation translating in waiting for around a minute at the end of installing (the biggest thing is to compile wrappers, so using NaroLinker may improve the compiling time), but startup time will simply halve. So you will "feel" NaroCAD as being more responsive when next releases will happen.

Friday, October 30, 2009

We want to release soon 1.2 and was expected to be done this week but some (blocker) bugs makes us to rethink our position. By blocker we mean that over some complexity the Cut goes to recursive infinite call, also it does mean that some undo/redo work was completely wrong. Those two days was a complete team work by targeting those hard issues.

We are close with that bugs but we aren't still to do a release. This means that we will want to make it in some days next week, who knows, maybe Monday but also we want that you to not find big crashes or miss of functionality. In fact the functionality that splits faces that gives problems is a huge gain from user point of view to define islands and sections of a shape.

Thursday, October 29, 2009

Added points on edge detection as magic points and also reimplemented the parallelism detection. Fixed the bugs and crashes at magic points and added more magic points at cone and cylinder. Some screenshots:

Tuesday, October 27, 2009

As main directions that remained to be fixed are:- the Undo Redo still needs fixing,- the magic points needs improvements so that the solver detects edges and surfaces (improvements are needed especially at curves like arc, surfaces like cylindrical),- because of the parametric propagation a node that references another node (like Extrude is referring a Rectangle node) is using a hidden node named SubShape node that describes the referenced node. We have to find and implement a guideline to establish when a node that references another node should hide the target. Ex: Extrude when applied on a rectangle should hide the referenced rectangle, when applied on the face of another Extrude should not hide it.

Currently in the bug list there are 12 more bugs and 7 bugs with enhancement priority (the enhancements will be not closed for this beta release). Closed around 49 bugs.

Thursday, October 22, 2009

In the previous day was pointed out a bug that was because of wrong marking nodes. This code was mainly used when it was wanted that a shape to be hidden. Right now there is a Hide function that simplify the code of setting up a shape to invisible. Also this code was applied everywhere so it remove in other shapes some hiding bugs.

Also the construction: Dependency.Child(id) is replaced with Dependency[id] everywhere in code. It does the same but the construction is shorter.

At the end there was a bug that applying fillet on two lines will make that the logic of auto-face to not work. Right now the code was made to be specific per shape and permit that fillet lines to be considered as a part of auto-face logic. Also it makes easy to add another shapes as part of auto-face logic (I will try to add arc as the next shape to be considered).

Wrapped and compiled the BRepCheck_Analyzer package. This package contains tools for checking the validity of a shape. Added this functionality to the MakeFace function that now checks if the generated faces are valid. This solves some of the bugs related to wire grouping as a Face and also at the AutoGroup functionality.

The Hidden On/Off works now. This tool is useful, when the model is displayed as wireframe the user can see how the model looks inside after several operations that affects its structure.

Wednesday, October 21, 2009

Undo-Redo have no known bugs for some time. At least not in areas like: computing diff between the previous Undo point and the actual point. Still, because some constructions were able to have some complex cases, like: the dependencies should be deserialized first before the shape itself, a lot of functionality was exposed and sometimes with some very good side effects, but sometimes with unexpected ones.

This last bug was really tricky and it was like this: every time an attribute is changed in the Naro document tree, there is an emit of an notification. This can be very useful to make propagations. Sometimes, this thing is not desirable, in case of Cut Through All operation, some changes may turn as an infinite loop. That makes that some attributes were able to be disabled to be notified. Without knowing, disabling this, makes that another operation to not happen. To be more precise, the diff marking. The Undo operation is implemented to not query the entire tree every time, but only the nodes that emits notifications of changing. By doing this, there is a big performance increase in complex nodes setup.

Based on this, hopefully this more complex Undo/Redo setups are fixed and it gives the status of making Undo-Redo operations more reliable.

Fixed related to Arc made from Radius Start End. Made also code refactoring at Arc.

Improved a lot the face picking mechanism: instead of selected faces mechanism now it uses highlighted faces mechanism to detect the face that the mouse is over. Picking a shape with a tool like Extrude that uses the FacePicker is improved. Added also code to change color of the faces that are targeted by the face picker.

Tuesday, October 20, 2009

There are fixed bugs regarding spline usage (creating invalid splines were able to crash Naro as it was try to make autogroup with them. Also a small update issue on deleted shapes. Both right now are fixed. Also I've reviewed the bugs regarding internal model of deleting.

I will continue to work on bug fixing regarding Undo/Redo and any document related issues.

Monday, October 19, 2009

Cris pointed out a problem that some faces remain not deleted still, even I thought that was fixed. The cause was that the removal of shapes is done automatically by NaroCAD as long as there is no consistency breakup. It happen that FaceSplitter keeps references to face shapes and their deletion was erroneous (they remains hidden but leaky) so right now is fixed. I look along for other associated issues.

Saturday, October 17, 2009

I was looking to solve all bugs related with loading/undo-redo cycle. There is only onle harder bug in this category and I hope to find why is happening (the situation that an undo step will override some values out of the undo changes, the worst of this bug is not to find what was doing it, but I think at least in future, the fix should enforce that an undo operation to not change anything that Undo step states). For now I've fixed a bug that deleting a shape was not removed internally, but was just hidden from the user eye point of view, which breaks the face splitter. Based on design, the face spliiter being a part of the tree, on the actual code, was removed too at some specific operations (like save/open). Right now Face Splitter and some other future shapes that may need to not be deleted if they are invisible (like constraints!?), they may get by design this extra attribute and to not break the delete code.

Wednesday, October 14, 2009

Old open code have been making some assumption like: shapes can refer other shapes (for example Extrude) that have a lower index of creation. This works fairly right if we don't count Face-Splitter. Face splitter by default is setup as being node with index 0.

Right now the applying of Undo/Redo or File/Open will do it in case of references to deserialize in advance the references, by this will remove one more assumption and it's following problems. Anyway, there are still bugs there, but I hope to address them today.

Monday, October 12, 2009

Splitter face code have some documents related problems. I've considered a refactor but for now there are many dependencies involved and I'm not completely sure if this is the way to go. I will have to decide with bxtrx if is right or not. This refactor should reduce the dependencies between the splitter and the document. Based at least on the skills gained today about how works the splitter implementation, will simplify for me the debugging experience for tomorrow when the refactor may introduce new bugs.

Today fixed the arc exceptions, improved the solver parallelism detection algorithm.Fixed the translation code. Translating from property grid and the translation tool work properly even if applied on models depending on other models. Also at Undo the transformations are applied correctly and the proper object position is restored.

Will continue with improving and fixing the shape intersection algorithm and integration with tools. Will also improve the Cut functionality and fix bugs related to it.

Friday, October 9, 2009

Based on bxtrx's bug fix, the installer should work on all machines that were still crashing. The issue was that Scintilla lexer was not added by default and the users that do have installed other applications, for example TurtoiseSVN, will not encounter any problem, as Scintilla was installed with that.

Also, this build is a snapshot of current nightly build, so a lot of small crashes that you've encountered in your past, are fixed. Based on this, this version appears to be the recommended install version for now and a good way to report other errors based on this.

Thursday, October 8, 2009

I've did debugging and removed all crashes found by me regarding face splitter. It still do not work completely right in File->Open case, but at least it removes the crases. Also, in case of crashes it does not give a huge messagebox meaningless error, but it will only fail this part of the document. This is grat mostly in case that are serialization bugs that happen when creating/applying an undo/redo operation.

It happen that because of various refactors, the propagation had an explosion of regenerations when happen a parametric propagation. This was caused that are two entities that store the shape that are equivalent form (the TopoDSInterpreter which stores the OpenCascade shape and NamedShapeInterpreter which stores the OCC View corresponding AIS_Shape). Right now it will happen only one of them, so right now just model notifications are emited for propagation purposes.

IronPython was removed as Lua offer everything that IPy has, only just Lua is better integrated, so there is no point to keep both.

Wednesday, October 7, 2009

Transformations were bad implemented in the idea that some objects override the base objects that they were based on. By this, only applying Undo/Redo or a simple(r) extrude makes everything to be moved to origin or to other point.

By starting with the idea of bxtrx, I've implemented eventually and the transforms are back again working.

The functionality of the MakeFace tool is that it groups wires into faces (it is also used by the AutoGroup algorithm) and I also added the functionality that it groups several faces (selected with shift+click) into a bigger face to allow extruding them in one shot. In order to extrude the generated face a problem is to cleanup the internal wires and faces.Tried to implement a remove internal wire/face algorithm.

if (shapeUpgrade.Status(OCShapeExtend_Status.ShapeExtend_DONE1) || shapeUpgrade.Status(OCShapeExtend_Status.ShapeExtend_DONE2)){ // If operation succeeded replace the result shape with // the one with no internal wires finalShape = shapeUpgrade.GetResult();}

The wrapper code doesn't work for the moment, it generates the same shape as the original one. Will move to solve higher priority bugs and come back at this algorithm soon.

Tuesday, October 6, 2009

The last two days I've mostly have no progress, probably because I've felt not so good. I've starting to track why is used TCL, no reason so far, after this I continue to look on found bugs and the single fix I've done in this days was a one liner, but what was the strange of that patch, was that the original code should work in its original form.

Today I've clean up a big file at least removing the calls to command line that are no longer used.

Continued fixing tools for the beta release that we plan to make this week.

Worked at improving the Face intersection algorithm and its integration with other tools. Refactored Extrude and added better integration with shape intersection, extruded Faces that are not intersected with other Faces are removed from the intersection candidate list.Still thinking how to handle the situation when some shapes are intersected and one of the intersection results is extruded, currently all shapes remain in the scene nothing is hidden.

Saturday, October 3, 2009

NaroCAD installer was updated to use the missing dependencies. This IS NOT THE FINAL 1.2 RELEASE, but for most users that could not start NaroCAD, they can do it right away (of course they may be hit by another bugs).

The issue was that the 1.2 uses Tcl/Tk libraries and they were added to installer. Anyone who has installed OpenCascade was able to run NaroCAD 1.2PRE without problems, but for the rest of users, it was a startup crash, hopefully it will not happen.

NaroCAD installer comes with a mini distribution of OpenCascade, but seems that adding extra code features to current codebase may increased the dependencies and make it to not be enough what is bundled.

Thursday, October 1, 2009

Still working at fixing and improving the application usage use case. The shape intersection algorithm integrates well with Extrude so that after an intersection shape is extruded if more shapes are added to the intersection the initial Extrude is not affected and refers the same base shape. Will continue testing its integration with Cut, also planning to hide the shapes on which a Feature like Extrude is applied. The Face Generation/Groping and Ungrouping will also be checked to see if it works well and then move to Fillet2D.

It seem that the transformation refactor gives a lot of regressions, so I did tried to refactor. Still I jump in others problems so I will need to rethink and fix my code for now. I will continue on transform issues.

Tuesday, September 29, 2009

There was a dormant problem that was found after a late refactor.So today I've get the bxtrx work a bit forward as he shows the problem. The problem is about propagating transformations. In fact the transforms did not propagate, only the shape creation. This makes odd effects like applying Undo and then Redo to appear as shapes do translate randomly or even break. Devasted helped me with his advices on transformation work and review the changes done, so hope to behave right.

The first part of the day I've did fix a developer debug tool which exposes in a clean way all NaroCAD document tree. Hopefully will simplify some cases of visual hints do not help.

Started bug fixing the shape intersection algorithm and also integrations with Extrude and Cut. Fixed the shape detection algorithm (the code that connects displayed shapes with Nodes), fixed an extrude bug on overlapped/intersected shapes that it wasn't extruding the correct shape.

Enabled all the functionality implemented until now and will continue fixing bugs and make all tools working properly.

Monday, September 28, 2009

Sunflow is an opensource raytracing engine. Right now there is an action for rendering shapes. This action give some advantakes and shows a real usage of triangularization.

Some shapes are not drawed right, but I don't know if is NaroCAD bug, OCC triangularization bug or Sunflow bug.

I've picked rendering because there were some requests of make printing in NaroCAD, and as there is not such a large work in that, the pursposed solution was to capture the OpenGL screen and to save it to file (or to print it). It may sound handy but it will not guarantee a lot of issues, the biggest for me was that it should be just hacky to take OpenGL surface and render it to a file, it should mean at least to hack OpenCascade code.

The choices I've had so far for rendering were Sunflow, PovRay and Yafray. The Povray is huge, making to add a huge bargain to installer, Yafray is nice but I found it hard to use (from command line and to integrate it) and Sunflow was the balance between two: it was the smallest of three (it use 1M), but requires Java, which is one of the most downloaded runtimes over the internet. Also sunflow have a very easy material (named shader) setup. So the rendering goes as this: you pick the shape, you pick the shader, and you will get all at once.

I think that are still bugs, in those dialogs, but is a fully working concept. Also I've not found a proper way to pick FOV (Field of View) from OCC view. If you will find a proper way to get it, please send it via email, and I will fix it to get it right away.

Sunday, September 27, 2009

Continued working at the shape intersection algorithm and succeeded to reach a quite acceptable solution: introduced in the application the concept of splitter node. A splitter collects shapes drawn into a candidates list, the ones that collide are stored into a separate list, the result of intersection is displayed (and hold into a separate list of Face shapes). If a feature like Extrude is applied on some shape generated from the intersection of other shapes, a hidden splitter node is generated with the shapes that generated that intersection, Extrude will reference this splitter node. In this way parametric propagation is possible also further modifications of the shape intersections by adding new intersecting shapes don't affect the Extrude reference. Refactored Extrude, Cut, Revolve to reference SubShapes that reference at their turn Face shapes generated from intersecting shapes. Undo/Redo seems to work well with the new added concept.

Currently the intersection algorithm is disabled on NaroCad until an Extrusion bug is fixed (Extrude sometimes picks a different intersection shape than the desire one). Also the display of the structure in the tree view needs some improvements to give access to the user to the initial shapes that generated the intersected shape. Planning to finish working at this algorithm into one more day of work and in parallel to add also wrappers for the Meshing algorithms.

Interesting that after trying at least 10-20 OpenCascade algorithms/solutions for intersecting/breaking/healing/combining wires, edges, faces, shapes, shape analysis, shape upgrade, closed area detection, closer wire extraction the only solution that worked in all cases for making a Face intersection algorithm was extremely simple: fuse all shapes and explore the resulting faces. Also Face colliding detection was made by using BRepAlgoAPI_Common algorithm and see if Face exploring iterator holds anything. The problem with these solutions is that they are not the fastest, the advantage is that they work well and cover most usage cases.

Saturday, September 26, 2009

Triangulation do not work still, but with help of bxtrx, it was found the most likely problem is because I've did not use (as he said in previous blog post) all steps to do that triangulation. Also the solution may need some extra packages, but without making an over design with the C++ bridge that I was tried yesterday to do without a success on that.

I've continued the rest of the code around triangulation, and when triangulation is in place, it can be exported in an external file and processed. So I've created a special action to do triangulation. The test right now works with a face of two shapes that defines a square. Fixing it's bugs will may have various applications, mostly to export transparently shapes to "outer world".

Hope with adding of those extra packages and minimal fixes to see before release (setup in the midle of the next week) an interesting usage of triangulation.

While developing a .Net application using the OpenCascade wrappers, some issues might appear: like an unexpected crash or a function that returns nothing when it should return some list with processed elements and no clue why it is not working. There could be many causes of the problem, among them there are:- incorrect usage of the class (forgot to initialize something),- correct usage of the class but incorrect parameters or not treating the error that the operation returned and moving to next steps (like the operation failed silently and I am trying to access the result shape),- bug in the wrappers (some parameter not passed correctly to the native layer) - not typical but not excluded,- bug in OpenCascade - not typical but not excluded.

Because investigating all these problems might take a lot of time I will explain from my experience with wrappers until now how to approach the problem to solve it quickly.

Let's assume that I write some OpenCascade code in C# and it doesn't work. I try one or two constructors for the class, I try the same function with different parameters but still the class/algorithm returns no results and I have no clue what's the problem. The problem can be in the C# layer, in the wrappers or in OpenCascade. Assuming (because of the lack of samples) that I am not sure how to use the class properly or even if this is the algorithm class that solves my problem, also I am not sure if the problem is on my layer or lower layers, I do the following:

1. Because the code is already written the first thing I would do is to use the OpenCascade error handling mechanism to see if there is a problem.To detail further this sentence: majority of the classes have the IsDone() method that should return true, also many algorithms classes have some function to get the operation status (they return something like OK, could not allocate memory, invalid parameters). Modeling algorithms docs have some hints on these.If all these look ok we move to the step 2.

2. If the result that I expect is an array of shapes, or some values I look at the class for functions related to the algorithm that might give me a hint what happened. I look at result array length if it is 0, or if the class has some methods that describe the solution like NbPoints() or IsGeneratedNewShape(). If all these are 0/false a possibility would be that I didn't initialize the algorithm properly so it couldn't find a solution. I always look for Intialize() functions.

3. This step could be a step before step 1, before starting to implement the algorithm.Replicate the functionality with Draw Test Harness. I make quickly a similar shape using tcl, apply the algorithm and see if this works. If it doesn't work it might be an OpenCascade bug, if it works I look at the command source code to see how they implemented the code.A problem here might be that I can't always find a command close to the functionality that I want to implement. An advantage would be that looking at their code I get the confirmation that I use the right path for my solution.

4. Search on forum for the problem. If some sample code is found in C++ I can always try it with copy paste on one of the mfc sample applications provided together with OCC. Also I look if the class usage is like the one from my code.

5. If none of the above steps to detect the problem worked I try to implement myself the solution in C++ to eliminate the wrapper layer. If it works in C++ we have a wrapper problem, if it doesn't it's an incorrect class usage problem or an OpenCascade bug.

6. The last solution and most time consuming one is to debug the OpenCascade function. I look first at the source codes to try to get a hint on why my code fails (maybe I see a check there if a parameter is a Face type shape). In many cases I find there some code that I don't understand and gives no clue why it doesn't work. An approach for it is to debug it while doing some operation to see where it stops or crashes.

How to debug:- first we have to build OpenCascade in debug mode. Using VisualStudio this can be made by going to OpenCASCADE6.3.0\ros\adm\win32\vc8\ and build the projects found there. Some projects might fail building because they depend on other projects so we try again after building the others. Some always fail, we can always copy from the release folder the release version of these especially if we are not interested debugging these missing libraries,- make the CASROOT environment variable point to our debug folder or rename our debug folder with the name of the release folder, make sure we use the debug folder by renaming the release folder and see if sample applications work,- launch the C#/.Net/C++ application, attach to it with a debugger and put a breakpoint in the OpenCascade function that we want to debug. In the trunk in NaroCad folder there is a file named DebuggingSolution.txt that explains in detail how to configure WinDbg to debug OpenCascade.

From debugging I made until now there is no point to have wrappers in debug mode, you can always check in the native OpenCascade code if the parameters passed are correct or garbled.

After all these debugging preparations if we don't understand the native code a chance would be to be lucky and have the code failing on some "if" check or see some message thrown that can give us a hint.

7. The final step would be always to start again from step 1 (or 3) searching for a completely different solution.

Many variations on the order of these steps can be done I just wanted to make a list of possibilities that can help us find a quick and reliable solution.