'Above' in this context is on the side of the face's front. If the face is flat and it were facing upwards your hand would be above it. The that face were facing downwards then your hand would be underneath it...

Hi NotaReal! You are greatly helping me for my first feet steps with Kerkythea. Here are some renders dedicated to you [image: clay_tstD003_th.jpg] [image: clay_tstD004_th.jpg] [image: clay_tstD005_th.jpg] [image: clay_tstD006_th.jpg] [image: clay_tstD007_th.jpg] [image: SuspBridge003_th.jpg] ++simon

For whatever reason, Organizer prevents LibFredo6 to load (hence all the messages from the other scripts). I am not familiar with Organizer (I don't have it actually), so I don't know what exactly it does under the hood. I understand that normally you must execute a command on each script you want to put into the Organizer context, and that this command may alter the code of the targeted script. If so, then, it is normal that it does not work, since LibFredo6 and my other scripts rely on their own loading environment. Thanks to advise if what I described is correct. Anyway, maybe Rick could have a quick check to the problem, if you describe how you apply Organizer to LibFredo and my other scripts. Fredo

It would be a sibling (neighbor?) of the Plugins folder on Windows.

Seems only Grow is necessary! Just make in 2 parts! [image: qE5o_grows.jpg] Select the previous group "growed" and grow again Not a big deal [image: hwov_grow2.jpg]

Thanks, This works. The problem I'm facing now is that I have added this "target" redraw capacity in a class function which extends DC functions but it appears they can't be referenced in a mouseclick interaction. Only in formulas. I have to find another work around. The redraw() function only refresh the DC which calls it. Any idea about a work-around ?

Id guess its to do with how ruby expects to receive arguments for the method. If you put brackets around it it should work, i.e. 4%(2) and 2.to_f-(1)

@maxim1000 said: Since ComponentDefinition is inherited from Drawingelement, calling visible? and hidden? seems not to be some incorrect operation leading to undefined behaviour. Yes, they may not represent actual state of geometry, but this shows that visible? is not the same as !hidden? at least at implementation level, and thus can it be safely assumed that they are the same in all other cases? http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/drawingelement.html#visible= @unknownuser said: The visible= method is used to set the visible status for an element. This method performs an opposite function to the hidden= method. Might be that the definition class causes an abnormality. Testing against any other DrawingElement derived class that actually is placed in the model they behave as expects. Though it is odd it should return true on both for definition. In practice - they do refer to the same thing though.

What thomthom said. But it is interesting. It's not easy to tell what entities can be transformed. Being transformable is not related to be a DrawingElement (as you might think) because a Vertex is not one of those. In fact, a Vertex inherits from Entity.

thanks, great explanation. I'm guessing nothing in parametric.rb is actually specifically changed to work with windows.rb and it is the windows.rb script that utilizes the methods and variables in the parametric.rb script. i'll keep working at it

Guys, thanks for the help. Chris, I will look very carefully at your example.

Thanks for answers. We ended up with approach similar to one of described by TIG: we have a separate layer with known and recognizable name and store all our geometry there. Any operation gets required data (actually it's only box size) from that layer and thus the problem with losing references to our stuff is solved. Of course problem with appearance of our geometry in saved modelы is still relevant, but it seems we can and will have to live with that (because after reopening the plugin catches existing geometry)...

@chris fullmer said: #3 - SketchUp does not give any control of normals. I think they always face the same direction as their face. Unless the edges is smoothed, then I think the normals average between the normals of the 2 faces. I think. Nope! The normals stay the same. You can see with if you use my Probes plugin - it lets you visualize the normals of faces and edges: http://forums.sketchucation.com/viewtopic.php?f=323&t=21472#p180592

Transformations are still an enigma to me as well. But I just got a couple of books on vectors and transformations. ...but my right eye is still blurry after the operation so I can't concentrate on reading. Scariest of all is Observers. I wish you'd start using them more - so you could share my pain. (And join in on the rants )

I wrote this one a while back: http://www.crai.archi.fr/RubylibraryDepot/Ruby/EM/rot90.rb Rotates by 90 degrees around your choice of red|green|blue axes with a right click selection (can be mapped to a shortcut key). CB.

@tig said: splitting out the parts of the material's 'skm' file [which is really a 'zip' file] and taking the image file part, then making that as your new material's texture [with appropriate scaling] etc etc... Thanks. I was afraid of that.

If all of your faceme objets have shadows that fall onto a flat surfaces (vs. hitting walls, steps, etc.) then maybe you could make a dynamic component with two sub components. One sub-component is the face me object and it faces the camera. The other sub-component is a fake shadow. It is the same object but with translucent gray fill and it is on the ground. Then this would be set to face the sun vs. camera, and ideally would set the length of this to scale based on the hight of the sun angle. Maybe an alternative is to swap out your face me objects for real 3d objects just before exporting to Vray. If you don't like the look of these 3d objects you could always make a duplicate rendering with your faceme components and layer in Photoshop to mask these back in. You would just have to make sure the faceme objects are slightly larger than the 3d objects, and you run into issues of seeing the same object from multiple views, don't know how Vray deals with that and faceme objects.

Would a dynamic component work with random attribute built into it. But when you take your first instance and copy it to other locations, I don't know if it re-calculates the random#. I haven't really used the random feature before. But I can see where it would be nice to quickly click on component instances and have it randomly replaced with a component from a specific list. At the start of the ruby it could ask for names of components to include in the list, or maybe the ruby is written for rubys with specific prefix in their name.

@unknownuser said: I fixed it because of your very useful comments...

Thanks very much !