Hi,

I'm an old-time spaceball user; I bought a spacenavigator a while back, and I've been really delighted to use it in MoI -- it makes modeling a ton faster. That said, things seem to work a bit differently than I'm used to. With the spaceball, there were two modes of operation. One, which is what the spacenavigator currently seems to do, was viewport-relative -- the z-axis always zoomed in and out, and and the x and y-axis panned in the appropriate viewport-relative directions. The other mode was world-relative -- the z-axis would move up and down the global z-axis, etc. When working in the second mode, you could swap back and forth between moving the viewport and moving a part, giving you direct manipulation of objects. Although I'm retraining myself, a big part of my brain still really expects (and wants) the world and part-relative modes. I haven't looked at the spacenavigator APIs at all, but while it definitely looks like they're pushing viewport relative in their current docs, some of the older demos use world relative motion. Any chance of (eventually) getting support for the other two modes?

/Ella

Hi Ella, I've added this to the wiki wishlist to keep track of it.

But bringing in a bunch of different modes would also mean creating additional UI to control those modes.... I'm kind of in a constant battle to reduce the amount of UI and keep it under control, so that can be a problem.

It seems like a world relative view manipulation mode could have some strange side effects... For instance moving the ortho Top view along world z would have no apparent effect.

Object movement sounds more interesting, but that is also kind of a hard fit - there is a lot of emphasis on precision object placement in MoI. It would be really hard to provide good snapping with this kind of movement, it would probably be just more of a general "shove things around" kind of a thing...

- Michael

I agree on the UI bits. It would obviously require at a minimum, more detail in the preferences pane. One solution for changing modes might be to take control over the device buttons from the main driver, if that's possible -- you could then simply allow the user to assign those as keystrokes for commands, like any other button.

Moving ortho top on world z would act exactly as it does now -- it would zoom, or, more precisely, dolly. Moving ortho top on object z wouldn't have any obvious effect, but if you're in split view, you'd still see what was going on. Perhaps another preference for whether or not you'd like object movement disabled on the projection axis of an ortho view?

For object movement, yes, a lot of it is just showing things around, but it's really very convenient if you're moving assemblies in and out of the way, etc. If you add a rotational snap to go with the current grid snap as an option when doing direct rotation, I think you'd actually get pretty crisp movement -- the dynamics of motion should be exactly the same as dragging. Object snap, likewise, can work in the same way.

/Ella

Hi Ella,

> Moving ortho top on world z would act exactly as it does now -- it
> would zoom, or, more precisely, dolly.

That's the part that would not really do anything - dollying (instead of zooming) any of the ortho views along their same view direction wouldn't produce any visible change. This is for moving the view's eye point, not moving objects - moving objects is different since you can see the change to the object in other viewports, that is not such a problem.


> Object snap, likewise, can work in the same way.

The way object snap currently works is essentially a 2D operation where the points or curves closest to the 2D mouse pointer are targeted for snapping.

To do object snap with only delta type movements in x,y,z and not any central reference point would probably require creating something like a full 3D collision detection system... Which certainly would be cool but also a really significant quantity of work as well.

- Michael