Google Earth's movement in Rhino?

HZone · Post by **HZone** » Tue Oct 30, 2007 7:26 pm

I've been trying to solve this for some time now without any success. Here's the problem...

NOTE: do bear in mind that all views I'm referring to in this topic have to do with the "perspective" viewport, so the term, "top view", for example, is not one of the projected viewports, but an aproximate camera angle in "perspective" view. Also, if you don't feel like reading it all, skip to the "sum up" part...

I'm predominantly using SpaceNavigator for architecture modelling in Rhino. As you might guess or know, modelling architecture can be (or is) a bit different that "general purpose" modelling in that you don't use views like "bottom" nearly at all. Since buildings are not something we can experience "upside down", real world axes and human spatial logic should be translatable to virtual scenes. And this is where Google Earth comes in...

You see, having the same set of motions on the controller always control the same function (as does "up and down" for zoom) is logical from the "viewport" standpoint, but not from the standpoint of real life movement. For example, if I'm looking at the model from the top, and push down on the controller, software "zooms", but to my mind, I'm simply "coming DOWN". In this case, the two "logics" correspond. However, the problem arises when I look at the model from the side and want to "get closer". To the software, it means "zoom" again, but to a human, it means "go forward". This is where the two logics collide, and force the user to adapt his way of thinking to that of the software. I've found that Google Earth's way of moving through 3d could be great for navigating an architectural scene, because it corresponds to the logic of fixed, real world axes as humans naturally perceive them. This way of navigating is very limiting when modelling something that can indeed be experienced from ALL sides, but I feel GE's concept of "Altitude" would be very useful when modelling architecture which, by it's nature, always has only one (absolute) direction that is "up".
Ofcourse, I can live with this "limitation" with no major problems, but it would be great if this could be changed, not so much for the purpose of modelling itself (you can always block the real world logic and model a building in the same way you'd model a furry creature, or an espresso machine), but for the purpose of spatial studies and walkthroughs which, I believe, would become more intuitive.

So, to sum up: is there a way to get the SpaceNavigator to behave in Rhino (or any other 3d application, for that matter) as it does in GE, (without GE's habit of having the camera as centre of rotation)? In other words, is there a way to use the concept of "Altitude" in 3d modelling applications? Custom drivers, workarounds, anything? Thanks!

Chris B. · Post by **Chris B.** » Tue Oct 30, 2007 9:52 pm

Under options/view check rotate around world axes. This creates an up bias. The rotate relative to view gives more freedom(more than you want). You may also want to uncheck allow tilt in the spaceball options.

HZone · Post by **HZone** » Wed Oct 31, 2007 1:05 am

Thanks for your input, but this isn't exactly what I looking for. Also, even though I don't use Roll (or "Tilt" as Rhino calls this type of movement), I have no problem with Roll turned on...

Post by **rstadie** » Wed Oct 31, 2007 2:20 am

Hi HZone,

I am not sure if i understood your intention, but perhaps what you want is to reverse all axes in 3Dconnexion Control Panel under the "Advanced Settings"-tab? Additionally you could use the Rhino Options under "Tools -> Options -> Rhino Options -> View [Rotate around world axes / Rotate relative to view]

Is that what you wanted?

HZone · Post by **HZone** » Wed Oct 31, 2007 3:47 am

rstadie wrote:Is that what you wanted?

With the risk of sounding ungrateful, I do have to say - no.

What I need is something that would emulate "altitude" behaviour (as found in Google Earth) in 3d apps such as Rhino.

Post by **jwick** » Wed Oct 31, 2007 6:35 am

Hello HZone,

Unfortunately, what you ask for requires changes to the mathematics inside Rhino. I don't think the Rhino developers thought about this particular architectural usage when they did the 3Dx device support (quite a few years ago).

Please contact Rhino support to issue an enhancement request. I think it is a very useful request. We are trying to get all architectural apps to work the way GE does. We'd be happy to help them out with the mathematics when the time comes.

Jim
3Dx Software Development

HZone · Post by **HZone** » Wed Oct 31, 2007 7:48 am

jwick wrote:Unfortunately, what you ask for requires changes to the mathematics inside Rhino.

I was afraid this would be the case. Thanks for clearing that up...