if two (or more) materials have the same RGB (color) setting (no texture images) but have two different names, they cannot both be used in the same model. whichever material is first selected will be the one displayed in the model list of materials used and you cannot select another from a list of materials.

if you have "material a" with RGB = 0f0f0f and "material b" with RGB = 0f0f0f, whichever one you load first will prevent the second from loading. so effectively the name of the material is meaningless, it's the numeric color setting that defines it. this is painful where i want to specify the same color for different materials: lumber_stud, lumber_runner, lumber_plate, lumber_sill, etc so my reports have their quantities broken out by material.

I do use Excel currently but i'm thinking a built-in solution for SU would be nice

looks like the price on that site was for a 10 pack, a single user is $350 for 1 year license - so basically $350/year...

yeah, naming your parts and using materials (i use colors named as needed "lumber_stud", "machine_bolt" etc then replace if used for rendering later) is key to making the reporting work well. then i import to excel and run some macros to remove extraneous values and summarize (DSUM DCOUNT etc) to create the materials list. it would be nice to have the reporting take families of groups and report directly though...

it would be cool if DC had a "record macro" function. but some more functions (like % (mod)) would be nice plus parent's parent referencing (as well as inserting of Ruby code )

i've been struggling because the intricate 3D models then need to be translated into 2D plans or exported as DWG in 2D to interact with other people in the process of getting things built... so having the ability to use parameters, scale, and switch between 3D and 2D views easily is important to my work flow. scripts only take it so far, so the DC components (like framed walls, doors, windows, etc) all help with the modeling, drafting and material lists more than the scripting or individual modeling does (at least for me). so i try to invest at least 5 hours per project creating re-usable DC components so the next project is somewhat reduced in time and the quality is the same or better even.

i think the biggest win for pre-built is the kitchen components - there seems to be quite a few nice ones out there plus Pella and Marvin both have some nice windows and doors.

like object programming - encapsulate the objects. if the picket is simple, then create as a group and use the master to host the parameters and things like "count" etc, then in the group (picket) simply use the Copies and simple space rules to lay them out. if the pickets need to align end to end and the space can vary slightly, then compute that in the master and create an adjusted space after computing the number of pickets you can fit in a given length. or if spacing is important, compute the final size picket (in the master) and IF(Copy=Copies, last_size, normal_size). on align, IF(Copy=Copies,Master!LenX-normal_size,Copy * (normal_size+spacing)) etc.

if the object is complex, then make it a component with everything it needs to function but remember to pass parameters to it from the master otherwise using the component options UI will not work as sub-components do not surface their parameters to the UI. likewise you cannot reference the parents parent so you need to pass parameters on the components.

it can be frustrating. i've spent a few days making dynamic stud wall framing which has a feature to prevent end studs from overlapping because i wanted them to be usable for 2D drafts. yikes! and even after you test and test, there's always a glitch which needs adjusting... i'll get it eventually... it would be great if there was a native API which could be used with Ruby scripts to i could use/replace some of my scripts as plugged into a DC as the math in a DC will not properly support some of the math needed...

picket_fence.skp

yea, being its occurring over several runs, it may be a variable scope issue where something is persisting which causes the subsequent run to make incorrect assumptions...

seems to work perfect. including complex ceilings. but... if you have the face @ zero on the z-axis, you do see the inverted faces which are flush with the grid and not dropping through. so just make sure your ceiling face is above the zero plane... then again i may have spoke too soon... a complex ceiling definitely exhibits some strange results even when sitting above the 0 on z-axis...

complex ceiling.skp

@tomot said:

@unknownuser said:

Hi:
Dear sdmitch,your plugin nice,maybe have little need to change:

Please lets not get carried away here! whats ... next a request for the actual supporting hanger holes and hanger wires?

next thing people will want an algorithm to place light and vent openings

yes, please.

if you use values like 2x4, 2x8, 5/4x4 etc then have the calculation to subtract to form the dimensional lumber, it should work... but i do like the nag suggestion as well

i added some code to mine so values larger than 2x6 in the lumber class so it subtracts 0.75 instead of 0.5. i think it would be best to modify the metric version to support both plus some other tweaks..

cheers! registry hacks-r-us! did the trick. i did report it as a bug to Google so hopefully this make the adjustment in the next patch or version.

so... the Google bug people pointed me to a feature: in the preferences -> work space is a button to "reset work space"

if i have two monitors - a large 24" (1920x1200) and my laptop built-in display (1280x1024). when using the large monitor, if i open the dynamic component attributes window and move it to the far right of the screen (taking advantage of the real estate) then close out SU. then open SU using only my built-in screen, and try to view the DC attributes window, it (per my desktop settings with shadows)only shows the shadow from the dialog box on the right (showing, un-showing the window has the shadow appear and disappear so the window is opening & closing, but off screen). i cannot see it nor select it to move it back to where i can see it. it seems to retain the absolute position versus a proportional/relative position.

the normal windows (component, entity info, materials etc) all respond proportionally/relatively so if i drag them to the right and open on the smaller screen they are position and viewable on the right end of the smaller screen (as expected).

any keyboard commands to allow me to move the window back into the viewing area? i don't have access to the larger screen at the moment.

thanks! very cool. i didn't realize there was a set of attributes which could simply be stripped. it works really well - pretty much instantly on a fairly complex DC. definitely a last step in the process...

i was wondering how to take a dynamic component and convert it into a static component. basically if after adjusting the parameters it was possible to explode each sub-group or sub-component and re-group it or re-componentize it with the same name as it originally had, if that would do the trick. if this script could also perform this on all DC at once or within the same family or selection, would be ideal. the sharing models with a lot of DC which are converted to static units (preferably losing all the calculations etc - purged?) would be nice to reduce size and or protect proprietary components.

almost sounds like a hash value pointing to the deleted page is embedded in the doc - perhaps preserved because of a layer or component value? maybe clear layers and purge the file?

i actually tried that (remarking out that line) and it still failed. i did reload the libfredo plugin fresh off the board just now (and had tried the beziersplines earlier), same issue, there is no mouse pointer and its the same errors. if i rem out the libfredo.rb, then it works.

copy of note in LibFredo thread:

not sure if it is the LibFredo 4.3b or the BezierSpline 1.4f plugin, but if the LibFredo 4.3b is enabled, the BezierSpline 1.4f does not work. i get a Ruby console error for line 592 cannot convert nil to float.

@unknownuser said:

Error: #<TypeError: no implicit conversion to float from nil>
C:/Program Files/Google/Google SketchUp 8/Plugins/BZ_Dir_14/bezierspline_main.rb:592:in -' C:/Program Files/Google/Google SketchUp 8/Plugins/BZ_Dir_14/bezierspline_main.rb:592:in onMouseMove'

Fredo tools works regardless of BezierSplines being enabled or not.
NOTE: I only encountered this error since updating to 4.3b and prior to that it was working correctly.

NOTE: this result was found with only the LibFredo and BezierSpline plug-ins running - SU8 Pro on Windows Vista SP2 Ruby 1.9.3

NOTE: it may be due to LibTraductor - the old version is still in the plug-in directory and the Lib6Traductor in the LibFredo dir is not compatible with the BezierSpline calls.

not sure if it is the LibFredo 4.3b or the BezierSpline 1.4f plugin, but if the LibFredo 4.3b is enabled, the BezierSpline 1.4f does not work. i get a Ruby console error for line 592 cannot convert nil to float.

@unknownuser said:

Error: #<TypeError: no implicit conversion to float from nil>
C:/Program Files/Google/Google SketchUp 8/Plugins/BZ_Dir_14/bezierspline_main.rb:592:in -' C:/Program Files/Google/Google SketchUp 8/Plugins/BZ_Dir_14/bezierspline_main.rb:592:in onMouseMove'

Fredo tools works regardless of BezierSplines being enabled or not.
NOTE: I only encountered this error since updating to 4.3b and prior to that it was working correctly.