What's wrong with the camera?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  11 November 2012
What's wrong with the camera?

I understand that both the mouse wheel and alt+rmb do dolly. It happens quite often that when I'm close to an object and I start to rotate the camera with alt+lmb, the viewport (the object) is rotated too coarsely (in huge leaps), as if the camera is physically far from the object, and I did zoom instead of dolly. The solution to this is to select the object, press 'f' to focus on the object, and then the rotation with alt+rmb would go smoothly. Does this happen to you too?
 
  11 November 2012
Have had this or similar behaviour for ages in Maya.

When dollying in or out it would suddenly slow down (in terms of how far in or out it would dolly for each scroll of the wheel, or pixel of dragging with rmb) extremely.

I've never quite understood how or why this happens, but yeah, reframing the camera always fixes it.

I suspect this behaviour happens when I use the scroll-wheel instead of alt-rmb to dolly AND/OR when I dolly in on some region to an extent that the current rotate pivot of the camera as defined by an earlier selection is far outside of my current view frustum.

This is just speculation. Personally I've gotten used to it. In most cases when this occurs I simply quickly select some component in my current view and press 'f' to frame, hardly losing time at all.
 
  11 November 2012
I've had that for as long as I can remember. Very annoying, but you get used to it. I assume that's what the folks at AD are counting on and decided to ignore fixing it and rather concentrate on breaking more things instead.

Cheers!
__________________
"Knowing is not enough, we must apply. Willing is not enough, we must do."-Bruce Lee


 
  11 November 2012
Why in Maya 2013 we still need to make these compromises on this most basic stuff??!

Nyro: Just to clarify, only the dolly itself seems to operate in a wrong speed or the tumble tool as well?
Concerning your theory, then what action (except for 'f'), do you think, would reselect this theoretical selection pivot?
 
  11 November 2012
Dolly gets slow (dollying in or out becomes virtually impossible as the camera starts to move at very very small increments) and coincidentally, tumbling goes pretty whack too. The latter is, as stated, probably due to the camera having a really big offset in its tumble pivot.

Tumbling, from how I understand it, is usually based (centered around) the last selection, e.g. an object's pivot or a components coordinates.
There is no action to 'reselect' the pivot; as far as the camera is concerned, it uses the same pivot until you select something else. Using 'f' sets that pivot to your current selection, or, if there is none, it acts as 'frame all'.

The main problem (or maybe its a feature, not sure) is that if you deselect an obejct, the camera keeps the last selected pivot as its tumble pivot. This may or not be the expected behaviour. An alternative would be to make the camera re-focus its tumble pivot to the current view center, or the object in view, or whatever, after deselecting. That may be more intuitive or confusing... hence not sure whether bug or feature.

From what I can tell there is no workaround for this. That's why I've gotten used to expecting this behaviour and then doing the quick left-click+f combo to get the dollying and tracking back to work.
 
  11 November 2012
Its interesting to me that you guys all think this is strange behavior or even a bug, because I never did. What you are seeing is the result of the camera getting close to its "center of interest", or to put it another way, the result of the centerOfInterest attribute getting close to zero. The camera centerOfInterest attribute determins the point along the camera's local z axis that it tumbles around (unless you set usePivotAsLocalSpace to 1).

When you use the "frame selection" command the camera position is set to frame the selection and the centerOfInterest is set to be the center of that selection, and that defines the cameras tumble pivot. When you dolly the camera in and out, the centerOfInterest is adjusted such that the world-space location of the camera tumble pivot remains in the same place. When you track the camera the centerOfInterest value remains fixed, but the camera's tumble pivot moves in world space.

When you dolly in, the rate of that movement changes depending on how far you are from the center of interest. I have always believed (and still do) that by design, the closer the centerOfInterest gets to zero, the slower the dolly adjusts, because it makes it possible to accurately dolly the camera when you are in close, and when you are far away you can move quickly. Personally I think this is the right way to do it. However I can see that you might argue that it would be better to make this an optional behavior.

If you do want to try a camera that dolly's at a constant rate, then you can do the following:
Create|Measure Tools|Distance Tool
click twice to place some locators (which creates a distanceDimensionShape node)
parent the locators under the camera
set the position of one locator to 0,0,0
set the position of the other locator to 0,0,-2000
connectAttr -f distanceDimensionShape1.distance camera1Shape.centerOfInterest;

Now the centerOfInterest will remain set at 2000, and you can dolly at a fixed rate.

This set up is impractical since it makes it difficult to tumble around something and dolly in and out, but even without the tumble pivot problem I still find the constant dolly speed less effective than the profiled way that maya does it by default.

Anyway, next time you get stuck with a very slow dolly, just enter a larger value for centerOfInterest, or do a frame selection.

David
__________________
http://www.djx.com.au
 
  11 November 2012
It's never felt like a bug to me either. I just hit F to set the pivot and it's done. There's another 3D app I use where they changed the way the navigation works to avoid stuff like this, and the result, for me at least, is that the navigation is almost unusable in some situations. For me Mayas navigation works fine and I really hope they don't change it.

cheers,
Brian
 
  11 November 2012
@Horganovski, it's not just press f. I'm already positioned exactly where I want to, and it took me some time to find this position. Why do I need to press the damn f and do the navigation all over again?
What if something else is selected, and I don't want to change the selection?
I mean, it's the navigation, the most basic operation, and it is a hassle as well.

@djx, that is the most clever-sound BS that I heard this week. Maybe you have some idea there, but it definitely doesn't pertain to the tumble bug. Let me demonstrate the problem, since you might be talking about something else. Please create one sphere at (0,0,0) and a second sphere at (120,0,0). Select the first sphere and press f to focus on it. The tumble pivot is set to the origin. Now please navigate to the second sphere and be close to it. On your way, you might have noticed a couple of changes of speed while dollying (goes up and down up haphazardly, and it sometimes depends on how fast I scroll the mouse) that aren't consistent with COI value. Now that you are close to the second sphere, try the tumble tool and see if the speed is correct or not. Now dolly back to the first sphere and try the tumble tool again.

So that we get it straight, according to your theory while f isn't pressed and the Tumble Pivot is set to (0,0,0), tumbling around the first sphere should be smooth, while tumbling around the second sphere should be jumpy. In practice you get a fully random behavior where sometimes it tumble smoothly around the second sphere, jump around the first sphere or any other of the four combinations (of 1,2 sphere x jumpy,smooth movement), i.e. although I see the Tumble Pivot in the attribute editor set on the origin it randomly changes. Note that whatever the case, when you are near sphere 2 the tumble pivot is never the origin (and mostly it's the place you are standing in).
Also according to your theory the trip to the second sphere should start slowly and get faster and faster, such that it would be hard to do a precise movement towards it, and the other way around when you get back. As I noted the speed changes haphazardly.

You might need to do a few such trips to see the behavior I'm talking about, since the bug isn't consistent (hence must be a bug and not a 'feature').

Last edited by zoharl : 11 November 2012 at 12:36 PM.
 
  11 November 2012
I think I found a pattern in this random behavior. While you keep the COI in view, tumbling back and forth preserves it (keep sphere1 always in view), while the dolly speed changes as @djx explained. But if it's not in view, and you get too far from it (dollying towards sphere2 for example), at some point the COI is set to zero and the tumble pivot is lost. Then, as it says (COI==0 in the attribute editor) the camera is the tumble pivot. This explains the jumps in the speed while going from sphere1 to sphere2. At this state, the COI would lock automatically on a new object, when you will be close enough to its barycenter (very close). So if you get close enough to the center of sphere2, at some point the COI would lock on to it, and it would start changing again (from 0) relative to the distance from the center of sphere2. Also the tumble pivot would be set to the center of sphere2, while in the attribute editor it still says origin (I'm dying to meet one of autodesk programmers...).
Now, we need to check what happens in component mode, and also think how to navigate an object which is larger and more sophisticated then a unit sphere.
 
  11 November 2012
@zoharl: As they say in LA, "Blow me" (...one more kiss, that is). Since I'm always open to the possibility of being totally incorrect, I wasted my time with your 2 sphere set up. No matter how I navigated from one to the other, and in repeated attempts to reveal some hidden meaning, I experienced only expected behavior, consistent with my description of how the COI works. So I stand by my explanation.

David
__________________
http://www.djx.com.au
 
  11 November 2012
Let's make it simple, please follow the following steps precisely:

1. Create a new scene
2. Create two unit polySpheres without interaction. Open the channel box and set pSphere2.translateX to 120.
3. Choose persp camera from the outliner, and set its translateX to -10. Tumble around (alt+LMB). You'll notice that as expected the tumble pivot is (0,0,0).
4. Tumble so that you will see pSphere2, i.e view direction (1,0,0).
5. Set persp.translateX to 110, and you will now look closely at pSphere2.
6. Now tumble around. You'll notice that now the tumble pivot is (120,0,0).
Now what does your theory says the pivot and the COI should be?
What does the attribute editor says the tumble pivot value and the COI are? (are they even consistent with each other?)
What are they in practice?

For your convenience:

http://www.apologyletters.net/lette...for_mistake.php

Last edited by zoharl : 11 November 2012 at 10:36 PM.
 
  11 November 2012
I remember this drove me nuts during my first days with Maya.
Don't think of it anymore tho', select something near where I want to work 'f' then small amount of navigation, before repeat to next location.
Quote: What if something else is selected

Guess this is why they give the camera moves a separate undo.

I wrote a script a while back that frame the currently highlited poly component without the need to select. Maybe something like that would fit your workflow?
 
  11 November 2012
I'm really sorry Zoharl, but you are either full of shit, or you are trying to be funny and serious at the same time. I hope it is the 2nd one and, in fact, I followed your example to the letter and I did feel a serious urge to laugh. It seems obvious to me that you have misunderstood what the COI represents (although I did attempt to explain it before).

center-of-interest is simply a point along the camera's local z axis. You could convert it to a world space location if you want to think in those terms, but everytime you translate the camera (not by dolly, but by track or translate or entering numbers in the channel box) the COI will remain fixed in the local camera space, but the world space location that it corresponds to will change. So this...
Originally Posted by zoharl: 6. Now tumble around. You'll notice that now the tumble pivot is (120,0,0).

...is expected and correct behavior.

I doubt you will agree, but since I've kind of lost interest, I'll leave it at that. Having said that I know I wont be able to resist dropping by again, because you do make me smile, and we all need to do that sometimes.

David
__________________
http://www.djx.com.au
 
  11 November 2012
Thanks @faux, if I won't be able to accommodate, then I would try to write something that changes the camera behavior. In this case, your script might be a good start, but I prefer to focus on components in view which aren't necessarily selected. Let me chew on this a bit.

@djx, smiling is the best way to go, but I was serious about 1-6, and in my following comments/questions I am serious as well. What you are saying starts to make sense, but there are still a few gaps.

1. You are saying that only the dolly changes the center of interest (COI), and it didn't occur to me, since I thought that dolly only changes the camera.translateZ in local coordinates, an effect which can easily be achieved by changing the translate values in the channel box. But what you saed proved to be right in practice, and this arbitrary definition also makes sense.

2. Now, I don't understand the tumble pivot (TP). Somehow I connected it to be the COI (while the value of the COI in the attr editor is only the distance to the COI). The TP is given by default in world coordinates, and changes only when pressing 'f', i.e. when I move around, in any way, it doesn't change. Also when I manually change the TP values, I can't see any effects on the camera movement (any type of movement).

3. Only if I change the TP to local space, it affects the behavior of the tumble. Then the camera tumbles around the local pivot (w.r.t. the camera position of course), and it's hard to follow the movement for TP values different than (0,0,0), since unlike the global space TP the camera doesn't keep its aim on the TP (what's up with that, how can I make anything useful this way?).

4. So if I forget about the TP, I'm inclined to accept your theory, and in that light, I admit that my theory is a little bit funny, although strangely it was consistent with my experiments. In this perspective, your observation about the camera speed depending on the COI does make sense. Also my solution to resetting the actual TP by getting really close to the center of pSphere2 and then getting back, also makes sense here. Because dollying forward keeps the COI at zero, until I synchronized it with the center, and afterwards, when I dollied backwards it started increasing, such that the actual TP was pSphere2 center.


To summarize, sometimes @djx might know what he is talking about (yes, I'm surprised as the next guy). I still don't get the TP in world coordinates. The fact that I agree with the explanation, doesn't mean that I agree with the chosen method. Although a local COI (as opposed to a global COI that changes only with 'f', as I thought at first was the case) is more close to my intuition. My alternative to press 'f' of getting really close to your objective, make sure the COI is 0, and then dolly back, is a plausible solution.
I still need to consider everything to see if I can find a better one. I think the most obvious tool to write at the moment is a focus tool similar to 'f' that doesn't change the camera position. Meaning it would only update the COI to be the distance from the plane that goes through the centroid of the selection, and its normal is the camera view direction.

Last edited by zoharl : 11 November 2012 at 01:41 PM.
 
  11 November 2012
The local TP can't aim on the TP, since the TP depends on the view direction, and changing this direction would change the local TP.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 07:41 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.