This is a weird one.  I edited a pz3 file containing a figure and three garments conformed to that figure.  Modifications were made only to one of the conforming garments, and it works fine.  One of the other garments, however, has picked up some odd behavior in the edited file.  When I move the camera (or change the actor selection while the joint editor is open), certain body parts of one of the conformers will jump or twitch, changing position but then snapping back.  I've seen something similar when a combination of ERC and Point At is in use, but neither is in place here.

Does anyone have any idea what is happening, or how I can try to fix it?  Has anyone seen this before?    It's driving me nuts, here.  :lol:

I've seen this happen without ERC and/or Point At being used.  Dunno what's happening or how to stop it, though.  

The only things I can think of are how some figures go bugfuck when rotated 360 degrees.  Is one of your figures rotated 360 or greater?  Or if IK is left on for something, perhaps?

Just guesses but I hope they help. 

IK is off.  The conformed figures aren't rotated, but the main figure may be.  I'll check that.

The weird thing is that this doesn't happen in the pz3 which hasn't been edited.  That file has no such problem.  Then I edit a bit, and blango!

I guess Poser is still an adventure, even with all the improvements in the latest release.  :lol:

You might like to try this. Save the edited figure to the Figures palette, then open the original pz3, and replace the figure in question with the edited version. If everything is still working correctly, save a new pz3, then use a file comparison utility (eg the free "ExamDiff") to compare the files. This method has often helped me to discover the crucial difference between a good and bad version of a file. Sometimes you may need to edit the figure numbers for consistancy, before doing the compare.

Thanks, Les.  It's worth a try!

Once I re-started Poser, the problem was less pronounced.  It's still happening, but not as predictably.  As far as I can tell, it isn't causing any serious problems.  Scripts and collision features find the geometry in the correct location and I haven't seen a render in which the incorrect "jump-to" position is rendered.  So it's just a troubling quirk of the 3D preview, with no further implications.  As far as I can tell, anyway.  :unsure:

No real clue here Cage, -- but if it is just in preview, now kinda curious if SreeD vs OpenGL might make a diff, or, if it perhaps jumps more when using one of the cams that is also parented to the fig.

It actually occurs with all cameras, as far as I can tell.  I might have expected the effect to be restricted to the Pose and Face cameras, having seen various oddities with those in the past.  But it's present in Main, Aux, and extra cameras in the scene.  I haven't checked shadow cams or dolly cameras, only revolving.

I'll try SreeD to see if that makes it stop.  Hadn't thought of that.  I try to avoid the SreeD, since it gives me flashbacks to much older versions of Poser.  :lol:

I think I've found the problem.  Ever wonder what that "flipped" line in the joint listings does?  Well, one thing it does is cause this problem, if it's there when it shouldn't be.

As far as I can tell, "flipped" should be present in the otherActor affector listings for a joint (such as shoulder twist in collar), but never, ever present in the joints for the actor itself.  I had exnded up with them incorrectly in place when I recreated my joint listings for some actors by pasting those otherActor affectors back in as main joint/twist listings in the actor.  I didn't remove flipped.  So Poser was confused, and part of the time it was apparently trying to reverse the effect of the joint or something.  Whatever flipped does.  :unsure:

Whoosh - the sound of a concept flying right over my head - but will tuck it away for future reference.   Nice detective work Cage.

Could be quite useful if one could use Python to add 'flipped' statements to magnets, maybe one could use symmetry to adjust magnets (provided the magnets have been renamed to "lMagnet_1/rMagnet_1" etc).

I don't know if "flipped" would work outside of jointX/Y/Z or twistX/Y/Z listings, which are reserved for body parts.  They wouldn't do much good in a prop such as a magnet.  But who knows?  Maybe it will do something if moved to a new context.  :unsure:

I think you should try it.  :laugh:  I'll be hiding back here, in the bunker.  :lol:

One other thing the "flipped" line was doing.  When it was present, those joints which had it incorrectly were not editable in Poser's joint editor.  Apparently this is a switch, or one switch of several, which can tell Poser that this is an affected actor joint and not an editable main joint listing.  Once I removed the flipped, I could edit the joints again and the figure stopped, errr, flipping out.  :lol:

Well, blangit.  This problem can evidently occur for more than one reason.  Now I'm having the same trouble with Dependent Parameters.  I had some DPs set up, they worked nicely.  Then I set up some more involving the same actors.  Now the original set malfunctions.  When I move the camera, the morph which should be DP-activated flips to the wrong position.  Meanwhile, all of the dependent parms show a zero setting, regardless of what they're really doing.

There seems to be some kind of generalized Poser display or scene refresh problem at the root of this.

Dang.  I'm going to have to deal with customer service, aren't I?  I really don't like that.  My reports never seem to be well-received and I never see any evidence that they're being addressed.  It's a hassle-and-a-half, so I'm tempted to say, why bother?  And yet... there's obviously a problem, here.  :crying:

The dependency foul up is a known issue, I reported it, hurry up and wait.

I forget what version I first reported it. I reported it again in this version as well.

What is happening is that the dependencies that broke will now be pointing at something else. This can happens a lot on character saves and seems to be hit or miss on file saves. Sometimes it will happen in one session as well.

Edit the cr2 and change the them from Master (1,2,3) to another name and correct the erc links and they should work again. If they were crosstalk erc, the will have changed from Body:1 to the body part of the figure they are on. If they are internal, check both the character numbering and figure link carefully.

Adding the Daz style erc links at the end of the file seems to stop Poser from changing them most of the time as well. But even that doesn't seem to keep it from happening all the time.

Putting dependencies in a character is causing many other problems as well.

Quote - Well, blangit.  This problem can evidently occur for more than one reason.  Now I'm having the same trouble with Dependent Parameters.  I had some DPs set up, they worked nicely.  Then I set up some more involving the same actors.  Now the original set malfunctions.  When I move the camera, the morph which should be DP-activated flips to the wrong position.  Meanwhile, all of the dependent parms show a zero setting, regardless of what they're really doing.

Hmm.  I haven't looked at the weird DP parameters in a cr2 editor, but they look fine within Poser.  Not that that necessarily means much, I suppose.  :unsure:

Possibly I screwed them up myself.  I assumed that just closing the dependent parameter setup dialog would stop the "learning" process.  It doesn't.  If you close the pop up without pressing the "stop" button, Poser will keep adding every parameter you modify to the depdency stack.  :scared:  I had all kinds of crazy things there, before I stopped it.  :lol:  Don't know whether that might have contributed to my problems.

That would definently cause havoc.

But there are issues with it as well that they have yet to address.

I have seen the issue where some parameter in a totally separate item will become slaved to some parameter in V4. Even a prop with morphs in it, that couldn't be conformed to V4 even if I wanted to.

I have also seen the issue where a piece of conformed clothing will "jump" slightly when the camera is moved, resulting in poke-through. Move the camera again, and the clothing "jumps" back to proper position.

A similar issue: Touching a prop, body part, or light can make it fly off to a new rotation and/or translation. Two Undo's required to get it back in place.

All three of these bugs, that seem accumulate after working in Poser for awhile, can be cleared up by restarting Poser.

Now, an issue that is not similar but perhaps related to whatever bugginess or memory problem that is causing the others: Switching cameras or typing into a text-entry field can become excruciatingly slow. Something called "pictd" in the Activity Monitor pegs up CPU use to over 90% during the lag, then drops to zero when Poser has finished contemplating its navel.

Restarting Poser doesn't fix the above problem, but restarting my Mac does. This one started after SR1.

The problem doesn't seem to go away for me, even after re-starting Poser.  :sad:  But I haven't loaded SR1.  Waiting for SR2, I think.  :unsure:

The cr2 looks normal, too.  It doesn't show me anything which isn't reported by the dependent parameter listings within Poser.  I manually edited the DPs to refine them, but the problem is still there, with the new settings.

I think this one may be a form of cross talk.  The belt is slaved to the hip of the conforming garment, the body suit.  The valueOpKey ERC has seemed to work properly on a conformer without pointing the ERC to the main figure which wears the garment and is posed.  That's true here, as well.  But it looks like the belt may be doubling the valueOpKey settings in preview, responding to both the posed hip actor and the unposed master hip on the garment.  That's my best guess about what's happening, anyway.

So far it does render correctly, but the broken preview is irritating and confuses matters periodically.  :cursing: