I want to roll the camera

Rhino Developer
,
1

I wrote a plugin to let we walk around inside my model using an XBox gamepad.

I used the gamepad to input camera translation and rotations. I move a vertical stick (Curve) around and collide it with collision surfaces (Breps). I use the point of intersection to centre the stick vertically.

Once the stick is moved and collided, I then position the camera at stick.PointAtStart.

My collision surfaces are large compared to the stick and are mostly flat or are gentle ramps.

This image shows the golden breps and a green stick (near the top). There is a point on the stick that represents the walker’s feet position. The parts of the stick below that point let me walk down ramps.

image
image1372×492 70.7 KB

Anyway, this works well and I am happy walking around my model.

Unfortunately: I got ambitious.

I want to walk around a cylindrical surface and have my camera stick stay aligned to the surface normal.

I’ve been playing around with Brep ClosestPoint which gives me a point of intersection and a normal.

I can move and orient my stick, I can place my camera at stick.PointAtStart.

But I think that I want to set my camera’s up direction to be the surface normal.

In my mind this would roll the camera.

In reality: the setcameraup call appears to do nothing.

In this 3dm file you can see a large, hollow, “cylinder” that has some flat parts coming off it in the +Y direction.

stick.3dm (1.2 MB)

If I stand on the stop of the cylinder and look in +ve Y, looking into the screen: and then use the gamepad to move right - I expect to move around the outside of the cylinder in a clockwise direction.

Now, if my setcameraup worked, then I would expect to see the cylinder rotating in the opposite direction beneath me. A full circle would take me back to the beginning.

But instead, the camera up direction seems locked to be +ve Z so i start sliding down the righthand side of the cylinder until it is above me then I can continue up the left hand side to return to the start (I started at the top)

Do I need to unlock something to make this work?

I see this in ViewportInfo private void SetCameraLock(int which, bool val).

What are the values for which? What is locked or unlocked?

What exactly does SetCameraUp do? Please don’t tell me that it sets the camera up direction :wink: is it for rolling the camera about the camera direction?

Anyway, any advice or code samples would be appreciated.

2

ok, the up direction does change but I see no change in the view???

3

RhinoDocument.Views.ActiveView.ActiveViewport.CameraUp = yourvectorhere;

This ^ works… but the camera will still rotate around the principal axis (unless you have tilt option active).
I guess you are going against the “tilt” matter, as usually we rotate around Z axis only.
(but is a cheap guess, you didn’t post any code…)

If I were you, I would build 3 vectors: from target to camera, the UP vector, cross product of those 2.
Then rotate and translate the 3 objects: camera, target and up vector with those 3 vectors.

4

Thanks Riccardo,

I do wonder what the ViewportInfo SetCameraUp method is for. But I am happy that RhinoViewport.CameraUp works.

It is late now so I’m going to quit for the day but I feel I have made some progress. Thank you.

5

wait what :exploding_head:

6

i beg to differ but honestly my head exploded and might be misinterpreting this here.

of course i have my own perspective on the matter which i decided to be currently researching again due to some of my current entanglements.

7

I don’t see any correlation to this directory…

8

i’m lost, not following this language…

9

it’s my opinion that you need control over the entities in the following image, in order to fully liberate mankind with 3D/4D navigation within Rhino.

image
image718×217 25.2 KB

i’ve been wishing for such control for about 15 yrs.

to this day, 3D navigators still aren’t plug and play – such a shame.

also, only about 2 companies exist that sell devices for such a thing.

it’s sad to see humanity evolve so slowly.

10

If you extrapolate only a single sentence out of context… how is that any useful?
But yes, in default Rhino and other 3d software (or videogames), you are free to rotate the camera around the vertical axis… usually no camera “tilt” is involved. Then again even on rhino we can enable tilting.

… I have the same 3dconnexion mouse for like… 10 years(?) and it is plug-and-play with rhino since my first time using rhino.

… care to argumentate?
What is your problem in this matter?
You didn’t ask any question… is this just polemic? :sweat_smile:

11

cause that’s the information to which I may have referenced my focus.

yes, and all 3D programs should allow 6-degrees of freedom for navigation – as well as control over said freedom. Hence, Rhino’s camera should be fully controllable in terms of it’s geometrical characteristics – camera length for example should be constrainable, and ‘dollyzoom’ should be antiquated by 3D navigator peripheral devices.

which device? spaceball 5000? which version of rhino? v4? v5? which drivers? 3dconnexion? or rhino?

I have a hard time believing we interpret ‘plug-n-play’ in the same manner. what i mean by it is, the world has yet to embrace 3D-mice to the same extent as regular 2D-mice.

3D mice drivers are still in conflict with most 3D modeling programs, unless you’re using 3dconnexion brand specifically with high end software brands like Autodesk, or 3DS Dassault Systèmes.

Rhino V4-V5, there were always issues with Rhinos drivers in conflict with 3dconnexion drivers.

3Dconnexion drivers were underdeveloped back then, and Rhino kinda took care of it, but there were still conflicts and prototype drivers to play around with cause nothing was perfect.

Then in Rhino V6 everything changed. Rhino dropped the ball on their end and tried letting 3dconnexion figure their sh*t out. Which seemed to work for most people, but we lost some solutions and gain some problems associated with the new behavior compared to the old.

So, we can still to this day use secret commands to turn on or off the new drivers and use old drivers.

Hence, still not “plug and play”. Instead the world is till very much lacking the embrace of 6 degrees of freedom and liberation in the 3D navigation realm.

fo sho

3D navigation in Rhino is still lacking power. 3Dconnexion drivers are bad. 3Dconnexion has their point of rotation intermittently updating upon moments of pause – very annoying behavior, and bad solution to overall matter.

I don’t always use “?” when I put attention upon matters. and wasn’t sure what ‘polemic’ meant but maybe lol!

12

Have you tried something like this?

import rhinoscriptsyntax as rs

view=rs.CurrentView()
vector = rs.VectorCreate(rs.ViewCamera(view),rs.ViewTarget(view))

for i in range(36):
    upVector = rs.ViewCameraUp(view)
    upVector = rs.VectorRotate(upVector,10,vector)
    rs.ViewCameraUp(view,upVector)
    rs.Redraw()

It will roll your current view around it’s axis in 10 steps. Works on both perspective and planar views here.

Note that rs.Redraw() is a very slow implementation.

So this is much faster:

import rhinoscriptsyntax as rs
import scriptcontext as sc

view=rs.CurrentView()
vector = rs.VectorCreate(rs.ViewCamera(view),rs.ViewTarget(view))

for i in range(36):
    upVector = rs.ViewCameraUp(view)
    upVector = rs.VectorRotate(upVector,10,vector)
    rs.ViewCameraUp(view,upVector)
    sc.doc.Views.Redraw()

If you want the angles to rotate the opposite direction then just swap the direction of the “vector” inputs from target to camera instead. But I chose the direction to match the viewport input:

image
image1484×584 71 KB