“Do you able to use the native sketchup snap engine, or did you have to write a custom implementation?”
The answer to this question might be interesting to everybody, so here it is: VR Sketch consists in part of reimplementation from scratch of some Sketchup features, and in part reuse of existing Sketchup logic. We reimplement the things that need either to be done a bit differently because of VR, or that need high responsive speed. In the case of snapping, both of these are true:
-
the snapping rules are of course clearly inspired by Sketchup’s rules, but they are slightly different because of VR. The basic example of that is that if a point snaps to another point, then it can do so along an axis (X, Y or Z) or in a plane (XY, XZ or YZ). Snapping to a plane is not something that comes from Sketchup. You couldn’t take a 2D mouse position as input and reliably deduce if the user means to snap in the XY, XZ or YZ plane. A similar story is true in many snapping cases, so we cannot reuse Sketchup’s logic out of the box.
-
high responsiveness is important: VR Sketch ideally runs at 72 to 90 frames per seconds, and every frame it gets a new 3D position of the controller. This 3D position is snapped, and we immediately display the snapped results (with the snapped position as well as the red/green/blue guide lines). That means that we cannot afford to send the 3D position to Sketchup’s Ruby extension and wait for an answer. We need to do it inline.
We are using the native Sketchup engine for one-shot commands when you finish an editing operation. When you do an operation (say, draw a rectangle), everything that you see before the final click is computed in VR Sketch only. When you do the final click, we send the command to Sketchup, which really adds the rectangle to the model and sends back the parts of the model that changed. This can take a bit of time: there is the indirection of sending the “add a rectangle” command via the Ruby extension into Sketchup itself; then for some commands Sketchup itself can be slow, specially in large models; then we need to send back the modified parts of the model. This can be slow enough that we end up displaying a “please wait” icon, in the form of a MacOS-like rotating color wheel over the controller.
One day, we may have a version of VR Sketch that can optionally work without Sketchup but still allow editing of models. We already have many of the functionality built into VR Sketch, like snapping, but so far we don’t have the logic behind the high-level editing commands like “add a rectangle”. Even “add a line” is a complex command in Sketchup, which will find and split faces that the line happens to go through, for example. This part of the complexity of Sketchup is what is missing from VR Sketch so far. (Of course there are other benefits to having Sketchup around, like all the advanced tools and 3rd-party extensions, but there are still some cases where it would be useful to have VR Sketch without Sketchup.)