Exams are finished

Yesterday was a momentous occasion. Completing my last exam, I have now finally completed the four years of my degree studying Mechanical Engineering. I guess that's party time for me!

With the unpredictable and quite volatile nature of British weather, there are bound to be a few days that will be pouring with rain, hence an opportunity for further work on getting this drawing module completed.

Over the past week, I have been making a few small refinements, consisting of fixes:

* Preventing a segfault when creating a dimension
* Fix for incorrectly placed dimension - was difficult to locate the bug
* Fixed a rounding error which meant decimals were not being displayed

Dimensions Arrows:

I have also added a support class for displaying dimension arrows, although these are just diagonals at the minute.

'

Having a separate QGraphicsItem class is more useful as it keeps the source code tidy by having the drawing code separate. Also it gives flexibility to manipulate the arrows, such as scaling, flipping etc more universally.

It would also be nice to get the page template working again, but waiting on some work to be ready!

Projected Dimensions:

I spent of time to work on this. Originally I thought this was going to be a difficult task. I thought that to get projected dimensions, I would have to make measurements of projected geometry, which would have been laborious to do. Instead, a quite simple solution is to use the same measurement code for true lengths, but project the measurement vector (direction and length) onto the view plane. Taking our complex case below, there will be a difference between true and projected dimensions.

Taking the top projection of this object and taking dimensions for the corner of each pad the result is below.

The dimension on the far left is the true length, and the right is the projected length. I have attempted to make all dimensions which reference orthographic views to use projected type. 

The next step is to work on getting edge to edge dimensions and angles working. The angles bit is more complicated because the angle value measured is based on the quadrant chosen. 

Quick experiment again with Sectional Views & General Updates

I am midway during exam season (two weeks) long and things seems to be going swimmingly which I'm happy to report.

Over the past two weeks I've just spent some time tidying up the code and trying to fix a pretty nasty crash in QGraphicsview, anytime you updated the view. I really hope this has gone, but if during testing you suddenly experience a crash when the view updates, please inform me. It seems to have disappeared but esentially was a problem with incorrect bounding boxes as the usual case is. Additionally I've just tidyied up the code and improved the performance by having QGraphicsView using a backend cache, so it doesn't have to constantly redraw features when it is unecessary.

Today, I decided to have a day off revision, as to be honest I am fed up with the mundane repetitiveness. Apart from what I mentioned earlier I wanted to take a quick diversion from the orthographic project stuff I've recently been looking at which I've also made a few improvements on.

I wanted to take a look back at sectional views which I had to give up on because I couldn't correctly produce faces by processing each edges in the correct order. I mentioned this in a previous blog entry some time ago.

Eventually I managed to find the problem and unexpectedly half of the result was from the drawing code itself, where although the edges were in the correct order there was a chance these could be reversed.  Eventually I got something working on most faces.

I then updated the work on the sectional view and behold...

This was taken from a simple planar cut through straight through the centre:

To be honest it's only a proof of concept that i've created over the past few hours. I have identified that some changes are needed to improve the structure to something less 'hacky'. The other limitation is there won't be use of 'true' dimensions because references are lost when the boolean cut is applied.

----------- UPDATE ---------

We all like updates. Spent this evening on it again, rather naughtily and tidied up the areas that I weren't happy with. The section plane is now it's own object in the drawing view, so I had to build up some infrastructure around there which I am more happy with. Now we can finally get some sectioning goodness!

I need to fix a bug that's causing a segfault, so hopefully soon I can push this for people to try and experiment with probably more complicated shapes. 

First work on Orthographic Projections

Having had a bit of a day off, I spent some time working on Orthographic projections with the Drawing Module. One of the problems with the older implementation was that only a projection direction was provided. This meant that the GUI / SVG had to deal with applying transformations to obtain the correct projection which isn't really ideal. All this took a while to realise, however, both the projection direction and its orientation (X-Axis) can be set during the Open Cascade Projection Algorithm.

The result is above and it later will allow more convenient production of orthographic projections, by setting the view type below.

The next step is to collect these orthographic projections together and allowing having these align to each other. 

Drawing Updates & Bloodhound SSC

Pardon me for starting the post off-topic, but last night I went to a talk given by Richard Noble the director of Bloodhound SSC (below), aiming to achieve Mach 1.4 or 1000 mph (~1600km/h ). I freely admit it was an inspiring talk and especially given how little I knew from the small excerpts produced by IMechE - UK's institute for Mechanical Engineering, it provided to be very informative.

Bloodhound SSC

Why I raise this, is that one of the key emphases on the talk is about inspiring the next generation of Engineers not just in the UK but all over the world - akin to Nasa's Moon Landing Programme in the 60's. We share a responsibility as engineers to foster the development of the youth. Many open design such Raspberry Pi and Adruino  are sharing such successes involving children and young adults alike.

Without becoming too philosophical, FreeCAD would be part of this idealistic goal. Being able to provide free but importantly open tools that I never had when I was at school would bring opportunities I wouldn't have dreamt off - I was the one of the last generation at our school to produce hand-drawn drawings, which shockingly was only six years ago.

Ultimately if you cannot contribute to FreeCAD as a programmer, there are endless ways you could help and I wish to thank the members of our community for doing so without initiative!

Back on topic: Drawing Tweaks and Updates

Probably the biggest changes came last night and was most surprisingly because of the fact how tired I was. The Drawing View (QGraphicsView) updates itself when you change it's property, this includes dimensions too and surprisingly works very well. Additionally the drawings are correctly created when you restore a document. 

Hopefully I'll publish a video to better demonstrate this, because  find it a satisfying result.

The other changes is scale independent rendering, edges retain the same stroke width regardless of the document zoom.All this we get for (nearly) free in QGraphicsView! There's a problem with selection at the minute, but hopefully will be sorted out soon (Fixed). I don't believe this is easily done using SVG because transformations are applied at object level. 

The example of above scales as you would expect, which was scaled really small on my screen but is not desirable in CAD drawings. You don't want lines to obscure each other when you zoom in, especially on an extremely complicated part with greater detail such as below.

I've also added a scale option. This currently transforms the original FreeCAD Part, however, I am still unsure is the best approach in terms of performance which could be natively applied in the projection algorithm. However, now it appears to work correctly.

In the previous drawing module the scale was applied at the presentation layer in SVG and wasn't really the best solution although it worked.

I wanted to put a picture up but I am currently upgrading Kubuntu. It will most likely not go smoothly, but atleast I'll be ready to report any problems compiling with FreeCAD.

Taken a short screen cast to show off the Drawing Module in it's current state. Only had 15 minutes to make it this morning, so sorry for the lack of quality!

Note: The drawing artefacts appear when recording the video for some reason but otherwise are not there normally.

Finally we have arcs that work!

For over a month this has been a problem where on 3D projections, arcs are turned into partial ellipses but were being incorrectly drawn. Attempts to diagnose the problem were unproductive - see the forum topic

There a sudden moments that make you realise that perhaps there is an easier way, just like last night. I though of mimicking the previous code that generates SVG directly. Instead of creating an actual ellipse arc, an cubic arc is produced instead - see the Mozilla Docs.For Qt to render SVG it must process this, so that there must be a method for drawing these somewhere. After some searching I found a function available in qsvg/qsvghandler.cpp. This had what I desperately needed and thanks to Opensource is possible.

Literally copy and pasting the relevant code - later will be re factored to be simplified if possible, this morning I got it working and produced the results I was craving!

This accomplishment crowns the ending of my Easter Vacation. I return to University tomorrow.

The couple of bigs tasks remaining are growing smaller. Ideally, I need the drawing to update automatically by itself, but changes don't propagate into non-3d views. Also we need working templates - looked at by Joshua.

The other is re-doing the export code - we get .svg and .pdf free with QGraphicsView, but .dxf.One thing I am going to enquire is an export to librecad. dxf sounds like the devil, so I think promoting an open format would go well.

The remainder should be smaller jobs that other people could get involved with. By then I hope I could get this be ready for testing by mid-summer. 

Little updates

Spent the past few days tidying up the Drawing Module as a needed break from revision.


It is starting to come together:

• Added support for radius dimensions on arcs.
• Added support for point to point dimension
• Improved selection of edges and vertexes
• Antialiased Edges

For an hour I spent adding a nicer selection box for moving a views around which definitely helps prevent annoying selection of the view. 

Dimensions are coming together too quite nicely, although the radius dimensions don't work yet in 3D view. I probably add some arrows, but these are not high priority. 

I've started the work on correctly showing hidden lines. I am pretty pleased with the result. I have opted for selecting the whole edge (visible and hidden), hopefully that seems reasonable.

I was slightly disappointed to find that references for some edges cannot be find in 3D views, however is a limitation imposed by Open Cascade. If a reference cannot be found, these edges are not selectable, since they cannot be used for any measurements. One possible idea to circumvent this problem is to compare the projected edges with references to edges on the original geometry that weren't found. This isn't really ideal, but would be a temporary solution.

One of the other problems is ellipse arcs which still I cannot figure out.

Parametric dimensions in the Drawing Module

After about three weeks, of having to work on various assignments (nearing completion) and revision, I finally had a day off to work on dimension support in the Drawing Module (see above and compare to previous post).

Obviously the dimensions look much better and are correctly positioned and it also shares similar behaviour to sketcher where if the datum label lies outside the arrow lines change position accordingly.

Additionally the dimension can be set to the edge length in X or Y direction now quite easily by changing the dimension mode. Currently the dimensions only work for Straight Line edges, but I plan to address some support for vertexes and obviously circular arcs.

One of the interesting things that had to be thought was how to reference edges that are broken up into smaller segments by any geometry in front.

My first attempt at this failed miserably, where I thought I would reference each segment of the edge and find the ends from there but clearly it wouldn't work. After scratching my head, I thought the best way to go was getting the reference to the original geometry and projecting the whole edge and using this instead for dimensions.

The limitation with this strategy is that if the original reference isn't available you won't be able to get true parametric dimensions. Generally this isn't a problem - nearly all the time I have found references are available and if they aren't usually it is for curves projected onto a 3D view.

It was a bit of work to get to work, because I was using HLRBrep_Curve and that require figuring out what type of curve was produced when finished. I kept to this OpenCascade Algorithm to allow perspective projections if they were ever needed. Luckily it worked!

Behold Parametric Dimensions!

The big test really was to change the projection direction and see what happens...

And yes it worked - although the datum label positions need correcting, nothing else had to be changed. Now changing the geometry (nothing too drastic)...

It's a pleasing result because it's been several months in the works to get this working, not knowing if this would be even possible. Obviously there's a lot left to do.One of my biggest problems at the minute is that if there are changes in the Document Structure, the drawing view must be closed and re-opened

The next priority is to tidy the module up more as it's still feels experimental.

First step of having DImensions in Drawing Module

Spent today working on adding dimension support. The first results are in and are quite pleasing. The dimension lines aren't correct but do indeed move interactively and the values for the dimensions update with changes basic changes in geometry. Obviously this is no where near being done, but is a step in the right direction once again.

-----

One area that does become problematic is making large changes in the geometry, and will be quite troublesome to deal with, even with robust naming. This should be a problem with vertices. because they cannot be decomposed further. 

Currently dimensions refer to the individual projected edge, or vertex because in theory multiple projected curves could exist. This needs further thought, but perhaps the best solution is consider merging projected edges together which share the original reference to the object and then having dimensions refer to these instead. Any ideas? 

Projecting Points - Drawing Module

Having started on dimensioning support I stumbled across quite an obvious problem, how would I do point to point  Dimensioning. Obviously I could extrapolate the points from the edges and use these, but any changes in the Base FreeCAD model and your dimensions would very easily mess-up. 

I started thinking about this last night and indeed to support such dimensioning modes with parametric relations, the points would have to be projected from the base FreeCAD model. I hit a brick wall trying to figure this out last night, but suddenly it came to me this morning. Sleep is a powerful thing. 

All I had to do is use the Projector algorithm to project points from project curves and then check if these can be referenced to the original object by checking if the topology exactly matches. 

The result is the above, all the points are recognised from the original object and now means we can in theory reference these. It is slightly dumb at the minute, because it projects points from all the edges (even if they are hidden). However, it should be trivial to fix this. 

Obviously in the GUI, the points will be hidden until an appropriate tool is used but is a step in the right direction indeed!

Easter break officially begins today and hopefully will have a helper who can assist me on the Drawing Module too *fingers crossed. 

Further work on Measurements Framework

I've spent a bit more time and adding more measurement tools that should be quite useful now for querying geometric properties of FreeCAD objects. This now includes measuring the

• total length of selected edges
• shortest distance between point and edge
• shortest distance between point and face
• radius of an arc or circle

Also now we can calculate the centre of mass for a selection of objects in a straightforward manner:

Fundamentally these were quite easy to calculate as they are provided by Open Cascade essentially for free and therefore it hasn't been very difficult to implement this.


Since the essential functionality is already there, the next step is to integrate this with the Drawing Module. This should hopefully be the start a dimensioning tool!

Hopefully I can push this onto Git for people to try during the weekend.


In slightly unrelated news to FreeCAD: I have finally received some funding for an interesting expedition that I will be attempting once finished University in June. Under this premise I do hope to continue working on FreeCAD as I will still be in civilisation and should have enough time to make smaller contributions and experiments that may be useful. It would be interesting to see if it would be possible to develop this on the go. Anyway we will have to see!

First signs of measuring

I spent last night putting something rudimentary together for this Measurement module to see how it will work. Surprisingly, I was up till 1:30AM probably because of a sugar high brought on by making chocolate cake last night. Nevertheless I was up bright and early to finish off my work from last night, and already we are bearing results:

Below 'Import Measure' are the commands used for making a measurement, hopefully it seems quite logical:

The output works correctly and fortunately when the geometry in the FreeCAD object does change, taking a new measurement does indeed return the correct result.

My only concern at the minute is whether it seems a good idea to bundle so many different measurements together in one package, even if the correct mode can be chosen and when the selection is incorrect an error is politely thrown to the user.

I guess in reality, this is more of a convenience solution to provide parametric measurement for most important measurements that both the user and in the case of Drawing Module may need.

What are people's thoughts?

Measurements Framework: (Plan of Action)

Having some further thought on making the measurement framework, my overall idea is that this should be very accessible to a novice user either using the command line or the GUI. Simplicity is key. Specifically the user should be able to specify a set of geometric features: edge or points and the measurement framework figures the rest out - that's the plan atleast!

This could be extended to gather more complex information such as surface area when specifying a face for the measurement or perhaps retrieving the moment of inertia or mass, for a given FreeCAD part. 

Querying Information:

This builds up a quite complex cases, but what I think would be eventually be a good idea is to create an extensible approach, so that plugins could be called to provide extra methods when querying a set of features. This is over-kill at the minute, but could be interesting. 

If a particular query cannot be made - e.g. querying the surface area of an edge an Exception will be thrown. Potentially this means we could introduce annotations that can reference the measurements and appropriately display output: e.g. 'Volume of My FreeCAD object: myMeasurement.volume()'

Building Annotations and Dimensions

Making use of measurements can be temporary, (whether in the command line or GUI). Using an object to store this information with reference properties means that these can be parametric hence update automatically. This means we should be able to pass this Measurement Object to a Dimension Feature and it can automatically create this and be absorbed into the Document. 

The Dimension Feature will be an Annotation Feature which will provide a more extensive coverage of options such as tolerances, dimension line type etc. These Dimension Features could in theory be used in the Drawing Module or in any other area of FreeCAD or atleast I would hope. 

Hopefully this sounds good!

Now it's time to shut up and time to start coding!

Thoughts on making Measurements

After having some troubles with projected faces (dealing with correct wire orders)  for the mean time I have considered looking at measurements or the ability to add parametric dimensions to drawings. These are dimensions which will update with geometry accordingly.

With some discussion on the forums about this: further discussion encouraged the idea for a generic measurement framework which would be useful throughout FreeCAD to make useful parametric dimensions and 'temporary' measurements which are common place inside most CAD packages.

Temporary measurement is a tool that provides a quick and convenient method to check the length of an edge or the distance (including components) between two points. These points use geometric references to provide a more accurate measurement unlike previously.

Parametric dimensions are more permanent and would be stored inside the Document as a feature or an annotation in the Drawing Module.

The Measurement framework aims to take a set of geometric entries such as line edge or two points and calculate the distance between them using a given vector. This is fairly simple stuff, but having a centralised framework would allow it to be adopted in other areas in FreeCAD, namely the Drawing Module for providing dimensioning support. it is in fact possible to calculate this from the projected shapes inside Drawing but using the previous reference geometry provides a means of obtaining the 'true' value for the geometric feature and will adapt to changes to the 3D Part more sensibly. However, in the future there could be an option for using projected lengths. 

Eventually, I would imagine this can be extended for displaying and calculating more complex properties such as moment or inertia, centre of mass etc. For the time being the measurement framework will only provide a c++ and python framework. The focus for the interface is simplicity - where it will specify the geometric features used and should then be able to determine measurement. There will be most likely ambiguous cases so giving an option to override this seems sensible.

In the Drawing Module  my aim is to apply a similar philosophy of creating dimensions using one tool; some people don't prefer this understandably, so there will tool bar and menu options for creating specific dimension types. In most cases this will allow convenient dimensioning.

I still need to figure out including point contacts since these are not explicitly projected by OCC and are contained inside the edge data.

This was slight regurgitation of thoughts I had on this before I attempt to start so apologies if this wasn't written well.

+ Checking out the current state of the Drawing Module:

I figured that it would be good idea to share my progress so far and allow people to contribute. The module is no where near ready for any testing - so please don't point out the obvious if something's broke. If there are any users interested in helping develop I would be more happy to take feedback and contributions to help with development!

Please checkout the github repo:
https://github.com/mrlukeparry/FreeCAD_sf_master/tree/drawing

A bit of fun on the side: Compiling with Clang

In the other bit of spare time I have considered looking at compiling FreeCAD using Clang. The end result is that only a few changes are needed to be made to the FreeCAD source so that it compiles with Clang.It doesn't seem to affect building using g++ either. I haven't measured the performance yet, but noticeably compiling takes less time.

I still need to collect these changes and post a patch for this and allow other people to test it out for themselves. I also have to find how I can debug FreeCAD after compiling with Clang - it appears to be incompatible with GNU's gdb.

Other Progress (slightly off-topic):

Workload seems to have increased once again at University. I spent a bit more time at the weekend on the Drawing Module: the majority of the work is looking at projecting faces onto the drawing plane. This is relatively similar to before but requires further work to sort edges into order, store these in a general format and then drawing using Qt's painter system. There's still work to do, but when I get that complete can hopefully share it.

What is Clang?

Clang is an alternative compiler that use LLVM to compile a variety of programming langaguesusing runtime optimisation methods. LLVM is used heavily in Mac OS X to improve graphics performance applications, but is also used in a handful of open source projects - in particular Open Source graphics drivers. LLVM provides the possibility to compile many different programming languages from Python, Fotran, OpenCL and importantly for this post c / c++.

Clang provides the infrastructure for compiling c++ and aims to offer a better alternative to gnu's gcc in terms of performance, better usability to developers and other advanced features such as static code checking. I won't say much more, but it seems a good alternative and therefore I decided to look at compiling FreeCAD using Clang.

What I did?

1. Install Clang
2. Change default compiler for make tool chain
3. Change some of the check inside CMakeList.txt file
4. (Ubuntu) Add a symlink for libgfortran for the linker to correctly work

Selecting the default compiler for your system (Ubuntu)

Most importantly install clang on your system. It seems that with Ubuntu installing clang introduces a an unwanted dependency of  gcc 4.6. Once installed, depending on your system you can inform Cmake explicitly to use clang or alternatively you can change the system wide default for make to use the clang compiler.The first option is obviously the most sensible, but I am not sure of the command.

The only help I have seen on setting the compiler is the following stackoverflow question:

In Ubuntu, it is straighforward to update the system wide compiler use for c++, simply run

sudo update-alternatives --config c++

This will bring up an interface to select the compiler you wish to use:

I need to post the patches to CMake, hopefully soon and these can be verified by other users. 

Following this, configure using cmake and then attempt to build using clang. You may notice that there is a linking error for lgfortran and then the build system fails. I think this is an issue with Ubuntu, but to solve this I had to create a symlink to gfortran library which isn't very convenient.

sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.so libgfortran.so

Hopefully FreeCAD should happily compile very fast now at blinding speed!

----Update---

I have spent some time last week to look at some further details.

Compiling using Clang per project:

There is an advanced option within CMake to specify what compiler to use for c and c++ per project build. Fortunately KDevelop makes this rather easy: Open Project Configuration by right clicking on the project to open the following dialog:

Click 'Show Advanced Values' and then set the following variable:

• CMAKE_CXX_COMPILER  = /usr/bin/clang++ 
• CMAKE_C_COMPILER to /usr/bin/clang

Compiler flags can be conveniently set in CMAKE_CXX_FLAGS, where for both gnu compiler and clang -g is for full debug.

Specifying Variables in the command line

It can also be done in the command line - I found really straightforward Guide for setting Variables in Cmake from (http://www.llvm.org/docs/CMake.html#id8)

Variables are set quite easily - simply prepend -D before the variable name and assign the value like so

cmake -DVARIABLE=value

Alternatively, you can specify the type of the variable below:

cmake -DVARIABLE:TYPE=value

Debugging with Clang:

Unfortunatly there is currently a bug that is preventing gdb being used with clang, which is apparently fixed in the latest release. I tried to get this too compile but I encountered errors. Hopefully with the next release of LLVM and Clang 3.3, the issue will be resolved. 

Compile OpenCASCADE Community Edition the Easy Way! (Update)

Introduction:

After a very late last night as a result from the following: splitting my head for three hours on Finite Element Modelling and for some reason watching Back to the Future:Part II whilst figuring out some code for the section plane, unbelievably I managed to wake up reasonably fresh.

Before starting on the chore of further University work this afternoon. I've been playing with compiling OpenCascade Community Edition in attempt to remove the shackles of Ubuntu's dictated policy of offering old packages.

All of this was inspired by a message on IRC #freecad over the past week about compiling OpenCascade with debug flags, so we actually have useful output when OpenCascade crashes without a warning (mostly from an unhandled exceptions on our part).

Benefits:

• The other benefits are testing some new features - only recently has a commit been made to improve performance of boolean operations that will soon be merged - see discussusion
• Full debug build so we can trace crashes correctly
• Living life on the edge of your seat!

The first compile went really well, however, after attempting to compile FreeCAD I found that there were a few missing libraries that prevent FreeCAD from building. These were the visualisation and Model Exachange packages used by SMESH and Part for the IGES and STEP formats import.  I am not sure if these should have been detected by FreeCAD's cmake but anyway, trial and error prevails.

I also attempted to build OCE using TBB which is a threading library that can be used to speed up operations, however from what I read this is only used in a few algorithms.

Note:

Compiling OpenCascade does take a long time, around probably 50% longer than FreeCAD for a clean build. On my six core AMD Bulldozer computer, it took in the region of 18 minutes in total to compile with each core at 100%. Also remember that you will need additional time to compile FreeCAD again. Once this has been done, recompiling is very quick.

Be prepared to find something useful to do in the mean and drink tea or even a beer for a good half an hour.

Compiling OCE OpenCascade Community Edition (Easy Guide):

Reminder: expect 20-30 Minutes to compile:

Clone the repository:

Grab the latest git source from the official Open Cascascade Community Edition from the github page. The source is around 240mb when fully expanded and may take a while to download on a slow internet connection.

git clone https://github.com/tpaviot/oce.git

Create a build directory:

Create a suitable build directory, this can be in the main source folder but preferably outside to prevent potential conflicts

mkdir oceBuild && cd oceBuild

Install libftgl-dev in Package Manager:

You need to install following development package for libftgl to compile the Visualisation Package in OCE. This will depend on your Distribution. 

Install libtb2 & libtbb-dev in Package Manager:

For enabling TBB - Threaded Building Blocks Library to be used in multithreading, you will need to ensure that these are installed on your system. Below are the package names in Ubuntu.

Remove any previous Opencascade libraries provided by distro:

I don't think OpenCascade and OCE can be run in parallel on the same machine - correct me if I'm wrong. Therefore you will need to remove any of these on your system.  

Configure the sources using CMake

Configure the OCE sources running the following cmake command in the current directory. This will install OCE to your /usr directory. 

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/ \
      -DOCE_INSTALL_PREFIX:PATH=/usr/ \
      -DOCE_WITH_FREEIMAGE=OFF \
      -DOCE_WITH_GL2PS=OFF \
      -DOCE_VISUALISATION=ON \
      -DOCE_DATAEXCHANGE=ON \
      -DOCE_MULTITHREAD_LIBRARY=TBB \
      -DCMAKE_BUILD_TYPE=Debug \
      ../oce

If you're installing on Ubuntu or Debian based distribution, it's advisable to change the install directory to /usr/local to isolate user compiled packages (@yorik) - (I need to confirm if FreeCAD can detect the location of the OCE header files from the location)

-DCMAKE_INSTALL_PREFIX:PATH=/usr/local \

You may find that there are some missing development dependencies, so if there are you will have to install these using your package manager. I found generally if you could install FreeCAD you wouldn't experience any problems atleast on Ubuntu.

Create a release build (Improve Performance):

You may not want debug flags enabled so that you can have full compiler optimisations and full performance when using FreeCAD: change the line previously from

DCMAKE_BUILD_TYPE=Debug \

to

DCMAKE_BUILD_TYPE=Release \ 

Begin Compiling:

When you start compiling OCE  be prepared to wait a while. Replace 6 with the number of cores or independent threads that can be run on your computer to speed up compiling by running concurrent make operations.

make -j6 -pipe

There has been some discussion whether the '-pipe' argument can reduce compiling times. If someone has enough time to make a comparison with OCE it would be interesting to see the difference.

Install:

Usually I install any compiled software to my user directory, but that wouldn't be straightforward. Therefore CMake was configured to install to /usr directory for simplicity later on. 

sudo make install

Installing on Debain / Ubuntu Systems:

Another helpful hint from @yorik is to install using the built in utility checkinstall. This provides a convenient method of uninstalling OCE using the system's package manager. Once you have finished compiling, run the following command:

sudo checkinstall

Type (y) to accept the defaults, then you will be presented with a menu to further describe the package - do this at your own leisure:

Once checkinstall is completed - this will take a while, it will produce a .deb package and OCE will have been installed to your system and registered in your system package manager.

Recompile FreeCAD:

There will be changes to the development sources since we are using a different edition of OpenCascade with FreeCAD. You will need to clean all the sources. From your previous FreeCAD build directory make sure run the following before recompiling (see previous post on compiling FreeCAD :

sudo make clean

If OCE was compiled and installed correctly, whilst configuring FreeCAD you will find the following log message (OpenCASCADE Community Edition has been found):

Recompile once again and you should have FreeCAD working with the latest OCE!

Hopefully people will have understand the guide and will now have a working version of OCE that is is used by FreeCAD. If there seems to be problems or something isn't clear, please let me know and I will update the guide. 

Drawing Module: Section Views

This past week has been a tremendously busy one at University, but in the few bits of time I do have available, I have been looking at incorporating section views into my experiments on the Drawing Module. For those unfamiliar what a 'Section' views, below is an example. These are highly important in mechanical design and allow complex features to be seen and also annotated

Sectional View Along Axis A-A

Yorik, already did some work within his arch module purely using the python capabilities within FreeCAD. This can be used in the latest release of 0.13. His solution is simple but works well. Below is a representation of the sectioning algorithm (I am currently waiting for a download to finish so found the time to draw it)

1. The user defines a 3D plane. The 3D Plane is then checked to see if it intersects with the object
2. The bounding box for the FreeCAD part is then projected onto the cutting plane - there are 8 points.
3. The maximum size of each projection on the principal axes of the plane are found. These are then turned into an extruded box prism and a boolean cut operation leaves the remaining part.
4. The remaining sectioned part remains. The faces are then projected and if they are coincident with the cutting plane it will be sectioned face.

Interestingly enough I decided to mimic such behavior in the Sectioned View of this. Although relatively simple, in c++ requires finding the correct modeling algorithms in OpenCascade. After some mind boggling, I eventually got something crude to work.

The functionality I am aiming towards is something similar to the functionality in other commercial CAD packages (namely Solidworks). My view is that using a 3D plane to section an object can be slightly tedious and awkward - atleast until we get a plane feature with the arrival on the Assembly Module. Instead I think it is more practical to create a section in the 2D Drawing User Interface.

 The user can create both 3D and Orthographic projections of the object and the user will 'draw' a section line AA in 2D. Upon completion this will create a new 'Section' View to the side that can be freely positioned.

The section plane is calculated simply by taking the cross product of the current view normal and the line, which produces the new normal of the plane.

This would hopefully cover most cases, but it should also allow an arbitrary plane to be set to create more flexibility when sectioning. 

The one complication that arises is that references will be lost because of the boolean operation. This will be of concern atleast until we get the more robust naming mechanism.

Hatching:

Any sectioned faces or even chosen ones should be fillable with a hatch pattern. This can be detected automatically if the face is coincident on the plane. I haven't yet decided the approach for storing hatching information but should be relatively straight forward.

I am hoping to get some more of this done tonight or tomorrow and have something to show but that all depends on University work... 

FreeCAD 0.13 Official Release Available

A big congratulations to everyone who has helped make our latest 0.13 release possible! This include all the contributors who have helped develop, code, build and of course our endless list of patient users who have been diligently testing our development snapshots.

There has been so many improvements throughout the whole application. Many new features have been added and further performance and stability improvements in sketcher has been achieved over the year. The release notes give a snapshot of what has been achieved over the past year. I stand now still finding it unbelievable how much momentum we have gained over the past year. 

It isn't official but we may decide to back-port improvements and bug fixes for the relatively stable 0.13 release now. 

The Future: The long road ahead

The future looks very promising, with numerous cool features in the works! The most anticipated being the Assembly Project. This is not to mention my render workbench and some other improvements that are hidden away in my git repos which are waiting further testing and refinement. My personal motivation is to get someone to use my render module to produce a render of their design for the new FreeCAD splash screen!

My pledge to everyone get involved, however you think you can! This doesn't have to be programming in python or c++, but there are  many ways you can get involved

• Test our development releases for bugs

• Help other users on the FreeCAD forums

• Create and publish tutorial guides

• Improve our documentation and translation efforts

• Design, Maintain and help our websites and promoting FreeCAD

• Package FreeCAD for Linux Distributions

Drawing Module: A Sneak Peak!

Having some time off this weekend, I have spent a bit of time further working on the experimental Drawing Module: I won't post the details of how I've got to where I am but I thought I would provide to you lucky guys a sneak peak at what I have currently achieved:

The left is the Drawing Module using QGraphicsView elements and the test model is on the right, although I am trying to work out why the projection isn't correct - maybe it's first angle projection? Also the edges that don't match up are arc of ellipses that aren't correct but that should be trivial to fix.

The point is I have manage to correctly project edges and rebuild nearly all the edge references from the original model, I found that on some occasions because a curve is broken up, the references can be lost but these are nearly always in 3D views, which would be difficult to dimension. It also supports edge selection and moving this projected view around the canvas despite there being no template.

The next step will be to tidy up the code and implement full interactivity and integration with FreeCAD's App::Property system, so that it can take advantage of the undo/redo framework.

 One of the frustrating things is not having anti-aliasing support in the opensource ATI drivers.

The Drawing Module: Part 2

As previously discussed the Drawing Module does it's job and produces the drawing our users require, but has its limitations. Now having some a little spare time every now and then in the evening, it seemed a nice little job in the mean time to experiment to see if we could improve this. How I envisage the Drawing Module to work is similar to what I've experienced in the past but relatively similar to its current behaviour.

Planned Workflow:

This is just an idea of the workflow I had in mind for using the Drawing Module.

1. Create Part/Assembly
2. Opens Drawing workbench
3. Creates Page Feature
4. Select template document and page properties (inherit data from FreeCAD document)
5. Select Part and create view (2D or 3D Projection, Section)
6. Add dimensions (attempt to import any sketcher dimensions - will require name framework)
7. Manipulate view features directly (move, 
8. Orthographic Projections can be created by dragging a projection in direction.
9. Provide a Measure tool for edges
10. Add Annotations to drawing
11. Provide a BOM or List of Parts

A note on page templates:

Currently the template would be kept as SVG so that this can be edited. I still don't know if these could be generalised so that it can be exported to another format but I don't think it would make much sense. However ideally it should be very easy to manipulate any 'placeholders' . This is not an immediate issue but I would speculate that the template placeholders would have a special edit mode to prevent any accidental changes by the user.

Below are the first jobs that need achieving for experimenting with a few ideas.

First Job: Low level shape storage

By unifying and abstracting the resultant shapes that are projected by Brep_HLR there is no restriction how these can be later represented. This means if the projected shape is a circle, we store the center point coordinates and its radius. This is extended to points, ellipses, b-spline form.

These can later be converted very easily into any other format whether .SVG, .DXF, Html Canvas or perhaps even Librecad may produce their own representation - who knows? 

It also allows us to represent this graphically in any way we want. Every time our part feature changes, this geometry is recalculated and can be then used in the user interface as needed.

Second Job: Building References

Looking more deeper into the projection code. Their algorithm seems to work by projecting all the edges and faces onto a projection plane, quite similar to an OpenGL projector. Then the algorithm sorts through all the edges and compares these with each project face to check if they are hidden.

Each edge and face is mapped from the original TopoDS_Shape and an index is built. By extracting these we can build up better integration so the drawing can have more interaction. I.e. we can extract edge lengths or update the projection without losing our annotations.

Third Job: Graphically Interface for Drawing

This could be done in SVG or using any other method. I prefer the use of QGraphicsView simply because it provides a framework for building up interactivity at a lower level which I don't think can be achieved in a web interface and should hopefully improve performance too. It would have been interesting to have used QML or QtQuick, but there are no objects available for drawing arbitrary shapes till Qt 5 and is more appropriate for dynamic interfaces. 

Conclusion:

Obviously there is more stuff that definitely needs considering, but this is at the moment an experiment to see what is feasible. In summary, what I am attempted is building a lower level data structure for storing geometry and reference data that can be exported and manipulated easily in any format. Then integrating this into QGraphicsView. 

Overtime I will report on my progress for what I have currently achieved in my spare time.

The Drawing Module

Over Christmas I have been away at home and in the mean time been quite busy with several projects for University and following graduation next Summer. Time has been quite short, so I haven't had the greatest chance to really work on much and that includes the CAM module. Instead, for the hour or two I have most evenings, I have been looking at several areas and thought it would be interesting to take on the Drawing Module. This module is quite isolated therefore much easier to develop without having to consult people.

Drawing Module:

The Drawing module is used for 'documentation' of FreeCAD part models. There is a great misconception that it should be the equivalent of AutoCAD or its free equivalent LibreCAD, which only recently have I had chance to use for documenting an architecture based project. There has been many discussions on this area on the forums in particular: however I didn't feel the module was intended for the production of technical drawings similar to other commercial offerings.

What I was taught as Engineer is that the production of technical drawings is to provide a reference detailed copy transferred to paper or electronic equivalent. This document should be readable by someone else and should allow this person to fully recreate the component inside CAD or manufacturing this. LibreCAD does offer the ability to document work becomes very cumbersome and leads to unproductive workflow. Let me illustrate, the user must have to export the model projection (degrading model information) and then manually drawing the Dimension lines each time.

What do I mean degrading information?

For example, when the Assembly feature comes this will support higher level information including the relationships of each part and most importantly a BOM - bill of materials. We also lose references between geometric entities such as edges. This means if we update the drawing, these changes are not necessarily propagated through and create extra work for us. With the development of Topological Naming, this should immediately take advantage of this.

The Current Drawing Module:

The Current Drawing module projects a part into a selected view and then gathers all the shapes and exports this directly into a the correct schema (.svg, .dxf) this works fine, as demonstrated currently, however is restrictive. Currently the drawing editor use QGraphicsView with QSvg which displays the SVG Result from the projection algorithm but doesn't allow any direct editing other than manipulating the SVG.

 There is currently the idea of moving to QWebview and rendering using the webkit browser, but I don't think this is appropriate even though it would improve the opportunity to interact. Using SVG for manipulating the drawing seems a bad idea and a more lower level data structure seems more appropriate.

Hopefully later I will explain what I am proposing....