I personally felt the license agreement, and more so the language on the web site and download links, was always quite clear regarding commercial use. But more-so, I do agree with you, that it is a rather unfortunate change of course. My biggest fear, is that it will destroy the bulk of the creative efforts going into the 3D Warehouse. I personally get a great thrill out of downloading various space ships and crazy vehicle creations -- almost certainly the efforts of a 14 year-old boy somewhere out there on the internets. And there's no way they will be plopping down $500 to continue such endeavors. So if I may, I'd like to offer my suggestion -- perhaps a $199 price point for Make? Or go even further, and offer something integrated with the 3D Warehouse -- so as long as you upload at least 1 model a month to the Warehouse, you can continue using Make for free. More on the subject of your post, I feel it was a little naive of you to pursue a commercial business model off of the free software that Google was offering. I would recommend you stay with Sketchup, and contact their bulk sales department, to see if you could get some funding, and negotiate a good price to continue what sounds like an otherwise great business model. --J

It actually re-orients the model's axis. So green is up and blue is shooting straight forward, like you asked for. You can write your own camera positioning tool and you can program it's "up" direction to be pointing any which way you want. But as soon as the user flips back to the built-in orbit tool, SU will default back to forcing the original model axis z, to be up. SU very strongly favors having the z axis not tilt left or right.

@tig said: Let's start simple... Thanks, TIG, for the suggestion. Unfortunately it does not work very well at all, basically because in 3D the mouse represents a ray, not a point. Sketchup generates a point via InputPoint and PickHelper using a heuristic that does not work very well at all in this application. I have a method that works well: get the mouse ray via view.pickray(x,y) loop over all segments of the polyline compute the position along the line containing the segment, where the ray is closest to the line trim that to the endpoints of the segment compute distance from the resulting point to the ray remember the closest one now I have the segment and location within the segment of the mouse generate the Geom::Transform for that location Basically this represents the centerline of a particle accelerator, and the code is inside my custom DragTool, using the mouse to place an object along the centerline; so the object is constrained to lie on the centerline, and its local z-axis is aligned with the centerline where it is located. For <= 200 segments this tracks the mouse quite well; for 1000 segments it takes about 1 second to catch up. That's acceptable for now; ultimately I may optimize it. I'm rather surprised that this much Ruby computation is acceptable. If a segment is parallel to the pickray, the math will divide by zero. So my code disallows any segment that is nearly parallel to the pickray. This makes sense, as the user cannot possibly select a position along such a segment; use the middle button to rotate the display so the desired position is visible. I ended the centerline with a half-infinite straight line. SketchUp cannot draw that (or rather, it tries to do so, zooming out so much that it's useless). So I split the final segment in two, with the first being half as long as the preceding centerline; the code does not display the final segment. The next challenge is to generalize this to include segments that are circular arcs (so far the code is limited to radius=0).... If anyone wants my code, or references to the geometrical calculations I'm using, just ask.

If you extend and instance with module "FooBar" then you can use instance.is_a?(FooBar)

Not is you want to use the native Select tool. But if you want to avoid observers and gain more control over your plugin's environment you could make your own tool.