A Ouija board works better than "Point At" with a camera
I have never in my life encountered anything more ridiculous in its outcome than attempting to use "Point At" with a camera in Daz Studio.
Every single time I've attempted to use it—without even one exception—the moment I select something in the scene I want an existing, carefully positioned camera to "Point At," the camera spins around into contortions like Regan MacNeil's head in "The Exorcist."
It makes no difference what the orientation is of the item I choose for it to "Point At." (What a joke.) I've even created Nulls, and centered them in the object I want the camera to point at, and made dead sure that the rotations for the Null are zeroed out. And then the instant I choose that for the camera to "Point At" (you really should laugh out loud every time you see that term), the camera becomes like a drunken sailor on decks in a hurricane. Oh, it "points" at the thing, but in some insanely twisted framing. And of course, it then is impossible to correct its cockeyed view of the world.
I searched as well as I could for any answer, solution, or documentation on this, and came up zip. The "Search Forums" box here is only slightly less useful than the "Point At" function for the cameras, and seems to be stuck in the 1980s, with no apparent way even to search for an exact phrase.
I hope somebody has some idea how to make "Point At" work—other than sending for Father Damien Karras.
Comments
A bit less hyperbole, a bit more detail on what youa re doing might help. I generally see no issuse if the target is on the negative z side of the camera, it does strt to twist oddly once the target is on the positive z side (and will twist right round as the target goes from positive to negative x relative to the camea's position). In other words it Doesn't like to be y-rotated beyond +/- ninety degrees.
I had a good laugh, @mavante. I stopped trying to get the camera to "Point At" things years ago. Using "Point At" with other objects doesn't give me the results I want either. But that's a story for another day.
I've gotten the best results using a keyboard short cut: Ctrl+Shift+A. That will center the selected object and set the Focal distance on that object at the same time:
You can do essentially the same thing by clicking on the "+" icon in the upper right corner, but that action will also zoom in or out, and not always as close as you were expecting. Since I've discovered Ctrl+Shift+A, I almost never use the "+" icon.
FYI, (for anyone reading this who hasn't realized it yet,) Rotate and Zoom work on the center of frame. Once you've applied either the "+" icon or Ctrl+Shift+A, the selected object/bone is in the center of the frame, so rotating or zooming the camera will keep the object in the center. But that's only because the object is centered in the frame. Once you pan the camera, moving up, down or side-to-side, the object is no longer in the center, and Rotate and Zoom may seem to move the object other than where you want it. (After five years, that still throws me off sometimes, as Photoshop zooms in to and out from where the mouse cursor is located!)
Yes. Forum search is less than "optimal"… lol Your best bet is to use the site search feature of Google:
I hope this helps.
And hold onto that sense of humor. It helps, too.
Oh, spoilsport! I enjoyed the hyperbole.
Just a word on the search - I never use the forum search but go with google site search (using "site:" instead of "http://" ) but I've noticed recently that the results from google are degraded to the point where topics I know are there and recent are not found so I have to find them by trawling through dozens of posts.
In all seriousness, I find the best results usually come from "Pointing At" a Null object rather than any models. You can try parenting a Null to another object, zero it, unparent and modify the angles, then parent it again if desired. After that, point the camera to the Null. Moving a Null around has less drastic impacts on camera targeting, in my experience. Parenting the environment sun to a Null also works wonders (you can move the Null to change the sun's direction instead of using the XYZ sliders).
In a related fashion, parenting a character or other object to a Null lets you esentially set the "origin" for rotating that character/model and it "attaches" (i.e. recalculates) a lot faster than parenting to a group or another object.
Oh, that wasn't hyperbole. That was a different rhetorical device known as "understatement."
Well, I explained very lucidly and unambiguously what I was doing—at least, certainly lucidly and unambiguously enough for other responders in this thread to understand it clearly, and even to recognize the exact same aberrant phenomenon in Daz that I've experienced. Here it is again, if it will help you, quoted exactly as I wrote it:
"I select something in the scene I want an existing, carefully positioned camera to 'Point At.'"
And that's when the carefully positioned camera flips and twists into a ridiculous framing of the target object—which, as I thought might be obvious to even the most obtuse, completely destroys the aforementioned CAREFUL POSITIONING of the camera, and any hope of it tracking the target object in any useful way through an animated sequence. Let me know exactly what part of that you're having difficulty with, and I will make a sincere effort to help you understand it.
Why thank you for that grossly undocumented insight. I will graciously give you the benefit of the doubt, Richard, and assume that you already know full well, given your status as a lauded expert, that what you just stated does not exist anywhere at all in either of these two documents:
Daz Studio 4.x Quickstart Guide
http://docs.daz3d.com/lib/exe/fetch.php/public/software/dazstudio/4/userguide/daz_studio_4_x_quickstart_guide.pdf
Daz Studio 4.x User Guide
http://docs.daz3d.com/lib/exe/fetch.php/public/software/dazstudio/4/userguide/daz_studio_4_x_user_guide.pdf
Given that assumption—and please don't hesitate to correct me if I'm wrong about you already knowing that information isn't in the documentation—I would be grateful if you would tell me what you, personally, have done to correct that gross oversight, and insist that such crucial information be gotten into the documentation.
"Doesn't like"? As long as I have worked with the cameras in Daz, I had no idea that they had feelings. I would have put it another way: The coding of that "Point At" function with Daz cameras does not have any Geometry 101 math that can account for and adjust itself for a camera's position if it is +/- 90 degrees on the y axis when the operation is called.
I wonder if that has anything to do with it being completely undocumented. I will be eager to hear what steps you have taken to insist that this buggy operation get documented and fixed.
It's how I keep from crying at times.
Not to channel Bill Clinton (shudder), but: "I feel yer pain." Thanks for all your tips and tricks, L'Adair. I have read them all attentively and intently. I'm on a Mac, so I believe I would be using Command instead of Control, but I have a dreadfully long render going at the moment and can't check your steps exactly. I will—but see what Richard wrote in this thread about a camera that has to start out in compliance with his specs. In this case mine can't. I've tried many workarounds to great frustration. Even trying to aim the camera at certain keyframes—without creating a "Point At" target—fails miserably, because rotating it manually on any axis causes Daz to create interim frames that make the camera go into its Linda Blair impersonation again. It is about as buggy as camera coding can be, in my opinion.
Why, I think you may be almost as gifted at the art of understatement as I. :)
Thanks for the tip—but if you'll check, I said in my original post that I had tried using a Null, zeroed for rotation on all axes. Didn't work.
I'll say this briefly, and may start a separate thread on it, because it is a trick I used to solve some of these "Point At" issues that got some great animations, even if not exactly what I originally had envisioned, and it was just this:
Voila. A completely smooth circular rotating movement of the CAMERA, always pointed at the OBJECT of desire—even as the OBJECT is, itself, in animated motion. I even found that I then could create keyframes for adjusting the vertical (Y-axis) height of the camera, and some up/down rotations of it, without it going psycho on the framing. Hope that helps somebody.
I sometimes parent (and "jump to") a new camera to a node that needs to point at something, then align the camera via another view (other camera or Perspective View) by hand. Then I'll switch to new camera to steer my adjustments of the node it's looking out from. Tedious but effective for aiming eyes at faces, et c.
I actually found a far worse camera system than in DAZ studio or even Blender!
Mandelbulber 3D takes that honour
it uses a target system and it is just nuts
...
The search function here definitely needs an extreme overhaul. It doesn't do the basic things it should do as a search function. Searching for "exact phrase" is a MUST. Searching for "braid hair" should NOT bring up every single result with the word hair mentioned; that's just insane. Putting quotes around it changes the result but still isn't showing the phrase I'm looking for.
I also agree there is a ton of user knowledge of the things DAZ can do that no documentation provides. It is wanting. This stuff SHOULD be mentioned... unfortunately I think this information is probably only found in the tutorials you have to buy in the store :/
Youtube does wonders for the teacher/student inclinded, though sadly many are outdated on that site as well. I have been noticing new tutorials being made that could be of use.
On youtube check out a channel called WP Guru, if not interested in games then ignore those one's he still has a lot of daz tutorials and he goes quite indepth about the subjects.
Thanks. I think I've seen all of his Daz Studio tutorials at least once each, and he certainly is one of the most competently thorough in his explanations and demonstrations. I don't know if you've seen the one where he does a fly-in on one of the Urban Futures sets, but even he talks about the weird spinning of a Daz camera on such an animated shot. He goes through a "fix" for it, but his "fix" will not fix all that's wrong on all anim sequences.
The episode is "Creating a Fly-Through Camera Animation in DAZ Studio."
Thanks for that one. The DAZ camera point-at algorithm is probably mathematically proper/correct, but it is functionally useless and a waste of life energy. There are a lot of places in modern software where it's pretty safe to say that the implementer is not the user. It's also quite impressive how many clever people figure out ways to get around this chronic phenomena.
--ms
Thanks. Pity he didn't include it in the original "Look at Me," which I've used on the current animation, and which works wonderfully—for what it does. For that matter, it's a !*#^*^&$* pity that DAZ didn't include it in the program, given that the fix is possible, according to what you're saying here.
I'll look for a (sigh) sale on it. So far I've managed to find hideously time-consuming and torturous workarounds.
Hun?! By what "standard" is some alleged function "mathematically proper/correct" while being "functionally useless"?
Man, I'd like to get hired at a place where that's the standard for coding. I'd buy a used Commodore 64 and I'd be set for life!
The original "Look at Me" does have functions such as:
V2 included moving the chest and waist too.
Wait: I feel a little bit as though Mister Mxyzptlk has flipped me into an alternate backwards universe. Either that or I'm missing some thing.
I started this thread about one and only one issue: not being able to get a DAZ camera to reliably point at and follow an object in an animation sequence without spastically twisting and spinning out of control.
As I said, I have the original "Look At Me," and I know the functions it has—I've used them—but none of them do the thing I started this thread about.
Just a tech note that may help to understand the whys. What Richard reports is indeed quite common in euler based systems. And it also affects animation. That is, the interpolator can't "guess" what you want to do when a rotation exceeds +-90 among keyframes. That's beacuse it doesn't use the whole animation path to undestand what you want to do, but just the start and end points. Keeping the values below +-90 helps the interpolator to do what we want. So the general solution is to use more keyframes thus the camera rotates in small degrees among them.
Quaternion based systems seem more stable and often avoid "odd" behaviours. That's why quaternions were introduced in CGI.
On a compass, 725 degrees is identical in direction to 5 degrees... but not-so-much to an animator who actually meant for the dancer to spin around just over two times... arguably correct, but functionally useless.
I'd like that job too, at least for a couple of days before I realized I was working in an asylum... :)
FWIW, I am in full agreement with your original post, and I can't understand why it's been this way forever.
Apparently, DS's point-at camera rotation function is only useful in 0<x<90 increments (euler and quaternions, etc.) and that's an OK situation for the decision makers. No mention of that constraint in the docs, but it seems to be the nature of the system. I mean, who would *ever* use more than 640k of memory on personal computer?
That said, the devs seem to be really working on the animation functions in 4.12.x, so maybe this will get another look - possibly as a settable option or some-such. (while you guys are in there, please take another look at BVH file import/export too!)
--ms
Sounds like gimbal lock stuff
it can spin along x, y and z axis and spins the shortest distance for all of them to the next keyframe
what was annoying about DAZ studio was the interpolation between all parameters without keyframes from zero or at points along the timeline, the new graph makes that easier to check and you can keyframe each step on all values now like I was used to doing in other softwares.
Before if you didn't check something at zero it would set a keyframe further along the timeline somewhere and tween from that from the beginning so you got some wild results.
most cameras assume an initial x,y,z rotation and changing two the third stays zero
ie pitch not affected by yaw until you actually change the pitch
but DAZ studio would tween in back to the zero point as if you were spinning all three axis not just from that point on the timeline, it drove me nuts until I realised what was happening and keyframed everything each step.
The trouble with the point at is it has no leveler
no way to stay aligned to the ground or x,z plane
so again it spins the shortest distance on all axis between frames
yes! - that's why the camera always seemed like it was held by a drunk or someone who was always tripping. No way to lock the gimble on a given axis either without mucking some other effect.
I suppose if you could 'record' the result of the point-at through the frame-sequence, then unpoint-at and clear the desired axis keyframes, it'd be somewhat usable... Is it possible to record the results of a point-at result? I bet mjcasual could write one if it doesn't already exist... (you shouldn't have to though... per the original post).
hmm,
--ms
Mavante, that was funny.
And if you look at the timeline for the camera, you see that the X and Y rotations are all over the place but there are no key frames, so it cannot be tweaked. Weird.
I am writing a small script to control the rotations for Star Wars BB8's body so that it does not slide on the floor. In it I had to determine the angle for the Y rotation in order to have the ball roll in the correct direction. I think I could modify that script to have a camera poit at an object. I could give it a try.
There is certainly some strange math happening during camera movements and specifically rotations. Always been annoying.
Didn't realized this was asked about a year ago...
Don't know if it's still needed but I was able to write a script that seems to be working properly, with a moving target and a moving camera too (or not). Struggled a bit the maths, last time I had some trigonometry lesson was about 45 years ago, lol.
still share it if you wish it would be greatly appreciated
Here it is. There is not much error detection but it seems to work. You must first select the object to be followed, then select the camera (order is important). Then you activate the script. It takes a few seconds to run but I thinks it's mostly because of print statements I used for verification while testing. Also some of the comments in the script are in French.
Save your file before running (just in case I did something wrong)
Any comment or suggestion welcome