hi tig, understood and done, works perfect, the combi-version is very nice and confortable and i can pass arguments to it from any method. you will then see it in the finished ruby! thanx a lot for the explanation. stan

You have to make a 'class'. SketchUp recognizes it as a 'Tool' from the way it is made into a command... Special 'Tool' methods can be used in that class... Go to the Extension-Warehouse and find the Examples - the 'draw box' example shows how to set up a Tool... https://extensions.sketchup.com/en/content/example-ruby-scripts

@tig said: ...an older version... BLAST! Thanks TIG. Started a while ago and completely forgot about the updates. Starting over LOL

Get the "container[s]" of the entities, get their "transformation[s]", then transform the vertex's point to match. Then you'll have the point in the model coordinate system, not the point in the container's coordinates system... This will give you the path through the nesting: http://www.sketchup.com/intl/en/developer/docs/ourdoc/model#active_path See these methods to get the 'accumulated' transformations of each container: http://www.sketchup.com/intl/en/developer/docs/ourdoc/transformation

hi tt_su, super, soft & smooth helps to identify. it works. the selected field of mesh is tranfered to a single face (i work with selection). thanx stan

get_center2d() and get_scale2d() C++ SDK functions return a camera shift and zoom-in factor for 2p perspective camera. You reply gave me idea, that maybe I could calculate the shift/zoom using InputPoint.position... This may work.

You have a component definition [ defn]. You have an instance of it [ inst1]. That instance has a transformation [ tr1=inst1.transformation]. That transformation has an origin [ org=tr1.origin] - i.e. its 'insertion point'. You make a new transformation based on that: tr2=Geom::Transformation.new([org.x, org.y, org.z+z_increment]) Where the ' z_increment' is the amount by which you want to move the copy upwards - either in inches or a Length. You add the copy thus: inst2=inst1.add_instance(defn, tr2)

@tt_su said: Ah! Found the crash report. ... I'm logging a new issue.

You could theoretically read the screen dimensions using JavaScript, divide by two and subtract half of the dialog's width and height (you can read the inner width without window border using JavaScript). This is not recommended. If it is not essential to the functioning of you plugin, think again if you can get along without it. This causes your dialog to launch initially with different dimensions and then "jump". On a multi-monitor setup, you don't know whether the dialog is on the second monitor, and the above formula will give you coordinates for the first monitor. The dialog will jump to the first monitor, if it was launched (by registry preferences) on the second one.

@jolran said: Bottom line is the crash does not occour when using GL_LINES. So for me all is fine.. We'd really like to close down any causes of crashes. So please send us examples if you come across it.

Yes, Thanks. I used that and noticed some increase in performance. But I have kind of abandoned the PolygonMesh for now. At least during the previewing state. I experimented building my own meshclass with indexing of points. Instead of using PolygonMesh class as a Point container. Keep arrays of indexes and a Hash containing Points. And the Transformation only deals with the uniq points(Hash) then. Quite a lot of speed improvements! The advantage here is that I can reuse the objects somewhat, while I can't purge/clear(?) a PolygonMesh. So the GC should work a little less. I'm sure you guys have/are doing something similar or more advanced...

If you are in the root context then you can't. If the user has set a custom axis then there is no Ruby API method to obtain that. We have that logged as a feature request.

This sound like a bleeding edge optimization - where you need to profile to get your answer. In general, try to create as few Ruby objects as possible. Reuse data. Make use of bulk functions if possible.

Thanks for reporting!

Hi Jim, Yes that's exactly what I wanted! Thank you. I've managed to get the code to draw the internal leaf as well. The only small problem now is I'm repeating myself in the code to get this result, which seems wrong. Is there anyway to get this result without have almost identical code running twice? Is there anyway to push two faces along the same path at the same time to give the result below? [image: 2014-06-23_1143.png] fyi this is how the code looks now. ` mod = Sketchup.active_model # Open model ent = mod.entities # All entities in model sel = mod.selection # Current selection wallGroup = ent.add_group #face points pt1 = [0,0,0] pt2 = [0,10,0] pt3 = [0,10,100] pt4 = [0,0,100] pt5 = [0,20,0] pt6 = [0,30,0] pt7 = [0,30,100] pt8 = [0,20,100] #line points lpt1 = [0,0,0] lpt2 = [150,0,0] lpt3 = [100,150,0] lpt4 = [0,100,0] path = [] face = ent.add_face pt1, pt2, pt3, pt4 path.push ent.add_line lpt1, lpt2 path.push ent.add_line lpt2, lpt3 path.push ent.add_line lpt3, lpt4 #line = ent.add_line lpt4, lpt1 status = face.followme path path = [] face= ent.add_face pt5, pt6, pt7, pt8 path.push ent.add_line lpt1, lpt2 path.push ent.add_line lpt2, lpt3 path.push ent.add_line lpt3, lpt4 status = face.followme path`

hi dan, yes, i understand. i solved the problem with the following solution: the component-related text is placed outside and with every calculation per ruby it is selectively deleted and placed with new parameters at the new components position. seems to work well. stan

hi dan,i willk take a look at it. yes, i was searching in the forum in the mean time a lot and found a topic from 2009 whit good ideas. i can now identify the component instance and retrieve its own height, especially when it is nested. there are still some minor problems , but the ruby returns the informations needed now. thanx for helping me! stan

No problem, glad to help if the tip worked.

I've been playing with raytest a bit. From my understanding, it works like this: It checks ALL entities in the model root context If something is hit and it's a face/edge/etc, the raytest returns the entity If the hit entity is a group or component, it again checks ALL entities in that group/comp And so forth until it hits a face/edge/etc So if you have a lot of loose geometry in one of the hit contexts, it will be damn slow. But you can have a shitload of geometry in a group/comp not on the path of the ray, and you'll have decent performances. To check if a group/comp is hit, the raytest doesn't look at the geometry inside it, but rather at its bounding box. This is really important because you could have a lot of geometry away from the ray, but if the bounding box of the containing group is on the ray path, all of that geometry will be checked. Resulting in a slow raytest. I hope it's clear?

@penpendrum said: I wrote this JSON file named input.json(I saved it inside the Tools folder): { "name";"Stephen" > "age"; 22 } Each sub-object in JSON must be separated with a comma ( , ). This is resulting in the unexpected token when parsing, because it sees the 2nd "age" token object while it is trying to isolate the 1st "name" token. It should be like: { "name" ; "Stephen" , # <-- comma seapartor "age" ; 22 } @penpendrum said: and I wrote this simple ruby code in the Tools folder name testing.rb: require 'rubygems' This is not needed (but harmless,) as the Ruby loader already loads RubyGems for Ruby 2.x