It's not much to look at but this is the beginning of the Medeek Structural Plugin: [image: ozJy_Structural-test1.jpg] The red panels on the wall indicate shear wall panels.

Not sure what is available in pure Ruby, but if you create Ruby C Extensions it open up a whole lot more - as you can make use of C/C++ libraries. It's often a lot more libraries available for C/C++ when you want to go beyond the standard Ruby API.

I have been looking for this algorithm too! it's so useful in design. Is there any follow up on this thread? The problem with ruby is that for all the available ruby geometry libraries I could find online are simple algorithms, I can write them myself. but for the hardcore ones such as straight skeleton... it does take some expertise to translate from other languages. looking forward to any ruby implementations for this.

Or perhaps top_face = entitiestb1.add_face(topcircle) top_face.reverse! if top_face.normal.samedirection?(topbaredges[0].line[1] status_top_bar = top_face.followme(topbaredges)

@medeek said: Are there any more gotchas I should be aware of with layers? Yes, SketchUp layers are not really layers at all. They do not "own" geometric collections of entities (like they do in most CAD applications.) In SketchUp, layers are display behavior property sheets, that can be shared with multiple entities. So in SketchUp, each object descended from Sketchup::Drawingelement has a layer property that can be assigned to point at one of these property sheets (that were misnamed "layers" by the developers.) So, in reality you assign a SketchUp object to "use" a layer, not put an object upon a layer. @paul russam said: ... could you please precede your layers with your/your plugin name this way they will remain unique, ... If you did the same with any component and material names your plugin(s) creates it would be very helpful too. This also applies to Attribute Dictionary names. They should be prefixed with the name of your author name and extension name in some way, so there will not be any clashing of dictionary names. (For example, we all cannot have dictionaries named "Properties".) Something like "Medeek_TrussMaker_TrussProperties" or whatever.

Its working great now, I'm using Chrome as my browser and zipping the files with Windows 7.

Groups are implemented as a special case of Components. They add some convenience methods that expose some aspects of the associated ComponentDefinition, and also a "lazy uniqueness" mechanism. By that I mean that when you copy a Group, it behaves just like a Component does - another instance is added to the ComponentDefinition. Only when you perform some action on that requires it to be unique does SketchUp clone a second ComponentDefinition and wire the Group to it (same thing as the make_unique method does). Any other copies remain associated with the original ComponentDefinition until you also alter them. For Group copies, it is a one-at-a-time thing.

"Some_Dict_Name" needs to be "Medeek_SomePluginName" at a minimum, and can be expanded even more, like: "Medeek_SomePluginName_Purpose" if "SomePluginName" will have more than one dictionary, each used for different purposes. Or you can nest dictionaries inside another dictionary. So you can have one toplevel company dictionary for all your plugins, called "Medeek" (or whatever) and create child dictionaries for whatever plugins that need them. Those child dictionaries could have grandchild dictionaries. But it is most important to know that you must separate your dictionaries from those of other authors. (It is up to you how to separate your various plugin dictionaries.)

When I use the truss plugin to create complex roofs I would like to be able to use the trim tool to trim some of the members (ie. a hip roof): https://3dwarehouse.sketchup.com/model.html?id=uade0f021-a386-402c-b784-087189478ecb

@thomthom said: @medeek said: Howevever, I can't seem to figure out how this attribute is automatically updating. I came across some code not too long ago that could explain this - but there is no documentation for this. SketchUp seem to apply transformations to Geom::Point3d and Geom::Vector3d object stored in attributes. This might be what you want some times - other times if you don't want it, store them as arrays. Which is basically what I said in the duplicate thread in the SketchUp forum, ... http://forums.sketchup.com/t/attributes-that-auto-update/27840 ... which has gone beyond the original questions.

Version 2.0.4 - 03.27.2025 Enabled removal of individual anchor bolts for stemwall step foundations. Enabled addition of custom location anchor bolts for stemwall step foundations.

group.material=material Where the given material is a reference to a material already available in the model, or perhaps it's the name of an existing material, or the name of one of the standard 'color' - that might be not yet loaded: So e.g. material=Sketchup.active_model.materials['truss_wood']Where material returns 'nil' if it's not found, or a reference to that named material otherwise. Or alternatively: material='truss_wood' which will work if you know that the material named 'truss_wood' is already in the model, or perhaps... material='brown' Which uses the material named 'brown', or it makes the new material then uses it otherwise. There is a preset list of 'colors' [à la html]: http://www.sketchup.com/intl/en/developer/docs/ourdoc/color If you want a material with another color or transparent, or a texture, then you must add it to the model.materials before referencing it. http://www.sketchup.com/intl/en/developer/docs/ourdoc/materials#add You then create a new color and apply it to that new material, which by default would be black with no transparency [0,0,0,0] http://www.sketchup.com/intl/en/developer/docs/ourdoc/material#color= If you also want to add a texture to the material, use http://www.sketchup.com/intl/en/developer/docs/ourdoc/material#texture= Which specifies the image file to use, then you can edit the texture's details with texture=material.texture Using:http://www.sketchup.com/intl/en/developer/docs/ourdoc/texture#size= etc...

I like to keep my data in a structure and I like to save structures to disk and / or store them as a complete record in a dictionary. So you can either parse the file / or parse the dictionary in the same exact way. Actually very simple and extremely future proof as they are key pairs. New versions that introduce new fields (elements) need only provide a reasonable default. I can provide you with examples if you want to PM me.

Are the original pt1 and pt2 created in the model.active_entities context ? If pt1 is always the ORIGIN then you really only need pt2 ? Why not use a transformation ? You can store the initial truss.transformation.to_a as an attribute with the truss. Then... when you next need to assess the current truss location/rotation just get the current truss.transformation and then modify [transform!] it OR even the saved point [or 2 points] - having adjusted it by the transformation that was stored as it was created - recreated from the attribute array back into a transformation. http://www.sketchup.com/intl/en/developer/docs/ourdoc/transformation

When I have collected usage information in the past I have done so only with the consent of the user. Furthermore the numbers simply go into a database and do not have names or locations attached. Many web sites today perform analytics. Even sketchucation performs a type of analytics to establish daily download numbers for plugins. The key bit is they don't track who downloaded - they just count the downloads. These are the download numbers for cab maker. You can see that the number of downloads gained momentum around the time Sketchucation featured my plugin. Now they have settled down. [image: iwt9_analytics.png] Similarly, in the past I have counted some usage specs to determine if a feature is worth more development or not. Again I do not know or care who used the feature. For example - If I were going to gather info on my CabMaker (which I have not done), I would first ask the user if it is ok and then I would provide them with a configuration that they could turn on / off anytime they want. The info could be something like this for Cabinet counts: Standard=155 Sink=6 Angled=1 Return=5 Left Blind=0 Rignt Blind=0 Tall=1 This combined with users emailing me with wish lists would help me streamline the priorities for further programming.

Both writing and reading with the registry with http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchup#write_default and http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchup#read_default is relatively straightforward and is applicable on an individual version and user basis, and can be construed to cover your own extension name and several key/value pairs as desired. However, the 'friendliness' I alluded to was relating to how it stores some of your data values. You can easily make some tests without attaching it to your main code. The newer versions of Sketchup do quite a good job of storing integers, floats, strings***, arrays*** and hashes and reading them back in successfully. See below for the *** caveats... *** There are some pitfalls to be avoided - e.g. including a double-quote " inside a string [e.g. even when properly escaped with a \]... so do NOT write "1'6\"" as a string, because you cannot read it back [the read back and now 'un-escaped' " produces an error], so you must use "1'6\\\"" to ensure that the enclosed " is properly escaped as \" when it's written, so it can be read back successfully... This sidestep applies to any plain string and also any string stored inside an array [where Ruby also encloses these inside double-quotes], but perversely hashes are OK with this because when a string is inside a hash that's written to the registry it is properly escaped 'doubly' [ "1'6\\\"" >> "1'6\""] so reads back in OK without any trapping here... These are just annoyances which can be got around... But watch out for them...

You don't really check the templates - you just ask the current model the user is using. The current model might be of a different unit than their selected template. At my previous job we switched a lot between mm and m in our project files. You use model.options to inspect the current model's options: options_manager = Sketchup.active_model.options options_manager.keys.each { |options_provider_name| puts options_provider_name options_provider = options_manager[options_provider_name] options_provider.each { |key, value| puts "> #{key} - #{value}" } } Output from that snippet: PageOptions > ShowTransition - false > TransitionTime - 2.0 UnitsOptions > LengthPrecision - 0 > LengthFormat - 0 > LengthUnit - 2 > LengthSnapEnabled - false > LengthSnapLength - 0.03937007874015748 > AnglePrecision - 1 > AngleSnapEnabled - true > SnapAngle - 15.0 > SuppressUnitsDisplay - false > ForceInchDisplay - false SlideshowOptions > LoopSlideshow - true > SlideTime - 1.0 NamedOptions PrintOptions > PrintWidth - 8.5 > PrintHeight - 11.0 > ComputeSizeFromScale - false > SizeInPrint - 1.0 > SizeInModel - 1.0 > VectorMode - false > FitToPage - true > NumberOfPages - 1 > LineWeight - 0.5 > PixelsPerInch - 150.0 > SectionSlice - false > ModelExtents - true > PrintQuality - 0 > ScaleAdjustment - 1.0 > QualityAdjustment - 1.0 So in this case you want to inspect UnitOptions: model = Sketchup.active_model model.options["UnitsOptions"]["LengthUnit"] Note that you want to use the constants in the class Length against the values returned here. Length;;Decimal Length;;Architectural Length;;Engineering Length;;Fractional Length;;Inches Length;;Feet Length;;Millimeter Length;;Centimeter Length;;Meter So something like this: model = Sketchup.active_model unit_type = model.options["UnitsOptions"]["LengthUnit"] metric = case unit_type when Length;;Millimeter, Length;;Centimeter, Length;;Meter true else false end I'm doing this check because LengthFormat got options that can be used with both imperial and metric units.

As Sam says, transformations only apply to containers like component-instances, groups and images. A Point3d does not have a transformation, BUT you can use point.transform!(transformation) it relocate it. Basic entity objects - like vertices, edges and faces - have to be transformed using: objects_parent_entities.transform_entities(a_transformation, [array_of_objects]) this works with any kind of transformation; or for a vector based 'translation': objects_parent_entities.transform_by_vectors([array_of_objects], [array_of_vectors]) note that each object in the first array must have a matching vector in the second array... Also if you are using the these to move say vertices, don't also include some edges or faces which use those vertices - otherwise the vector transformation will be done twice, with unexpected consequences...

@thomthom said: https://github.com/thomthom/SKUI Could you add version to README.md? Pretty please with a cookie?