Hello Cage, I don't know what was going on with your scene, but I think I know what "Gimbal Lock" means: Your model has 3 rotation channels. If you use only one of the channels, then the rotation axis is aligned with one of the main axes of the Poser scene. But if you set two or three rotation channel at the same time, then the rotation axes are modified, and strange things can happen. Whenever you set the middle (second) rotation channel to 90 or -90, the first and third rotation channels rotate the model around the same axis of the Poser scene. So, your model loses a rotation axis, whenever the second rotation channel is 90 or -90. This is "Gimbal Lock". For example: yRot = 54 xRot = 90 zRot = 0 looks exactly like: yRot = 0 xRot = 90 zRot = -54 The middle rotation (xRot in this example) at 90 locks the gimbal completely, so that the first (yRot) and third (zRot) rotations share the same rotation axis. This happens, because Poser computes the rotation channels one after the other, and the rotation axis of later channels is modified by the rotation of prior channels. So you can't avoid this effect. You can sometimes arrange the rotation channels (the rotation order) properly, to minimize gimbal lock effects: You find out, which of the rotations won't be close to 90 or -90, then you place this rotation between the remaining two rotation channels. The arms and legs of Poser humans have for example the rotation order "Twist", "Side-Side", "Bend", because the middle rotation ("Side-Side") will never be close to 90. When you try to set "Side-Side" to 90, you lose a rotation axis, and "Twist" looks exactly like "Bend".

You're welcome :)

Now this is strange. You maybe found a Poser bug? The steering wheel example comes from the old batmobile model. You can download it (870 KB) here http://64.38.105.73/bmexample.zip The "Steer" master is in "Body". The slaves are in body parts "steering", "fwheell" and "fwheelr". You couldn't, for example, place the master in the steering wheel or in one of the front wheels, because there is no parent-child relationship among these parts. If you can't fix your problem, you can send me the cr2 (no geometry if possible) for my Poser mysteries collection :)

Hello ScottA, This could be a hierarchy problem: When you modify a dial in body part "steeringWheel", Poser updates all children, and the immediate parent of "steeringWheel". But the parents of the parent body part aren't automatically updated. You need to nudge a dial in the parent body part, to force an update event. If body part "frontWheel" is neighter the immediate parent nor a child of "steeringWheel", then "frontWheel" won't be updated, when you move a dial in "steeringWheel". Therefore, if the master and slave channels are placed in different body parts, then the slave channel should be placed - either in a child body part, - or in the immediate parent body part. You find a more detailed description of this effect in my ERC-tutorial (Part 1). There is also a steering wheel example code in Part 3 or so. You can download the tutorial here http://64.38.105.73/erc_download.html

hello bloodsong, Yes, I think you're right, except for the last one: When I scale my Poser humans, the feet don't stay on the ground. They scale (and rotate) around the abdomen, unless I set the origin to 0 0 0. As far as I can see, Poser's scale channels perform a common scaling operation, that is, every vertex moves on a straight line towards the rotation center (down scaling) or away from the rotation center (up scaling). Here's a little experiment to prove the theory: 1. When you down scale the geometry, all vertices move towards the center point. When you down scale more and more, the vertices should pass the center point, and then move away in the opposite direction. You can for example move the 'xScale' channel towards 0, to move the vertices on a straight line along the x axis towards the x coordinate of the center point. If you set a negative 'xScale', the vertices should move beyond the x coordinate of the center point, so that the geometry is mirrored in the yz mirror plane. Right? 2. Of course, this doesn't work, because you can't set negative scale channel values. 3. But if you use a valueParm master channel, and make the scale channel a slave, then it works. You can set the master channel to negative values, and the scale channel slave follows. 4. The negative scales work as expected: Is you set a scale channel to -1, the resulting shape is the mirrored variant of the generic geometry. Negative 'xScale' mirrors in the yz plane, negative 'yScale' in the xz plane. Negative 'scale' mirrors the geometry in the center point (which is the same as mirroring in the xy, the xz, and the yz planes). 5. The resulting geometry has 'reversed normals' (as expected): The scale channels move the vertices, but don't adjust the facets. Therefore, the surface of the mirrored geometry is 'inside out'. You can use the 'Reverse Group Normals' command in the Group Editor, to adjust the normals.

Attached Link: http://64.38.105.73/erc_download.html

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

The numbers are the Mac notation of the filepath: The first number (-1 in the example) is the drive ID (the volume on your disk), the second number (e.g. 173584) is the directory ID (the folder in the volume). The two IDs and the file name together form the pathname. If both numbers are 0, or if there are no numbers, Poser uses the text included in the filename as pathname, for example

textureMap 'myDisk:myFolder:M2HeadM2.jpg'
0 0

Poser for Mac evaluates the IDs faster than text. Because of this, a pathname is converted to IDs, and the IDs are stored in the pz3 document. To find out the IDs of a specific folder, you can for example locate a texture map within this folder in Poser's Material Editor, then save the document, re-open it in a text editor, and inspect the textureMap lines.

I assume you're on Poser for Windows. Did you delete the geometry .rsr file? The alternateGeoms are stored to the figure resource file (that is RuntimeGeometriesfemaleSkeletonfemaleSkeleton.rsr). If you modify the geometry in the cr2, you also need to delete the existing resource file, so that Poser uses the new alternateGeoms the next time you load the figure.

'objFile 1002 :Runtime:Geometries:props:cone.obj' means, that Poser adds a geometry resource ID 1002 to the figure geometry resource file, when you load the figure. So the modified 'femaleSkeleton.rsr' file contains the standard resource ID 13 for the figure, and an additional resource ID 1002 for the cone geometry.

Hello MartinC The Swiss versions for one million and 14/100 are 1'000'000.14 It's not important, of course. If you would want to pay me 1'000'000.14, I'd take it with comma or point : )

Well, I don't know if 'forceLimits' 1 or 'forceLimits' 4 makes any difference. I think 'forceLimits' is a flag, which can be 0 (off) or any other value (on). If you choose for example a 'forceLimits' 1, 4, 32, or -100 in the library code, Poser sets the flag always to 4. That's why I'm using 4, because this is the 'correct' value. But you can choose 1, -100, 666, or something else, if you like. All values force the channel to the 'min' and 'max' limits. BTW, if you activate the 'Use Limits' menu command, the 'useLimits' flag in the 'doc' clause is set to 1, which forces all channels to the 'min' and 'max' limits (including the channels of cameras, lights, etc.). The 'useLimits' flag doesn't lock the dial itself (the slider in the dial palette), whereas the 'forceLimits' flag forces the channel values and the dial to the 'min' and 'max' limits. I guess the 'forceLimits' flag is stored in the third bit of a binary value, which is the integer value 4. The 'customMaterial' flag is stored as 0 (off) or 32 (on), for example. This could be the sixth bit of a binary value.