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.
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.
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.
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....
Hi Luke,
ReplyDeleteThe move to webkit is actually more because qtsvg only supports a small subset of svg called tiny svg. It can't render many things like right-justified texts or hatch patterns, which can be pretty important in tech drawings...
I also don't like much the idea of drawing things directly on the svg sheet... Curious to see your proposals!
Hi Yorik, It is good to see you're back!!
ReplyDeleteI think it is your last point which is most important and I completely agree with. Having a low level representation using our Document Objects and editing these is what we need to build better integration with the rest of FreeCAD and support dimensions that dynamically respond to changes. It also means we can more easily export the whole Drawing document.
I do not actually have a problem using a QtWebkit for the GUI interface providing it can change the data structure directly and offer interactivity. It might be worth investigating this as an experiment later.
I am really curious if we could write your own projection you have in the draft module into c++.
Hi, this looks very cool! It's interesting to see some of the decisions that go into designing the drawing module.
ReplyDeleteI'm interested in contributing to freecad. Do you need any help on the drawing module? I'm new to open source, but have some experience with c++ and python and would love to help out.
Keep up the great posts!
Hi Andy,
ReplyDeleteYou are more than welcome to get involved and I would encourage it too! This was also my first open source project I contributed too also.
I am currently overloaded with work at University, so yes it would be very helpful if you wanted to contribute to the drawing module. It would be a nice module to get started with because it's quite interdependant from other areas of FreeCAD. Hopefully you may have some experience with QT?
Please send me an email l.parry(-at-) warwick.ac.uk and we can get things rolling from there