Tue, Jan 7, 12:51 AM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2025 Jan 06 7:01 am)



Subject: Morphs not deleted, just hidden?


imax24 ( ) posted Wed, 25 August 2010 at 8:19 PM · edited Mon, 28 October 2024 at 12:30 AM

I have realized that user-created morphs usually aren't deleted by REM files, they're just hidden. If you look at the text of a REM file (just a few lines), all it does is hide the channel the morph resides in.

This can create difficulties if you modify a morph and inject it into that same channel. It pays no attention to the modified morph in the INJ file, it just unhides and activates the old one. Sometimes it "doubles up" the morph by having the FBM tell dependent body parts to apply it twice. Because the first morph in that channel never really went anywhere, I suppose.

It's possible to remove a morph by physically cutting out the whole channel, either by using Poser's delete morph menu item in the Parameters Panel, or using one of the utility scripts that  do the same thing. But then the channel is gone. You can't use it to inject another morph. If you try, instead of shifting to an empty user channel (PBMCC), Poser overwrites one of the "factory" V4 morphs. You might not realize that until much later.

So my question is, how to clean out a user morph without eliminating the whole channel? I realize you can go into the .CR2 file and delete the morph section in there without killing the channel for future use. But most folks aren't comfortable doing that, for fear of wrecking the .CR2. Is there a more layman-friendly way to get rid of a morph, not just hide it? Or completely replace it within that channel?


markschum ( ) posted Wed, 25 August 2010 at 10:40 PM

a rem pose file - to remove a morph should do two things . It should hide the dial detail, actually change the name, and it should specify a delta count of 0. That drops the delta statements and so removes the morph.

    version
        {
        number 4.01
        }
    actor hip:1
        {
        channels
            {
            targetGeom PBMCC_30
                {
                name -
                indexes 0
                numbDeltas 0
                keys
                    {
                    static 0
                    k 0 0
                    }
                }
            }
        }
}

this is part of a rem pose


imax24 ( ) posted Wed, 25 August 2010 at 11:13 PM

Here is a REM file that came with one of my character morphs.You see the only thing with a 1 next to it is "hidden," so I thought that was the extent of its action. And the morph did seem to linger in the character when I tried to inject a modified morph of the same name into that channel after deleting the first one. This REM file seems a bit different than your example. For instance, yours does not include the "hidden" line.

 

version

{

number 4.01

}

actor head

{

channels

{

targetGeom PBMCC_42

{

name -

hidden 1

indexes 0

numbDeltas 0

}

}

}

}


adp001 ( ) posted Thu, 26 August 2010 at 10:24 PM

Quote - Here is a REM file that came with one of my character morphs.You see the only thing with a 1 next to it is "hidden," so I thought that was the extent of its action. And the morph did seem to linger in the character when I tried to inject a modified morph of the same name into that channel after deleting the first one. This REM file seems a bit different than your example. For instance, yours does not include the "hidden" line.

 

version

{

number 4.01

}

actor head

{

channels

{

targetGeom PBMCC_42

{

name -

hidden 1

indexes 0

numbDeltas 0

}

}

}

}

I've marked the essential part for you. Most important is "numbDeltas 0".  This definitively wipes out all the "geometries" for this morph. 

You may try it: Leave the name intact  (remove "name -") and also "hidden 1". Activate the pose. Then turn the dial and nothing will happen.




imax24 ( ) posted Thu, 26 August 2010 at 11:59 PM

Thank you. What's the point of the "hidden" line? If the morph is deleted, what is there to hide? A dial with no name that doesn't do anything? Why isn't the dial deleted, too, not just hidden with a hypen for a name?


nruddock ( ) posted Fri, 27 August 2010 at 4:42 AM

Quote - If the morph is deleted, what is there to hide?

The dial.

Quote - A dial with no name that doesn't do anything? Why isn't the dial deleted, too, not just hidden with a hypen for a name?

Because there is no way to delete the channel.
It has to be there in the first place (and remain) because there is no way to add new channels (which is why there are many empty channels supplied).


markschum ( ) posted Fri, 27 August 2010 at 9:47 AM

In my rem pose example there is another section that hides the dial .  Clearing the name and hiding the dial I took from Daz by looking at their inj and rem poses. The PBM CC channels are meant to be retained for users to add morphs by inj.


lesbentley ( ) posted Fri, 27 August 2010 at 10:49 AM

Quote - This REM file seems a bit different than your example. For instance, yours does not include the "hidden" line.

The contents of a REM file can vary a bit depending on what you want it to do. The only line that is absolutely essential is "indexes 0" (not "numbDeltas 0"), eg:

{

version
    {
    number 4.01
    }

actor head
    {
    channels
        {
#
        targetGeom PBMCC_42
            {
            indexes 0
            }
        }
    }
}

"indexes 0" does the actual job of deleting the deltas from the channel. Other lines like "name -" to change the displayed dial name, or "hidden 1" to hide the dial from the parameters palette, or "k 0 0" to set the channel value to zero in frame one, are optional. I think that the people who coded poser can't have been completely sober the day they did this part of the coding, because in Poser Script "indexes" means the number of delta lines in the morph, and "numbDeltas" means the number of vertices in the actor. These meanings are the inverse of what the names would suggest.


lesbentley ( ) posted Fri, 27 August 2010 at 11:05 AM · edited Fri, 27 August 2010 at 11:12 AM

Also note that a targetGeom (morph) channel may be slaved to a valueParm (FBM) channel in the BODY. A normal REM file does nothing to remove the slaving code from the morph channel. So if the "targetGeom PBMCC_42" channel is slaved to "valueParm PBMCC_42" in the BODY, that FBM dial in the BODY will continue to affect the morph channel after a REM has been applied, though of course nothing will actually happen unless a new morph is injected, in which case the new morph will continue to be affected by FBM dial.


imax24 ( ) posted Fri, 27 August 2010 at 11:16 AM

Great info. I didn't know that about slaving coming back to haunt me if I ever stick a morph in that channel again. That might explain some of the weirdness that happens when I delete a morph and put a new one in the same channel. I need to remember to go to the FBM dial, before I delete the morph, and edit out any dependencies so they won't be multiplied by the dependencies created in the new FBM.

The Poser manual should tell us this, and not assume users will never make their own morphs. So much of what is useful knowledge about Poser seems to be word of mouth, learned by trial and error, rather than explicit instructions.

So the REM example I posted seems to be a good and proper one. It sets the name to "-", it hides the dial, it deletes the morph deltas. A line to remove dependencies would be useful, too!


lesbentley ( ) posted Fri, 27 August 2010 at 12:57 PM

Quote - I need to remember to go to the FBM dial, before I delete the morph, and edit out any dependencies so they won't be multiplied by the dependencies created in the new FBM.

You will not normally find anything useful in this regard in the valueParm (FBM) channel. The slaving code linking a morph to a valueParm is in the targetGeom (morph) channel itself. I said "A normal REM file does nothing to remove the slaving code...", but this does not mean that nothing can be done. Providing that the morph channel is only slaved to one channel, which is usually the case, you can add this line to the REM file "deltaAddDelta 0.000000", eg:

{

version
    {
    number 4.01
    }

actor head
        {
        channels
                {
                targetGeom PBMCC_42
                        {
                        name -
                        initValue 0
                        hidden 1
                        keys
                                {
                                k  0  0
                                }
                        <span style="color:rgb(0,255,0);">deltaAddDelta 0.000000</span>
                        indexes 0
                        numbDeltas 0
                        }
                }
        }
}

"deltaAddDelta 0.000000" will set the control ratio (strength of the slaving) to zero, thus in effect disabling the slaving.  If desired a pose file can then inject a new morph, slaving it to a different master channel, or it can restore the previous deltaAddDelta value.
I have also included an "initValue 0" line. This is another optional line. When you use the Poser Memorize functions the memorized value is stored in the initValue line, if you later use a Restore function the value to restore is read from that line. As the memorized value may no longer be appropriate to a new morph injected into the channel, I like to zero the initValue in the REM file.


imax24 ( ) posted Fri, 27 August 2010 at 1:55 PM

Quote - You will not normally find anything useful in this regard in the valueParm (FBM) channel. The slaving code linking a morph to a valueParm is in the targetGeom (morph) channel itself.

Actually, I meant I'd go into the Master Parameter by clicking on that little icon next to the dial and removing any dependent parameters I see in the dialog window.

That's cool that there is a line for the REM file that can clean up any dependencies. And I suppose it does no harm if there are no dependencies, so I can just include it in all REM files. Thanks.


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.