Tag Archives: FreeCAD

Logarithms: Better than bad, they’re good!

Yesterday’s work was focused on two different TO-DO items:

1) I did a little bit of work on the position dialog box, as requested on the forum a few days back. The position dialog has two modes, incremental and not-incremental (I’ve been calling that one absolute), where the position indicated to the dialog is either applied against an object’s current position (incremental), or against the origin of the coordinate space (absolute). That mode is selected by a checkbox, the requested feature was to make the state of that checkbox persist between uses.

Screen Shot 2015-04-24 at 2.13.25 pm

In addition to making the checkbox state persistent, I ended up also changing around the transitions between the two modes a little bit, so now that part works a little more intuitively. Now, when incremental mode is entered, the GUI widgets are initialised to reflect the equivalent incremental placement to the change in absolute position that had been in the GUI before.

I suppose a video clip would’ve been a clearer way to convey the original problem and my changes…

2) The auto-scale in Drawing had a few problems, so I’ve re-worked two areas to resolve those.

First, there’s a little function (Attributed to David Eppstein, whose blog led me off to reading about the Harriss spiral – neat stuff) that takes a scale value and computes a ratio of two integers that closely approximates that scale. The problem was that the function wasn’t really setup for handing big or small scales, so I wrapped it up with a little math to essentially deal with adding 0s onto either the numerator or denominator depending on the scale.

Second, the algorithm for calculating the initial scale to use didn’t handle small scales very well. The re-work there was a little more involved, but fortunately a lot of my earlier work on the placement of orthographic views was useful.

So, now it’s easy to use the drawing workbench for bigger or smaller things than it used to be, though there are still a couple issues. One of them is that there’s a hard-coded level of detail parameter somewhere, which I intend to do something about. So, right now if I try to draw a sphere the size of Earth, then it gets computed to some absurdly high resolution, 0.01mm or something along those lines. There’s a similar problem in the regular 3D view part of FreeCAD too, for instance at the default settings a circle drawn in Sketcher looks like a 30-something sided polygon, so maybe that issue requires a bit more thought.

Aleph Objects Rocks!

For a few days now, I’ve been meaning to post an update here on the general state of this experiment. This afternoon, I received a nudge in that direction in the form of a very generous donation from Aleph Objects, makers of open source LulzBot 3D Printers! Thanks so much!

lulzbot logo

For the last week or so I had been considering reducing the time spent on this stuff, as the numbers just weren’t adding up. Now though, it’s clear that I can keep at it for a while longer!

With that in mind, a few thoughts about the experiment so far, in no particular order:

  • The sense of accomplishment that goes with a commit to an open source project is amazing! Open Source gives a real sense of connection with the customer, and there can be an aspect of instant gratification too since it’s so easy to share changes.
  • Although I really like my somewhat-outdated MacBook Pro, laptops aren’t the best ergonomically for all day work. So, I intend to arrange a better workspace, starting with a regular desktop monitor (which I suppose implies a desk!).
  • Keeping abreast of the FreeCAD forum, and updating this blog, takes quite a lot of time! For some reason though, it still feels a bit weird to admit to spending time on work-related online reading, posting, etc. In a regular job I wouldn’t think twice about accounting for equivalent time spent in meetings or on conference calls, but for some reason the OSS equivalent doesn’t feel the same.
  • Especially considering how little effort I’ve put in to publicity of this project, I think this is a viable way to spend a few weeks/months in a productive and fulfilling way. That said, I do need to find a Real Job, and it’s hard to get motivated to work on that while I’ve got so much other fun stuff to do! Fortunately, things on that front are still moving forward, stay tuned.
  • I’ve mentioned the Dunedin maker space, DSPACE, on here only briefly. It’s a great resource, and I’m hoping to get a bit more involved with that as the Drawing workbench gets a little more wrapped up. There are a few 3D printers available at DSPACE, so I’m hoping to get a bit more hands-on experience with drawing up parts in FreeCAD to be printed on them.
  • Getting back to the Aleph Objects donation – as a former Boulderite, I’m super proud of the Colorado tech scene! Thanks guys!

little things, and The Process

While I was playing around with FreeCAD today, I felt a little twinge of frustration and decided to do something about it. Perhaps my loyal reader will find the process of identifying issues, fixing them, and publishing fixes interesting?property viewer

There’s a widget, the “Property Viewer”, which is one of a few key GUI components in FreeCAD. It contains two lists of properties (dimensions, positions, colour, etc.) for the thing you’re working on, and allows them to be changed. There are other ways to change most properties too, but the Property Viewer has everything in one place and is usually accessible.

The Property Viewer has two tabs; Data and View, so you can either work on Data properties or View properties at any particular time*. The issue is that I manipulate Data properties much more frequently than View properties, but FreeCAD always starts up with the View tab in front. So, I usually have an extra click to get Property Viewer in the right mode for changing the properties I’m interested in.

To fix this, I added ~20 lines of code to save the last tab that was selected, and to select that tab next time FreeCAD opens. Then, I “pushed” that modification to github, and made a brief post to the FreeCAD forum to ask people to try it out and comment. Assuming that my change doesn’t cause any problems and people like it, in a few days I’ll submit a “pull request” and one of the core developers will bring the code in to the main FreeCAD codebase (unless they notice a problem in the new code). Not all changes justify asking for popular opinion and testing, but that’s a judgement call. This particular change affects a core GUI component of FreeCAD so I felt like it was worth asking.

Every now-and-then, a “release” is made of FreeCAD (incidentally, we just made a release today!), next time that happens, any changes incorporated to that point will be included. Releases happen every few-to-several months, so in the meantime people can only get the new changes by building from the latest source code, which is what some of the early posts on here, for instance the one about building on OS X, are about.

All that said, the process for the Drawing module, which is where I’ve been doing most of my work lately, is a bit different. At this point there are only a couple people working on that module, and we’re working on a fairly significant re-write that involves breaking the existing Drawing module. So, rather than asking for comments and incorporating changes into the main FreeCAD, we [even more] informally push and pull our work to/from github to keep the latest and greatest moving forward. Eventually, when there’s some consensus that the module is ready to go, we’ll go through a testing phase with the wider FreeCAD community, and hopefully the whole thing will eventually be a part of the main codebase.

* Of course, as I type this, I realise that it might make sense to just get rid of the tabs altogether and just put all properties in one widget…

Bounding bounding boxes

Today, and a little bit of yesterday too, were involved in a bit more geometry-related than most of my FreeCAD time so far. That’s a good thing, I think, but a bit tedious at times.

Without getting too far into boring details, there were some problems in the Drawing module, which boiled down to objects having bounding boxes that weren’t centred on the origin of their coordinate space. This is a problem because the position of things displayed on the screen (eg one of the orthographic views), is calculated in part based on the object’s bounding box, which is assumed to be centred on the origin of the object’s coordinate space. So, with the bounding box origin changing, the position of the object would in turn change, and make things move around on the screen in odd ways.

Getting a little closer to boring details, the issue was that a scaling operation used the wrong origin – the objects were being projected to 2D, then scaled using the origin of the original 3D coordinate space. Result is the top situation, where the scaling operation “pushes” the object off to the upper-right. The solution is just to be mindful that the operations are combined properly, so that the scaling uses the centre of the object as the origin.
bb scaling issue

The patch behind the orthographic projections post basically corrected for this error at a later stage, so now that fix is unnecessary and future work will hopefully be a bit more intuitive! That’s how it goes though; it took a “first draft” solution to see what the problem actually was, then the final draft got a better solution, but obsoleted the first.

Have also put a few hours in to work on the file opening stuff – the patch I submitted has some issues on Windows (unicode…), and so have put together another version. Unfortunately, the second iteration involves some changes to an “external” (quotes as it wasn’t written specifically for FreeCAD, but is packaged with FreeCAD’s source code) open source library, so not sure how that’ll go over. It’s a really annoying problem; basically the issue is just that we can’t confirm the filename of the first file stored in a zip file…

More about file opening

Today, I spent a couple hours trying to understand, and possibly re-work some of the FreeCAD bits involved in opening documents following yesterday’s diversion.

In the end, it looks like “fixing” this would take a bit more effort than I want to put into it, for a rather small gain compared to some other areas. So, if anyone else is interested in a project, there’s a branch here https://github.com/ianrrees/FreeCAD_tinkering/tree/read-unordered-zips that has some of the work done, but I think the proper solution will involve getting rid of the current istream-oriented approach in favour of something that’s file/database/XML-oriented. Basically, I’d start with removing the current Base::Reader’s inheritance from istream, then replace the getStream() with something more like getStream(specific_filename). Right now, Base::Reader has an awkward “is-a and has-a” relationship with istream, which in my opinion needs to go away. The combination of the XML parser, and only maintaining stream handles (versus handles to the original input file) is why we have the requirement for files to be stored in a specific order inside the FCStd file.

Have put also some time into updating the wiki, making some notes, doing some testing, and putting together a small patch that improves the error handling and reporting around improperly formatted input files.

Another TO-DO too: When a file fails to open properly, it should either not leave an open partially-loaded document in the GUI, or it should prompt before saving over the original document. As things are, it’s really easy to “shoot yourself in the foot” if FreeCAD fails to open a file, because hitting “save” will overwrite the entire original file with only the bits that FreeCAD managed to open successfully…

FCStd Format

I went on a bit of a tangent this afternoon – the plan was to continue with some work around projections in the Drawing module, but I got distracted by working with the text in the bottom-right corner of the page…

That led to me wanting to modify a Drawing’s SVG template inside an existing FreeCAD document, which I don’t believe the Drawing module can do yet. I knew that the FCStd file format that FreeCAD uses is just a Zip container, so unzipped the file, made some changes, zipped it back up, and watched FreeCAD crash on attempting to open the file…

I discovered an old post on the forum that points out FreeCAD’s expectation that the files in a FCStd container are stored in a particular order. FreeCAD also provides a “Project tool” to handle exactly this situation, but that tool doesn’t seem to work as I expect it to, and the wiki pages for FCStd don’t mention the file storage order requirement.

So, the TODO item here is to, at a minimum, update the wiki pages that relate to FCStd, figure out the “Project tool”, and maybe get rid of the file ordering requirement if it’s not too much work.

Slow startup fixed, more TODO items!

The slow startup of Drawing was being caused by a “broken” regular expression, which was causing the text search it was used in to try using up too much of one resource or another (eg: stack space) and throw an exception (after ~20 seconds on my machine). There was a try/catch around that particular chunk of code, which essentially just kept the program quietly running.

Anyways, to get it going again I changed:

"<text.*?font-size:(.*?)px.*?x=\"(.*?)\".*?y=\"(.*?)\".*?freecad:editable=\"(.*?)\".*?<tspan.*?>"

into:

// Regex e1 attempts to find:
// [0] - A text tag that contains "freecad:editable=", and it's matching tspan tag
// [1] - positive integer font size in px
// [2] - pos/neg float x coordinate
// [3] - pos/neg float y coordinate
// [4] - one or more character Perl "word" for freecad:editable value
...
"<text.*?font-size:([\\d]+)px.*?x=\"([\\d.-]+)\".*?y=\"([\\d.-]+)\".*?freecad:editable=\"(\\w+)\".*?>.*?<tspan.*?"

Now, we get a much faster load, and the beginnings of another working feature! Now, we’ve got editable text boxes for the title, author, scale, etc. as encoded in the drawing templates. Of course, all this will require a fair bit more work before it’s ready to go…

Screen Shot 2015-04-05 at 11.05.12 am