[Tutorial] PickHelper - Visual Guide

[Dan Rathbun]

@thomthom said:

@dan rathbun said:

Text in Console Boxes a bit too small.
Green bubble text 2 steps too small.
Content text a bit too small.
How are you viewing it?

When I click the download... Chrome d/l's it into the " %(#004040)[~/documents/downloads]" directory.
I have PDF set to open in Adobe Reader (a separate process, rather than within the browser.)

@thomthom said:

Full pagewidth?

Yes. I have Adobe Reader set to open docs in page width by default.

@thomthom said:

On what size monitor?

A 20 inch diagonal, Samsung 204B (1600x1200px,) which is 16" wide by 12" high.

[Dan Rathbun]

@thomthom said:

Hearing why you think it's too much white-space would be interesting.

That's a minor thing... don't worry too much about that now.

@thomthom said:

First of all I'm trying to gauge if the information is making sense.

Yep.. I find the information very easy to follow.

[thomthom]

I'll have to review the page size. To be honest - I don't know what paper size it is any more. I started out with a normal page format - but in order to focus on laying out the info I abandoned it and just expanded the page to make fit. The physical size is probably inherited by the underlying grid I used. Being vector I wasn't too concerned.

Thanks for the feedback.

[jolran]

@unknownuser said:

Expand on what "segments" and "points" are?

The last part where it says "Segments and Points".

It all depends on what user-level you are targeting.
Me, I felt I needed more information about points. (I've never used pic helper so I'm totally green on subject.) But then again I suppose this is meant to be a visual guide with as little text as possible, so that might work against the whole concept.

@unknownuser said:

I'll have to ponder on all this feedback.

No need to "ponder" It is really good as it is.

Got a 21 inch screen. At full screenmode and 66,7% zoom the text size was fine on my computer.
Is target for print?

[thomthom]

@jolran said:

It all depends on what user-level you are targeting.
Me, I felt I needed more information about points. (I've never used pic helper so I'm totally green on subject.)

Yea, the thing with the pickhelper is that it serves multiple purposes. It let you pick entities in the model, but it also let you test against simple Geom::Point3d object - which which isn't represented by a model entity at all. I kind of feel the class should have been broken up into two separate classes because it's currently doing two separate jobs. I have been playing with making a wrapper that might make more sense to use.

@jolran said:

Is target for print?

No, screen was the target. Saving them poor trees.

[slbaumgartner]

@thomthom said:

Revision 3

I've finally got around to work on a revision for this. Would you please have a look at this draft and give me your thoughts? Is it more understandable?
This version is more verbose and instead of trying to explain the entire class in one diagram I broke it down into categories.

Thanks TT, looks clear and helpful. Now for your next assignment, compare/contrast pickHelper and InputPoint!

Steve

[thomthom]

@slbaumgartner said:

Now for your next assignment, compare/contrast pickHelper and InputPoint!

Not sure if infographics is needed for that.
PickHelper let you find out what you clicked on - like if you where making a Select tool. InputPoint uses inference, used by drawing tools such as Line, Rectangle, Circle etc.

[thomthom]

Revision 3.1 posted here: http://www.thomthom.net/thoughts/2013/01/pickhelper-a-visual-guide/

[honkinberry]

I have a Tool currently that uses the pick method, in order to place a Component that needs to be scaled.
The problem is, that seems to keep picking the component itself, so it keeps floating towards the camera.
I'm thinking PickHelper would, well, help with this? Am I understanding this right?
So conceivably, I would be replacing my @ip.pick with an @ph.do_pick, and then I could rifle through the objects to expressly avoid the component instance in question. Am I on the right track?

--J

[thomthom]

I think you'd still get problems. You might have to avoid the PickHelper all together and use model.raytest - if you ray hits your component, you then re-shoot the ray from the point where it hit until it hits some other geometry or returns nil.

http://www.sketchup.com/intl/en/developer/docs/ourdoc/model#raytest

[honkinberry]

That was the route I was going, and then it hit me... what if I just toggle the Visible status of my object?!
Works perfectly, so it's a very simple Pick call and done.
Thanks as always!

--J

[thomthom]

That doesn't produce visual flickering?

[Trogluddite]

Hi ThomThom,

I'm currrently stumbling around the API trying to get comfortable with interacting with the geometry, and I found your .pdf incredibly informative. It would have taken me days of reading doc's and experimenting to gain the same understanding that I could see there in just a few minutes.
My only complaint is that you have thrown the shortcomings of the official documents into sharp relief and it pains me now to return to the API pages! - and that goes for the rest of your blog too, you really have some talent as a technical author.

The only suggestion that I would make is that it might be nice to see an example of how the picker works with "virtual entities" such as curves and polygons - it is not clear whether these would behave like groups/compnents as 'branches' with their individual segments as 'leaves'.
But your explanation makes the principles very clear, so it is now easy for me to go and test that for myself - and maybe it's not a bad thing to leave some details for folks to discover for themselves.

[honkinberry]

@unknownuser said:

That doesn't produce visual flickering?

Nope, at least none that I notice on my Macbook Pro.
Even if there was a little, it would be acceptable for the rock solid performance.

--J