At first I didn’t know if it would be possible however after giving is some considerable thought, the trick is to come up with the most general solution and then to make sure it is efficient enough so that even though there is a lot of geometry to process the performance will still be acceptable.
I haven’t actually generated the code for the rafters yet but I think I’ve established the direction I need to take (it’s all in my head right now), the question is can I make it a reality?
Added logic so that customized roof planes can co-exist with the “Move Roof Edge” and “Edit Roof Outline” tools of the complex roof module.
Previously, moving roof edges would potentially shift the customized roof planes if certain roof edges were removed or consolidated. I think we have now achieved a fully parametric status with the various tools all working together.
After giving it some further consideration I’ve decided to enable dutch gable and half hip options for custom roof planes rather than leave it for later. If I include these options now it will force me to keep my other more specific algorithms general enough to handle all cases. The geometry calcs required to generate the roof primitive for these two other configurations is really not that difficult and actually provides a rather intriguing challenge.
Notice the additional “setback” parameter in the menu. Also a half hip roof plane has both hip and gable parameters with the non-applicable parameters grayed out, as shown.
Similar to a gable end, the half hip can only be applied to certain roof planes, the plugin automatically restricts this placement.
The overhang of the half hip is governed by the gable overhang parameter, hence the overhang under the hip options is grayed out.
In a recent question posed on Youtube I provided the following response:
I actually started developing these plugins quite by accident (Truss plugin). I have a web based truss calculator that I initially programmed as a purely academic exercise but eventually became a web based tool when I saw that others might have use for it. This web based app provided a way for the user to generate a DWG of the truss geometry and then download it. I don’t remember who it was, but a SketchUp user emailed me one day back in early Oct. 2015 if I could also make it generate a SketchUp file instead. At that point I had no idea if I could or not, I had no knowledge that SketchUp even had a Ruby API, so I said I would look into it. A few days later in some spare time I was curious if SketchUp might have some sort of AutoLisp like feature (similar to AutoCad) so I dug around on the internet a bit and sure enough an API did exist.
In a few hours I quickly hacked together a bit of Ruby code (my first time coding Ruby, all my previous coding experience is primarily Perl, javascript and HTML) and pretty soon I had some code that one could drop into the ruby console or your plugin folder (.rb file) and it would draw the truss geometry. At the same time I also discovered the various SketchUp forums (SketchUp and Sketchucation). I posted about my update to my truss calculator since I figured other SketchUp users might find this useful if they wanted to model up accurate trusses: 3D Truss Models • sketchUcation • 1
A few days later Julian Smith (South African Architect/Designer) asked me if this tool would become a “real extension”. That got me thinking and I thought if I can find the time it might be fun to actually make this into something. I was finding that the API and ruby were actually quite fun to program and it didn’t take much convincing to keep working on it, in truth it was strangely addicting. One thing led to the next and pretty soon the truss plugin was capable of generating a number of truss types.
In 2016 I started work on the Foundation plugin however I held off on developing the Wall plugin since John Brock (Estimator for SketchUp) had announced his work on a framing plugin.
By early 2018 the Truss plugin had gradually evolved into quite a complex and deep plugin and I had a number of people begging me to consider doing a Wall plugin, including Larry Belk who had been pushing me in that direction since 2015. Brock’s wall plugin had still not been released so I finally decided I’d go for it. Except this time, instead of working on it part time, I decided to go for it full time, a major leap of faith. I did a KickStarter campaign to see if there was sufficient interest in a Wall plugin and started programming it full time in early April 2018. By May 25th, I released the first BETA of the wall plugin and by January of this year I felt like the plugin was good enough to move it from BETA status to full.
All of the plugins are currently under active development, much work remains to be done. They have been my full time job since I started the Wall plugin last year. My current push is to complete the complex rafter roof module. I am grateful to SketchUp for having the foresight to provide an API, and for my customers who allow me to keep creating and pushing the ball forward, without them none of this would have been possible. One day I would like to see SketchUp become the predominant architectural tool used for residential and commercial work.
I have no idea on your first question. If you get a bug splat during a plugin operation I would chalk that up to something plugin related however a file not getting saved and problems with other plugins is outside of what I can answer.
You can install the plugins in 2018 and 2019 simultaneously. Both installations are independent of each other (separate plugin) folders.
A few more kinks to work out in the sheathing module, but overall it is working better than expected and it wasn’t nearly as hard to code as I initially thought it would be.
View model here:
Still a bit more work to do with sheathing when the dutch gable option is utilized. As you can tell from the model the sheathing is not tucking under the gable end overhang just yet. I will be addressing this tomorrow.
Well, if it all works as planned you should be able to create a really complex roof in about as long as it take you click on the points that define the perimeter (30 seconds) and then however much time you want to further adjust custom roof planes or other parameters.
I imagine a fairly experienced SketchUp user could generate the same complex rafter roof in about 4 - 6 hours.
I’m trying to make the tools and menus as flexible as possible so that most if not all manual editing is eliminated.
My previous post was dealing more with the performance of SketchUp rather than a comparison with a manual draw vs. the plugin. My concern is that on a really complex model a regen might take upwards of 15 seconds or more. I guess we will just have to see.
I’ve been thinking about connecting roofs together, for example a gable roof connecting to another building where the roof meets the wall. For this type of scenario it might be useful to have an option for a cutoff end (gable end with no overhang etc… I’m not sure exactly what to call this.
P.S.
It’s funny where my thoughts take me when I take a breather from the code, I guess even when I’m on break I’m still contemplating what needs to be done with these plugins. I just realized that I can enable one additional option in addition to all the other options (ie. gable, dutch gable, half hip). I will call this a “CONNECTION”. Basically you will be able to connect one roof to another (secondary roof). However, rather than having a separate module for the secondary roof I just realized that with the connection option complex roofs can become secondary roofs, so an additional module is not necessary.
I will need to give this considerably more thought but I think this direction I need to go. There will need to be some options for connection type (another roof, a wall or a roof and a wall). I will need to explore the possibilities, this is going to get interesting.
If things weren’t complicated enough with complex roofs, they just got a lot more complicated.
Rather than having two or three different types of connections I think it makes more sense to sub divide it into two additional options and then a connection is simply a connection. You end up with two additional options: TERMINAL and CONNECTION
With terminal it is very similar to a gable end however the roof just ends, no overhangs, no outlookers etc… This would be used when framing the roof up to a wall that is parallel to the roof edge. Theoretically this same type of roof could be achieved with the CONNECTION option however it would remove the requirement for selecting a primary roof (or solid) to connect to, and just simply end the roof in a squared off fashion.
The CONNECTION option is a bit more interesting. To get the results that we want we need to make this end treatment as general as possible. One could potentially connect to any group or component in the model or to another Medeek complex roof assembly. I will need a tool within a tool which allows the user to select the primary roof/object that they would like to connect to.
If the selected group is a Medeek roof assembly then the primary roof will also store that it is being connected to by a secondary roof, and the secondary roof will list the instance name of the primary roof it is connecting to.
If the selected group or component (must be a solid) is a non-Medeek roof assembly it will also store and list the instance name of the primary object that the roof is connecting to.
Here are shown a couple of possible connection scenarios:
To keep this option from completely spiraling out of control we must make the assumption that the only roof planes impacted by the connection will be the two adjacent and orthogonal roof planes that are either side of the connection roof edge (the connecting roof plane technically does not exist). I’m sure there will be users who try to subvert this requirement in certain design situations, so some logic to check this limitations may need to be implemented.