"... it gets the point across." ... very funny (and a groaner!).

@beepee said:

Dave: I think your argument that I should pay the high cost for the Pro version because I use Sketchup to make some things to sell doesn't hold water. I use a LOT of other software as part of my business too: MS Word, Excel and other aspects of MS Office, Outlook, Video making software, music recording software etc etc etc.

I don't think I should have to pay the high price of your music on MP3's because I only listen to them while I'm on the road and not all the time (I like country too). I can find your (great) harmonica songs on another site where they are free. In fact, there are a lot of free MP3's available on regular sites so why should I pay the much higher price for yours? You would do your listeners a favor and it would be a PR win for you if you just gave them away.

Like the developer's at sketchup, I find you to be very talented.

FredoGhost perhaps?

@baz said:

Fab drawing, love the combination of solid line and x-ray. (Now to figure out how you did it

I'm very happy with my "Dell Ultra HD 4k Monitor P2715Q 27-Inch Screen LED-Lit Monitor" ... under $400. But, then again, my eyes are old so it might not meet your specifications!

Might this be what you're looking for? https://www.youtube.com/watch?v=vNt8g6ERUE4

Thanks for your continued help, Dan.

I've been closely following the methods outlined in "Sketchup & Layout for Architects" by Sonder and Donley (see http://sketchupbook.com). I use the Sketchup and Layout templates that are provided with great success -- the documents that are generated from all of the scenes look great (although I'm still learning -- there's a lot of information provided in the book that I have yet to understand and/or utilize). The methods in the book appear to expand the concepts outlined in the "Ten Fundamentals about LayOut for Architects" tutorial.

Modern, stick-built structures don't require the architect to detail each unique lumber component, fortunately. Timber Frame builders, however, often require detailed dimensions for each unique timber. This is where I think the methods for timber construction might need to add some new steps to the process.

A frame I'm currently working on (a 744 sf garage) has 24 different frame members. Using the same type of methods in the book I would have to create 76 different scenes (24 * 4) for the four views of each member. I would then create 24 layout pages each having four viewports for each of the members so that dimensions can be added. I'm just trying to wrap my head around how I might automate these tasks in an effective way -- especially when there are several design iterations that would require regenerating some scenes and layout pages.

@dan rathbun said:

Yesterday SketchUp 2018 Pro was released, and with it we now have a Ruby API for creating and accessing LayOut documents from SketchUp. (A live in LayOut API with application hooks has not yet been implemented, but is likely within a version or two.)

Doc: LayOut API overview
Doc: Layout module

Thanks, I'll be reading the docs to see how they might automate the workflow we've discussed.

@dan rathbun said:

This is important for you to know that SketchUp Make is discontinued (and will not be updated beyond v2017.) It is replaced by the cloud SketchUp Free (formerly my.sketchup) which as yet has no API, and when it gets one it'll likely be Javascript rather than Ruby.

This will be a disappointment to those who currently use (or plan to use) the TF Rubies extension. I suspect they will continue to use the 2017 version until the web-based version allows the use of extensions. I don't have much concern since I have Pro.

@dan rathbun said:

(Not a timber person, but am a fan of "BarnBuilders". Wouldn't the peg holes be drilled in place after the bent is assembled on site? I could see starting a pilot hole in the post.)

You're correct ... the holes are typically laid out in pencil and not drilled until shortly before raising when the joints are "fit up" to ensure all the joints fit together. Posts are drilled first and then the beam and braces are removed and drilled separately with the hole slightly offset ("draw-bored") so that pounding the peg in will draw the joint tightly together.

@dan rathbun said:

NO. This is not how it is done for LayOut. ONE copy is made and moved off to the side, and perhaps set to use it's own "detail" layer.
Then, four scenes (camera positions) are created for the 4 viewports in LayOut, each showing one of the post's sides (in each of the 4 scenes the "detail" layer is set "visible" whilst all others are "off" [except for "Layer0" the primitives layer which must always be visible].)

I could imagine twenty or thirty unique timbers that would need shop drawings in a more complex timber frame. That's a lot of scenes! Automating it would make it easier to generate the scenes/pages but importing all those models and arranging the viewports in Layout would be a pain. However, I'll experiment with generating the scenes as you suggest.

@dan rathbun said:

The original "unmods" could be associated with the "working" layer up until the point when you do the intersection, and make them unique. The code could create a "unmod" copy and put it on a hidden layer, but in proper position for possible mod later.

OR, the code could have a command to recreate (instantiate) an "unmod" post at a later date using the current transform of the "moded" post. (This way you don't have unused geometry bloating the model. The same would need to be done with the beams. I prefer this workflow.)

Another alternative is to build the frame and copy the entire thing perhaps as a unique assembly component, before adding the bracing ? This could be all on a hidden later "in limbo" so to say. So that any timber can be copied "in place" (already having the correct transform) to the main "working" layer.

All excellent suggestions. Your preferred method would be my choice also. Beams (and sometimes posts), however, often have tenons (or other complex geometries) at the ends that would probably make the first suggestion more viable (although I'll think about the others a bit more).

I don't expect to take up more of your time, Dan, but if you have more suggestions please keep them coming!

Dan & Dave,

I was wondering if your collective experience could help me work out a more efficient workflow. The one I've been using is based off of the way the "Timber Framing Rubies" extension worked. That extension works with the free version of Sketchup but I think the Pro version (with its solid tools and Layout), and with the help of some custom code, is much better suited for timber framing design.

Here's a simple "bent" (collection of joined timbers) for the sake of discussion. This bent consists of six components: right and left posts, a beam, right and left braces and a peg (six instances). Only the "male" parts of the joinery are drawn (the tenons) so, in this case, the post is simply a rectangular volume.

Let's say the design is pretty much finished and I wish to generate a shop drawing for the left post. I would select the post and choose the "Make Shop Drawing" item from the context menu. The script would copy the selected post, make it unique and trim the post with each intersecting component (the beam, right brace and two pegs).
It would then create a group (maybe in a layer named "Shop Drawing" perhaps) with four copies of the post (now with all of the mortises and peg holes). The four copies give the parallel projection view of each of the sides of the post that can be brought into a layout viewport for dimensioning. I have the ruby script doing these steps right now (short of creating the new layer) but the shop drawings are saved to a separate file. I was thinking of modifying the script to create a "Post Shop Drawing" Scene showing just the "Shop Drawing" layer the group of four copies positioned in the window with all the right settings (if the script doesn't do that for me).

I would like to keep the original (unmodified) post in place so that if I later decide to, say, replace the 30-60-90 degree brace that's shown with a more conventional 45 degree brace, I can just replace the one that's there, select the post and execute the script once again (presuming I can replace the group in the "Post Shop Drawing" layer with the new one).

I do like the idea of keeping all of this in a single skp file and doing away with the separate shop drawings. Does the workflow I describe above seem reasonable? I welcome any suggested improvements.

Dan & Dave,

Thanks for the feedback you've provided. I'll be re-reading your comments (probably many times) as the methods you both describe would probably work better for me.

I have resolved the issue I originally described. The code that performed the trimming and second original.set_attribute() operations were between a model.start_operation() and model.commit_operation(). When I moved the second original.set_attribute() after the model.commit_operation(), I got an error on the console implying original was deleted. I modified the code to save a reference to operation.definition and then using this to set the attributes,.
After doing this, the code worked as I first expected (I hope that all makes sense).

@dan rathbun said:

I notice some errors in your coding:

if original.volume != original.definition.set_attribute("timber", "volume_uncut", original.volume)

You cannot both test and set in the same statement like above. This statement will always be true because it sets the attribute every time.

I think you meant "This statement will always be false ...", right (the comparison is !=)?

Yes. I had read the documentation of set_attribute and it mention that it returns "the newly set value if successful". It doesn't mention what it'll return if unsuccessful so I assumed 'nil' or a null string (in Python, they're different but I'll have to look it up for Ruby). My assumptions were incorrect so I'll change the code to your suggestion (besides, I like your code better) --- THANKS!

Great to have people like you, Dan, to help us neophytes out!

Hi, Dan. Thanks for taking the time to respond to my question.

@dan rathbun said:

Both instances and definition can be assigned attributes. Normally an instance type data attribute would be assigned to an instance's dictionary, not a definition's.
This is because instances can be scaled to change the volume. Sometimes the scaling is along a single axis resulting in a "stretch" of the original. (Different instances of the same definition can be scaled and stretched differently.)

In the problem domain in which this code will be used (Timber Framing), there isn't usually the need to scale any of the instances but I didn't state that figuring I'd keep it simple (sorry about that!). If a timber is different in dimensions, a new component is typically created.

The extension I'm writing allows me to select any one instance of the timber and it then trims the beams (with tenons), braces (also with tenons), pegs, roof rafters, etc. that intersect with it. The resultant solid is then formatted as a shop drawing, saved to a separate .skp file, and then deleted from the model (thus, losing the any attributes that would have been saved with the instance). I want to use the difference between the volume of the selected component and the volume of the resultant solid to determine the amount of wood that needs to be removed -- this would be used to arrive at a rough estimate of the effort required to cut the timber. Saving this information in the definition makes much more sense in this case since it's the same for all instances using the same definition.

Moreover, if the dimensions of a timber were to change, a new shop drawing would be generated and the definition attributes related to the dimensions would then be updated.

@dan rathbun said:

Volume: Manifold solid instances of group and components have a built in API method to return the volume, named volume(), so there is no real need to waste time computing it and saving it to a dictionary attribute.
http://ruby.sketchup.com/Sketchup/Group.html#volume-instance_method

Point taken. I used volume as an example for the code but there are a number of other attributes (section modulus, moment of inertia, etc.) that I plan on saving.

@dan rathbun said:

---

Now, Jim Foltz created a plugin called Trim and Keep that works around some of the annoying creating of new group from solid operations.

Look it up in the PluginStore.

Kewl, I'll look this one up.

In light of all this, might you have an idea on why the second set_attribute would not work?

Also, I (re)discovered Layout Tables, maybe this might be a better way to collect up the data associated with the timbers and get it into the 2D drawing. Thoughts?

I have another little problem that I just can't figure out (after perusing the forums for a few hours).

I have a solid component (the "original") that I add a few attributes to the definition before I copy it, perform some solid "trim" operations on the copy and then attempt to save the volume of the copy as an definition attribute of the original.

` original = Sketchup.active_model.selection[0]

if original.volume != original.definition.set_attribute("timber", "volume_uncut", original.volume)
print("ERROR: Unable to set original's attribute\n")
end

theCopy = model.entities.add_instance(original.definition, original.transformation)
theCopy.make_unique

perform a number of "trim" operations on theCopy and other solid components

if theCopy.volume != original.definition.set_attribute("timber", "volume", theCopy.volume)
print("ERROR: Unable to write data: #{theCopy.volume}")
end`

Using the Eneroth Attribute Editor, I can select the original component and see only the "volume_uncut" attribute -- the "volume" attribute is missing.

The console doesn't report any of the ERROR messages and I've verified the the values for original.volume and theCopy.volume are valid numbers just before invoking the set_attribute methods.

Nothing else is done with the original component than shown here.

I'm at a loss as to where I've screwed up and don't have any more ideas on how to fix it. Any hints?

Thanks