Dead (not working) pose for Freddie



  • Poser 11 Content --> Cartoon --> Cartoons --> Freddie --> Standing 2 does nothing to the figure. When I opened Standing 2.pz2 in a text editor I noticed that for starters it's targeting Freddie's shirt instead of him, but editing this in both places didn't make any difference.

    Can someone at SM correct this and post the corrected file?



  • @duanemoody Thanks for the heads up. I'll look into this personally.



  • @Teyon The other thing I noticed after loading Freddie was that his head's twist/side-side/bend values are almost but not quite zero, and a few other limbs are like this too. Is there something weird about his rigging going on here?



  • @duanemoody No, his limits are just very extreme.



  • Although I thought we fixed that in the content updater.



  • @Teyon I'm not talking about his limits, I'm talking about the default twist/side/bend values for his head (and other limbs) when he's added to an empty scene.
    0_1475252735434_freddieheadie.jpg



  • @duanemoody Oh. That's weird. They should be zero. I'll have to speak with Charles about that one. Did you notice that on any of the other toons? They all should be zero from the outset.



  • @Teyon I haven't checked. But while we're on this subject, I noticed that if you select Edit --> Copy to copy all the actor's values to the clipboard, they don't have the same precision as the actual values:

    Head 0 yRotate Spline -0.0000 2
    Head 0 zRotate Spline -0.0007 3
    Head 0 xRotate Spline -0.0041 1

    Notice the rounding compared to the values highlighted in the screen shot. Is there a reason not to use the same precision?



  • @Teyon It's exclusive to Freddie. None of the other gen 1/2 toons have these minute variations in their rotX/Y/Z for head, collar parts, etc.

    FreddieDevRig has some of this as well but the values are different:0_1475253675108_fdevrigheadie.jpg

    Ignore the Freddie2 and Freddie3 in the library, those were edits to the .cr2 to attempt to fix this by zeroing those rot values (keys and initial) which had no effect.



  • I didn't check the toon dev rigs so I went back and checked them.

    All of them have minute variations on the head position – except Minnie2DevRig, which weirdly asks for a missing .PMD file (the other devrigs don't seem to have any). Once I dismiss that dialog and get to the scene, her head's fully zeroed just like the regular Minnie2.

    Reading Minnie2DevRig.cr2, I see 2 lines referencing a morphBinaryFile that's not in that directory. Looking at Gramps2DevRig.cr2, no mention of morphBinaryFile and I presume the rest of the devrigs are the same.



  • Appreciate it. Something really wrong must have happened in the final build for them to have gone out like that. I'll speak with Charles asap. Thank you. Sorry for the hassle.



  • @Teyon One last thing about these dev rigs that might be relevant.

    Gramps2DevRig has nonzero Side-Side/Bend values on the head, but when I open Gramps2DevRig.cr2 and drill down to the actor head channels to find the relevant rotate channels, they're zeroed both in initValue and the keys:

    	rotateY yRotate
    		{
    		name twist
    		initValue 0
    		hidden 0
    		enabled 1
    		forceLimits 0
    		min -100000
    		max 100000
    		trackingScale 1
    		keys
    			{
    			static  0
    			k  0  0
    			}
    		interpStyleLocked 0
    		}
    	rotateZ zRotate
    		{
    		name side-side
    		initValue 0
    		hidden 0
    		enabled 1
    		forceLimits 0
    		min -100000
    		max 100000
    		trackingScale 1
    		keys
    			{
    			static  0
    			k  0  0
    			}
    		interpStyleLocked 0
    		}
    	rotateX xRotate
    		{
    		name bend
    		initValue 0
    		hidden 0
    		enabled 1
    		forceLimits 0
    		min -100000
    		max 100000
    		trackingScale 1
    		keys
    			{
    			static  0
    			k  0  0
    			}
    

    Something else is overriding those values which explains why manually editing copies of Freddie.cr2 to zero out initValue and the keys had no effect.

    Is this somehow related to weight mapping?



  • @duanemoody Not necessarily. It could be a bug within the app itself upon load. We're going to have to take a hard look at this. Again, thanks for bringing it to our attention.