Making a SketchUp tool - incorporating the mouse & keyboard
-
A good little learning exercise for the Tool protocol, is to see what messages SU tries to fire at it.
Add this to your class to log whenever SU queries your Tool instance to check its capabilities. You'll be surprised how much querying goes on!
def respond_to?(msg) result = super puts "unhandled respond_to(#{msg})" unless result result end -
Oooh!, that looks great! I'll try that when I get back on my working computer.
How do you guys find this stuff? I guess you just pick these tricks up over time. Thanks Adam!
Chris
-
... I still can't figure out how to really implement mouse control yet, and haven't been doing much in terms of learning any SketchUp API for a while.
The first 'scrip' I'm trying to write would be presumably simple; but that's just a guess. I've decided I would try to make a "pinch move" as a first ruby script extension, because I think it could end up as something useful for others (possibly).
How I think I could make it work:
select a point, and move it ( x, y, z). This distance is called 'V'. The script would get all endpoint entities, and put them into an array. It would then check to see if the distance between them and the selected point is greater than __. If not, then it would put the point into another array. It would take the points in this array and find the distance between the point and the selected point. This distance is called 'D'. It will then move them in ( V with an exponent of -D) xV . This creates a "pinch move".
... Before I even think of starting: How hard do you think a script like this would be to make; and if it's not that hard, how hard do you think it would be to implement mouse interaction (probably optional)? -
Thats a good sounding script. I think it will be hard to write, but its do-able. I think you might have to simplify some things at first until you get it working. Then make it more complex over time. Here is how I could see it working easiest.
I'm envisioning this on a terrain (for now). So a large flat field full of nice triangles.
Place a construction point somewhere. Then move it to the extreme "pinch" position. Then select it. So far none of this is actually your script yet. But you might need to provide a way to make and place construction points.
Now select the construction point and activate your tool. A box pops up asking for the pinch radius (I know pop up boxes are lame, but they are the easiest to implement). Enter 50' or something. Hit enter and your mouse tool is active and you have to click on the vertex that will act as the "center" of the pinch. That vertex will move to the position of the construction point. all other points within the 50' radius will move in that same direction, varying distances, based on their proximity to the selected vertex.Does that workflow make sense?
Then in time you could implement a better looking UI, and get the VCB included (I think thats a pain). Perhaps have visualization geometry drawn in, and use the mouse to move the vertex using all inferencing, instead of having to use the re-set construction point.
Those are my thoughts. I'm sure there's plenty of other ways to do it, but that makes sense to me, trying to imagine what parts of the process will give you trouble.
Chris
-
@adamb said:
A good little learning exercise for the Tool protocol, is to see what messages SU tries to fire at it.
Add this to your class to log whenever SU queries your Tool instance to check its capabilities. You'll be surprised how much querying goes on!
> def respond_to?(msg) > result = super > puts "unhandled respond_to(#{msg})" unless result > result > end >Undocumented feature?
-
Other than finding out that my math is completely flawed (the larger the number, the smaller the pinch. I have to fix that...), I have also mannaged to make a script that will draw a line starting at [0, 0, 0,], and going to wherever you input into the control box. Now, how would I change it so what's input into the box is in meters?
` model = Sketchup.active_model
entities = model.entities
selection = model.selectionprompts = ["X", "Y", "Z"]
defaults = ["0", "0", "0"]
list = ["", "", ""]
results = UI.inputbox prompts, defaults, list, "Input X, Y, Z."
pt1= Geom::Point3d.new results.to_i
pt2= [0, 0, 0]
edges = entities.add_edges pt1, pt2` -
SU will work in the default unit that the user has set. So you might be best not trying to force it into meters.
And your defaults:
defaults = ["0", "0", "0"]Since you have the zeros in quotes, it will treat the user input as a string. So you would need to convert each answer to a float. OR if you remove the quotes and use 0.0, 0,0, 0,0 then it will treat whatever the user inputs as a float, which is what you want to use (or an integer) to make a point3d object.
Then what you posted works like a charm.
-
... Yeah, that would help; it still works as it is though, because I switch it using .to_i later on.
...Also, it seems to make a value of 1 to be 0.0254m, and my default is in meters. This value of 0.0254m also seems to be the value at which sketchyphysics joints like sliders use (if I type in 1 in the joint max, it's max is 0.0254m).
-
It doesn't work for me the way its posted. I got an error teling me that it couldn't convert an array ( results) to an integer. For me I needed to convert each element of the array separately.
Unit conversions are still important. Here's the trick. SU works in the users default unit. So if you are in meters and type 1 into the box, its already in meters. Or you could over-ride it and enter 1cm into the box. But now its a string. Convert it to a length with .to_l Here are som examples to run one at a time:
distance = "2000cm".to_l.to_m
distance = "50km".to_l.to_m
distance = "2000'".to_l.to_mthe .to_l converts whatever it is given into the default base unit. Then .to_m converts whatever it is given to meters. Does that make sense? Play with those and check out the entire Numeric Class:
http://code.google.com/apis/sketchup/docs/ourdoc/numeric.html
Hope that helps with converting,
Chris
-
Hmm, I see, I think that I do have something wrong about the base units. I suppose SU always works in inches and you have to always convert back to .to_l to get to the default base unit? I've clearly confused myself.
-
2 things;
first; really? It didn't work for you at all?
Ah well, I'm mostly playing around, and with it written out like you said, it works too.second; I don't think it's in the user's default length automatically, because as I said, for me it works as 0.0254m, or 1 inch. My default is set to meters.
UPDATE: I wrote that before You finnished writing your last post. Sorry
-
Yup, if I run it in the webconsole just as you have it written, I get this error:
(eval):9:in ‘initialize’: undefined method ‘to_i’ for ["1", "1", "1"]:Array
It doesn't like converting the array to an integer. It wants each element of the array to be converted separately on my machine. SU7
-
-
That's strange. .to_i worked fine on my mac.
-
Hey!!!! Great job. I was really confused how on earth to get the inputbox to work in the default units! That did the trick though, setting it to 0.0.to_l. I really couldn't figure that out.
So there you have it, 0.0.to_l makes the inputbox work in the default units. Thanks for posting the solution before I went crazy!
Chris
-
@chris fullmer said:
you might need to provide a way to make and place construction points.
` model = Sketchup.active_model
@ent = model.entitiesprompts = ["X", "Y", "Z"]
defaults = [ 0.0.to_l, 0.0.to_l, 0.0.to_l]
list = ["", "", ""]
results = UI.inputbox prompts, defaults, list, "Input X, Y, Z."
pt1= Geom::Point3d.new results
@ent.add_cpoint pt1`
-
Excellent
-
... Now I need to figure out where in the class to put that
. I'm still not that fond of what defs do what exactly. -
I think you'll probably put it in its own method.
If you want it to be the first thing run every time the user begins the script, then you can call that method at the bottom of the activate method.
And then call other methods from the onReturn method probably (though onLbuttonUp is common too). So it works like this, if you want your script to advance when the user hits enter, then call all YOUR methods from the onReturn method. It only gets triggered when the user hits enter/return. So only call your method from within onReturn and it will only get run once they hit enter. Here's an example of how it could flow
Your "add cpoint" method gets run from the activate method because that is run everytime the user starts the tool. So that will run your construction point right off the bat. Then the user should click on a vertex to specify that vertex as the center of operations. So you would have code in the onLbuttonUp method that yould trigger when they click the mouse. It should take the InputPoint and store it as some @centerPoint variable, assuming its a vertex they clicked on).
Once the cpoint is set and the centerpoint is selected, you could pop up a UI.inputbox asking what radius to use. When they hit enter, then you run a method that does all the calculation and drawing/transforming.
The way I described it there did not require the user to hit enter, so all that would be run from the onLButtonUp method then.
Seriously a tool with the mouse, and with transformations. Nearly as hard as it gets, but do-able. Good luck!
Chris
-
One problem i'm having is not knowing what to enter in the grayed in area. I thought that Pinchmover, the name of the class, would work, but it doesn't. What does?
Advertisement