Wednesday, 23 January 2013

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. 


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.


  1. Very good plan. I'd like to add a few more considerations:

    - Indeed I think there is not much sense to try to think in unified templates for different export formats. SVG is very different from DXF, etc. Ideally I believe in some future we might be able to create, inside the Drawing module, different kinds of pages, svg or dxf, each with its own template. But maybe it is even easier to simply convert the svg one to dxf, I don't know.

    - I didn't know the OCC projection algorithm was able to maintain a relationship between the original edges and the projected ones! This is super interesting, it would allow us to "tag" the edges in the SVG representation... Many possibilities arise there.

    - The problem with the OCC algorithm is that it treats everything as edges. So you cannot get closed, fillable areas from faces. I did a different method in the Draft module, which takes shapes face by face and project them as closed paths. This allows for any kind of fancy fill. Of course this works well for 2D shapes, not so well when you have hidden faces. For that, I made another system in the Arch module, which does face sorting ( But it is slow and cumberstone and not very reliable. One day I should try to pass it to C++...

    - I think you have it very right about modifying things directly on the SVG page... When you do that, it should indeed actually modify some property in the document itself, not the svg representation. So probably the most crucial part would be able to click the SVG page, and know which shape is under the mouse cursor... Now if we can tag svg edges, this might be easy, I believe one could even do that in javascript. I'll investigate...

  2. Hi Yorik, thank you for the comments!

    I am not really sure on the page template format - From my own experience, every time I have created a technical document I print it straight away or transfer to .pdf but having a backend flexible so that we can accommodate whichever format would be nice.

    The OCC algorithm hides alot of its functionality in its private methods and these you cannot even inherit from. It took some time to find this out. It does in fact project both edges and faces - you can get a list of faces too, but I don't think these are exposed in the sorting algorithm (HLRBRep_HLRToShape) so possibly we might be able to get filled shapes. I think having colored 3D views is quite important especially in your role. But it would be useful for technical documentation and illustration which is actually lacking the Mechanical CAD package I use.

    It would be interesting to look at - especially for the clipping / section views. I am still terrible at python but it might be a good exercise to convert it to c++ for you :) I will have a look at seeing if OCC can extract filled shapes when I am free.

    I will admit QGraphicsView is not the most straightforward solution , but if javascript were possible it would make life easier although I am unsure if it's a good idea to introduce another language to c++ and python.

  3. Ah the javascript I meant more because it will be easier for me to play with, and because with all the online drawing apps in html5 out there, there must be much example code to interact with svg elements. But of course the right path would be to do that in a more solid form...