YORIK’S COFFEE CORNER

Hi, this is my blog, and also a guestbook. I publish stuff I do from time to time. Be welcome and feel at home, have a coffee and don't hesitate to drop me a line or two. All languages are highly welcome, especially the most exotic ones (nederlands, bij voorbeeld...).

Also, get me on twitter, facebook or google+.

Already 98 messages this year, showing only last 50. Click here to show all, or browse by tag: sketches, freecad, opensource, trilhas, linux, works, architecture, projects, 3d, blender, detail, talks, inthepress, animations, opensurce, firefoxos, bede, idsampa, photo, gaming, wordpress, webdesign, Architecture, orange, cooking, or search the 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, .

First and foremost, your name:

And your message:

To publish it, just press this ...

permalink:  422   posted on 16.11.2017 20:27
From Yorik
Commenting post 420: Hi,
Doesn't QGIS import DXF directly? In any case FreeCAD doesn't export to KMZ/KML or shapefile... At the moment there is no tool to geolocate things

permalink:  420   posted on 15.11.2017 12:45
From David
Commenting post 274: Hi, thanks for this post it's very insightful. Was wondering whether it's possible to export a DXF file from FreeCAD to a format that can be recognized by QGIS (e.g KMZ, KML, Shapefile)

in categories  sketches  permalink:  419   posted on 11.11.2017 22:23
From Yorik
Todays drawings with the São Paulo Urban Sketchers group, at the iconic Copan by Oscar Niemeyer. By very far my favorite of his works...




permalink:  418   posted on 11.11.2017 22:20
From Yorik
Commenting post 417: Hi Jacob,
There is a "merge point clouds" option in the Points menu

permalink:  417   posted on 09.11.2017 10:32
From Jacob Abdelfatah
Commenting post 274: Hi:

Thank you very much for your valuable aportation. When I convert the contours into points I get several points cloud, each one associated to the respective contour. So, I would like to know how to join them into a single entity.

Thank you in advance
Best Regards
Jacob

in categories  sketches  permalink:  416   posted on 04.11.2017 21:25
From Yorik
Todays drawings, Rua 7 de Abril and Praça da República in São Paulo




permalink:  415   posted on 02.11.2017 23:06
From Kees
Commenting post 414: A lot to do!
Good to hear you now have more time for it.
Thanks for the blog and keep the good work going!

in categories  freecad  opensource  permalink:  414   posted on 02.11.2017 17:27
From Yorik

FreeCAD Arch development news - October 2017

Hi there,

Time for a new report on the development of Architecture and BIM tools for FreeCAD. Remember, you can help me to spend more time working on this, by sponsoring me on Patreon, Librepay or directly (ask me for a PayPal email or bitcoin address).

Campain and future development

Since I just recently opened the Librepay account, and the Patreon campaign is progressing much (I'm receiving above US$ 600/month already, thanks so much everybody!) I think it's time to be a little more serious and transparent about it, and give you guys some more "accountable" feedback on how the money is used. I'll start using this report to give a sum of how much I receive each month, all crowdfunding accounts together, and also make a bit of a better plan.

As you know if you read my last article, I just returned from the US, and we are also now finishing the WikiLab project (Grand opening is on next friday, november 10th). So I have been a bit away from FreeCAD coding for some time. But I've been saving the money from this campaign, and I'm now getting back to it, and it's quite refreshing! I have many ideas to work on, that I'm in the process of classifying. Basically I am currently working on two main ones (see below), and I'll also start attacking my overdue issue queue on the FreeCAD tracker, and I also have this "small" list of smaller items/issues that have either to be checked further or solved or implemented:

  • Publish FreeCAC manual as a printed book (it's reviewed already, almost ready)
  • Add visual feedback to rectangle, circle, polygon Draft tools when entering dimensions via keyboard
  • Fix IV mode in Sketchfab exporter
  • Allow to draw a beam/column directly, like walls
  • Add option to make Length autofocused when drawing line/walls, so one can indicate a direction with the mouse and type a length, same as AutoCAD does
  • Move back the Arch Floor concept to Arch Cell (like it was before), so the floor object (the name is wrong anyway) can be used to stack objects together in any form youmight think, not only by level/floor
  • Xrefs/lightweight embed objects from same file or other files - experiment further
  • Add a command to move selected objects to construction group
  • Work further on PropertySet type (a property that can contain other properties, tremendously useful for IFC property sets)
  • Allow to auto make a Window from solids (auto recreate base wires and extrusions)
  • Selection view - When typing in the search box, add an option to change selection on Enter only, otherwise, starting to type the first letters makes huge (and slow) changes in the selection
  • SArch materials library - A software-agnostic table of materials used in construction, with properties, color, generic textures, etc
  • Refine material editor - allow easy and proper editing of material properties with appropriate widgets (QItemDelegate)
  • Parking slot object and maybe develop a framework for all that category of custom, mostly-2D-but-not-necessarily-only-2D objects used in BIM work: parking slots, rainwater grids, etc...
  • Section/elevation symbol - Allow to easily add these symbols on a TechDraw sheet manually
  • Align TechDraw views - add a way to align different TD views made with Arch Section Planes
  • Experiment with Coin-based 2D views
  • Make all window parameters accessible in the property editor (O1, O2, W1, etc..)
  • Experiment using App::Part in Arch Cells
  • Better multi-dimensions like in Revit - refine the coin representation to reflect multiple dimensions
  • Level marks
  • Door/Window marks
  • Room finish marks
  • Auto section/elev marks from section plane
  • RCP plan
  • Allow to convert multilayer wall to multiple walls and vice-versa
  • Make all Roles available to all Arch objects
  • Allow to change Draft Label's target object
  • Add Rebar length property
  • Solve "length not working" in walls
  • Addon manager - allow to update all installed addons at once
  • Export meshes to IFC and handle hi-res objects
  • Task panel for Draft Clones (allow to add/remove objects)
  • Add "fill shape" to arch sections
  • Taper for structural objects
  • Remove background from offlinedoc css

I should really transfer all this to the bug tracker...

Current work

I'm currently working on two things, that are not finished yet and therefore not ready to be used:

One is a new FreeCAD importer for Blender, that allows Blender to import FreeCAD files. A prototype exists already, but the Python3 version of FreeCAD that is needed by this importer still gives me problems (crashes on opening, etc). But once that is solved, we should have a proper importer again. And it will have a couple of more advanced features too, such as Cycles support and the ability to re-import a FreeCAD file later, and keep all your existing materials (only update the geometry of existing objects).

The other feature I'm working on (I have no code that is good enoough to test to share yet) is adding Appleseed as a new renderer to the Raytracing workbench. In a first step I am simply looking at producing an .appleseed file from FreeCAD, that can be fed to the renderer externally (same as we do with PovRay and LuxRender), but Appleseed has a powerful and elegant python (and C++) API too, that can in the futre allow a much more seamless integration, and litterally control and display the rendering progress within FreeCAD. But first things first. I'm also extending a bit the Raytracing workbench code, which is currently C++ only, to allow to add new renderers in python code, which will make it much easier for other people to help and add more renderers.

That's it for this month I'm afraid, thanks once again to everybody who helps me with money, and for your patience with me this last months during the WikiLab construction, I'll make sure it was not lost and reverts into concrete, usable material to push the development of BIM projects with FreeCAD closer to what we all wish it to become!

By the way, if you haven't yet, check the amazing work that Regis is doing with recreating one of Aravena/Elemental open-sourced projects in FreeCAD...


permalink:  413   posted on 31.10.2017 17:52
From Mohamed Safaa
Hello, i am trying to import ifc file exported from revit, but when it is opened, the values of the properties of the objects seems different from the values in revit like height, width and the length is always zero.
so what is the problem here ?
thanks in advance

permalink:  412   posted on 27.10.2017 12:53
From Jordi Bardají jordibardaji@gmail.com
Commenting post 411: Thanks a lot for your narration. It's very interesting.

in categories  freecad  opensource  trilhas  permalink:  411   posted on 26.10.2017 23:41
From Yorik

The Google Weekend

Last week was the Google Summer of Code Mentors Summit, a yearly event organized by Google, where they invite mentors of the Google Summer of Code program, a program that pays students to work on open-source projects. This year, like last year, FreeCAD participated to GSOC. This year we had 4 really good students, and the one I have been mentoring, Amritpal Singh, has done a really remarkable job with his Reinforcement Bar add-on for FreeCAD.

The two years, FreeCAD participated to GSOC together with other open-source CAD, CAM or 3D-related projects, under the "umbrella" of BRL-CAD (they basically did all the organizing). Each year, Google invites a certain number of mentors from each organization to the Mentors Summit, at Google headquarters, in California. So this year, I applied and was lucky enough to get selected. We were five in the BRL-CAD group: Sean, Vasco, Gauravjeet and Inderpreet from BRL-CAD, and myself from FreeCAD.

My main motivation to go was, beside a huge curiosity to see Google inside, I was really eager to know and chat with the BRL-CAD people, our umbrella organization. This project is quite fascinating, it is the first ever registered project on Sourceforge, it is very hard to see it progressing (their website doesn't show much), but it is a huge and powerful application, that stays a bit arcane, and hard to explore by newcomers. But I had a good contact with Sean over the years, and was really curious to know more.

So, the said day, after a pleasant flight (not so pleasant because at he last moment they changed my São Paulo -> Mexico -> San Francisco flight to São Paulo -> New York -> San Franciso, which added 2 or 3 hours of flight time), I landed at San Francisco and shared a ride to the Google headquarters with other people going there (everybody chatting and arranging these things beforehand through a quite interesting open-source chat system called Zulip that got used quite extensively throughout the event. Another chat app, RocketChat was there too, there has been quite interesting debates between the two, I still didn't make my mind fully).

So we arrived at Google HQ, landed to our hotel (conveniently located INSIDE the Google campus (which is not really one campus, they basically own half the cities of Sunnyvale and Mountain View). This is located at the southern tip of the San Francisco Bay (San Francisco being at the North).

And it began immediately, right there. You get your badge, and immediately you can start eating and drinking and chatting, because they reserved some rooms of the hotel and stuffed them with food. After a little while, a transfer bus takes you to one of the Google building, where there is a dinner (two large restaurants plus many cafés, food trucks, etc where everything is for free were available for us basically the whole time), then an opening session, then a couple of lightning talks (3 minutes talks to present GSOC projects), then more beer

I couldn't get a chance to showcase our GSOC projects of this year though, there were around 300 people wanting to present theirs, and only 50 or 60 slots.

There was also a cool table where everybody dropped chocolate brought from all over the world.

The next day started early, around 7h, with a breakfast at Google, and a whole day packed with "unconferences" (basically small spontaneous lectures or workshops organized by the mentors themselves), more food, more coffee, more chat, more lighning talks, and at the end, of course, more beer, and even roast marshmallow on the open fire, maybe the most epic moment for us non-Americans.

The last day was like that again, and ended up with a closing session in the afternoon.

Like I guess most people there, I didn't attend many unconferences. I basically stayed most of the time in the common areas chatting with people. My impression is that I never chatted so much in two days. At the closing session, the event organizers said they were happy, because they almost never saw anybody alone with his computer, which is something you see a lot in other open-source events. Everybody just kept talking with everbody, all the time.

This is really a magic that Google operated. There were no "boot camp" crap, or "socializing games" or any of those activities to make people socialize. They just provided space, food, drink, and a friendly atmosphere. That's it. Even me who is not a very social person, kept playing that game of going sitting for lunch each time to a different table with unknown people and talk about our projects. I've never seen an open-source event like that.

I also tried to get a glimpse at how life is at Google, but couldn't do much. The security schema was tight, no pictures allowed inside buildings, we were only allowed in a very small zone of the Goolge campus, you gave one step out of it and a security guard came to herd you, etc. But all in all I believe they do their publicity extremely well. In my mind everybody at Google would just lie on colored sofas, picking free drinks in an open fridge, would cycle around marvelous campuses on Google bikes, etc. The reality seems actually much more normal, you just sit on your computer and do computer work, and have meetings with your colleagues. But the atmosphere seems really relaxed, there really is free drink and coffee Other than that, my spying mission at Google failed miserably.

Ah, there were ice cream sandwiches too.

I talked a lot with Ton Roosendaal, the father of Blender. I met him other times already, he always keeps an eye on FreeCAD too. Ton made me a bit anxious, because he told several horror stories about big companies threatening to sue open-source project developers about patents, and in some cases managing to scare developers away of coding completely. We really need to start thinking about that at FreeCAD, and think of strategies to protect ourselves as much as possible.

But we also talked about things we could do together with Blender. The big game engines out there are moving towards offering more tools for CAD software, and we should do something similar, like an easy/1-click, template-based export from FreeCAD to the new stunnigly realistic view mode they are preparing in Blender, called Eevee. Just do a small search on youtube for "blender eevee" and your jaw will drop

Another person I hanged a lot with if François Beaune (Franz) from Appleseed, a stand-alone rendering engine, similar to Luxrender. I knew Appleseed for some time, and I had a vague idea of trying to integrate it in FreeCAD some day, but this has now become a much better and more realistic plan, after François showed me around the renderer, its API and file format. It is definitely doable, and could become easily the best integrated renderer in FreeCAD. It is in fact possible to make it totally seamless, as if FreeCAD itself would do the rendering. But first things first, we'll start with exporting an appleseed file from the FreeCAD Raytracing workbench first, like the other engines we support already. I'll also take the opportunity to make the Raytracing workbench a bit more pythonic, so new render engines with a python interface will be much easier to add.

And the third really interesting talk I had was with Sean from BRL-CAD. BRL-CAD is a very old project, started by the US Army, which later on released it as open-source. I really thought BRL-CAD had become a pretty inactive project, but this is very far from the truth. The thing is, BRL-CAD's main user is still the US Army, so almost everything that is modelled with it is classified, so it is very hard to publish anything that was done with it, which explains the very sparse image galleries, social media, etc.

However, it is an extremely interesting project. It consists of about 700 commands, a bit like a Unix/Linux operating system where all the base commands you use in a terminal, such as ls, mount, chown, etc.. are actually each one a file, or individual program. Then higher-level tools, such as the desktop environment, uses these commands under the hood to list directories contents, move files, change file permissions, etc.

BRL-CAD works exactly like that, it's a bit like a Unix of CAD... It has a graphical interface, but its real power resides in the vast array of command-line tools. And a modelling tree in BRL-CAD is in fact a shell script!

Another interesting feature in BRL-CAD is that it is capable of managing absurdly huge models. Since it doesn't really have a graphical modeling interface, which must display the model (and therefore compute it and triangulate it, because most computer 3D visualization systems around, such as OpenGL, rely on triangles), they can produce raytracing directly from the model definition and not from a triangulated version of it. This removes a big part of the process that FreeCAD has to do.

So there is much interesting stuff there that maybe we could do something with in FreeCAD. I am not sure what exactly yet, but only the "command line" system itself could easily be integrated into FreeCAD, it's not very different than what we do at FreeCAD level itself between App and Gui.

And BRL-CAD and Appleseed are also working on integration.

After the mentors summit ended, I got really curious about something I read in The Circle, the main character, who works at "some computer firm close to the south tip of the San Francisco bay", likes to take her kayak, go behind the office and paddle in the bay. I saw that the Google campus lies at a few minutes by foot to the bay, and there are many trail paths around, so I went there for a walk, and wasn't deceived. The area is magical, lots of channels and water ways, with here and there a stand-alone, man-made artifact, like a radar, a ship lock, etc...

After that I spend a couple of days in the lovely San Francisco, which I decided should integrate my list of magical cities, together with Barcelona, Venice, Cape Town and Rio de Janeiro. I did a bit of drawing too, and checked a couple of architecture icons like the Federal Buiding by Morphosis (impressive "concretization"of everything Morphosis has been saying, but big doubts about the so-called "green building" stuff and the very poor attempts at making the building users "socialize"...), Libeskind's Jewish Museum (really disappointing, very little more than just a "funny space", or the MOMA by Snøhetta (couldn't enter unfortunately, wrong planning).


in categories  sketches  permalink:  410   posted on 22.10.2017 21:03
From Yorik
A couple of sketches a did in San Francisco. Didn't really choose much the views, unfortunately, I mostly sat and drew where there was a cool place to sit and have a coffee...


Telegraph Hill


Fisherman's Wharf


Union Square


Federal Building


The Embarcadero


Jewish Museum


Twin Peaks

in categories  sketches  permalink:  409   posted on 07.10.2017 22:03
From Yorik
Todays drawings at Praça Benedito Calixto plus two quick ones I made this week in the bus and at UFABC








permalink:  408   posted on 04.10.2017 24:29
From Planndesign Info
Great stuff. Do visit: www.planndesign.com for more autocad drawings

permalink:  407   posted on 04.10.2017 7:51
From William
Commenting post 396: Hi there,

Just wanted to say this article was really well written and covered a lot of ideas I have been considering as well.
William

in categories  freecad  opensource  permalink:  406   posted on 01.10.2017 17:46
From Yorik

FreeCAD Arch development news - September 2017




Hi everybody! Here we are for another monthly report about the development of BIM tools for FreeCAD, our favorite open-source 3D CAD modeling platform. The coding I am doing for FreeCAD is now more and more heavily supported and funded by many of you via my Patreon page, thanks once more to everybody who contributes to this, it is incredibly motivating. We won't stop until we get a proper open-source, multiplatform BIM modeler!


WikiLab


As expected in last month report, this month I had very little time to dedicate to FreeCAD coding itself, because our WikiLab project construction started, and it swallowed almost all of my time. I am saving the Patreon money of this month, though, and as soon as the WikiLab is finished (about two more weeks to go) and I'm back from the GSOC mentors meeting (see below), I'll be back at FreeCAD coding with full dedication and twice the money to spend (and I really miss coding already).




This time spent on the WikiLab is not lost at all for FreeCAD, though. First, the project were entirely developed on FreeCAD. The whole project files are open-source, hosted here. Check the two FcStd files in the main repo folder, one contains the base WikiHouse module, called "Wren", that file was used to generate the CNC cut sheets, and the other is the complete assembled model, that was used to generate the construction manual, documents for aproval, etc.



Second thing, everything happening during the construction (changes from the original project, difficulties, etc) is being recorded, documented, and is onlien on the same github account. There will be several reports written at the end of it all about the different aspects of the experience (technical, financial, etc..)


Also, the construction of a WikiHouse building is an amazing experience, and this is giving us a wealth of useful information, feedback, ideas. We used one of the main WikiHouse designs (the Wren module) almost without any modification, to stay on the safe side. However, we added many experiments around it, for example the "rain cover" that we're currently placing around it, or our hybrid construction model, part made by volunteers, part made by a professional construction team.



This all is too much information to be resumed here in a couple of paragraphs, but count on me to write detailed articles about all this after the dust settles. To resume a bit what's going on, the WikiHouse construction itself is a wonderful thing. People with no experience at all in building come, need only two tools (a rubber hammer and a flat screwdriver to "help" hammering the joints in), and in 2 hours everybody has turned into a WikiHouse building professional, able to build without even looking at the plan. There was no difficulty, no accident, and no "gambiarra". The result is very solid, while still manageable (the biggest parts, once assembled, can still be moved around by a 10-people team).


The rain cover is being built now, I'll have more to tell about it next month, but it is a very simple, cheap (whole cover costs less than 4000 BRL/1300 USD/1100 EUR), ansd easy to build solution. The polypropylene sheets we used can be cut with a pair of scissors. And they give a nice look (kind of cheap SANAA )




The hybrid construction system, half professional, half volunteers works up pretty well to some extend, but it is the hardest part to manage. They are very, very different types of construction. The volunteers part is very, very fast, but requires everything to be very well planned ahead. The traditional system with a professional contractor, however, is slower, but they take care of a big part of the planning themselves, and there is much more experimentation and and on-site modifications possible. Really, both have their strengths, and I'm still very much convinced that it is a good way to go. But their different rythms are really hard to sync and "compatibilize", specially that we did this in three parts, first part with the contractor, second part with the volunteer team, and now the third part with the contractor again. This scheme should realy be simplified in the future.


Also one other thing stiked my mind, that I hadn't fully realized before: You don't make this with a team of volunteers to save money. You do it because people want to build their own house. The construction itself is the "product", not the finished house. The disappointment of the team when their "task" is over is big In the future we'll need to find smart solutions that allow the team to stay on-site up to the very end.



Both the professional and volunteers teams also need very different kinds of documents. Professionals are used to architecture drawings, and they feel more at ease opening a plan, that has everything on a single sheet, than browsing through a book. However, the book makes the whole construction easier to understand by volunteers. If you have both kinds of teams, you need both.


Let's talk about BIM


This started from a discussion that I had with a friend this month, about "all that BIM stuff", and several other discussions I stumbled upon on the net go in the same direction, so let's sum some of it here, no doubt it's a subject all of use are interested in


The basic point we started with was "What about all that fuss, BIM here, BIM there, at the end where is the big gain?" Everybody who works in a BIM-enabled architecture office has a lot to rant about. BIM makes project organization actually MORE difficult than before, BIM is just a commercial concept idealized by software vendors to make you pay more, BIM actually RESTRICTS creativity (Some things were avoided in your project because they were hard to do with the BIM software being used, don't tell me this never happened to you), collaboration works "more or less" when everybody uses the same software, but becomes so complicated when different software is used that you end up needing a "BIM manager" to sort things out, etc.


Compare this with the 2D-based era, there are clear steps back IMHO.


However, what we're trying to do goes beyond the mere BIM term. I mean having a project that is fully (and reasonably accurately) modelled in 3D, and that is organized semantically (this cuboid shape is a wall, that other is a beam, both belong to the same floor, etc), and that contains as much non-geometrical data as possible/needed (this wall is made of 20cm of concrete block with specific thermal and structural properties), so that model can be used in many ways (to generate drawings, to study structural resistance or thermal behaviour, etc). Basically, a model that can be understood and used by others.


When you tell all this to mechanical engineers they usually look at you like, what's the fuss, we're doing that since a long time, and we still call it CAD.


But there is something interesting happening now: More and more you hear or read similar opinions. And far from being something negative, I think it actually serves the general direction. Many BIM gurus are having new looks at IFC, the good, old, clumsy, ugly, all-in-one BIM format that everybody likes to hate. That format should already have died a long time ago, by commercial standards. However, not only it doesn't die, but many people are having a new go at issues like versionning (or this one) or, like in a previous article I wrote, parametric files. And more and more people are also using it (I think) the way it is meant to be used: controlled and validated by rules.


It turns out the good old IFC format, even being ugly and clumsy, has surprisingly more tools than previosuly thought to deal with these "advanced" issues. In the case of versionning, I also think that the problem is beyond the file format itself, versionning CAD/BIM files is a complex problem where a change can be significant for a machine but not for a human, and vice-versa, unlike code. So the problem is actually larger, and when you look deeper at it, the IFC format contains many stems and tools that could at some point give birth to realiable solutions. We'll probably need to invent a revision control system that is very much based on semantics too (a way to "tell" or "describe" what has changed in a model).


All in one, I hope all the "myth" around BIM is beginning to fail/die, and I think it's a good thing for BIM...


Survey


I've not been able to do much in FreeCAD this month, apart from a couple of bug fixes. But I managed to work on one feature that needed a bit of love, which is the Arch Survey tool. This tool allows you to quickly take a couple of measurements by clicking on a model, like traditional quantity surveyors would do on a plan, by measuring the lines.



Until now you had to sum things up yourself. Now, the tool has gained a proper interface that sums lengths and areas as you click them. So it becomes very easy to measure, for example, the total length of walls that you have, or the total area of concrete slabs. And the final result is exportable as a CVS file, that you can import in a spreadsheet.


There are many more possible improvements, be sure to add your voice to the forum thread!


GSOC


Finally, next month I'll be in the San Francisco Bay Area for the Google Summer of Code Mentors Summit. I'm really curious to see the inside of Google (Count on me to reveal all the secrets I'll be able to grab!), and it will be a great opportunity to meet the BRL-CAD people too, with who we're participating to the GSOC program for the second time, I hope we can set up more ideas to work together with other free and open-source CAD projects.


If you are in San Francisco around october 15-19, be sure to tell be and let's have a beer or coffee somewhere!


in categories  sketches  permalink:  405   posted on 10.09.2017 21:15
From Yorik

Urban sketchers meeting in São Paulo


4 days sketching through São Paulo with 250 people from whole Brazil and beyond...






















permalink:  404   posted on 10.09.2017 21:12
From Yorik
Commenting post 403: No but I have several friends who do

permalink:  403   posted on 04.09.2017 14:31
From Rafael (bitacovir)
Commenting post 402: Are you carrying watercolors everywhere?

in categories  sketches  permalink:  402   posted on 03.09.2017 21:18
From Yorik
At the new SESC 24 de Maio in São Paulo, incredible project by Paulo Mendes Da Rocha...




in categories  sketches  permalink:  401   posted on 01.09.2017 24:34
From Yorik
Quick sketch today after lunch


permalink:  400   posted on 01.09.2017 24:34
From Yorik
Commenting post 399: I've known about 3D PDFs for some time, but never really seen them used anywhere...

permalink:  399   posted on 31.08.2017 19:03
From hambre
Commenting post 398: There is actually a way to embed "real" 3D data in a PDF doument using the U3D or PRC file formats. These can be directly embeded in a PDF document and can be navigated using a PDF viewer supporting 3D PDFs. At least Adobes acrobat reader can display those (but not on linux AFAIK). The PRC format seems to support CAD data directly whereas U3D seems only to support triangulated data. There is an U3D library available but unfortunately there is no free/libry library to create PRC files.

in categories  freecad  opensource  permalink:  398   posted on 31.08.2017 3:42
From Yorik

FreeCAD Arch development news - August 2017

Time for our monthly development report, explaining a bit of what I did this month. Thanks again to everybody who help me on Patreon, each month we're getting higher! If you don't know about it yet, you can help me to spend more time working on FreeCAD by sponsoring me with any amount you want on Patreon. Some of you have asked me if it was possible to give me some money directly via PayPal, well it sure is! My PP email is yorik (at) uncreated (dot) net.

Bugfixing

This month however I will have much fewer to share than usual. There are two main reasons to this, one is that I've been doing a lot of bugfixing, which is too boring to talk about here. It is boring to do too, of course. Any coder will tell you that it is much more fun to develop new features than fix bugs. However, they are very important. The stability of an application depends heavily of the relentless testing, identifying and fixing of bugs.

I saw where FreeCAD comes from, and when you compare it with FreeCAD as it is today, even with all the remaining bugs and problems it has, the evolution of its stability has been phenomenal. All thanks to this: tiny bugfix after tiny bugfix...

There is a story I always like to tell about bugs. We architects are usually very sensitive about errors. Doing a mistake is a terrible thing for an architect, and results in huge blame, shame, guilt. You always try to show that you know everything. As you can imagine, this also comes with a strong tendency to hide the dirt under the carpet.

When I began to work with Jürgen and Werner on FreeCAD, it is one of the first things that surprised me much: How these guys treated their own errors as a normal thing, a bug. Bugs happen. You are human, you make mistakes, the same way as you breathe or eat. It wouldn't make sense to feel guilty for this. Since then, I always try to treat architecture work like that too: Consider your mistakes as a normal part of what you produce, try to make them appear (unit tests for architecture?) so they can be processed and fixed.

Jürgen and Werner and all other FreeCAD developers, if you guys read this, thanks! I am learning a lot with all of you.

Draft Scale UI

One of the things I did that was really sorely needed is a better User Interface for the Draft tool, that was really clumsy (you needed to "indicate" graphically the scale factor). Now there is a simple, proper dialog to scale things up/down, which allows you also to choose the result: Scale the original objects or produce a Draft Clone (where the scale can be changed later).

WikiLab

The other reason why this report will be less interesting this month is that the construction of our WikiLab project has started yesterday, so I simply had less time to work on new FreeCAD stuff. There has been quite a lot of work to do these last weeks to have all the construction documents ready before construction start, and the approval process ended up not being as smooth as we thought either (it is actually not entirely finished...).

But all this is also not work for nothing. The main issue with approval is, as you might imagine, fire resistence. Our WikiLab is made of wood, which burns. The risk for human beings is extremely low (the room is very small, only holds a few people, is escaped very easily, nobody will sleep there, etc), and the OSB panels we are using already have a slower buring rate because the glue they are made with acts as a fire retardant, but the problem is that there is as of today very little official record of all this. People in charge of approval basically want to see a document that guarantees them that such wall will hold a certain time under fire. These documents don't exist yet, because people rarely build walls with OSB panels, so panels manufacturers have little interes to pay for the research and fire tests needed to obtain such guarantees. Plus, these tests are very specific, so in our case a fire test would be valid only if it was made with the exact same wall composition as we are using.

This is a well-known problem when using experimental systems. Convincing authorities is very hard. But that is also where this process is interesting and useful, when done, we will have created a precedent, which will lower the difficulty for all subsequent ones, because they'll be able to refer to this one.

Coin-based views

The work on the WikiLab construction documents also allowed me to play further with another idea I had: The 3D view of FreeCAD is pretty nice: It is anti-aliased, line style, width, thickness, color, transparency are configurable by object, it has a nice support for fonts, and even things like transparent textures. So instead of the heavy ans slow workflow needed to produce "traditional" 2D views with the Drawing or TechDraw workbenches, you could simply grab a nice view of your 3D window.

So far these cannot be exported "as is" to vectorial 2D. Exporting a 3D view to PDF is supported by the Coin3D engine (which powers the 3D view of FreeCAD), but the result is often buggy, the engine struggles at rendering some complex 3D situations to PDF.

However, exporting a 3D view to bitmap formats usually works very well. Most architects who will read this might dismay in horror at the idea of exporting architecture work as a non-vectorial format, but there are many "but" here.

First, it makes sense of course to export your work in a CAD format, such as DXF or DWG if others need to work with it. But a PDF? Will anyone ever import a PDF to work on it in a CAD program? That would be pure masochism, there wouldn't be much you could do with it. Also, when working in an open-source way, or any case where your base files are more easily acessible to others, and are in an open format, all this discussion looses a lot of its meaning... If a person can get a FreeCAD file, why would that person need a PDF file

The next advantage of a vector-based format such as PDF is the reduced filesize. However, this is true for basic line-based work, but as soon as you use more fancy things such as transparency or textures or gradients, most CAD systems will turn that into bitmap anyway, so much for the file size. And large complex areas filled with one color can often be smaller in size in bitmap than vector format, where havy triangulation is needed (which by the way often stays visible in the PDF file). So there is not much difference at the end.

The third advantage of vector-based files is that you can zoom in and things continue to look sharp (this is certainly only useful for on-screen viewing, has any of you ever printed a PDF file at higher scale than 1x?). But this is just a matter of resolution, just save an image with enough resolution to be well readable when zoomed a lot, and this problem disappears. Plus, even if your image is embedded in a PDF file, zomming is blind-fast compared to zooming vector-based PDF files.

In the last years I've used bitmap files more and more to show traditional CAD work like floor plans. You can do all kinds of fancy things in Photoshop Gimp, and if you manage your layers well, it is totally manageable to reimport a layer from your CAD/BIM app when something changes in the project.

So I used this a lot in these construction documents. By using Working Plane Proxies you can easily configure views that you can recall anytime, so it is easy to produce a new image that is identical of the last one when the project has changed. And the Tools->Save image dialog of FreeCAD allows you to save an image with a very high resolution, which gives a very sharp result.

There are sill issues to solve, such as calculating the resulting scale, or ensuring that texts and dimensions have coherent and consequent size across different views, but that shouldn't be hard to solve.

Of course this is not the holy grail. There is still a series of situations where you'll need vector-based output. But when you try to show a project in different ways, like we did here, it might become a lot more convenient.

Arch Grid

The only real new feature I've been working on this month is the Arch Grid, that I just merged. A tool to construct a grid object, like you do in a spreadsheet: define columns and rows, change their sizes, and merge cells together.

This object can then be used to perform a series of other operations with Arch objects, for example spread objects on its vertices, face centers or edge midpoints, or use it as a base for windows, instead of a sketch, or for any other kind of situation such as constructing railings.

Download that test file here (you might need to wait a bit, because I just committed the change)

That's it for this month I'm afraid, sorry I couldn't do more, next month will likely be like this one too as we will be building the WikiLab, but you can count on me to share all I can during the construction. Almost all our wooden part are cut and ready to be assembled, the masonry base is being built now, and the assembly is scheduled to start on september 12th. If you are in São Paulo at that moment, don't miss the opportunity to participate!

Thanks again to everybody who is helping this adventure to come true, each month a step closer to a full, feature-rich open-source BIM application!


in categories  sketches  permalink:  397   posted on 27.08.2017 22:09
From Yorik
Aquarelas de hoje, uma ruim e uma muito ruim...




in categories  freecad  opensource  permalink:  396   posted on 21.08.2017 18:12
From Yorik

About parametric IFC files

The title of this article sucks, I know, couldn't think of anything better...

This is a concept I wanted to play with since a long time, and last month I was finally able to setup a proof of concept. The only missing part was to write an article explaining it, so here it goes.

For who is not familiar with the BIM or parametric 3D world, IFC is a file format used to exchange BIM data. BIM stands for Building Information Modeling, and is basically "3D parametric modeling for the construction industry".

There has been quite a fuss for a long time on the internet about this. "IFC is not parametric", you'll read around. "So it cannot be used to transmit model intelligence", Revit users (and specially sellers) will tell you. This always annoyed me... After all a file, that is stored on your computer, is a "dead" thing. It cannot perform computations, it's just a storage for data, so how could it be intelligent? There is no such thing as an "intelligent file format" except maybe in the mouth of some astute marketing gurus...

The "intelligence" doesn't lie in the file. It is the application that does intelligent things with the data it finds in the file. Also consider what a parametric object is. A parametric box, for example, would have 3 parameters: Length, width and height. A program would then construct a box geometry from these 3 parameters. The 3 parameters are everything that is needed for the program to construct the box. If you save these 3 parameters to a file, when reading the file back, the same program will be able to reconstruct the box, just knowing its length, width and height.

I'm using in this text words like "parameters" or "attributes" or "properties" more or less indifferently. It means basically, a piece of data (number, text, whatever) that is attached to an object, for example the length of our box.

This idea comes from an old discussion I once had with Inkscape people. Inkscape uses the very well-known and very standardized SVG format, which is readable by a huge amount of applications, including almost all web browsers. The SVG specification is something tighly maintained and controlled by the same consortium that maintains HTML and almost all the web standards.

However, Inkscape needs to save things in its files that are not part of the standard SVG specifications. They do this by writing standard SVG files, but adding custom properties to standard objects, which is something the SVG specification allows.

So Inkscape, when reading that file, will see the custom properties, and be able to use them the way they are meant to, while other applications will simply ignore those properties, and will only consider the standard parts.

An example of that is the "star" tool of Inkscape. The star object created by this tool is parametric, that is, if you edit the star after you created it, you will still be able to modify the number of spikes, the radius, etc. If you save the file, and reopen it, you are still able to change the number of spikes.

If you open that same file with any other SVG application that is not Inkscape, they will show the star correctly, but won't be able to edit it. Inside the file, the object is a standard SVG path object like this (the data inside the d parameter are point coordinates with instructions such as Movement or Line) :

<path d="M 100,100 L 90,75 L 100,95...">

This is standard stuff, readable by any SVG app. Inkscape adds its own attributes like this:

<path inkscape:type="star" inkscape:sides="5" inkscape:cx="90" inkscape:cy="95" d="M 100,100 L 90,75 L 100,95...">

"inkscap:sides" or "inkscape:type" are additional parameters that only inkscape will see when reading the file. Inkscape wil then know that this path is actually a star, and will be able to re-generate a different path data if you edit the star.

It was thought right from the start that applications might want to add such custom content to their SVG files, and therefore the SVG specification provides this nice namespace system where you can write your custom additions by preceding them with a name that identifies your application (inkscape: in this case), which turns it easy for you, the Inkscape developer, to identify Inkscape-specific content in the file. If you use such namespaces, the SVG specification even forces you to add a line like this in your file:

xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

So other developers, when reading your file, when they see your inkscape: attributes, will not need to google for it, they will be able to go right to a page where you have carefully documented it all... Isn't that nice?

So basically here we are: the same concept can be applied to IFC. IFC supports adding custom properties to any object. Let's say you have an application that draws chocolate walls (yes, it's a BIM app for cake makers). You could make your application save your cake as an IFC file, and store its walls as standard IFC walls. But you would add a special property, for example: chocolate_type="milk chocolate". Your cake would still open in Revit, but only your app will see and read and use the chocolate_type property and will be able to recreate the cake faithfully and parametrically (you will be able to change the chocolate type after loading the file).

So I added this to FreeCAD, as a very simple proof of concept. There is now an option in Edit -> Preferences -> Import/Export -> IFC named "Export full FreeCAD parametric model". When you switch it on, when exporting to IFC, the resulting file, instead of being formatted like this:

IFCWALL (made from extrusion)
 ->   EXTRUSION (made by extruding a base polygon 2m high)
  ->      BASE POLYGON

Now contains additional properties like this:

IFCWALL (made from extrusion, and using 'FreeCAD' property set)
 ->   EXTRUSION (made by extruding a base polygon 2m high)
  ->      BASE POLYGON
 ->   'FreeCAD' PROPERTY SET
  ->      PROPERTY ObjectType="Arch.Wall"
  ->      PROPERTY Width="20cm"
  ->      PROPERTY Length="200cm"
  ->      PROPERTY Height="200cm"

See the full IFC file here, and the originating FreeCAD file here

The IFC importer of FreeCAD has also been adapted so when reading that file back in FreeCAD, you obtain faithful, 100% identical parametric objects as when you exported it. In fact, when FreeCAD finds an object inside an IFC file that has a "FreeCAD" property set, it will simply skip all the rest and reconstruct the object only from the contents of the property set.

But other applications, unaware of the FreeCAD contents, will still see the "standard" definition:

So far this is just a proof of concept. There are many property types of FreeCAD that are not yet supported. But it would not be much work to extend the system to support them all.

Now I can hear the arguments against all this gathering in your head. What's the point, if other apps won't be able to do anything of that shit? What if the other app modifies the standard IFC content, but leaves the FreeCAD property set intact? FreeCAD will ignore the modified version. Etc, etc. The counterarguments are many.

However, the discussion has shifted. What if such "extra" parameters/properties/attributes were clearly documented somewhere? What if, for example, Revit would export its walls with a defined set of properties that would allow it to recreate the wall 100% as it was before exporting? We could make FreeCAD see, use and modify those properties too. Or, even better, have a common definition that says "all walls must have length, width and height properties". That actually exists up to some very basic point in IFC, you can add a "standard wall property set" to walls, that contains such generic properties that should be common to all walls. I have never seen that system being used very much yet, though.

So is the problem not in defining things correctly, instead of blaming IFC for not being technically fit to the task? The model works well for SVG, it would be really worth trying...

Jon Mirtschin, the famous IFC guru behind GeometryGym, experimented a lot recently with similar concepts. The difference with his approach is that he found a way to bind properties to certain values in the IFC file. Simplifying a lot, his file looks like this:

IFCWALL (made from extrusion)
 ->   EXTRUSION (made by extruding a base polygon by the value of "Height")
  ->      BASE POLYGON
 ->   PROPERTY SET
  ->      PROPERTY Height="2m"

So the relationship between the extrusion value and the Height property is written in the file. This is obviously a much more interesting solution freedom-wise. Everything is stored inside the file. You can invent any kind of parametric relationship like this. And when you remember that GeometryGym is developed principally for Grasshopper, where you could read that file and reconstruct any kind of wild, crazy relationships written in the file (for example: The height of the wall equals to half the width of the whole facade, minus the height of the front door), this makes a lot of sense.

Image source

But the question remains: What would Revit do with a file that contains a definition like: "The height of the wall equals to half the width of the whole facade, minus the height of the front door". I think that's something where both approaches meet the same issue: Sooner or later, some of the parametric content will be discarded by some application, that will say "Here we don't construct walls like that. We don't allow this".

But my point in this article was to show this: Not only IFC can perfectly well contain parametric objects, it can even as Jon's example shows, contain your wildest parametric dreams, actually probably far beyond any other proprietary file format out there can do. Implementing parametric relationships in the IFC file format is something that has been researched for quite some time already, and there are other further plans too.

An IFC file that can do the full round-trip (be exported from your application and reimported with 100% faithfulness and all its "intelligence") is totally possible, that's now clear and proved. The remaining problem is actually not a technical issue, but much more a communication issue.

What if the consortium behind the IFC format would issue a chart, with things like "The parametric properties that a wall should have", or force you, if you add custom properties, to provide an URL where you explain it all, like SVG does? These things would not make the problem solved tomorrow, but would allow to progressively structurate and consolidate parametric IFC files, that could progressively become fully editable by more and more applications.


in categories  sketches  permalink:  395   posted on 12.08.2017 23:58
From Yorik
Two drawings I did today at Galeria Nova Barão and Viaduto do Chá in São Paulo




permalink:  394   posted on 09.08.2017 13:06
From Yorik
Commenting post 393: Hi, there is now a much improved version called render wireframe: https://developer.blender.org/T26997

permalink:  393   posted on 08.08.2017 3:58
From John
Commenting post 73: Hi, does this work with the current version (2.78)? I tried installing and didn't get an error, yet it doesn't seem to show up in the menu as mentioned.

== John ==

permalink:  392   posted on 07.08.2017 19:24
From 3Dprintje
Well, lets see whats going on here

permalink:  391   posted on 02.08.2017 19:24
From Flavio Garcia
Commenting post 389: this is a good software to dothe ideas in a drawing

permalink:  390   posted on 01.08.2017 23:28
From Danilson Gomes
Commenting post 389: Gostei muito de saber como o FreeCAD está avançando. Sonho um dia poder fazer vídeo aula em pt para dar minha contribuição. Estou aprendendo muito com os vídeos do Regis Nde Tene. Estou realmente ansioso para testar na prática as novidades apresentadas. Eu já estou usando o FreeCAD nos meus projetos.

in categories  freecad  opensource  permalink:  389   posted on 01.08.2017 20:19
From Yorik

FreeCAD Arch development news - July 2017

WTF, July development news in August, I hear you yelling (it's not only me!) But there was some last minute topic I really wanted to complete to include in this report... But now that it is complete, I think it deserves another post on its own, so I'll only mention it here briefly. It will be worth it, I swear

First off, I'd like to thank once again everybody who is contributing to my Patreon campaign and through there helping me to spend more time working on FreeCAD. This month I passed over USD 500/month, which becomes pretty important. In Brazil, where I live, the "official" salary of an architect (that is, recommended by the national council of architects) is around USD 2500/month. In reality, only some architects working in public institutions earn that much, in the private sector the usual salary is about half that amount. To put things in context, the 10% bar, that is, the salary you must earn to be in the richest 10% in Brazil is around USD 1100. So my 500/month begin to represent some consequent weight (it's almost a teacher salary). Yeah, these things make you think a LOT about what value is. And for who.

I started this Patreon campaign not really knowing where it would go and if it would allow for something serious, but now I begin to really believe it can change a lot. Working half-time as an architect and half-time as a FreeCAD coder is an idea I'm growing really fond of...

But enough about me, there is quite a lot to tell this month.

Parametric IFC

This is the big thing I wanted to merge before writing this report. I'll post something more detailed soon, but the idea is basically to export all the parameters of FreeCAD objects to IFC. So when reimporting that IFC file in FreeCAD, parametric objects are fully and faithfully restored. The idea is to show/prove that yes, IFC is totally adapted for parametric design. More on that very soon.

Nester

So the big thing I have been working on these last months is now merged in FreeCAD. I have been posting about it in the previous report already. It is an algorithm that organizes shapes to fit into a containing shape. This is useful in CNC operations, when, for example, you want to cut out a series of wooden pieces out of a wood panel, and want to stack all these pieces the best possible way on your panel.

There is now a nesting tool in FreeCAD, located in the Arch workbench, under the panel tools:

The system is simple, you launch the tool, select the containing object, then add the objects to be placed inside. Tune some parameters if needed, and launch the calculation. It is currently not much optimized and quite slow. When the calculation has finished, you can see a preview of the result, and if you apply that result, the object get moved and rotated to their preview position.

The next two features I'll add are support for margins (you usually don't want te pieces to touch, but leave a certain margin between them) and allow for non-rectangular container, so for example you could reuse scrap material easily. Then it'll be time to attack some optimization.

The nesting algorithm itself is separated from the tool above, so it could be used differently by other tools and workbenches. And also, it can be recoded in C++, which should make it run a lot faster. That will be done too later on.

New axis behaviour

I also introduced several changes to the Arch Axis system. There was already a way to make a series of structural objects spread over the crossing points of different axes, but it was not very easy to find and weird to use. I believe the new system is much cleaner and powerful. It basically works like this now:

  • The old Axis System tool is still there, it has simply been renamed to Axis. It has a different icon ( ) and it still does what it did before, that is, it creates a 1-direction series of axes. For example, all the A, B, C axes.
  • That tool has also gained a couple of extra features: You can now give it a series of labels, one for each axis, that can be displayed next to each axis (you can fine-tune the position). And you can turn the bubble off. This allows to use the axis for many different scenarios, such as indicating levels.

  • There is now a new Arch tool, called Axis System that now really does what the icon means: Organize several axes series into one system. It can take two or three axes objects (you can edit that by double-clicking the axis system in the tree). Its function is basically to calculate the intersection points between all the axes.

  • Not only structures, but all Arch objets can now be spread along axes or axes systems. For that, they gained a new Axis property. By setting this property, you can make your object be duplicated automatically. The rule is as follows:

    • If the Axis property points to an axis system, the object will be duplicated on each intersection point of the axes in the system
    • If the Axis property points to a single axis, the object will be duplicated once on each axis
    • Otherwise, if the Axis property points to any Shape-based object, the object is duplicated on each vertex of that shape.

    Now I think the situation is much cleaner, it's much easier to first create your axis systems properly, then make your other arch objects make use of it, and change/undo all this whenever needed. Also,by using any other shape as an axis system, many wilder possibilities become possible, such as using a sketch to drive the position of Arch objects, etc.

Working Plane Proxy enghancements

The Draft Working Plane tool is something you use constantly and everywhere when working with Arch. It is one of these tools that grew more and more complex over time, and that is now quite a powerful behemoth... For who is not used to Draft/Arch, it is responsible for setting a 2D plane where all the subsequent Draft and Arch operations will take place. The location of this working plane is represented by the Draft grid, that shows the position and orientation of the plane, and also gives a visual interval (the grid size), which you can also snap to.

The current possibilities are fair already, you can set that working plane quickly to one of the origin planes (top, front, side) or select a face and make the working plane adopt that face orientation and position.

Now I added a new Working Plane Proxy tool in Draft, that stores the position of the current working plane. It is represented on screen by a small widget (the size is customizable).

When selecting this widget and pressing the working plane button, the working plane will return to the location/orientation of the widget. You can even move and rotate the widget by conventional ways (it has a Placement).

The idea is that you can now save important working plane positions in your document, precisely, without the need to have "real" geometry there.

This proxy object also has two more interesting features: a Restore View property, that will, when restoring the working plane to the proxy position, also restore the camera position. So you can use the proxy object to store not only the position of the working plane, but also the view angle. You can change/store the current view anytime to a proxy object, by right-clicking it in the tree.

The other feature is a Restore State property that, when restoring the working plane, will also restore the visible/invisible state of all document objects (the ones that were present in the document when storing those states, that is). Here too, you can store the current state anytime by right-clicking the object.

With these two features, we are paving the way for a more conventional BIM environment, where you can switch from working on one floor to another floor, and all your environment (working plane, view orientation, visible objects) will change accordingly.

Next thing I'll look at is how to tie that to Floor objects, but these floors need a good refactoring first...

Rebar / non DAG workaround

The recent GSOC work on Arch rebars (I strongly suggest you to have a look at the impressive work being done by Amritpal, our GSOC student, and several members of the community around, the image above is taken from there) also gave us the opportunity to tackle a long-lasting inherent design problem of the Arch workbench, the famous non-DAG bug. DAG stands for direct acyclic graph. It describes a type of graph or tree which all flows in the same direction, where it is forbidden to go backwards. The relationships between objects in a FreeCAD document is a DAG.

That means the dependency chain between FreeCAD objects must always flow in the same direction: You can object C that depends on object B that depends on object A, but you cannot have object A that depends on object B that in turn depends on object A. That would be a cyclic dependency (you cannot know which one comes first, A or B) and is forbidden in FreeCAD (if you find yourself in such a situation, FreeCAD will print non-DAG error messages and refuse to process anythingmore until you fix the problem).

Two Arch objects were constantly creating non-DAG situations: Windows and Rebars. The window, for example, often depends on its host wall (in order to know on which face it lies) and the wall also depends on the window to know how to drill the opening where the window is placed. The workarounds I had imagined until now to circumvent the problem were really not very satisfactory (for example create a second wall, so the base wall and the wall with the opening were two different objects).

With the Rebar, we now experimented a new idea that seems to solve the problem for good. It is not the "parent" object that knows which "children" it holds anymore. It is the child that knows which "parent" it belongs to, and the parent is not dependent on the child anymore.

That introduces a bit more complex system: The wall doesn't know which window is part of itself anymore, so when updating its geometry, it now has to "scan" the scene to find the windows it must use to drill openings. But this is a very ponctual and unperceptible slowdown, and I think totally worth the much cleaner situation and the vanishing of the dreaded non-DAG problem.

The Rebar object already uses the new system, and it seems to work very well, so I'll adapt the window to use the same system in the coming days.

Cabinet design

Another talk I had with a FreeCAD user (that will soon become a more stucturated plan) lead me to this interesting experiment, where you take a simple Part Box, and use it as a "driver" shape for inner objects, like the panels and doors of a cupboard. This is an interesting workflow, and I liked to be able to work with simple boxes, that contain their own more detailed components.

The test file is here if you want to have a look at how it works.

I already had other discussions before about furniture/cabinet design with Regis and others, it would be a good time to think about a proper workbench for it.

Talking about Regis, one of the most knowledgeable Arch/BIM FreeCAD users around, have a look at the impressive series of videos he has been producing lately about BIM work in FreeCAD...

Arch space bounds

I also added UI controls to edit the boundary objects of Arch Spaces. Spaces can be based on a solid object (their shape is therefore the shape of the solid object), or a set of boundary faces (the shape of the space is therefore the bounding box of all these faces, subtracted by the volumes - or half-spaces - behind those faces), or a mix of both (the shape of the space is the shape of the base solid, subtracted by the half-spaces behind the boundary faces).

There was until now no way to edit the list of boundary faces without using the python console, this is now solved.

That's it for now, sorry about posting late! Still a lot that I wanted to do this month that will be for the next month, but step by step we're getting there. Thanks for reading, thanks to everybody who help me to make this come true, and as always, comments are welcome!


in categories  sketches  permalink:  388   posted on 29.07.2017 24:37
From Yorik
Daily sketches








permalink:  387   posted on 29.07.2017 6:39
From Victor V
Commenting post 97: Very inspiring, thank you! Looking fowards the BIM revolt

in categories  sketches  permalink:  385   posted on 24.07.2017 1:32
From Yorik
Couple of bad ones this week, just for the record... The last one was waiting for a concert to begin






in categories  sketches  permalink:  384   posted on 16.07.2017 21:24
From Yorik
Traditional Sunday Minhocão sketch




in categories  sketches  permalink:  383   posted on 15.07.2017 24:13
From Yorik
Today's drawing with Urban Sketchers São Paulo, in São Paulo city centre.






in categories  sketches  permalink:  382   posted on 05.07.2017 23:43
From Yorik
Drawing I did today at praça Roosevelt


permalink:  381   posted on 04.07.2017 3:02
From Yorik
Commenting post 379: Hi,

This is not so easy unfortunately, you cannot just take a script written for one application and make it run on another, even if they are written in the same language. It would take days or weeks and might be even easier to rewrite from zero.

It might be easier/more fficient for you to work in Blender, no?

permalink:  380   posted on 03.07.2017 19:24
From Arq German Alcala
Commenting post 372: Tengo interes en Patrocinar FreeCAD, favor de contactarme, te envie solicitud de amistad Facebook.

permalink:  379   posted on 03.07.2017 9:11
From amer
Hi yorik
I am amateur interested in the history and the immitation of citadels and old castles built in stone and brick
And as I want models with details cornices, bow, pilaster, ceiling, etc.
I try to write a macro for freecad
For this I find a program written in python to blender:
Add_mesh_masonry.py written by Paul Spooner
Can you help me to make it compatible with freecad especially with the architecture workshop of freecad

Thank you in advance and here is the code:
##
#
# add_mesh_masonry.py (c) 2007 - 'til now; Paul Spooner (Dudecon)

snipped (...)
#
# optimize for speed. Make it run faster?
# Grout model... yeah.
# consider removing wedge crit for small "c" and "cl" values
# wrap around for openings on radial stonework?
# auto-clip wall edge to SMALL for radial and domes.
# unregister doesn't release all references.
# repeat for opening doesn't distribute evenly when radialized - see wrap around
# note above.
# if opening width == indent*2 the edge blocks fail (row of blocks cross opening).
# if openings overlap fills inverse with blocks.
# Negative grout width creates a pair of phantom blocks, seperated by grout
# width, inside the edges.
# I was going to add an "inner/outer" toggle for steps and shelves but user can just rotate 180
# though you can't set shelf and steps on opposite sides of wall...

permalink:  378   posted on 02.07.2017 22:52
From Yorik
Commenting post 376: Hehe I thought someone would ask... We linux users cannot resist desktop screenshots.

The desktop is fluxbox (yeah I'm old-school but I really like it), with a theme I did and modified a bit afterwards to match the gtk theme base color, the gtk theme is elementary dark, the icon theme is Surfn Numix, the background I don't remember, and the geany theme is made by hand, just editing the filetypes.common file.

permalink:  377   posted on 02.07.2017 22:37
From Yorik
Commenting post 375: Thanks! Those are indeed good ideas... You are thinking ahead of me!

permalink:  376   posted on 02.07.2017 16:44
From Gergő
Commenting post 372: Hey,

I don't know the first thing about FreeCAD, but when I saw your screenshot I instantly fall in love with your Geany (and GTK) theme. Could you possible share what themes do you use (and where can I get them)?

Thank you very much!
Gergő

permalink:  375   posted on 02.07.2017 6:33
From Rafael (bitacovir)
Commenting post 372: Thanks for the news and congrats for the grant. About the patron. maybe you could give printed copies of your book. Or send them t-shirts with the FreeCAD logo (or with legends like "I am a FreeCAD patron", etc)

permalink:  374   posted on 29.06.2017 21:16
From Yorik
Commenting post 373: Oh thanks!!! I didn't know that. Will look at it right now.

permalink:  373   posted on 29.06.2017 20:27
From viralata
Commenting post 372: Hi Yorick, I don't know if you had a look at it but BlenderCam in it's last releases had a slicing part with a way to pack curves on a sheet. No idea what algorithm it uses but should be opensource.
blendercam.blogspot.fr/
A bientôt

in categories  freecad  opensource  permalink:  372   posted on 29.06.2017 20:08
From Yorik

FreeCAD Arch development news - June 2017

Hi all,

This is time for a new review of what has been going on in Arch development this month. Quite a lot actually, it's exciting that several things I've been working on during the last couple of months begin to flourish into pretty interesting and usable features.

There is another interesting thing happening, is a very good synergy between the WikiLab project I'm working on now, which you must grow tired of hearing about, and FreeCAD developement. FreeCAD fuels the project development, which in turns fuels FreeCAD with bugfixes and new features. Me and other FreeCAD community members are really keen to pursue and extend that synergy further with other projects.

As always, don't forget you can help me spending more time on FreeCAD, by sponsoring me via my Patreon campaign. As a side note, that campaign is really taking flight, sooner than I had expected, I'm highly overdue to update the campaign page, and add some whistles and bells such as goals and rewards.

As a possible reward, I am thinking about doing some short videos, explaining in detail specific feature of the Arch workbench, and more generally, doing BIM with FreeCAD. For example, one about walls, one about working with imported dwg files, things like that. These videos would be, in a first time, available to Patreon supporters only, as a kind of present to thank them, and then, after a couple of months, added on youtube for everybody. What do you think? Good idea? Lousy idea?

So enough of this, here is the real stuff:

WikiLab

If you are following the progresses of our WikiLab project, you might have seen that the crowdfunding campaign ended successfully, and we are now getting started. The wood panels have been ordered already, the final cutting sheets are being made, and the cutting should begin next week. This will take roughly two months, during which we will contract a constructor to build the foundation and base walls, and hopefully everything will be ready to build the WikiHouse-based part, at the end of August, during the university holidays, and just before the rainy season.

On the image above is a first "rib" we've been mounting this month, as a kind of proof-of-feasability, and to boost the crowdfunding campaign too. It went amazingly well, this element was built in about 2 hours by 5 people, it is very easy to understand and build, and the solidity is really impressive.

I'm also starting to write a manual (in portuguese) that willbe the actual construction document. No plans and sections in this project!

There are still several details to solve, some of them have been already discussed and solved on the WikiHouse community slack, which is a really cool way to solve these issues collaboratively, something we've been doing with OpeningDesign for quite some time already

Last month I also had an online conversation with Harry Knight from the WikiHouse Foundation, and wrote an article on Medium.com about our project. Check it up!

We are also studying small changes and improvements to the design, such as holders for shelf supports, and ventilation holes at the top, that can be closed with 3D-printed custom lids.

Draft Label

This is a new feature I've been working on, inspired by Revit's tag objects. In Revit, you have different types of tags, that you can attach to an existing object. That tag will then automatically display a certain information about the attached object. For example, material tags will show the material of the object, door tags will show the door number, etc.

In FreeCAD I decided to go for a bit more generic approach: There is a new generic Draft Label object, which is made of a piece of text and a two-segment line, which can have an arrow at its end. The text can be made to display some property from the attached object. At the moment only a small list of properties are available, and can be selected from a drop-down box, but the system is very extensible and you could have those Labels display just any kind of information that can be retrieved from the base object.

As always, this is only the first, rough version, it works, but over time and use it will certainly refine ito something more solid and powerful. It should also gain additional feature so it can be used for all the Revit scenarios: show component numbers, space tags, etc. All these should be displayable in a distinct manner (in a rounded rectangular frame, in a circle, etc...)

Shuttleworth Foundation

The other big news of this month, is that I've been elected for a Shuttleworth Foundation Flash Grant! Thanks to OpenSourceEcology fellows, who indicated me! I still don't have fully formed plans for what to do with the money, but a couple of things I definitely want to do: 1) Help founding the wikilab project above (that is done already), 2) Turn the FreeCAD manual into a printed book. Most of the work is done already, it still needs a professional editor review, then it can be printed and sold, which nowadays is very easy thanks to sites like lulu.com. And 3) extend what I'm doing with the money from my Patreon campaign, spend more time coding for FreeCAD. I would be able to work half-time on FreeCAD for a coupe of months, I'm trying to see how to set that up now. As a point 4), I might have more/better ideas later on, still thinking about it.

GSOC / Rebar

This year, FreeCAD has received four student projects for the Google Summer of Code. For who doesn't know, it is a program by Google to sponsor students to work on open-source projects during the (northern hemisphere) summer months. We are now approximately at the middle of the coding period, and our 4 students are doing great!

I am myself mentoring one of these projects, together with Bernd, which is Amritpal Singh's proposal to extend the Reinforcement bar tools in FreeCAD's Arch module. So far so (very) good, Amritpal is surprising us with the quality of his code, which you can already test if using a development version of FreeCAD: Just install the Reinforcement addon via the addons manager, and on next run, the Arch workbench will detect it and add its tools under its current Rebar tool.

The objective of Amritpal's work is to extend the User Interface around the Rebar tool, to add it a series of tailored dialogs to create specific types of reinforcement bars, such as straight bars, U-shaped bars, stirrups, etc. All this UI work integrates with the current Rebar object, which is kept as the overall, can-do-everything Rebar object. The different dialogs help the user to create and edit these rebars in a more friendly way, but doesn't remove anything of the power of the base rebar object, which is simply made of a profile, an extrusion path, and a series of placements, and can therefore represent any kind of rebar we can think of.

Everybody wins with this approach: The normal user, who just wants a clear and easy way to add reinforcement bars, and the power user, for who these dialogs are not enough and who wants to tweak or script these rebars in any way possible.

Nester

Here is the best part, in my opinion. I'm working (it's not finished yet, but working already) on an algorithm to perform bin packing in FreeCAD. It is an operation that consists in placing/packing different shapes inside a container (the bin), so it uses as little space as possible. The immediate output, obviously, is toproduce cut sheets for WikiHouse-style constructions, like this:

Interestingly, this is a subject that renders a lot of theory (lots of research papers on the net), but few open-source applications. The only "readable" ones I found were SVGNest and the WikiHouse plugin for SketchUp. None of them is usable directly in FreeCAD (different coding language, too tied into their host system, etc), but they provided precious resource to understand how such an algorithm should work.

They both use the same concept, which is the no-fit polygon. The idea is more or less this: You place a first piece inside the container. Then, for each other piece, you try to "rotate" it around the already placed piece(s). You are basically trying to place the new piece as close as possible to the ones already there. By doing this, you end up defining a "no-go" zone, that is, a zone where our piece cannot go otherwise it would overlap the already placed pieces. By subtracting that zone from the container area, you obtain an "available zone" where the new piece can be placed. You then place the piece at the leftmost available position in that zone, try again with different rotations of the piece, measure the results, and keep the one that occupies the smallest space.

The above concept is working already. It takes a lot of time now, it still needs a lot of optimization. But the concept seems solid. Later on, I will try to implement a genetic algorithm which would run several passes, swapping the order of some pieces, and keeping the best solution. There is a lot of space for improvements.

In the coming days/weeks I should have a basic implementation ready in FreeCAD, so we can start playing!

Panels

The nesting system described above is made to work with any shape or feature of FreeCAD. You select a series of flat objects, and another flat object as the container, and the algorithm will return a series of placement transformations, that you can apply to the object to have them packed into the space defined by the container shape. So this will work with any Part-based object.

However, the main interest for me is to use this with Arch Panel objects, for constructions such as our WikiHouse-based project above. These panels, at the moment, already have several features that will be useful for this kind of use, such as the Panel Cut feature that produces a flat view of a Panel, to be placed on a Panel sheet, you see that everything is ready for the nesting, we already have both the shapes and the container.

I already added a couple of useful features such as individual margin settings for each Panel Cut (the minimal distance it must keep with other pieces on the sheet), and the ability to render a Panel Cut either as a Wire or a Face. I also added a way to define and represent wood fiber orientation on a Panel Sheet:

This, allied with a way to restrict possible orientations of a piece on the sheet, will allow to have the nesting algorithm respect the fiber orientation when placing the pieces. There are also other features to come, such as the possibility to use any shape as the container (at the moment it is restricted to rectangular shapes), and I believe we will have a pretty powerful and flexible system.

Then the last operation needed in order to make FreeCAD produce WikiHouse components entirely, is to generate Path objects from the Panel Sheets, a task that has been already worked on extensively by Sliptonic (check this video where he explains it all).

That's it for this month I guess, as always,all comments and ideas are welcome, be it by posting on Patreon, on my blog, or on the FreeCAD forum!


in categories  sketches  permalink:  371   posted on 25.06.2017 22:13
From Yorik
Drawings I did today on the Minhocão. First aquarelle in ages, there is work down the road...