(click image for larger view)

I have come across a very strange and rather disturbing problem. I'm trying to rig a model of an engine lift by unbroken-fighter. The model has a hydraulic ram, and it needs to use 'Point At', to operate the ram. This is the sort of thing  many of us will have done before. Two parts 'ram' and 'cylinder' both need to 'Point At' each other. At the moment the engine lift is a collection of props parented to a BODY actor.

I got the ram and cylinder rigged and working correctly in 'Poser Pro 2012' (PP2012).

I then opened the same scene in P6. In P6 the origin is in a different position!?!

WHAT THE F***!!!

How can this be? In the Joint editor In both PP2012 and P6, the Z value for the origin is the same number, but the position of the cross-hair is very different.

All values are in Poser Native Units. In both PP2012 and P6, the Z value is displayed as a different number in the Joint Editor as opposed to the Parameters palette. In the case of P6 the values are close enough to suspect that the difference is due to rounding in the Joint Editor, but in PP2012, rounding would not seem to account for the difference.

Thr cross-hair does accurately represent the effective pivot point in both versions.

Perhaps I'm doing something wrong, perhaps I made some stupid mistake. But if I did not make a mistake, then this looks like a very serious bug in Poser. I'm not sure which version is doing it wrong, but I suspect it is PP2012.

Has anyone else experienced this issue? Does anyone have any ideas as to the cause, or cure?

Here is what the same pz3, created in PP2012, looks like when opened in P8. At first sight the position of the origin looks to be the same as when opened in P6, but on closer inspection the position is not identical. In P6 the cross point of the hair lies just outside of the mesh, where as in P8 it lies just inside. It's an orthognal view, so the discrepancy is not due to paralax.

The P8 Joint editor displays seven digets after the decimal point YEAH!(you need to scroll to see the last two), in P6, and in PP2012 Joint Editors, only three digits are diaplayed after the point BOO!. On the down side for P8, only three digits are being displayed after the point in the Parameter palette BOO!.

 

Will the real origin coordinates please stand up!

The Z value for the origin in the pz3 saved from PP2012 is 0.490964 PNU. The only place where this is correctly represented in the interface, is in the Parameter palette of PP2012, and even then, only when the numeric field is expanded by clicking on it.

The value displayed for Z in the PP2012 Joint Editor is not correct.  The value displayed in the Joint Editor is 0.483,  as opposed to 0.490964 on the Parameter palette, and in the pz3. That's a huge difference of  0.007964 PNU, or approximately 20.88 mm.

In the P8 and P6 interfaces, none of the displayed values for Z match the value recorded in the pz3.

I believe the number in the file is poser units while the number in the interface is whatever units you selected.  Its a real pain when getting values in python.

 

There were two values given for Poser native units and one given by bagginsbill.

I think 1 pu = 108" is about right.

 

The error is within 2%, and I don't believe there's any interface unit which is that close to a PNU (generally held to be 103.20000458 inches).

I don't remember experiencing this problem before, but I'll try something in P7 and see what happens.  

I still don't fully understand what happened.

Somehow the value in the zOffsetA channel was different to the value in the 'origin' line. It seems probable that one version of Poser was reading the value for the origin from the 'origin' line, and the other version was reading it from the zOffsetA channel.

The question remains why the value in the zOffsetA channel was different. It seems to be related to the fact that I had used the "Animatable Origin" switch in the Properties tab at some stage. Turning the switch off again later did not resolve the problem. I was stuck with a rogue value in the channel. Interestingly it was only the OffsetA channel that was wrong, the OffsetB channel held the correct value (the inverse of the value in the 'origin' line).

It seems so blindingly obvious in hindsight, but I had not realised that the enabling the "Animatable Origin" switch set 'static  0' in the channel. Of course the very name of the switch tells you that it does just that, but I must have been  having a Homer Simpson moment.

:blushing: