Attached Link: http://www.renderosity.com/messages.ez?ForumID=12356&Form.ShowMessage=1250958

Below is a question from the poser forum and my answers, plus a link to the thread -------------------------------------- I tried searching in free stuff to see if there were any "point at" poses I could crib from, but had no luck. What I'd like to be able to do is load up a character and then just hit a "point at" pose to get their eyes pointing at a "focus ball" prop parented to the main camera. Is this possible? Thanks anticipatorily for any and all suggestions! -------------------------------------------------------------------------------- Really interesting question. I just tried it with a ball and discovered that poser adds a valueParm channel to the cr2, called 'pointAtParm' Give me a few minutes and I'll try and isolate it and throw it in a MAT file. mac ----------------------------------------------------------------------- Hmmm... can't get it to happen, and I'm not sure why. I made a MAT for the 'point at' channel, but it didn't work. Then I added a blank channel to posette's eye, assuming that the MAT needed the blank channel to insert it's command into, but that didn't work either. I'm still thinking.... In the meantime, I'll cross-link this post in the tech forum and see if someone else has another take on it. It's interseting tho' because I've very rarely used the 'point at' command, and didn't realise that it actually adds a new channel. To put it simply, it's something like vicki's INJ/REM, exceot this is not really a morph channel, because it has no deltas. It's a 'pseudo-morph'. It could be fun to play around with. Will be back when I figure out more. mac ---------------------------------- So, I'm throwing it open here. As I said, I didn't know about 'pointAtParm'. I never use the command, but I tried it and it does actually add a new channel to the parameter dials, and of course the cr2. Here's what the channel looks like. --------------------------------- actor leftEye:1 { on channels { pointAtParm Point At { name Point At initValue 1 hidden 0 forceLimits 4 min 0 max 1 trackingScale 0.005 keys { static 0 k 0 1 } interpStyleLocked 0 pointAtTarget ball_1 } } } -------------------------------------- As you can see, it's a morph-type channel, but with no deltas of course. As you alter it's value, the eye returns to the original position. I'm interested to hear if anyone knows about this. mac

I posted as message to the other thread in the Poser Forum (I saw that one first). You need a pointAtParm in the actor, but it looks like Poser stripes out the reffrence to the actual object pointed at when the cr2 is relaoded, looks like you have to add a pointAtParm to the cr2, then also apply a pose telling it what to point at. I'm just going to test that theory now.

Hum...Thats strange it does not seem to work!!! Sorry for doubting you Maclean, I thought this would be simple and work like normal pose files!?!

Um, yeah.... that's what I thought too, but it doesn't. See the other post for more info. mac

I wanted to include this in a package I've been working on, so as it happens, I spent a couple hours on it last weekend. I simply saved a couple cr2 files, one with the eyes "pointed at" a camera, then another with the eyes "pointed at" the universe (which effectively disables the "point at"). That's when I first learned of the PointAtParm.

It was nothing to get MATs to work with it. At least, making it work wasn't a problem. I did it like morph injection. Basically, you have this PointAtParm channel, and the key line is the PointAtTarget. So, here's what I'd inject for an eye, note that I didn't want the dial showing up, so I set it for hidden, which the menu option doesn't do:

actor leftEye:1
{
channels
{
pointAtParm Point At
{
name Point At
initValue 1
hidden 1
forceLimits 4
min 0
max 1
trackingScale 0.005
keys
{
static 0
k 0 1
}
interpStyleLocked 0
pointAtTarget FACE_CAMERA
}
}
}

You'd just change the camera for whatever camera you wanted. You can find the names for each of them in Dodger's hack list. However, I only stumbled across Dodger's list a couple nights ago, so I had already learned all the camera names by saving cr2 files. But, as a result, I discovered that when saving a cr2 file where the eyes have been "pointed at" the Universe, the script was identical, except the entire pointAtTarget line was gone. Otherwise, the PointAtParm channel was still there.

Thus, the problem I ran into, which I still haven't figured out: Simply injecting the channel with new channel info that doesn't include a pointAtTarget line will not remove the previous "point at". Which makes perfect sense. Poser remembers any settings for a channel which were not overwritten by a MAT or injection. So, the dilemma. How do I get rid of that channel, so people can "point at" something new (pointing at nothing is as easy as setting the init and key values to 0, no matter the pointAtTarget line)? Once the channel is injected with the pointAtTarget line, it's there. And changing the line to point at Universe doesn't reset anything. the PointAtParm remains set at whatever it was previously.

I have an idea on how to deal with it, but I haven't tested it yet. In VK's post the other day concerning valueOpPlus and whatnot (very cool post, where I also found the reference to Dodger's hack list), I saw him use a line called, NO_FIG.

What the heck is NO_FIG? Is that like a Null in most languages? Because, if that's the case, maybe pointing at NO_FIG would remove the previous settings. One thing is certain, Point At can be changed through the menu system, so it's getting done, somehow. It was easy to figure out how to set it and remove it with scripts, but changing the Point At from one object to another, that's where I stumbled.

So, I will test to see of pointing at no fig will kill that target setting. If that's the case, we'd simply make all "point at" injection scripts so that the first thing they did was call the script that sets the target to the null, then call the script for the object we really want to point at.

Back with results later.

Oh, another thing I should mention: There is something special about the pointAtParm channel, making it different from channels like valueParm and targetGeom: Blank slots are unrequired. The entire channel can be injected -- it does not have to pre-exist. But, like regular TG and VP channels, once it's there, it isn't going away until the figure is unloaded.

ruh-roh... Okay, I remade the scripts I had done the other night, because I had given up on it and trashed them. Learned a couple things in the process: A) NO_FIG doesn't solve it. B) The entire pointAtParm channel is a very strange beast. Try this: 1) Load up a figure. 2) Select one of the figure's eyeballs. 3) Go to the Object menu and choose "Point At." Point it at a camera. Any camera will do. 4) Save the figure to the library. 5) Open the cr2 you just made and search for "pointAt". You'll jump straight to the channel you just made. 6) You'll see the channel and it will include the pointAtTarget line, directed at whatever camera you chose via the menu. 7) Don't change the cr2 at all, but now close it. 8) Go back into Poser and load that cr2 you were just editing. 9) The figure will load with the Point At channel there (the dial will be showing in the eyeball and it will be set to 1). BUT, the eyeball will not be pointing at the camera you had previously chosen. 10) Save the figure again, without changing anything. 11) Open up that new cr2 and go to the pointAtParm channel. The entire pointAtTarget line will be gone. So, it appears that the pointAtTarget line gets wiped out during load. This might explain why I can't change it once the figure is loaded and I've already changed it once. On the other hand, I have to wonder how the menu system is changing it. I realize there could easily be some non-cr2 code in the exe that is handling this part, but if that's the way it is done, why have the pointAtParm channel at all? As you can imagine, I'm now searching Dodger's list for strings that might be related.

cont. from above... The pointAtTarget line in a pointAtParm channel is saved in both a cr2 and a pz3. However, it only loads correctly from the pz3. the pointAtTarget line is discarded by Poser when loaded from a cr2. I scanned the pz3 for differences between it and the cr2. I was expecting a linkParm, or maybe an IK chain that linked the eyeball to the camera in some limited fashion, but I couldn't find anything. The PAP channel was the same as it was in the cr2, except for those funky sl, sp, whatever lines in the pz3. Including those lines in the cr2 makes no difference. The camera (object the eyeball is pointing at) had no extra channels and contained no references to the PAP channel or a target of any kind. IOW, I have no idea why the pz3 works and the cr2 doesn't, when there is no discernable difference between the two, regarding "point at" and the object being "pointed at." I've seen many commands that seem to work in a pz3, but not in a cr2 or pz2. useCamera is an example. I'm wondering if pointAtTarget is the same. However, like I said before, if that's the case, why does Poser save the pointAtTarget line in the cr2 at all. Perhaps a series of buffers get flushed and reloaded with a pz3 file and these particular commands can be fired at that time, or can be dynamically fired from the PUI (as the exe variable names call it). Has anybody figured out the parameter/variable typing in Dodger's list? It's safe to say the %s is a char, a string. But, what about %ld, %d, %.2f, %f... Am I being too simple in assuming these might be double-long, double, double-float and float? And what on earth would %v, %g, %02d be? Or, maybe I'm nuts for hoping there is a logical acronymous relationship of any kind.

Not sure what list you're referring to, but Poser is witten in C (and possibly C++). Judging by the Error messages, P5 was compiled with Microsoft C++. In C the %d etc. are format specifiers for the standard input/output library functions scanf and printf. %d and %ld are 32 bit decimal, or integer (no difference between them in a 32 bit compiler), %f is float and %lf is double (long float). %s is string, %c character and %g (which is consistent with the way Poser writes values to files) is another alternative floating point format that doesn't output a decimal point unless it's necessary, and the uses the exponential (eg. 1e-5) format whan the resolution has a certtain size. There are a lot additional modifiers that can be added to the basic formats. In the case of %02d, it means that the integer will be printed in a field at least 2 characters wide, and if the integer has less that 2 characters, it will be padded on the left with zeros ie. '7' will be printed as '07'. Bill

Okay. That explains some things. Been about fourteen years since I studied a little of the old Borland Turbo C (DOS) and I was hunting for an %I for int. Err... cin, cout, stringh, conio... How old am I? Heh... After a couple days making the infamous, "hello world," I quickly concluded I'm a 4GL kind of guy. But, at least now I know what kind of values I can try with what commands. It looks like they are using %g exactly as you said -- numeric, decimal only when it means something to the value. %ld seems to be used for both boolean and the literal numeric, depending on the command, which makes perfect sense, based on what you're saying about 32-bit and int. Thanks, Bill! :-)

NO_FIG is used in ERC when the master channel is located in a prop.

The pointAtTarget seems to survive a reload form the pallet only when the target is a child of the figure, and is saved in the same cr2.

Ahhh... Okay. I'm curious, what did you use for a child? I've tried pointAtTarget rHand:1, but I suppose that's part of the same figure that contains the pointing object (the eyes). It didn't survive the cr2 load. Did you use a sphere or some other prop parented to the figure? And thanks for the info on no_fig. You are a vast wealth. :-)

Migal, Good stuff. It's becoming clearer. VK first told me about '_NO_FIG' a year ago when I was adding ERC to props. It's a placeholder for the valueOpDeltaAdd channel, but strictly for props. Second point. I also tried reading the PointAtParm in a pz3 and saw no difference other than the sp, sl, etc (spline references for animation, in case you were wondering). But I didn't try saving it, so didn't discover that the cr2 discards it on reload. This explains a lot. Like why I couldn't get the MAT to work, even after adding a blank PAP channel. So, it looks as though you're right. It's added from the menu and can't be modified in the cr2 (other than the value). According to Ajax, in the other thread, it points the body part to the axis of the target, without altering the rot dials at all. I'll be interested in anything new you come up with. mac PS I was doing all my experiments using the poser ball as the target.

PS Here are the 5 code lines for '_NO_FIG'. They go after 'interpStyleLocked 0' in the slave channel you're using. This is from the Zrot channel of a clock-hand in a clock prop, which I eventually gave up on and turned into a figure. Too much of a pain working with props. valueOpDeltaAdd NO_FIG hour hand_1 vpHour deltaAddDelta -30.000000 mac

Thanks, Mac. I have a feeling I'm going to be playing with props, based on what Les is saying. I wish I could test it now, but I'm at work. You guys will probably have it figured out by the time I get home. :-

I haven't figured out pointAt yet, but in chasing it, I've discovered I was wrong about some things -- specifically, certain things only being possible via a pz3 load or the PUI menu. Please forgive me if everybody is already aware of these things and I'm being redundant.

I'm not sure what to call it... A channel? A section? I don't know. In any case, the part of a pz3 file immediately following the word "doc" contains several items which indeed control the PUI. I was interested in a specific pair of these items, useCamera and pickActor. They can easily be used in a pz2 file, once again proving my not knowing how to do something is probably a good indicator there is a way to do it. ;-)

The selection menu under the document window will chase the following pose files:

---

Select_Face_Cam.pz2

{
version
........{
........number 4.01
........}
camera FACE_CAMERA
........{
........}
doc
........{
........useCamera FACE_CAMERA
........}
}

---

Select_Right_Eye.pz2

{
version
........{
........number 4.01
........}
actor rightEye:1
........{
........}
doc
........{
........pickActor rightEye:1
........}
}

---

pickActor and useCamera require two things: The actor/camera must be declared, channel-style, previously in the script. And, the command itself must fall within the doc section, which will only function on previously declared items.

Like I said, sorry if I'm causing yawns. I haven't tested everything in the doc section. There are a lot of lines having to do with the interface, things like controlling the document size, background color, background pic, uselimits (global), so on... I wouldn't be surprised at all if we could make pose files to control these things. But, it would take a while to catalog and these are the only two I've found so far in that section that I think might be useful in trying to create a workaround for pointAt.

BTW, the interesting thing about pickActor versus defaultPick: There is no visual indicator that defaultPick is doing anything. With pickActor, you'll see the menu change. The result of pickActor is exactly the same as if the user went through the menu system and selected a certain actor on a figure. IOW, it could be used to make the actor focus jump to V3's body or head after an injection, so the results were immediately visible.

... Yeah, this pattern works for a lot of things, except some don't require a previous declaration. We can do pre-saved render settings.

---

Final_Render.pz2

{
version
........{
........number 4.01
........}
renderDefaults
........{
........antialiasing 1
........textureStrength 1.000000
........bumpStrength 1.000000
........useTexture 1
........useBump 1
........castShadows 1
........toNewWindow 1
........newWinWidth 2000
........newWinHeight 2000
........newWinDPI 72
........}
}

I think I've done it. A couple more tests and I'll post over in the main group, where I now realize most of this discussion was taking place.

Re: Posts #12 & #13. "...what did you use for a child?" I used a the Poser Torus primitave, and seem to remember that I have used it with other P4 primitaves in the past. I also tried using the figure's own right hand, for me this DID survive a reload (using Poser 4.0.3.126). I'm surprised you report this did NOT work for you. In post #12 I said that the prop must be parented AND saved in the cr2, but thats more than I really know, parenting and saving a prop in a cr2 usually go together, but it is posible that only one of these conditions needs to be met. I must admit I never noticed the "pickActor" line before, this could be very usefull, thanks for bringing it to light. It may be usefull to remember that a pz3 can be loaded from the figures pallet merly by changing its extension to cr2. You are donig a great job of reserch here Migal, I hope you can crack this point at thing.

Well done, migal. A lot of good info there. I was interested in 'pickActor' too. Always wondered why that stupid 'defaultPick' didn't work. Thanks les. I didn't know you could load a pz3 from the library either. mac

Very interesting. Thanks a lot for the information.

Thank you for teaching me JCM. :-)

You can also use the pointAt channel to create interesting automatic rotations (similar to ERC code). The pointAtParm-channel displays a "Point At" dial on the controlled object. By default, the dial value is 1 (pointAt is on). Poser rotates the controlled object, such that its origin and end point, and the origin of the target-object, are aligned. You can position the end point of the controlled object (the red cross in Joint Editor), to adjust the pointAt-direction. In a figure, pointAt is only available for the last children in the hierarchy (because end points of parent body-parts are disabled). When the "Point At" dial is 0 (pointAt is off), there is no pointAt-rotation. The object has the previous orientation (set with the rotation channels). pointAt values between 0 and 1 interpolate between the previous orientation and the pointAt-rotation. By default, the "Point At" dial has maximum value 1, and forceLimits is on. You can increase the max value, or turn forceLimits off, to set higher positive pointAt values. Higher values increase the reversed pointAt-rotation: When you move the pointAt dial beyond 1, the object rotates around its origin. "Point At" = 2 is the same as "Point At" = 0. Unfortunately, Poser acts a bit hysterically with higher pointAt values. Scene updates display random rotations. "Antialias Document" sometimes renders many rotations. When you're modifying the background color with Poser's color-picker, the object pops to random rotations, as the colors are updated (very funny). On some computers, a random rotation is displayed, whenever the mouse-pointer leaves and enters the document window, when you modify the camera view or a parameter dial, or click an object in the scene.

You can also move (translate or rotate) the controlled object, or the pointAt-target, to rotate the controlled object. The angular speed of the rotation is variable, and depends on the setting of the "Point At" dial and the position of both objects. You can for example create an irregular rotation, when you move the controlled object or the pointAt-target with a tran dials. In the above example, the cone points at the ball. When you move the cone or the ball, the cone rotates around its origin.

Attached Link: planets.pz3 (5 KB ZIP)

This works as well, when you parent the controlled object, and translate or rotate the parent object. You can for example create a solar system with automatic pointAt-rotation. Sun, earth, moon, and the black hole are made of ball props. Earth should rotate around sun, and at the same time moon should rotate around earth: Moon is parented to earth, and its origin is in the center of earth. Earth is parented to sun, and the origin is in the center of sun. The end point of moon is outside of moon. The end point of earth is in the center of earth. Moon points at the black hole. The "Point At" dial on moon is at 3 or higher values. Now you can use a rot channel of earth, to rotate earth around sun. Moon will automatically spin around earth because of the pointAt. The black hole could be invisible. It's only a pointAt target for the moon outside of the system (because pointAt sun or earth doesn't work). When earth rotates, the position of moon in relation to the black hole is modified. pointAt adjusts the position of moon, and, because of the high dial value, rotates the moon around its origin.

Wahhh!!! This is becoming complicated! And really interesting too. Well, what I've been doing is experimenting with using BODY as the PointAt controller. You can use PointAt from BODY to target BODY or BODY to target prop. I was using furniture, not humans, and I still haven't found a serious use for it, but, as VK says, you get some incredible rotation effects. I'm still messing around with it, but I don't have much time. Thanks for the info, VK. This makes what I was doing a bit clearer. mac

'In a figure, pointAt is only available for the last children in the hierarchy (because end points of parent body-parts are disabled)' Hmmm... I wonder if there's a way round that? If I could enable the end point for the BODY, I would have more control over the direction of rotation. I tried setting the OffsetB channels for the BODY to 'hidden 0', but it did no good. mac

Nice work, VK. I've had little luck getting predictable behavior when playing with the key value. I've tried the negative range and saw no effect, with minimums adjusted to accept it. I don't know enough about math to figure the algorithm being applied here.

VK, Do you know of any way to capture the values being created by the relationship between the pointAtTarget (the master) and the object containing the pointAtParm (the slave)? I'm sure you know where I'm going with this. I can't figure out how to numerically capture that 3D relationship. Slaving to a pointAtParm with k 0 1, captures the 1, which does not change. Slaving to the joint being overidden by pointAtParm captures nothing, because the joint's values also remain unchanged. Should I be looking to the target itself?

Cool discoveries in here! You guys should rename this thread "Poserstein's Laboratory". LOL! Without even thinking about the thread, I was using a point-at ball earlier today for a test pic.

mac, I know only one useful application of pointAt in a figure: You can easily make a cylinder-piston mechanism (shock-absorber, hydraulic device, etc.). You point the piston at the cylinder, and the cylinder at the piston. The origin of one part and the end point of the counterpart are at the exactly same position. When you move the parents of the cylinder or piston, the parts are always properly aligned, and the piston moves in and out of the cylinder. Migal, I have posted a new thread with some pointAt-formulas here in this forum. Hope they are helpful.