How can i create cover panel on left or right side of component?

Developers Ruby API
1

this is my code but it’s giving wrong dimensions.here i am selecting the component on which i have to put cover panel , and giving direction left or right on which side i want to put the cover panel…
comp_height = Sketchup.active_model.selection[0].get_attribute(:rio_atts,‘height’)
comp_width = Sketchup.active_model.selection[0].get_attribute(:rio_atts,‘width’)
comp_breadth = Sketchup.active_model.selection[0].get_attribute(:rio_atts, ‘breadth’)

def add_cover_panel sel2,direct
	vector = Geom::Vector3d.new(0, 0, 1)
	angle = 90.degrees
	model = Sketchup.active_model
	definitions = model.definitions
	panel_path = "C:/something/cache/PANEL.skp"
	panel_def = model.definitions.load(panel_path)
	trans_right = Geom::Transformation.new([1,0,0])
	defn        =  definitions.add "defn_name"
	trans_comp = sel2.transformation
	y_factor = comp_breadth.to_i.mm
	z_factor = comp_height.to_i.mm
	if direct=="right"
		int_width = comp_width.to_i
		x_factor = int_width.mm+18.mm
		instance = defn.entities.add_instance panel_def,trans_right
		transform_rotate = instance.transform!(Geom::Transformation.rotation(trans_right.origin,vector,angle))
		transform_size = instance.transform!(Geom::Transformation.scaling(x_factor,y_factor,z_factor))
		ent = Sketchup.active_model.active_entities
		new = ent.add_instance defn,trans_comp
      end
end
add_cover_panel Sketchup.active_model.selection[0],"right"

component_on_which_to_put_cover_panel.skp (212.4 KB) PANEL.skp (140.0 KB)

2

A little more explanation, especially what the method argument represent, would help.
Screen shots of the component, as well as attaching the panel.skp so someone could try your code.

The word “new” would best be reserved for the name of class constructor methods.

Also please use good program style and leave space on each side of operators like =. Your code is hard to read.

1 Like
3

I have edited the code…please check again @DanRathbun

4

I also struggle to read this code. If you write shorter methods doing one thing each, optimally 10 lines long or less (but longer sometimes makes sense), it would be much easier to understand what the intended behavior is. If shorter methods were used you could perhaps also isolate the problem to just one method and only have to include that in the post. Maybe you could even see the error yourself. Also, if you use two spaces for indentation and and keep line lengths to 80 chars or less, we can read the code without having to scroll sideways.

5

Now, I made the code shorter…please check again @eneroth3

1 Like
6

The code is a lot easier to get an overview of now! Still we can’t run it and try it without all having to make modifications to it, as we don’t have a file “C:/something/cache/PANEL.skp”. Also it’s not clear what the intended behavior is. rough_tran doesn’t say anything; I’m not even sure if it’s English.

7

i have already shared the both the skps you can check using it… @eneroth3

8

Using local variables (comp_breadth, etc.) that are defined outside a method will not work. The method cannot see them. You would need to pass the variables into the method, or they’d need to be @vars.

We are assuming that this method is inside your extension submodule (which is inside your unique namespace module.) Ie, it is not allowed to define varibales and methods in the toplevel Ruby ObjectSpace. (Such variables and methods would become global and possibly clash with other extensions.)

Using a symbol might cause issues if your file is ever read using the C API.

Reference the Sketchup::AttributeDictionary#name getter method that indicates the value for dictionary names are strings.

EDIT: I do notice that the API converts the symbols to Strings.

Also the modelspace is a shared space, and all attribute dictionary names need to also be unique (just as your extension code must be separated from other extensions.)
For this reason, your extension’s attribute dictionaries should be uniquely named the same as your namespace module and extension submodule names are. You concatenate the names together with an “_” character.

At the top of your extension submodule you should have …

    DICTNAME ||= Module.nesting[0].name.gsub('::','_')

… and thereafter use the local constant DICTNAME within your extension submodule.

If the reference vector will not be changing, then there is no need for this reference.
The Ruby API defines 5 global constants that your code can use (as readonly.)
They are …

ORIGIN # (Geom::Point3d)
X_AXIS, Y_AXIS, Z_AXIS # (Geom::Vector3d)
IDENTITY # (an identity Geom::Transformation)

So your code can just use Z_AXIS instead of creating a new vector object.

The coding issues aside …

The main reason the size is weird is because you are using hard dimensions and not scaling factors.

Also the panel definition is a weird size of 900mm x 900mm x 18mm.
In order to more easily scale the panel, make it 1m x 1m x 18mm.
(And do not scale the breadth [thickness] of the panel.)

Then your unitless scaling factors would be …

      x_factor = comp_width.to_i / 1000
      y_factor = 1.0 # leave at 18mm
      z_factor = comp_height.to_i / 1000
9

I also noticed that you make the situation more complex by drawing the definition for the panel component rotated 90 degrees from the cabinet component’s axes. It would easier applying transformations if these “related” components were drawn using the same axes. (ie, the panel should be unrotated with respect to the cabinet’s eventual transformation.)