"move vs copy" and "gravity on vs off" should be separate

#1

When using the freehand tool to copy and move:

I was happy to see many improvements in the latest release, but the fact that move/copy and gravity are the same button is a real issue. When placing out elements, e.g. vegetation or furniture, I sometimes want the object copied, while other times I want it moved. Switching quickly between the two have always been a great feature.

Switching gravity on and off is also useful, because some objects (eg trees) should stand upright while others (eg. furniture or buildings) should preferably land flat on the ground.

However, cycling all 4 settings with the same buttons makes the shortcut almost useless as I have to click many times while looking at my controller and think hard to get the right setting, it is much less intuitive, and slows down the workflow. I now find using the submenu more inutitive, even though it is slow.

Ideally you could make “down” toggle gravity on vs off and “up” would toggle copy vs move
Alternatively you could make up-down control gravity on vs off and left-right control copy vs move.
cycling between all 4 combinations is really the worst of both worlds and going back to the original system would be better, with only a tick box for gravity.

If you for some reason prefer the new system, a setting should let me chose which of these the toggle affects (I would use only copy vs move)
(As a workaround, i tried using “copy” on one hand and “move” on the other, but VR Sketch insists on using the same settings for both hands)

Finally, when I use the “copy” function on, I would love to keep the object selected even after having “dropped of a copy”. Eg when placing out a bunch of trees, having to grab the last tree again is always a small hassle, especially when grab/snap/precision distance is low (It can be hard to grab the object).
Perhaps the submenu could have an tickbox option “Deselect object when copying”. Alternatively there would be one button to copy and deselecting (current system) and another button to copy but remain selected/in hand (ëg joystick to the side)
the ability to always keep a copy “in hand” would be a great addition for efficient workflow.

Thank you!

#2

Thank you for the feedback! The “freehand” tool was conceived as a somewhat experimental addition to the toolset. It’s great to have some detailed comments on it.

Yes, I can see how the 4-settings cycle is not good. I’ll try with your idea of “up” to change move/copy and “down” to change “gravity/no gravity”.

Also, thank you for the idea of how to make multiple copies more quickly. Maybe it can always work like this in the “copy” mode: after you make a copy, the group remains in hand and you can click more for more copies, or click “cancel” when you are done—i.e. what you said, but not necessarily with an extra “copy multiple” mode; just always. It’s easy to press “cancel” so it shouldn’t be a problem even if you only want a single copy. Does it seem reasonable?

I’m also writing down that I should review these and other similar settings which are currently shared for both hands, to see if it would be better if each hand had its own settings.

Another feedback I just got from someone else with a different usage pattern: some people don’t want the gravity at all—but as it is the default, they keep getting a surprise the first time they use the tool, with the group unexpectedly falling to the floor (or into the abyss if they are editing a model with no explicit floor). This could be fixed by saving the “gravity” setting between sessions.

#3

Another issue with this tool: in “gravity” and “non-gravity” modes it works a bit differently, namely:

  • in “non-gravity” mode it lets you do click-and-release to start, move, click-and-release to end (in addition to also recognizing click-move-release; this is similar to most other tools)

  • in “gravity” mode, instead, clicking-and-release really releases the group immediately, so that if you click-and-release without moving, the group will immediately start falling.

I feel like this difference is unexpected, even though it makes a bit of sense in each case individually. Maybe instead of a “gravity mode” setting, we should instead have click-release-move-click-release never applying gravity, and click-drag-release always applying gravity? I fear this would be differently strange, because the two modes are equivalent for all other VR Sketch or SketchUp tools as far as I know. Maybe do this by default, but with three explicit items in the menu to choose when to apply gravity (“never”, “when dragging with trigger”, “always”)? Maybe with an extra menu item “make this group fall now”?

Or instead of all this, you make a group fall simply by scrolling down?

Yet another option would be to have a different tool altogether, the “gravity tool”, with which you point to groups and they fall. It might be nice for your use case to have the “freehand move tool” in one hand and the “gravity tool” in the other. The drawback is that some movements would require two steps when they can now be done in a single step. Also, as described, you wouldn’t be able to “throw” groups any more…

#4

After some tries, the simplest solution seems the best: I removed the “gravity” mode completely, and instead, if you end the movement by using “scroll down” then the group falls.

You can also pick it in the context menu, but that’s mostly to give the user a clue that this option exists; the hint in the context menu tells you that you can just use “scroll down”.

I like this option the best because it’s the one with the least amount of state that the user needs to juggle with, and it feels very consistent.

#5

That solution sounds great! button press down to let the object drop, while up toggles copy vs move. I also agree that the default option should be to keep the object in hand after copying and cancelling when I am done copying.
Now that I’m on a roll, I’ve noted that not that complex objects (tables/chairs with acceptable polygon count) tend to partially fall through the ground. I’m sure you are aware of this and trying to fix, in the meantime I’ve added a transparent base beneath the object, which works well. Unfortunately transparent objects automatically become glossy, so I get a shiny invisible base instead of only invisible. I’d love to have a general shinyness slider for all transparent materials, or tick box to disable this. Ideally only materials with “shiny” or “glass” in their name should be shiny. Forced shinyness is particularly annoying with my vegetation models which are cutout trees with alpha masks, the plant itself is opaque but still count as transparent because of alpha mask and as a result look shiny

#6

Yes, it’s another change not released yet: figuring out the shape of the object that falls down has been improved. It also includes now the standalone edges, so even if you needed to add a base for other reasons, you could make it only 4 edges instead of a complete face.

About transparent objects, there are two kinds:

  • materials that have a regular non-transparent image as a texture, but that have an additional setting for making it transparent overall. For example, “Glass and Mirror”, “Translucent Glass Blue”.

  • materials that have a texture, possibly with partially or fully transparent pixels, but which are not otherwise globally transparent. This is meant for cutouts. For example, “Landscaping”, “Fencing Lattice Natural”.

I think the plan was to have the first kind shiny but not the second kind. But I see that both are actually drawn shiny. I will try to make the second kind non-shiny like the normal, fully-opaque materials and see if it improves things. As I’ve said elsewhere: you are welcome to try it out if you want. Just tell me if you need the PC version or the Oculus Quest version.

More generally, there are two parameters per material that could easily be changed: “smoothness” (this is shinyness) and “metallic”. It might be an easy way to get a slightly better rendering, but the basic problem is that SketchUp doesn’t know about these parameters. We could let you change these two parameters anyway in VR (in the materials dialog box). The parameters can be saved with the materials used in the model. What is less clear is if we should also let people customize them “globally”. Maybe we should let them be changed on collections of materials, too, and then use these values as defaults for materials that are used in models?

1 Like
#7

I assume that one controls how reflective the surface is and the other how glossy the reflection looks (eg “radius” of the reflected light), both would be great to control. I don’t think global control is needed if each material can be tweaked individually instead.

I’d love to try it, PC version please!

Another quick feedback:
I believe the “send to VR” button used to have two function. First it will send the model to VR, then I can use it again to move the VR user around in the model. This was very useful with clients who are slow to learn controls, I could easily send them on a journey through the model using this button, by placing the avatar on various places. When I tried this earlier today, when I pressed the button it re-leaded VR Sketch all over again, loading meshes and textures and confusing the user. (at least if I had ued another tool in the meantime). I don’t believe this was the case before (it is possible that I had not noticed this simply because I kept the same tool selected) In either case it is useful to be able to place the VR headset user on various places without re-loading the model.

#8

Yes, I changed a bit the button assignments. Now the button that corresponds to the VRSketch tool is always the 3rd one. If you use other tools, you need to click on this 3rd button to come back to the VRSketch tool (which is the tool that allows you to view the VR headset inside SketchUp and to move the VR by clicking inside the model).

#9

Here is the beta:

#10

Thank you, I think the new controls work perfectly with drop button and copy/move toggle. Copying that remains active also works great. However there a bug, the object I copy will only be copied once. The object remains active as expected, but any other copies I try to produce immediately disappear.

#11

Ah yes, this problem comes from the Ruby part which I had to fix. Maybe you didn’t restart SketchUp after installing the .rbz? Can you try again?

It’s also possible that the bug is still there but more intermittently. I will check.

#12

Restarting SketchUp did not help.
When loading VR sketch I get error message about version mismatch (130200 vs 130100)
I installed the rbz without uninstalling the old version, should I remove the old version first?

#13

Strange. I don’t really understand how it’s possible that installing the .rbz doesn’t update the Ruby files. Try uninstalling, and installing the .rbz again?

#14

I tried reinstalling. Still some strange behaviour:

  • Groups copy as intended, a copy remains selected and I can make infinite copies. Works great.
  • Components do not get copied. This time around, not even the first copy is created (before reinstalling it made 1 copy but no more).

I still have issues with objects falling through the ground, this time around even very basic cubes fall partially through the floor (as well as slightly more complex benches)

#15

  • Groups versus components: it works for me with components too. Could you make a small .skp file with a component that you cannot copy, and send it to me?

  • Same with cubes falling through the ground: can you make a cube with a ground in your .skp file, such that it falls through? (Ah, maybe a flat square tends to fall through the floor now, indeed)

Thank you!

#16

I’ve replied in an email with attachment as I couldnt find a way to upload a file here.
The falling cubes solved itself somehow, but I still can’t use the free hand tool to make multiple copies of the same component, only of the same group.

#17

I just noticed that the component copying issue isn’t limited to freehand tool, I have the same problem with regular copy. Essentially, VR Sketch no longer lets me copy a component, only a group, whether I use the move/copy tool or the freehand tool.

#18

This should now be fixed (thanks to a private e-mail exchange).