My First Plugin questions
-
Hi All,
I am new to SketchUp and Ruby. As part of my first plugin I need to accomplish the following.
On execution...
-
Query model for all Dynamic Component Instaces with a definition name of, let's say "MyBox", which is a transparent cube.
-
For each "MyBox" found, retreive Custom Attributes "FromEntityID" and "ToEntityID"(From... and To... ID's represent particular Entities in the current model), then Move/Transform all Entities that are phsyically located inside the transparent "MyBox" from the Origin of "FromEntityID" to the Origin of "ToEntityID".
Some of my questions so far are...
-
Can I be sure the Entity ID's will be constant throughout the lifecycle of the SketchUp Model?
-
Once I have an EntityID, is there a way to get directly at that Entity without cycling thru all Entities in model and checking each EntityID?
-
Any suggestions on determining if an Entity is physically located within "MyBox"?
Thanks in advance for any help.
Jon
-
-
#2 instead of cycling through all ENTITIES, try cycling through just the definitions list.
Sketchup.active_model.definitions
http://code.google.com/apis/sketchup/docs/ourdoc/model.html#definitions
If you know you are looking for an object stored in the definitions list (component, group, or image), then you can save time by searching through that.
#3 How complex is "My Box"? The more complex the shape the hardder it gets (testing if something is insdide a cube is easy(ish), anything more than that starts proving to be difficult). Also, it depends what your object that might be inside is too. If it is a complex object, than that also adds to the dofficulty. I don't know if anyone has succesfully mastered this with plain SU methods. SketchyPhysics does it I think, but that is by exporting his model data to a physics engine.
-
@jonalbert said:
2. Once I have an EntityID, is there a way to get directly at that Entity without cycling thru all Entities in model and checking each EntityID?
You would think that this was the original intention of the feature, and that it was never fully implemented.At first.. it sounds like a good idea... that it could speed things up.. but ONLY if the ids become persistant between sessions.. AND if the API includes a fast C/C++ side function like:
model.get_by_id(entityID) or entities.get_by_id(entityID)The developers have been whinin' for this (you are not alone.)
However.. on second thot, (as it is now,) in order to get the id in the 1st place, you'd have the iterate the entities, find the one you want (which means you have it's unique 'handle', ie the reference to the object itself; not just a reference to one of it's attributes.) At that point, you'd just as well save the object reference, to an Array that you declare inside your module. The Array reference can be a module Constant (ie: BOXSET) or a module var @@boxset. Then you don't need to iterate the entire Entities collection, again, unless a box is added to the model. (Which should be detectable with one of the Observer class objects [some are bugged.])
Since you are creating these Components.. you could mimic an entityID by assigning YOUR OWN "id-like" dictionary attribute that WILL be persistant between sessions.
-
@jonalbert said:
1. Can I be sure the Entity ID's will be constant throughout the lifecycle of the SketchUp Model?
NO
@unknownuser said:
(http://code.google.com/apis/sketchup/docs/ourdoc/entity.html#entityID)":va1v2m6r]The entityID is not persistent between sessions.
-
@jonalbert said:
3. Any suggestions on determining if an Entity is physically located within "MyBox"?
A quick and dirty test might be using BoundingBox class:
%(#BF0000)[if ent1.bounds.contains?(ent2.bounds)
do something
end]
That might return false if part of ent2 (including only it's origin.) is outside the other.
To be sure, you'd have to iterate the sub entity's vertices and verify that each is within the BoundingBox of the encapsulating entity.
BoundingBox.contains? will also test points (hopefully comparible with Vertex also.)
So you have the means to test if the subentity's origin is inside/outside the receiver's bounds.
You'd need to write some nested conditionals. -
Thanks Dan!
Bummer about EntityID, but I think assigning my own Unique ID can work for my purpose.
"MyBox" will always be a basic cube, and I am fine with only detecting if origin of other entities are within the bounds of "MyBox", sounds like that wont be difficult.
I'm sure I will have future questions, so let me give a better idea what I am trying to accomplish. For starters, check out this short video of my AutoCAD version of the plugin(Hopefully you can get the jist despite poor quality video).
Bascially this is what I like to call an "Option Solving Engine". The idea is to let the user "Graphically Program" Architectural Design Options within a SketchUp model, and give the ability to "Resolve" this model for any number of selected option configurations. Each time the model is "Resolved" it will first be copied in order to keep original model intact.
-
Thanks Chris, only iterating the Instances of my desired Component Definition is a big help!
-
@jonalbert said:
"MyBox" will always be a basic cube, and I am fine with only detecting if origin of other entities are within the bounds of "MyBox", sounds like that wont be difficult.
FYI the origin of an Instance (Component, Image, Group) is in the origin attribute of it's Geom::Transformation object, ie:
where comp is a reference to a component instance you got thru definition.instances:
compOrigin = comp.transformation.origin
then moveArray is an array to store objects that need to be moved
and box1 is one of your "smart boxes", you'd have something like this statement in a search loop:
moveArray.push(comp) if box1.bounds.contains?(compOrigin) -
@jonalbert said:
Bascially this is what I like to call an "Option Solving Engine". The idea is to let the user "Graphically Program" Architectural Design Options within a SketchUp model, and give the ability to "Resolve" this model for any number of selected option configurations.
You could do alot of the "heavy opting" with Sketchup's Dynamic Components. Do a search on the forum... you'll get numerous 'hits'.
A DC does not have to be small like a cabinet, door or window; it could BE a whole house. With large things that turn on/off or change features, like breakfast nooks, sunrooms, swimming pools, roof type, fireplaces, kitchen layout, etc.
Dynamic Components can be nested just like regular Components.
-
It did cross my mind that you could setup a DC for the entire house, but I feel that may get hairy, especially when working with Nested and/or Intersecting options. Also the fact that Free Users cannot author DC's is a draw back.
I do want to take advantage of DC's for some optioning, but dont see it as an efficient solution for complex production homes.
Thanks again for you help so far!!
Advertisement