Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2025 Jan 03 1:41 pm)
What version of Poser are you using? The only reason I can think of that would misplace an eyeball copied from the other, is if one eye has non-zero translations. Normally the translation parameters are hidden for most body parts. If you have Poser Pro, you can show hidden parameters, and check whether the eye you copied has non-zero translations. If it does, you would need to negate the x-translation applied to the other eye, or it will move the wrong direction. Poser wouldn't normally copy the hidden joint parameters from one eye to another. With hidden parameters shown, you would notice that the left and right eyes have opposite signs for their xOffset and xTranB joint parameters. If their values were copied and pasted, the second eye would definitely pop out of the side of the head.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
Hmmm, I haven't tried that for a long time. I usually use valueOperations from master dials on the head or body actors to control the directions of both eyes simultaneously.
I have noticed that if you select an actor and click Copy from the edit menu, you can paste what's been copied into a text editor to see what's there.
Apparently, in the latest Poser Pro 11.1.0.35540, it does make a difference what gets copied, depending on whether you have show hidden parameters enabled or not. With hidden parameters visible, everything gets copied, including the joint parameters, which is a bad thing if you want to paste them to an actor on the opposite side of the body.
V4 lEye actor copied to clipboard, with hidden parms invisible:
lEye 0 PHMEyePupilRetina Spline 0.0000 42
lEye 0 Point At Spline 0.0000 66
lEye 0 PHMEyeCorneaBulge Spline 0.0000 42
lEye 0 PHMEyeIrisSize Spline 0.0000 42
lEye 0 PHMEyeIrisBulge Spline 0.0000 42
lEye 0 PHMEyeIrisConvexity Spline 0.0000 42
lEye 0 PHMEyeIrisAlign Spline 0.0000 42
lEye 0 PHMEyePupilDialate Spline 0.0000 42
lEye 0 PHMEyePupilSlit Spline 0.0000 42
lEye 0 zrot Spline 0.0000 3
lEye 0 xrot Spline 0.0000 1
lEye 0 yrot Spline 0.0000 2
you may not have all those morphs.
lEye actor copy to clipboard with hidden shown:
lEye 0 FBMGND4 Spline 0.0000 42
lEye 0 PHMEyePupilRetina Spline 0.0000 42
lEye 0 Point At Spline 0.0000 66
lEye 0 PHMEyeCorneaBulge Spline 0.0000 42
lEye 0 PHMEyeIrisSize Spline 0.0000 42
lEye 0 PHMEyeIrisBulge Spline 0.0000 42
lEye 0 PHMEyeIrisConvexity Spline 0.0000 42
lEye 0 PHMEyeIrisAlign Spline 0.0000 42
lEye 0 PHMEyePupilDialate Spline 0.0000 42
lEye 0 PHMEyePupilSlit Spline 0.0000 42
lEye 0 PBMDC_01 Spline 0.0000 42
lEye 0 PBMDC_02 Spline 0.0000 42
...
lEye 0 PBMCC_49 Spline 0.0000 42
lEye 0 PBMCC_50 Spline 0.0000 42
lEye 0 taper Spline 0.0000 28
lEye 0 zOffset Spline 0.0241 21
lEye 0 yOffset Spline 0.6891 19
lEye 0 xOffset Spline 0.0135 17
lEye 0 scale Spline 1.0000 10
lEye 0 xScale Spline 1.0000 7
lEye 0 yScale Spline 1.0000 8
lEye 0 zScale Spline 1.0000 9
lEye 0 zrot Spline 0.0000 3
lEye 0 xrot Spline 0.0000 1
lEye 0 yrot Spline 0.0000 2
lEye 0 xTranB Spline -0.0135 18
lEye 0 yTranB Spline -0.6891 20
lEye 0 zTranB Spline -0.0241 22
lEye 0 xtran Spline 0.0000 4
lEye 0 ytran Spline 0.0000 5
lEye 0 ztran Spline 0.0000 6
Whoops! Now we've copied stuff we wouldn't want to paste on the other eye.
I frequently copy parameters from one magnet deformer prop (or base or zone) to another when I'm creating morphs, but I haven't tried that with Show Hidden set, though for identical props, it wouldn't matter. But eyes are problematic if the joint parms get copied and pasted.
All I can suggest is to make sure Show Hidden is off and do your copy, then paste it into a text editor to see what you get. If the translations are hidden, they shouldn't be copied or pasted.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
Darkworld posted at 8:30PM Sun, 04 August 2019 - #4358743
how do you turn show hidden parameters off? i don't remember ever turning it on
You must have your parameters palette on screen. Go to your upper right hand corner of the parameters tab, select the white arrow and that will give you the drop down menu that includes turning off Hidden Parameters.
The whole "Show Hidden" scenario is a bit of a problem, because turning it on changes the state that Poser reports to python scripts, which confuses any script that relies on certain parameters being hidden to determine information currently unavailable to Python scripts, like camera type. Yet Poser retains the channels' original hidden states, and restores them when show hidden is turned off.
As quietrob describes:
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
an0malaus posted at 2:09PM Thu, 08 August 2019 - #4358739
Hmmm, I haven't tried that for a long time. I usually use valueOperations from master dials on the head or body actors to control the directions of both eyes simultaneously.
How do you that? Vicky's been needing eye target for ages. The worst part is that I've accessed the valueOperations by accident but now that I want to do it on purpose, I can't.
STUPID POSER TRICK
No more selecting/ aiming eyes! Simply put the Target prop where you want the eyes to look. Easy to find under the Props dropdown. Easy to reset to looking straight ahead by Restoring the prop. Note that "looking" too close to the figure's face will result in crossed eyes.
Works with every figure I've tried it on.
WARNING!
This user has been known to swear. A LOT!
Worked like a charm. I even had some glasses with arms that now looks like an eyetarget.
One correction. Step 6 should read Select Object > Point at from the top menu bar. Selecting Edit at this point is incorrect. But thanks, it was otherwise the perfect micro tutorial.
Also to access valueOperation, you select a Parameter dial from the parameters pallette and right click. Select Edit Dependencies. Now how you use this to make an eye target is beyond me...still, thanks for the tip FREE BASS
ghostship2 posted at 12:52PM Sat, 10 August 2019 - #4359099
Eyes, to look real and alive, have to be posed separately. The up-down value should be the same but I always have to tweak the side to side to get life into the figure. (especially if the figure is looking at the camera.)
I agree with this too. The side to side must not be perfect in humans because it doesn't seem to be quite right at extreme looks to the side. I manually tweak it as well. Still, it will do to save some time early on.
Yup, my bad... Object menu it is. Good thing I wasn't teachin' absolute beginners ;)
As for the sideways "focus", I find this approximates it rather well, but if you wish to exaggerate it just bring the target in closer (zTran; not all the way to cross-eyedness, but enough to break the "thousand mile stare").
Glad to have helped :)
WARNING!
This user has been known to swear. A LOT!
There are minor problems with Point-At for eyes (indeed, any actor), in that the actor's rotations are not updated with the values that are applied by the Point-At function, so the limits set for eye rotations will be completely ignored. Move the target behind the head, and the eyes will point backwards into the skull, until you turn off the PointAt. Some figures also have different y-rot limits for left and right limits of eye rotations (less towards the nose and more away), which cannot be enforced if the eye target moves fractionally beyond where the eyes are supposed to be limited to. Poser is also not very good at reliably interpolating intermediate values of the Point-At setting. A value of 0.5 should rotate the actor half way between its original heading and the target, but iterating through frames of an animation doesn't always set this as expected.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
an0malaus: These are indeed minor problems not worth getting worked up over or starting a heated debate with all the mud slinging & name calling which that ensues (although I'm up fer it if you are ;) ). However I'm baffled by your example of putting an Eye Target behind the head. Why would anyone do that?
WARNING!
This user has been known to swear. A LOT!
It's more a case that if the eye target isn't parented to the head, or if one selects a scene prop or another figure for the eyes to point at, then that target moves, or the figure turns leaving the target behind, the eyes will not be restricted to their normal range of movement because limits don't apply to point at. It's just a small frustration that one Poser feature has been implemented in a way that ignores/overrides the normal operation of another Poser feature. In a perfect world, where this could and should be fixed, they would work together. If a user wants PointAt to override rotation limits, then simply turning off limits for the required actor's parameters should be sufficient. Without perfect memory of the chronology of Poser features, it would make some sense if PointAt had been implemented before individual channel limits could be disabled, but it remains just another of the myriad of relatively low priority issues that it would be nice to have work consistently with intuitive expectations. Similar to IK ignoring joint rotation limits completely, so knees and elbows get bent on the wrong axis.
My current suggestion for such situations in the latest version of Poser is to use Grouping Objects, and let their constraint channels be keyframed to indicate what one wants a figure to look at (still using Point-At). Have the eye target parented to the figure's head and sufficiently far away that both eyes' rotations are almost zero. Add grouping objects for everything that you will want the figure to look at during an animation, including cameras, and keyframe the constraints channels (on the eye target) accordingly. With all constraints off, the figure will look ahead at ~infinity (1000 yard stare). At other times, with a single constraint on, the figure will look at the object associated with that constraint. With constraints gradually transitioning between one another, the eyes will smoothly follow the target between grouping objects.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
Sounds like a well thought out & reasonable method worthy of further investigation/ development. However as the OP was about a basic cut/ paste operation (i,e; about as simple as you can get), I think your method is perhaps a wee bit kinda-sorta completely over the top, whereas my method is more "entry level".
WARNING!
This user has been known to swear. A LOT!
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
I miss that. Now if you do it the second eyeball pops out of her skull. So you have to adjust each separately :(
WTF happened why was this changed?