@airwindsolar said:
@slbaumgartner said:
This is one of the known problems SketchUp has with very high dpi displays:
If 1920x1080 is "very high dpi" then their first problem is that they haven't moved into the current decade yet.
Please re-read the earlier posts. He was talking about 3000x2000, which I think is still considered very high dpi.
According to the info on forums.sketchup.com, the main purpose of this release was to fix things that cause crashes on Sierra.
The technique of entering n/m works only because SketchUp's measurements box accepts fractions, not because it implements a divide operator as such. In a fraction both n and m must be integers. Any other type does not get treated as a numerator or denominator of a fraction.
Two-point perspective is just a special case of three-point perspective in which the camera is oriented parallel to the horizontal plane. SketchUp's two-point perspective mode is a fast and exact way to point the camera that way (you could do it manually if your orbit skills are good enough). That's why you lose the mode when you orbit any direction except perfectly horizontally. As noted, all this orientation does is to cause vertical (parallel to blue axis) lines not to converge in the view. Parallel to any other plane will cause the same effect for lines perpendicular to that plane.
When viewing real 3D objects, our two-eyed visual system blends depth and direction of view with perspective and we interpret converging edges as really being parallel. Tricking that system is the basis of many optical illusions.
But on a 2D image or computer screen there is no binocular depth available and view direction is toward the screen no matter what the model orientation in the view, so our visual system can't do the interpretation correctly. As a result, three-point perspective can look exaggerated and unrealistic, especially when viewing an object from up close or with a wide angle camera. Two-point perspective tends to give the visual system an easier task to interpret the underlying 3D.
Do you have length snapping enabled in the model info->units setting?
Groups are implemented as a special case of Components. They add some convenience methods that expose some aspects of the associated ComponentDefinition, and also a "lazy uniqueness" mechanism. By that I mean that when you copy a Group, it behaves just like a Component does - another instance is added to the ComponentDefinition. Only when you perform some action on that requires it to be unique does SketchUp clone a second ComponentDefinition and wire the Group to it (same thing as the make_unique method does). Any other copies remain associated with the original ComponentDefinition until you also alter them. For Group copies, it is a one-at-a-time thing.
If you are using the Ruby API, Geom::Transformation.translation followed by Geom::Transformation.rotation.
If you watch closely and/or freeze the motion as he rotates the shapes, you can see that the illusion relies on a combination of curves in the vertical sides and also in the top edges. Your eyes and brain are determined to interpret them as a planar array, so when they line up just so it takes them as either circles or squares. The math to make this work is beyond me, but that's the theory.
For the benefit of others who may come across this topic: WIndows update has been quietly bundling the plays.tv app along with an update to the drivers for AMD graphics (most likely AMD initiated this, as plays.tv is a project they co-sponsor with Raptr). This app causes graphics conflicts that crash SketchUp. Uninstalling Play TV has cured the problem for many people.
Those inferences are for the center of the arc. I don't think there is any way to turn them (or any other inferences) off.
For anyone else who sees this, I just uploaded the corrected version to the plugin store. Sorry about the error!
Geom::Transformation.rotation takes three arguments: a Point3d, a Vector3d, and an angle. You need to either create an explicit Vector3d akin to what you did for vector or else pass the three components as an Array [0,1,0].
Oops! Gilles, somehow the cursor image I saved for pre-2016 versions of SU wasn't scaled down properly. If you replace the cursor_intersect_cursor.png file in folder SB_circle_intersect with the attached version I think it should work correctly. Sorry about that!
I uploaded version 1.1 to the plugin store. I think it should work ok with the additional plugins folders. Please let me know if you encounter problems.
@wo3dan said:
Using the Axes tool inside the group permanently changes the group's axes.
You are correct, I overlooked that tool. But this actually supports my statement that it matters how you are changing the axes!
For both our sakes, don't ask my wife how I know that!
Beware! Once you've drunk the green Festool koolaid your wallet is in permanent jeopardy!
I am confused by this discussion, and @Wo3Dan's last question seems key: how are you changing the group's axes?
If you open the group for edit and then use the right-click "align axes" menu item, that is a temporary action that affects the drawing axes not the group's definition axes or the model's axes. It helps with axis inferences for drawing while you edit the group, but is cancelled as soon as you close the group.
The only way I know for sure will work is to open the group for edit, rotate all of the contents to align with the existing axes (rather than vice versa), close the group, and then rotate the group (without opening it) back to the original orientation.
When using these workarounds, one needs to pay attention to model statistics. Lines styled in this way are geometry heavy, meaning that each little section is one or more separate edges. If you use a lot of them, you can seriously bloat the model and thereby affect SketchUp's performance. That's why native support is a frequent feature request.
To expand on Jean's theory (which makes sense to me): maybe the two red faces are joined by a header above the doorway (so they are really parts of a single face) but that portion is not visible due to the section plane.