@tt_su said:

In your case that you describe I would have used construction lines and construction points for the markers - instead of edges. This is because edges might "stick" to other geometry while construction doesn't.
You can aid your pick helper by adding an attribute to the construction geometry so when you do your pick you can use this to get the position of the construction point.

Since InputPoint infer from many source I'm not sure we can provide transformations in the same manner as the pick_helper. I think that even the native tools sometimes use both in combination - but you need to beware that "picking" results can differ.

As for the docs, yes, there are much to be improved. For PickHelper I spent a lot of time trying to work out what it actually did. The description is poor and it's function is overloaded as it let you pick entities as well as "virtual" points and segments.

I didn't fully grasp it until I visualized what a pick looked like:
http://www.thomthom.net/thoughts/2013/01/pickhelper-a-visual-guide/

Thanks for the link, it is very helpful. When I first saw it I just didn't understand that I needed to use PickHelper

I thought about using clines but the drawback is that they disappear when I globally delete all guides. (Using Edit->Delete guides). The geometry that I create are created inside the hole to make sure that they don't stick to other things, but this cannot be avoided 100% obviously. (Edit: I just realized that I can make the crossing edges a group when I create them.)

I don't think it is a good idea to provide multiple transformations in InputPoint (now when I understand the logic behind InputPoint and PickHelper) and now I have started to think of the translation in InputPoint is highly unreliable as it is not possible to know from which entity it was derived.

@tt_su said:

@f94sbu said:

It might be desirable to extend InputPoint so that it can return the transformation for each of the different entities that it can refer to. Or at least add a note to the documentation that the transformation might not be useful for all referenced entities.

The purpose of InputPoint isn't to pick entities, that's why there is differences between the PickHelper.

The fact that is returns a face, edge, or vertex is simply meta data to indicate what it gets the position from.

Are you trying to pick an entity and at the same time get a 3d position? Can you explain the use case for this?

It took me a while to understand the difference between PickHelper and InputPoint, and your explanations were very helpful. The documentation was rather vague as it mostly described the two as 'similar' but did not go into depth of the difference.

This is the use case:
I have created a 'drilling' tool that allows you to drill holes through objects. I am using Sketchup for mechanical construction and I needed a way to place (and track) screw holes in my model. The usage of the tool is rather simple, just click a face and the tool will ask you which drill size you want to use (and an optional depth for blind holes). The tool will then create a circle on the face (centered around the click), push the cut surface through the object and then it records the center by placing a cross (2 edges) in the center of the circle. The drill size used is also assigned as an attribute to one of the edges so that I can iterate through the model at a later time (during G-code generation) to generate G-code for drilling the holes. The purpose of the cross is to have an anchor for the hole when you want to line things up (such as screws or objects with corresponding holes). Most of the time, matching holes will be of different sizes as one hole is sized for the screw and the other is sized smaller to use a tap to create threads in it. (That's why I don't rely on Sketchup's ability to snap the two holes together.)

Also, if I have added a hole to an object and I want to drill the corresponding hole, all I need to do is to add a guide that is perpendicular to the hole by grabbing a perpendicular edge and then snap the guide with the center of the cross.

To accomplish the above I needed to get the following things to work:

• To push the hole through, I obviously needed to get the face to modify, but I also need to get this in the local coordinates of the face as I am adding entities to the same group/component as the face it self, otherwise I would just add a cylinder, not a hole, and it is desirable tha the holes move with the component if I rearrange things
• To know which 3d coordinate to use, I need to get the 3d coordinate that the user clicked on, but this needs to be snapped to whatever guide that the user used. As often place holes referenced from other holes, I need to make sure that the 3d point is snapped correctly. Most of the time, I create the guides without caring about which group that is open for editing. The transformation returned by InputPoint will be from the guide which is often different from the transformation of the group that I will be modifying.

PickHelper gives me all that I need (picked face and translation) except that it does not tell me the 3d coordinate that was snapped from the mouse x,y. Thats what I need to use InputPoint for. I guess I could disregard the face returned from InputPoint, I just added a comparison between the face from InputPoint and the leaf in PickHelper to make sure that they are equal in case something goes wrong and PickHelper does not pick the same face as InputPoint snapped to. I guess this is unlikely (impossible) and I have not yet seen them to be different, but I just felt it was a good safeguard.

So short answer I guess would be, Yes I need to pick an entity at the same time as I am picking a (snapped) 3d position

I would not be surprised if the 'problem' fredo described is related to what you described about InputPoint. InputPoint may have used several entities to snap its position and as it is not possible to tell which of them that was the origin for the transformation in InputPoint, the transformation in InputPoint is most of the time too ambiguous to be used for editing or adding entities.

@tt_su said:

When you get identity transformation, did you check the depth? Maybe the position of IP is coming from an inferred point and therefore isn't coming from inside the group/component you click on?

That was exactly the problem that I was having initially which prompted me to ask my question. The only reliable way that I found to solve this was to use a combination of InputPoint and PickHelper.
InputPoint will give the face that I am looking for and I iterate through the results from PickHelper until I find the same face. PickHelper will always return the correct transformation for the face, but InputPoint may (as you pointed out) return the transformation of something else. The design of InputPoint is a little limited for what one may want to do. InputPoint can return a face and an edge at the same time, but if those two entities belong to different groups, the transformation returned by InputPoint will obviously never be able to apply to both entities at the same time.

It might be desirable to extend InputPoint so that it can return the transformation for each of the different entities that it can refer to. Or at least add a note to the documentation that the transformation might not be useful for all referenced entities.

regards,
Stefan

@tt_su said:

If you are interested in InputPoint.position to be in the local coordinates then transforming it with model.edit_transform.inverse is the way to go.

If you want to pick positions inside of nested component, say the user picks an edge vertex inside a group and you want to get the position relative to that edge's parent group then you want InputPoint.transformation.inverse.

A part of my problem I guess is that I the edit_transform does not help me unless the user has navigated all the way down in the tree so that the surface to be modified is considered the local scope. I only ran into the problem when I used my drilling tool to arbitrarily drill holes in faces without making sure that the group containing the face was open for editing. (From a theoretical point of view, I am well aware of the fact that it may not be desirable to allow a part to be edited unless the part is 'opened'). However, I wanted to see if there was another way. As you pointed out, the InputPoint.transformation just gave me a relative transformation, so whenever I added lines using that transformation, they had a chance to be added in a different spot as they are supposed to be added relative to the group they are added in and not relative to the feature that InputPoint used for its navigation. (It worked fine as long as I clicked on faces directly as InputPoint had no choice by to find the transformation of the actual face. The problem became apparent when I used features outside the group to guide the mouse.

Anyway, this information was very helpful and I learned a lot more than I originally asked for and I hope that we leave a trail that others may find useful. (I tried to google this problem for a good hour before I asked, that's why I am a little more elaborate than for a simple question )

regards,
Stefan

@anton_s said:

To transform global point into local coordinate system use this:
local_pt = global_pt.transform(ent.transformation.inverse)

To transform local point into global point:
global_pt = local_pt.transform(ent.transformation)

P.S., I think PickHelper would be a better choice over InputPoint since pick helper can give you a path the face is in.

Transform the global_pt point trough all the groups/components and you will get that point relative to the current entities coordinate system.

Thanks a lot, PickHelper was a good way to get the transformation at the leaf level. I still need to use the InputPoint to get an accurate snapped point in 3d. (I still want my drill holes to be guided by geometrical features in its vicinity).
Looping through the array returned by PickHelper and comparing to the face that InputPoint is indicating as the hit point allowed me to get the correct transformation matrix.

regards,
Stefan

Hi!
I am working on a plugin that can be used to add drill holes to components in a model. To find out which object that the user want to drill through, I use InputPoint to translate the mouse click into a face (and a point)

This works nicely with ungrouped objects. With grouped objects, it becomes a little trickier as I need to add my new entities at the same level as the face (to make sure that they cut a hole properly)
The transformation in the InputPoint object works nicely for me to translate my drawing operations to the coordinate system of the face as long as I click on a face directly. If I use any kind of guide to lock the mouse onto the face, the transformation returned seem to be the transformation of the guide and not the face. This obviously doesn't work if the guide was created at a different level than the actual face. The simple question is then:
What is the best way to turn a mouse x,y coordinate into a coordinate that is local to the coordinate system of the face that is being referenced?

Best regards,
Stefan