Spacemouse Navigation issue while Viewing from Top or Bottom

image

Didn’t put much effort in that tool button … but it works [and assigned to one to the physical buttons on the 3DCx device

2 Likes

I’m not getting any discernible effect from that option.

1 Like

it is in some situations, certainly in extreme close ups, but there are many unique situations where it is helpful

1 Like

Well a ‘plan’ view is a parallel view, and the spaceball wont rotate a plan view until it’s rotated with the rotate command and regular mouse, first. So, that’s part of my point, is that option technically is deficient in it’s apparent claim to rotate ‘parallel’ views.

And that option is also redundant in that this other option seems to have the same effect:

Although, this option might be more related to the ‘regular’ mouse.

I did however just notice that even the regular mouse wont rotate the plan view until after it’s been commanded by the rotate command first, only then after will the view rotate normally with the regular mouse.

So maybe the developers are purposely locking up the plan view. There’s definitely better ways of going about this behavior – imo. The lockup is completely unnecessary.

And, not really sure I like the new look on the camera frustum in R8 vs R7 in parallel mode, but I guess we’re not really supposed to talk about the frustum so I guess the old frustum no longer applies in parallel mode:

old vs new:

Maybe there’s secret options to change the way it looks. Someday I’d like to have more control over the whole frustum.

Unleash the frustum, I’d say.

1 Like

Bam!!! That’s the one right here.

This is what was making it funky.

The rotation may be a little weird now, but this was the major cause to the problem that I had.

Thank you very much.

“Lock Horizon”

1 Like

The camera “frustum” shows the field of view of the camera. In a perspective view the angle changes as the focal length of thecamera changes. The field of view extends to infinity.but the frustum has finite length. Objects further fron the camera and parallel lines appear to coverge/diverge unless they are perpendicular to the camera axis.

In a parallel viewport the sides are parallel because the fild of view has parallel side. The apparent size of objects is independent of distance from the camera. Parallel lines are always parallel.

The frustum vs box makes sense to me.

2 Likes

Ikr, :beers: like why would someone ever want to lock the horizon haha. :sweat_smile: Especially with a 6 axis device. Also, I rarely ever use the ‘dominant’ axis feature – I used to in the past but it’s really unnecessary lol.

Yeah but they jus changed it in R8 to be totally rectangular prism like, so is it still called a ‘frustum’ when it’s shaped like that in parallel mode? :sweat_smile:

Cause ‘frustum’ means triangular pyramid shape, not box shape :upside_down_face:

I guess it includes cone shapes, and I guess a pyramid shape could have parallel sides and look like a box lol. so maybe it’s fine :smiling_face_with_tear:

Frustum still it is then. :beers:

The big question is when do the users get to have direct access to the features of said frustum.

Yeah 3dconnexion has made their drivers better, but the frustum is still the key to 3d navigation behavior, and R8 still super glitchy cause of all the redundancies and conflicts between what Rhino used to do, and still kinda does and what 3dconnexion trying to do that still doesn’t do very well – per say.

Bottom line, still too many conflicts between what drivers tryna do, and no one focusing on the darn frustum – frustum geometry is key.

We need to get rid of the redundant parameters and options, and create valid solutions for proper fluent 3d navigation behavior.

1 Like

Just a side note, I surmise that the developers have some hidden parameter that probably says something like ‘always pan plan’ed views until the user invokes the rotate command then rotates a little bit, then the user can rotate regular and doesn’t have to pan after that point’.

What a weird GUI behavior lol. Are users just subconsciously ok with this clunky workflow. I’ve always found it silly. Why lock up a plan view to change the mouse’s button behavior …

Guess I’ll search for some secret advanced parameter that holds the key… I wouldn’t be surprised if there is one at this point, but I’d be surprised if there isn’t.

Not sure this option really helps:

That option almost implies that somehow it would be necessary if the plan’ed views weren’t already forcing user to pan :joy:

1 Like

Have been following this discussion with interest as I’m using a SpaceMouse on V7 and plan to upgrade.

Do you use “Object Mode”? Or the other one - (can’t remember what 3DConnexion calls it, helicopter mode or something, (not at work computer atm)).

Am using object-mode and generally find that the horizon-lock helps in keeping things oriented to “gravity”, or some world-bound vector in some sense.

Indeed, experience here has been that ignoring the Rhino settings and only making adjustments in the 3DConnexxion system application works out the best. Hopefully these glitches will get resolved in V8

2 Likes

I mostly use ‘object mode’, because the other ones don’t really work correctly imo. And even ‘object mode’ is still a compromise cause it doesn’t really meet the needs of more fluent controlled navigation – imo.

image

There should be a ‘control the target/camera frustum mode’ with parameters and constraints DOF’s etc.

1 Like

Object mode for me. Lock Horizon off!!!

2 Likes