I am working on a university project with SketchUp. We recently updated our project from the 2016 version to the 2017 version and now have an issue with the InputPoint:
When using the InputPoint, the z-Coordinate is always 0, or if you click on an object it is a point on that object. We use the same code we used in 2016, but get different results. in 2016, the point would be close to the already existing objects. Here is the code we use to get the point (view, x, y are from onLButtonDown):
Not when clicking on empty space, but after I placed the first few entities, when clicking in the general vicinity would lead to a point that was in 3d space, which now returns a point in the x-y plane or the first point on a Sketchup Entity. Please see this imgur gallery, since it is pretty hard to explain for me (can’t post more than one image as a new user)
point = view.inputpoint(x,y).position leads to the same result.
After looking at your images, I cannot but think that the old behavior was flawed. Ie, the z co-ordinates seem to somehow return results that are on a vertical plane, that may be perpendicular to the camera eye -> target vector.
The second 2017 images seem to be defaulting to the (XY) ground plane.
Another thing that could cause differences is if the camera is in perspective or parallel projection. (guessing)
Well, the old behavior was pretty much how I would pick the points intuitively, while I can’t think of a scenario where defaulting to the x-y-plane is useful if you have objects nearby the input line.
Even though it is only used at two points in our code, it is one of the most important part of our plugin. Is there any way to get the old behavior back or at least something similar?
How do I get the current camera to change the perspective via the API?
Changing perspective does not change the behavior.
I don’t use inference. I tried it, but it still picks only points on the x-y plane, I don’t know if I used inference correctly though. I tried three things from a short research:
V1:
The InputPoint [class is] used to pick entities that reside under the current cursor location. InputPoint and PickHelper are similar, but InputPoint also uses inferencing.
Regardless of whether the Z coords is a bug or an intended change …
Are you trying to get 3D points or vertices belonging to objects or object references themselves ?
(Perhaps we can help with a workaround, such as using the Sketchup::PickHelper class instead ?)
“The input line” we’ll define as the ray fired from the cursor on the screen perpendicular to the viewing plane.
If clicking on empty space, how would the modeling engine know where along that infinite ray the desired point is ? (Kind of a rhetorical question, but how would you expect the application to know your intentions over that of what other users might expect.)
(Normally modelers begin by drawing objects upon the “ground” plane. I do remember many forum threads where new SketchUp users were trying to draw on the ground plane, but SketchUp was not doing this. This caused much frustration for the users. So, perhaps there were changes made when the inferencing was overhauled in the last two cycles, to default to the XY plane ?)
Another, question. Are you attempting to pick while in the model entities, or when a group or component is open for edit ?
Yea you could put it that way. I mean if you don’t use the inferencing calls, then you won’t get inferenced points.
Nevermind what I said. I was thinking generally, you can’t switch off the user’s inferencing. (Just serevd to confuse the issue, I suppose. Removed from previous comment.)
So I get an inferenced point every time I call inputpoint.pick(view, x, y), right? Then I am using inferencing.
I understand that, when clicking on empty space, that a solution has to be found and that putting the point on an coordiante system plane or ground plane is probably the best way. That’s also how we experienced it in SU 2016.
However, after I placed the first line of bottles, rather than defaulting to that same plane again, the new point when clicked in the vicinity of that first bottle line was normally “above” or “below” that first object in SU 2016, while now in SU 2017 it always defaults to the ground plane.
I attempt to pick while in the model entities (if that’s when no entities are selected).
This is my impression from reading the description of the pick method, and I seem to recall a SketchUp employee telling us that inferencing could not be switched off with regard to InputPoint. (But John disagrees above.)
You do need to actually show the inference onscreen to the user by calling the InputPoint.draw(view) method. If the inference point is related to a snap from within another object a dotted line will connect the cursor to that snap point.
Another thing you can do in your testing, is call the InputPoint.valid?, InputPoint.depth and InputPoint.degrees_of_freedom methods.
Combine this testing with the new planar inference locks (new for SU2017), ie the arrow keys. See if you can use the up arrow key to get a point above the last point, instead of behind it on the ground plane.
These “bottles” are component instances ?
I’m just wondering if the point is inferencing off of points within the instance, but outside it’s bounds.
Now,… re your tool. You should know what the last two points were (ie, store them in instance variables.) You should be able to calculate the midpoint between them, and you can draw a temporary construction line upward to give an “On Line” inference, if the 3rd point should be along that line.
OR,… use the optional 4th argument to the #pick() method, and create a pseudo inputpoint at the midpoint between the 1st and second points. Something similar to this (not tested, just a possibility):
Using the debug methods had following results:
input_point.draw(view) never drew a dotted line or a point
Unless we were directly hovering over an entity, it always had 3 degrees of freedom and a depth of 0.
It was always valid.
While I think that the method you proposed works (getting the mid point as a reference), it does not help us with the plugin as a whole (we want to publish it soon, since I am only a student working on the project, I don’t have too much control about when exactly).
The plugin itself mainly creates Truss structures (tetrahedron, octahedron) from bottles, containing four or more of those bottle lines. The tool will probably used once in succession for debugging and aesthetic purposes, but if we save the last created single line it may well be on the other side of the previously created structure (the largest structure we built was a pavillon from about 1500 bottles).
InputPoint uses inference - and that cannot be turned off. It’s what you want to use when creating drawing tools etc. PickHelper does not use inference - you want to use this one for tools similar to the Selection Tool.
The API for InputPoint did not change for SU2017. However, there were some changes to the inference engine - which is why you might be some change in behaviour.
That’s a start. Can you tell me about the changes to the inferencing? While it seems that it does inference off the objects in the scene at some points, it only does so when extremely close to those objects. I tried picking a point above the current structure in two ways. One way was to simply select the point above. It then picked the point with z = 0. After that, I started to move my mouse from the center of the structure to the same point (mouse moved only upwards). This resulted in a z coordinate > 0, while the x and y coordinates were unchanged from the starting point on the object. Both points were at about the same screen point.
We want to publish a first version of our plugin TrussFab in the next weeks, I think this is a lot more understandable if you can try it out.
You can set an aperture for InputPoint. I think the default value is 10px. Perhaps this value is physical pixels and not logical if there is a difference from earlier versions.
Sorry, my bad. Pickhelper upports a custom aperture but InputPoint doesn’t.
However if you have to be extremely close to a point to have inference I’m still suspecting this is a problem with high DPI support. Do you know what scale factor SketchUp uses on your computer?