Archicad Keyboard Shortcuts Pdf Writer

FreeCAD Arch Development News - November/December 2017 Hi all, First off, sorry for the delay, I was trying to finish the new Render workbench (see below) before posting this report, because otherwise there is not much exciting stuff this month, and it ended up taking more time than I thought, because I kept experimenting a lot until arriving to a good solution. And since not much more will be happening this year, given the coming new year events (a good friend of mine calls this The Great Intoxication) I'll exceptionally make one report for two months, if you don't mind. But I'll give you some more news before the January report. I'd also like to take this opportunity to thank you all who contributed to my (or Librepay) this year, it has triggered some big changes for me, which took (and are still taking) more time than I thought, you don't turn into a part-time programmer overnight, but it is a really cool process, and, truth be told, during last year's dire economical crisis in Brazil, this FreeCAD 'job' I now have thanks to you guys helped me a lot to keep the boat afloat. Thanks a million for that. Basically FreeCAD development has now entered 'feature freeze' mode, in preparation to the upcoming 0.17 release. I can hear the question rushing from your hearts: When???

There is unfortunately no answer to this yet, as some of you know, a motto we have at FreeCAD, that we really like a lot is: 'It's done when it's done'. This can be interpreted in many ways, you might think 'lazy developers don't want to work hard enough!' But it is not that. It is very important to all of us to be able to release when we think it has reached the correct level of quality. As the project grows too, there are more and more developers involved, and more and more features weren't touched at all by one of the core developers, and it takes time to have everybody focus on fixing bugs. In a sense, FreeCAD has its own rythm, and we try to make sure everything that needs to be done is done before releasing.

Mar 26, 2017. EPDF EXPORTPDF / Exports drawing to PDF. Using PDF Files in ArchiCAD. AutoCad 2007 Keyboard Shortcuts. Keys ALT+F8 VBA Run ALT+F11 VBA Editor CTRL+1 Properties Palette CTRL+2 DesignCenter Palette CTRL+3 Tool Palette. List of keyboard shortcuts that you can use with Adobe Acrobat DC.

Also, but this is more my personal opinion, working on an open-source project is awesomely cool. You don't have a boss telling you how you must do your job, no schedule, no deadline, no need to do this or that today, you decide what you want to do, how you want to do it and when. Total freedom. And I believe one of the main reason why open-source projects thrive well is this. People like to work on them, they have cool communities full of entusiast people who stick there for a very long time. And I think it is important to keep an open-source project a very cool and awesome place for developers to be.

And I'm not sure very strict projects with lots of schedules and roadmaps are as cool to work with as FreeCAD I'd like to hear it if you have a different opinion, though. Also in the case of FreeCAD we have a pretty permeable workflow. Development versions are easy to obtain and install, even side-by-side with the current 'official' release, and are usually very stable. Most long-time FreeCAD users only use development versions.

So the urgency to release official versions is low. So, we are now in feature freeze mode, which means we don't add new features to the code anymore (at least we try to), we concentrate on testing and fixing bugs. There are still a couple of nasty ones to be fixed, but in general the process is going well. Regarding the Arch workbench specifically, I am currently developing with it, and using it as a test bed to test all possible scenarios and find bugs (and fix them of course). There is unfortunately nothing very exciting to share here, it's mostly small things, but this is an important phase. All in all, I think the Arch workbench is in pretty good shape for the coming release, we of course still don't have all the features we want for it to be a full BIM application, but the existing tools grew a lot in stability, versatility and usability. For some of them like the structure or panel tools, I believe we're not far from commercial counterparts.

Also, there are now several tools and addons around Arch, such as Reinforcement or Flamingo, that, together with Arch, are building a much bigger and more complete BIM ecosystem in FreeCAD. There are many things you can do to help to speed up the release process, if you are interested.

For example, helping with the or more generally, do some work with FreeCAD and help to find bugs. As always, the is the best place to go if you want to help. The Render workbench The is a new workbench I've developed last month. It is meant to replace the built-in of FreeCAD. The main reason is that the Raytracing workbench wasn't really made to be extended with other rendering engines, but these engines get obsolete quickly and new ones pop up all the time, so I thought it was worth starting a new one from scratch.

The Render workbench is coded in Python, because since the rendering itself is performed by another application anyway, there is no critical speed issue here, so the speed of C++ code is not really necessary, and it makes the workbench much easier to extend by other people. I also took extra care of making it simple to understand and extend, you basically only need to add one new file for each new renderer, and write 3 functions inside: One that writes the position of the camera in the file format of the renderer, one that writes the geometry of a given object, and one that is called when the 'Render' button is pressed. So far the two original engines of the Raytracing workbench are supported ( and ), plus a new one,. Other such as Blender's Eevee and OpenCasCade's are on my todo list. The Render workbench works exactly like Raytracing: You start by creating a Render project, then add your objects to it. You can tweak some things like color, transparency, etc (the Render workbench also supports FreeCAD materials, which turns it the third workbench with material support, after FEM and Arch), and finally press the Render button to create the rendered image. And the Render workbench uses the same templates as Raytracing, in the good tradition installed with TechDraw and Drawing.

This is still pretty new, but in the coming days I'll try to produce some good-looking images to post. That's it for today, thanks once again to everybody who helps me on or, it's really thrilling to see what this can produce, this year has been very rich in new features, I can't wait to see what we'll do next year! Cheers Yorik. FreeCAD Arch development news - October 2017 Hi there, Time for a new report on the development of for. Remember, you can help me to spend more time working on this, by sponsoring me on, 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, I just returned from the US, and we are also now finishing the project ( 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.

FreeCAD Arch development news - September 2017 Hi everybody! Here we are for another monthly report about the development of tools for, 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, 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 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. 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, and the other is the complete assembled model, that was used to generate the,, 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 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 '. 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 ) 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 (or ) or, like in a, 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 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 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! GSOC Finally, next month I'll be in the San Francisco Bay Area for the.

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! 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. Eminent Persians Pdf. 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): This is standard stuff, readable by any SVG app. Inkscape adds its own attributes like this: '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='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'.

FreeCAD Arch development news - July 2017 WTF, July development news in August, I hear you yelling (it's!) 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 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.

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. 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 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 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 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. 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 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 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 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 tool in Draft, that stores the position of the current working plane.

Download Anime Hatsune Miku Sub Indo 3gp Heck there. 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 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. 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 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 he has been producing lately about BIM work in FreeCAD.

Arch space bounds I also added UI controls to edit the boundary objects of. 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 to make this come true, and as always, comments are welcome! FreeCAD Arch development news - June 2017 Hi all, This is time for a new review of what has been going on in 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 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.

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?

So enough of this, here is the real stuff: WikiLab If you are following the progresses of our project, you might have seen that the 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 (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 for quite some time already Last month I also had an with Harry Knight from the WikiHouse Foundation, and wrote an about our project. 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 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! Thanks to 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 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. And 3) extend what I'm doing with the money from my, 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 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. 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 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. 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 and the. 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.

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 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 feature that produces a flat view of a Panel, to be placed on a, 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 objects from the Panel Sheets, a task that has been already worked on extensively by Sliptonic (check this 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,, or on the!