[Tutorial] PickHelper - Visual Guide
-
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.
-
I had a quick look. Good stylished job! Appears very easy too follow.
-
Text in Console Boxes a bit too small.
Green bubble text 2 steps too small.
Content text a bit too small.
Any Ruby expressions could be in Ruby-color.
Basically - too much wasted whitespace on the pages.
BUT the organization looks good... a should make a nice tutorial.
-
@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? Full pagewidth? On what size monitor?
@dan rathbun said:
Any Ruby expressions could be in Ruby-color.
Higher contrast for the code expressions would be good. But I wanted to ensure the content made any sense before I polished up the graphical details.
@dan rathbun said:
Basically - too much wasted whitespace on the pages.
Specifically where? The edges?
I've deliberately used white space to separate the sections and divide the information into chunks so the eye is served smaller units. Hearing why you think it's too much white-space would be interesting.First of all I'm trying to gauge if the information is making sense. I want to nail the big details before I polish the small details.
-
@jolran said:
I had a quick look. Good stylished job! Appears very easy too follow.
Did it make any sense?
-
Yes it made sence. I love these visual guides
I might be a good testsubject because I have never used pickhelper.
Segments and Points confused me a little, and maybe another row of explanation would not hurt.
Theese following ideas may just be a subject of personal taste.
(People have their way of "taking in" information visually, and it might be impossible to please everyone.)Label groups and components G1, G2 etc maybe adds 1 more level of translating information? If its for conserving space, maybe the example should include less entities.
The "Test scene" picture could be a "standard style"(lightgrey) screengrab? So user feel familiar with the scene and working in SU.
In any way. Great job, and thanks for doing guides like this.
-
@jolran said:
Segments and Points confused me a little, and maybe another row of explanation would not hurt.
Expand on what "segments" and "points" are?
@jolran said:
Label groups and components G1, G2 etc maybe adds 1 more level of translating information? If its for conserving space, maybe the example should include less entities.
This is something I went back and forth quite a bit with. Initially I had just plain colours, one for containers (groups and components) and one of leaves.
But I felt the need to reference and identify each branch - as the order of nesting is important. I find it difficult to remove the number of entities as the test scene is specifically set up to cover a multiple of scenarios. (Several entities overlapping each other but in different context.)
I agree though, it does add more noise to the chart - but without them I fear it'd be impossible to follow the flow. The Gx and Cx symbols are used to be able to reference specific entities in the descriptions.@jolran said:
The "Test scene" picture could be a "standard style"(lightgrey) screengrab? So user feel familiar with the scene and working in SU.
Maybe so. I set it so I'd have darker background to match more the code blocks. But maybe that's not needed. But the light grey is just one of the default templates - Engineering templates are completely different.
I'll have to ponder on all this feedback.
-
@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.
-
-
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.
-
@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? -
@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.
-
@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
-
@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. -
Revision 3.1 posted here: http://www.thomthom.net/thoughts/2013/01/pickhelper-a-visual-guide/
-
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
-
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
-
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
-
That doesn't produce visual flickering?
-
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.
Advertisement