since the original thread was blocked and sensored, bare with me:
hope u don’t mind a few jabs Jim * now that i think about it i probably shouldn’t use that word…
quote=“JimCarruthers, post:59, topic:24470”
By which you mean “it’s not like this other software I use, which is intended for a different purpose.” I can assure you if it was changed there would be plenty of complaints.
"
You don’t understand actually. That’s not really it at all. But yes there’s a few other software that have better navigation abilities and not necessarily intended for different purpose. So, not sure where you’re getting that from. But I’ve seen that argument before.
The complaints that may follow due to change in navigation functionality, is probably something that has never gone away in over 10 yrs – the navigation characteristics have changed.
But there’s one key factor still remaining that has always been true – and that has to do with lack of control over the behavior of the camera geometry hidden that almost no one notices.
I used to point this out many years ago – to this day it’s still the biggest misfortune in the whole matter. Regardless of all the new improvements, it still plagues the overall capabilities. Those of which would be more powerful than any software I’ve ever used, including CATIA and others.
But no one pays any attention. So normalcy biased it will be.
secrets take time. people have to pay attention first.
at any rate, before I begin to dig into this again and attempt to share the secrets – off the top of my head, what comes to mind is “the distance between the camera and the target”
a few more thoughts I’ll say before giving everyone some time to consider what I’ve restated here in the year 2021 is this:
the number one problem is when the point at #1 gets to close to the point at #4 – this is what leads to what I’d call the “quicksand effect” that I’m sure everyone experiences at some point.
So, one of my proposals is possibly allow the user to have better access and control over what’s happening to these entities – in a direct and intuitive way.
If you mean by quicksand the slowing down and ultimately stopping of a zoom then you’re using the incorrect camera manipulation. Don’t use zoom with mouse wheel scrolling or ctrlRMB-drag, use dolly with altRMB-drag instead.
@lander are you aware that you can press F6 to view the camera and grip points? You can even select the points and manipulate them. This may help you discover your issues more clearly.
I think I understand the quicksand effect, but I don’t think it is a distance constraint issue. When you zoom with the mouse wheel, the entire camera object scales larger and smaller, but the points all stay the same relative distance from each other. The main issue of the quicksand effect is zooming too much, which makes the entire camera too small. What you need to do is move the camera closer to the object you are trying to look at, not zoom.
My fix for quicksand is using the Target command. I made an Alias for quick access once I’m stuck in the ‘quicksand’. This will resize your camera and move it to the object you are trying to look at. _-ViewportProperties _Target _Pause
interesting proposition, yes I’m familiar with how to display the camera, and I kind of remember the grip points, but I’ll look more into it – thanks for mentioning.
I will say though, I’m not confident the grip points will provide the control all users need, but I’ll get back to you on it after I do some study.
I think I agree with you on this. This is why I say the distance between the camera point and the target point need to be ‘constrained’ by the user to a particular unit of length in order to lock it, so that it doesn’t change – this would prevent the ‘quicksand’ effect. And, should allow for the 3D space navigator devices of the world to be able to do what you’ve described above “move camera closer” rather than change size
but, not biased to close or far, just free. the camera dimensions should be accessible and controllable. The sizes and distances of it’s features should be constrainable.
This would allow the camera to move freely within 3D space and have plenty of degrees of freedom for navigation.
yes, this is one of a few things I’ve always relied on for about 13 years. but enough is enough.
I will add, also, that 3Dconnexion has added this characteristic to their latest drivers – quite a while ago actually. But this can be frustrating for some users who don’t understand what their driver is doing and when or how it’s doing it.
3Dconnexion, has basically streamlined this feature into their driver/plugin so that upon each “pause” of motion some kind of script or something resets the target point.
This is not good for users that have no idea it’s happening, and can be detrimental to their path going forward.
some users, will turn off the new drivers and use old archaic permutations of navigation capabilities that date back to antiquity.
maybe it’ll be another ten yrs before ppl get around to this mess and actually make some break throughs.
if ppl will wake up and smell the coffee, they might realize the potential power Rhino could have in this regard.
Because, imo Rhino could be one of the best navigators – if this ever gets corrected.
* now that i think about it i probably shouldn’t use that word…
