One thing I like to dip my toes into every now and then is speed modelling, specifically speed CAD modelling... The basic idea is that you are given the drawing for a specific object and you recreate in your CAD program as fast as possible. To me this seems like an obvious thing to practice. Doing CAD work is often extremely slow and unwieldy, and is often made worse by people not being comfortable with hotkeys and other such time-saving tools in the program like a pie menu. When "speed" modelling, you are also forced to practice coming up with a plan in your head as fast as possible, since your planning stage is included in your time.
Anyway, there's a lot to say about speed modelling. The purpose of this post is to talk about working on the "estimateWB" FreeCAD workbench made by one "erroronline1" on github. The point of the workbench is to simply give you simple metrics about your model like the volume and weight of it. Those two values are used to verify you did everything just right when completing a model from a drawing. I should also mention the other method in FreeCAD, which is the "FC Info" macro. I've tried both and found FC Info to be too much work compared to EstimateWB, but FC Info might be better for you and your use case (if you can get it to work).
I've done most of the programming a while ago, and without documenting it in a way that can be copied here. You should be able to check out the changes in the github pull request further down, and I've also given an overview in a forum post here. But, a quick overview of the changes I made before starting this post:
A pop-up that will display the weight of the selected object - this includes a button to copy the value to the clipboard.
Added units to the input box for calculating the weight given a volume.
Added a selector for different weight units
Since last I touched the project, the author made a few changes I wanted to make sure I had in my fork of their project. So, I added the original repository as a remote repository called "upstream" in my local git repo:
git remote add upstream https://github.com/erroronline1/estimateWB.git(I also made sure my fork was up-to-date with my changes). Once I was ready to merge in his changes, I followed this stack exchange post in order to get the new stuff. I originally tried rebasing my changes, but then discovered I probably should have done that before pushing my changes to my own repository. I'm not an expert in git, obviously. I just reset back to my existing changes, did away with the rebasing, merged in his commit to my code, and verified the whole thing still seemed to work.
Cool. Now I should be set up to make a pull request and hopefully improve the workbench! Before I submit one though, I want to make my strings use the provided language files - so it's possible to show more than just English text. This is a matter of replacing raw strings like "Set weight to" in the python source file, with a function call to pull the string from a .json file. The code to set the command name and the tooltip and all that looks like this now:
And one of the git diffs looks like this, with before & after:
I'll be leaving the German language file alone, since A) I don't know German, and B) I tried adding to it, and simply saving the file seems to have replace the space characters with different space characters...? No clue, I erased my changes and will leave it for the next guy.
The Pull Request
This is actually my first pull-request! I know, it's weird. I have worked on some other projects with other people before of course, but always with access to the source repository itself and able to push commits to either master or my own development branch. Indeed, a lot of the motivation of working on this workbench was to make a simple pull-request. When I am able to complete more work on the FreeCAD source itself, I will need to be practiced in making a proper pull request. Same goes for other projects.
Anyway, first thing to do is push my local changes to my 'remote origin', my github fork of estimate WB. After that, I went out and checked for websites talking about how to make a good pull request. Turns out there are a lot of resources for this! Some good tips are:
Rebase before a pull-request (oops! hopefully next time?)
Keep them small (not a problem in this case..)
Make sure they are well documented
Be nice :)
And with that, I made my first pull request. Link here. I went ahead and made it a full pull request, rather than just a draft, but I am interested in trying those as well in the future. I also believe it's possible to "update" a pull request with further commits, which would be extremely useful when adding large features and incorporating feedback or fixes.
Future Ideas
I don't know how much time I will be putting into this workbench, but it seems worth further development since it's so easy to use and is also very easy to install from the add-ons repository. Hopefully these ideas serve as future inspiration for myself and others:
Icon updates - they are currently bit ugly, though very simple and obvious
More body details - things like bounding box size, center of gravity, etc. I'd personally prefer if these were tucked away behind a few clicks so they didn't make the workbench too messy
A hotkey to bring-up the volume & mass of the current object, specifically for submitting those in a competition as fast as possible
Thorough testing with strange and complex parts - I have a feeling there might be some additional cases to consider.
Allow selecting multiple bodies at once - show the total weight & volume and maybe a breakdown of each one
Maybe make it easier to set your own material presets - I know I've seen some competitions where, for example, I think the ABS density was different than the one pre-programmed in estimateWB.
Maybe tweaks to the .gitignore file? Pretty sure it can ignore things like the pycache files.
Constant tally - just a tiny window somewhere showing either the current weight and/or volume. Seems like an interesting sanity check while modeling, but low priority
What I've Learned
This will often be the most important section. In this case I've learned a bit more about git, and I'm hoping I will soon be more capable with it. Mastering fancy commit history control, rebasing, proper commit messages, pull requests, multiple remote repositories, I learned more about all of this in this quick project. I've also gotten to practice my python skills a bit, and I've gotten to think about what I need in tools like estimateWB.
If I was to pull generic lessons out of this, I think I could say that doing things "right" the first time around has been proven wise once more. I could have made my pull request a lot sooner if I had included the language file strings when I wrote them the first time - and I knew that at the time.