**Hidden (Part 3).**Doors and 'hidden'.

When a pp2 (prop) or cr2 (figure) contains a door, it is usual to hide all the rotation and translation dials, except the one that opens the door, and to force limits where appropriate to stop the door moving in undesirable ways. This is usually done by editing the pp2 or cr2 in question, but it can also be done in the Poser interface via the application of a pose file.

Sometimes you may download a freebie where the door has not been set up correctly. In that case you can try this pose file on it, rather than text editing the original file. If it works as desired you can save the item back to a pallet.

In the file below, it is assumed that the 'yrot' channel opens the door, as that is the most usual case, but it may not always be so. Especially if the "door" is a hatch, you may have to edit the pose as appropriate. It is also assumed that that the door is in the correct position when all its translations and rotations are set to zero.

{
//DoorFix.cm2
version
        {
        number 5
        }
actor $CURRENT
        {
        channels
                {
                scale scale
                        {
                        hidden 1
                        }
                scaleX xScale
                        {
                        hidden 1
                        }
                scaleY yScale
                        {
                        hidden 1
                        }
                scaleZ zScale
                        {
                        hidden 1
                        }
                rotateY yrot
                        {
                        name <span style="color:rgb(255,0,0);">Open</span>
                        hidden <span style="color:rgb(255,0,0);">0</span>
                        forceLimits <span style="color:rgb(255,0,0);">1</span>
                        min <span style="color:rgb(255,0,0);">-360.000</span>
                        max <span style="color:rgb(255,0,0);">360.000</span>
                        }
                rotateZ zrot
                        {
                        initValue 0
                        hidden 1
                        forceLimits 1
                        min 0
                        max 0
                        }
                rotateX xrot
                        {
                        initValue 0
                        hidden 1
                        forceLimits 1
                        min 0
                        max 0
                        }
                translateX xtran
                        {
                        initValue 0
                        hidden 1
                        forceLimits 1
                        min 0
                        max 0
                        }
                translateY ytran
                        {
                        initValue 0
                        hidden 1
                        forceLimits 1
                        min 0
                        max 0
                        }
                translateZ ztran
                        {
                        initValue 0
                        hidden 1
                        forceLimits 1
                        min 0
                        max 0
                        }
                }
        }
}

!!!CAUTION!!! You should use this file in a scene that only contains the prop  or cr2 you want to modify. Then save the modified file back to a pallet. If you use it in a WIP, and it has unexpected results, or you apply the pose to the wrong element, if you have not first saved the scene to a pz3, you may find it hard to put things back the way they were. You can edit the 'min' and 'max' lines in the 'yrot' channel to limit how far the door will open. For example, to only allow the door to open to -90º, you would use:

                rotateY yrot
                        {
                        name Open
                        hidden 0
                        forceLimits <span style="color:rgb(255,0,0);">1</span>
                        min <span style="color:rgb(255,0,0);">-90.000</span>
                        max <span style="color:rgb(255,0,0);">0</span>
                        }

NOTES:
You will probably have to select some other element in the scene, then reselect the door to refresh the pallet and hide the dials. Because the above file uses 'actor $CURRENT' it will only work in P5 or above.

The scale dials have been hidden, but no limits have been set for them as I do not think this is really necessary. If you do want to set limits for the scale channels, remember that the default value for a scale channel is "1", not "0".

Because you may want to use the file when there is no figure in the scene, it is best to save it to a camera folder, with a cm2 file extension.

Thank you for testing the INJ script ,I'll ask on Python forum and I'll bring here the answer ( if any !)

Quote - **
**The default curve has 4 nodes, and is a less flexible starting point because there is no way to delete nodes in the Graph Editor. But you do this at your own risk, this is experimental stuff, bending the curve in the wrong way might rupture the fabric of space-time or something, and God only knows what would happen then!.

Good news, you CAN delete nodes in the Graph Editor!  Drag/highlight/select a chunk of the graph window over the points you wish to delete.  When you have those points selected, hit delete and they are gone.  Hope this helps!

-WTB

@ William,

Thanks for the tip William. I never realised that you could do that. Serves me right for not reading the manual.

@ alizea,

Thanks alizea. Please keep us posted. This issue seems quite important to my mind.

**REM Poses.**REMove Morph Deltas.

In the posts on Delta Injection we have seen how to inject deltas into a targetGeom (morph) channel. Deltas typically account for a very large amount of the code in a figure, so removing deltas from unused morph channels can be a good idea. I should really have put this post immediately after the Delta Injection stuff, but somehow I forgot. There is some latitude as to exactly what should or should not go into a REM pose. These are just my thoughts on the subject, arrived at after making REMs for my own use, I have never distributed a delta injection/REM package, and claim no particular expertise in this field.

The job of removing deltas from a targetGeom channel is done by using 'indexes 0'. The file below will remove the deltas from the "PBMCC_01" channel in the head:

{
version
        {
        number  4.01
        }

actor head
        {
        channels
                {
                targetGeom PBMCC_01
                        {
                        indexes 0
                        }
                }
        }
}

Usually we want the REM pose to do more than just remove the deltas. Below is a REM pose that also resets the dial name, and hides the dial from parameters pallet: { version { number 4.01 } actor head { channels { targetGeom RoundFace { name - hidden 1 indexes 0 numbDeltas 0 } } } }

Most REM files that I have seen include the line "numbDeltas 0". I can't see that it serves any useful purpose in a REM pose, but I may be mistaken on this point. Perhaps it is best to include this line, just to be on the safe side. It's probably debatable exactly what should or should not be included in a REM pose. DAZ seem to leave out the 'hidden 1' line, but use a pz2 containing readScript to call both REM and Hide poses. To me this seems an unnecessarily complicated way to do things.

I think a case can be made for zeroing the 'k' line value in the REM pose. This should not really be necessary as the delta injection pose should, in my opinion, set this value as appropriate (to zero or one, depending on circumstances), but not all do. An even stronger case can be made for setting the 'initValue' to zero, as the figure may have been Memorized at some point, and if the morph deltas are being removed, then the Memorized value is probably inappropriate to any new morph injected in this channel.

The dial name is usually set to "name -". An alternative is to set the internal name as the dial name, so that if the dial should be unhidden for any reason, you can see which channel it belongs to, however this can be extra work.

Where targetGeom (morph) channels are slaved to valueParm (FBM) channels in the BODY, another question that is open to debate is whether the REM pose should reset any parameters in the valueParm channel, and if so which ones. I tend to think that the 'name', 'initValue', and 'k' lines should be reset in the valueParm.

So my current thinking is that a REM should look like this:

{
version
        {
        number  4.01
        }

actor BODY
        {
        channels
                {
                valueParm PBMCC_01
                        {
                        name PBMCC_01
                        initValue 0
                        keys
                                {
                                k 0 0
                                }
                        }
                }
        }

actor neck
        {
        channels
                {
                targetGeom PBMCC_01
                        {
                        name PBMCC_01
                        initValue 0
                        hidden 1
                        keys
                                {
                                k  0  0
                                }
                        indexes 0
                        numbDeltas 0
                        }
                }
        }
}

Some people may think that the above is a bit over the top and unnecessary, perhaps they are right. Below is a pz2 produced by svdl's "SpawnCharacterP6.py". Note that it hides the valueParm channel. As hiding the channel reduces some of the clutter in the parameters pallet, it may be a good idea, but some future injection may forget to unhide the channel, this is probably not very likely, but is something to be considered. The file also sets 'static 0' (animating off) in the valueParm, in my opinion this is very unlikely to be needed. I'm not trying to knock svdl's REM poses, I think "SpawnCharacterP6.py" produces very good and well thought out poses, I'm just pointing out some things to be considered.

{

version
        {
        number  4.01
        }

actor BODY
        {
        channels
                {
                valueParm       PBMCC_01
                        {
                        name    -
                        hidden  1
                        keys
                                {
                                static  0
                                k       0       0
                                }
                        }
                }
        }
actor head
        {
        channels
                {
                targetGeom PBMCC_01
                        {
                        name    -
                        hidden  1
                        indexes 0
                        numbDeltas      0
                        }
                }
        }
} 

In the end, what you do or don't put into a REM pose is up to you. As I said at the beginning, I am no particular expert in REM poses, and what I have said in this post is meant as food for thought, not dogma. I would be interested to hear other people's thoughts on this subject.

**Version Numbers.**The first block of code in any Poser file is the version block. This tells Poser which version the file was exported from, or created for.

{
version
    {
    number 4.01
    }
}

If you try to use a a Poser library file that has a later version number than the version of Poser that is trying to open it, then Poser will generate a message: "The file has a newer version number
than expected. Poser will attempt to
read it anyway"

You then have to press an "OK" button (there is no "Cancel" button). As far as I am aware, generating this message is the only effect of the version number.

You should use the lowest version number in the file that you are confidant is consistent with all the code in the file working as desired. I have never owned P3, but I know that "normal" poses to set joint rotations or translations work in P3, so for those type of poses I use a version number of 'number 3'. 'actor $CURRENT' was introduced in P5, so any file that uses that should have a version number of at least 5. The 'shaderTree' was also introduced in P5, as an addition to the 'material' blocks, so any file thats main purpose is to set shaderTree nodes should have a version number of at least 5. However if the shaderTree is not an essential part of the function of the file, you may want to use an earlier version number to avoid the pop up message. P6 introduced these:

injectPMDFileMorphs
createFullBodyMorph
attachFBMdial

So any file that uses these should have a version number of at least 6. There were some other things introduced in P6, but as they are not normally essential to the operation of pose files, you do not usually need to take them into consideration when deciding which version number to use.

P7 introduced its own additions to Poser script, but as I don't have P7, I can't give you any information on them.

All the examples I have posted in this thread were tested in P6. Many will work in earlier versions. I hope that Poser is, and will remain, backwards compatible with all earlier Poser script, and that the examples in this thread will continue to work in P7, P7 Pro, and future versions. But there is no guarantee that Poser will continue to implement everything the same way in future versions. "Pose Overflow" mentioned in previous posts is an example of something that used to work in P4, but no longer works in P6.

Les, thank you so muuuuch for sharing this text book of code.

For me personally, I hate code because it baffles me. But all of this is just awesome man!

Quote - I would be interested to hear other people's thoughts on this subject.

Making sure everything is explicitly set to a known (and hopefully consistent) state is a good programming practice.

**Disable Slaving.**This may be a bit of an obscure topic, but someone may find a use for it.

Sometimes you may want to disable slaving for some particular channel. In the slaving code the value in the 'deltaAddDelta' line determines the strength of the slaving, so setting this value to zero effectively turns the slaving off. We can do this if there is only one block of slaving code in the channel, or if the block of slaving code that we want to disable is the last block in the channel.

Method A:

{
version
        {
        number 4.03
        }
actor hip
        {
        channels
                {
                targetGeom heroineHip
                        {
                        deltaAddDelta 0.000000
                        }
                }
        }
}

The above pz2 file will set the 'deltaAddDelta' value to zero for the last slaving code block in the channel, thus effectively disabling the slaving. If the channel is only slaved to one master, all is fine and dandy, but sometimes a channel may have more than one master. When the channel has more than one master, and the slaving that we want to disable is NOT in the last block of slaving code, we need to find another trick. If we can find an unused channel to subvert to our purpose, we can do it like this.

Say for example we have a morph channel in the head that uses the dial name "MyMorph", which is slaved to a FBM in the BODY which also uses the dial name "MyMorph", both these channels use the internal name "PBMCC_01".

Say we have a spar channel in the BODY with the internal name of "PBMCC_07". Here is the pz2 we could use to disable the slaving.

Method B:

{

version
        {
        number 4.03
        }

actor BODY
        {
        channels
                {

# Slave the PBMCC_07 channel to the MyMorph dial name (PBMCC_01), using 'valueOpMinus'.

                valueParm PBMCC_07
                        {
                        name <span style="color:rgb(255,0,0);">-MyMorph</span>
                        initValue 0
                        hidden <span style="color:rgb(255,0,0);">1</span>
                        forceLimits 0
                        min -100000
                        max 100000
                        trackingScale 0.004
                        keys
                                {
                                static  0
                                k  0  0
                                }
                        interpStyleLocked 0
                        <span style="color:rgb(255,0,0);">valueOpMinus</span>
                                Figure
                                BODY
                                <span style="color:rgb(255,0,0);">MyMorph</span>
                        }
                }
        }

actor head
        {
        channels
                {

# Slave the PBMCC_01 in the head to the dial name "-MyMorph" (PBMCC_07) in the BODY.
# The deltaAddDelta value needs to be the same as that which you are trying to cancel out (MyMorph).

                targetGeom PBMCC_01
                        {
                        valueOpDeltaAdd
                                Figure
                                BODY
                                <span style="color:rgb(255,0,0);">-MyMorph</span>
                        deltaAddDelta   1.000
                        }
                }
        }
}

The morph in the head (or where ever) is slaved to two valueParm channels in the BODY. Because the value in "-MyMorph" channel is the exact inverse of the value in the "MyMorph" channel (in the BODY), and the same deltaAddDelta value has been used in both slaving blocks in the head, the tow sets of slaving cancel each other out. To finish up, here is a way to temporarily disable all slaving for a channel, even future slaving that has not yet been applied. One nice feature of this method is that it gives you a dial that allows you to turn the slaving on or off.

Method C:

{

version
        {
        number 4.03
        }

actor BODY
        {
        channels
                {

# First we set up the master valueParm channel the way we want it.

                valueParm PBMCC_07
                        {
                        name <span style="color:rgb(255,0,0);">On-Off</span>
                        initValue 0
                        hidden 0
                        forceLimits <span style="color:rgb(255,0,0);">1</span>
                        min <span style="color:rgb(255,0,0);">0</span>
                        max <span style="color:rgb(255,0,0);">1</span>

                        trackingScale <span style="color:rgb(255,0,0);">1</span>
                        keys
                                {
                                static  0
                                k  0  0
                                }
                        interpStyleLocked 0
                        }
                }
        }

actor head
        {
        channels
                {

# Now we slave the channel who's slaving we want to disable to the
# master channel, using 'valueOpTimes'.

                targetGeom PBMCC_01
                        {
                        <span style="color:rgb(255,0,0);">valueOpTimes</span>
                                Figure
                                BODY
                                <span style="color:rgb(255,0,0);">On-Off</span>
                        }
                }
        }
}

NOTES:
What the 'valueOpTimes' operator does it to multiply the 'k' line value in the slave channel by the 'k' line value in the master channel. When the value in the master channel is zero, the slave channel will always be at an effective value of zero, irrespective of what value is set on its own dial, or of any slaving it has to any other other master channels. When the master channel is set at a value of one, the full effect of its own dial, and any other channels it is slaved to will be seen. In this case the "On-Off" channel has been limited to the value of either 1 or 0 by the use of 'forceLimits 1', 'min' and 'max' and the 'trackingScale'. Besides the normal 'valueOpDeltaAdd', and the 'valueOpMinus', and 'valueOpTimes' operators that we have seen in this post, there also exist 'valueOpPlus', 'valueOpDivideBy', and 'valueOpDivideInto' operators. The value operators that use division can cause divide by zero errors, so you should familiarize your self with how they work before experimenting with them.

For in-depth information on ERC, see "How to Write ERC Code" on VK's (a.k.a. atlantis23) site. He has downloadable tutorials on all aspects of ERC. For specific info on the different value operators, see "A different approach to ERC code" on VK's site.

I'll try to come up with something simple and useful for my next post.

**Animating off/on ('static').**You will be aware that both lights and cameras have an  "Animating" check-box in their Properties tab. The state of this check-box determines whether or not the item can be animated in a Poser animation. The "Animating" check box sets the 'static' switch in the channels of the item to either "0" = animating, or "1" = none-animating.

Every Poser channel, by default, contains a 'static' line in the 'keys' section of the channel.

                        keys
                                {
                                <span style="color:rgb(255,0,0);">static  0</span>
                                k  0  0
                                }

So although the Poser interface only provides a way to change this switch for lights and cameras, a pose file can set the 'static' status for any channel, in anything. OK, interesting, but what use is it? One use is in Walk Cycles, where we want the figure to walk either above or below the level of the Poser GROUND plain. First I'll show you the pz2 file, here it is:

{
//static 1-Bod y.pz2
version
        {
        number 4.03
        }

actor BODY
        {
        channels
                {
                translateY ytran
                        {
                        keys
                                {
                                static 1
                                }
                        }
                }
        }
}

The pose to turn 'static' off is the same as above, except it uses 'static 0'. Now load a Walk Path and run a Walk Cycle on a figure. In frame #1, yTran the body, then run the animation. The figure immediately drops back to the ground in frame #2. Now, in any frame of the animation apply the above pose file, and yTran the BODY. The figure (of more precisely the BODY actor) will maintain this altitude throughout the animation. You can adjust the yTran of the BODY in any frame and it will remain constant throughout the animation.

Of course there are other ways you could get the figure walking at different altitudes. You could use the Graph Editor, or parent the figure to an invisible prop. The parenting to prop method is particularly flexible, as it even allows the figure to walk upside-down, but for a quick, one click fix, 'static 1' can't be beat.

Note that you need to apply the correction to yTran after you have applied the Walk Cycle, and that applying another Walk Cycle will drop the figure to the ground again.

NOTES:
When 'static' is set on, Poser stores the value you set for the channel in the line 'staticValue' which will be created in the channel when you turn 'static' on. This value will be preserved in the current session, so if you turn static off, then turn it back on, the value will be used again. However if you save the scene with static turned off the 'staticValue' line will be stripped out of the file. This might be a good time to point out that the first number in the 'k' line of the 'keys' section is the frame number, 'k 0 ?' is the first frame of an animation, this is (rather confusingly) represented as Frame 1 in the Animation pallet, 'k 1 ?' is the second frame in the animation, 'k 24 ?' is the 25 frame in the animation, etc.

[bookmarking while slapping forehead]  
Gees! How'd I miss this one until NOW!?!?

Wonderful collection of work Les.  Thanks!

I'm still digesting all the cool technical info in this thread!

A question on ERC's - I see that ERC info can be stored in the FBM level.

Does that mean that I can take thios section out of the cr2, and make it into a PZ2, so that if I need to reload the morphs themselves, I can just inject the ERC info back in? Like in case of touching up morph geometry and then loading it back in (Via dimension3D's add morph tool).
This is asuming that the morph names didn't change.

Great thread! I'm very glad I found this (finally).

I'm trying to figure out how to set and pass variables between cr2 - pz2 and pz2 - pz2 files. Is it doable?

Well if you don't want to junk up your runtime with all your LARGE PZ3 files renamed and placed in the character or props directory, you can create prop shells that will load your PZ3's from outside the runtime. This also keeps your runtimes slim and trim instead of bloating them with PZ3 files renamed to CR2 or PP2.

Prop to Call PZ3

{
version
     {
     number 4.0
     }
     readScript ":Runtime:Libraries:Scenes:Room.pz3"
}

Outside runtime:

{
version
     {
     number 4.0
     }
     readScript "D:ScenesRoom.pz3"
}

Here's how I make PMD INJection pose files that load the morphs and group them all at once. First I make the Pose file that groups the dials:

Quote -
{
version
 {
 number 4
 } actor head:1
 {
 channels
  {
  groups
   {
   groupNode Transform
    {
    collapsed 1
    parmNode taper
    parmNode scale
    parmNode xScale
    parmNode yScale
    parmNode zScale
    parmNode yrot
    parmNode zrot
    parmNode xrot
    }
   groupNode Morph
    {
    groupNode Brows
     {
     collapsed 1
     parmNode RBrowDown
     parmNode LBrowDown
     parmNode RBrowUp
     parmNode LBrowUp
     parmNode Worry Right
     parmNode Worry Left
     }
    groupNode Eyes
     {
     collapsed 1
     parmNode Blink Right
     parmNode Blink Left
     parmNode Eyes Natural
     }
    groupNode Head
     {
     collapsed 1
     parmNode Jaw Slim
     parmNode Chin Slim
     }
    groupNode MatrixWorkz
     {
     groupNode Ears
      {
      collapsed 1
      parmNode Ears Out
      parmNode Ears Up
      parmNode Ears Orc
      parmNode Ear Lobes Low
      parmNode Elf Ears
      }
     groupNode Brow Expressions
      {
             collapsed 1
      parmNode Brow Fierce
      parmNode Brow Furrow
      }
     groupNode Cheeks
      {
      collapsed 1
      parmNode Cheeks Out
      parmNode Chin Weak
      parmNode Dimple Cheek
      }
     groupNode Face Shaping
      {
             collapsed 1
      parmNode Chin Square
      parmNode Cleft Chin
      parmNode Head Chubby
      parmNode Head Slim
      parmNode Jaw Narrow
      parmNode Nose Narrow
      }
     }
    groupNode Mouth
     {
     collapsed 1
     groupNode Lips
      {
             collapsed 1
      parmNode OpenLips
      parmNode Lips 1
      parmNode Lips 2
      parmNode Lips Fuller
      }
     groupNode Phonemes
      {
      collapsed 1
      parmNode Mouth F
      parmNode Tongue L
      parmNode Mouth M
      parmNode Mouth O
      parmNode Tongue T
      }
     parmNode Frown
     parmNode Raise Mouth
     parmNode Smile 1
     parmNode Smile 2
     parmNode Snarl left
     parmNode Snarl right
     }
    groupNode Nose
     {
     collapsed 1
     parmNode Nose Beaked
     parmNode Nose Slim
     parmNode Nose Wide
     }
    }
   }
}

Then I make the Pose that loads the morphs and calls the dial group pose:

Quote -
{
version
{
number 4
}
injectPMDFileMorphs :runtime:!MatrixWorkz:Centaur:MWCentaur.pmd
readScript runtime:!MatrixWorkz:Centaur:HeadDials.pz2 }
 

@Conniekat8

Quote - I'm still digesting all the cool technical info in this thread!

A question on ERC's - I see that ERC info can be stored in the FBM level.

Does that mean that I can take this section out of the cr2, and make it into a PZ2, so that if I need to reload the morphs themselves, I can just inject the ERC info back in? Like in case of touching up morph geometry and then loading it back in (Via dimension3D's add morph tool).
This is asuming that the morph names didn't change.

I've been off line for some months, and only just saw this post today. I'm not sure I understand exactly what you mean when you say "this section".

An FBM has two parts, a master valueParm (FBM) channel in the BODY actor, and the various individual targetGeom (morph) channels in various body parts that are slaved to the master. If you are using a figure that has spair targetGeom and valueParm channels, such as the DAZ figures that have the PBMCC channels, you can inject any content you like into these channels at any time by using an appropriate pz2. You can inject a diffrent set of deltas (deltas=the morph itself), diffrent dial settings, diffrent limits, add slaving code to a channel, what ever you like. So yes, can store any or all the content of targetGeom and valueParm channels outside of the cr2, in pz2 files.

In the case where spair targetGeom or valueParm channels don't exist in the cr2, the situation is more complicated. In P6 and above you can use "createFullBodyMorph" in a pz2 to create a new valueParm channel. You could then add a normal pose section to to change any of the values in the valueParm channel if necessary. You can add new targetGeom channels with a PMD file called from the pz2. See the tutorial at Nerd3D for details on PMD files. You could also use a python script to create the new targetGeom channels, but it may need to be a two step process, as I'm not sure you can inject new deltas or other date from the same pz2 that calls the python script to create the channel.

@Tiny

Quote - I'm trying to figure out how to set and pass variables between cr2 - pz2 and pz2 - pz2 files. Is it doable?

Sorry I don't know how to do that.

Geometry InjectionInjection new geometry into props.

A cm2 (Camera) file can be used to inject new geometry into a prop. A pz2 can also be used, but in that case there must be a figure in the scene. Given that restriction, it's usually best to use a cm2 so the file will work even if no figure is in the scene. Here is an example of a cm2 file that will replace the geometry of a Poser box primitive item with the geometry from a Poser cone primitive. Load a box primitive and apply the pose. The box must be named "box_1", that is to say it must be the first instance of the box prop loaded in the scene. Note that the box is addressed as "actor" not "prop".

{
//box2cone.cm2
version
        {
        number 3.0
        }
actor box_1
        {
        storageOffset 0 0.3487 0
        objFileGeom 0 0 :Runtime:Geometries:props:cone.obj
        }
}

Instead of the 'objFileGeom' statement, we can also use a 'geomCustom' statement so that the geometry is carried within the cm2 file itself, instead of having to reference an external obj file. The file below loads a square geometry into the box_1 prop. { //box2square.cm2 version { number 3.0 } actor box_1 { geomCustom { numbVerts 8 numbTVerts 4 numbTSets 8 numbElems 2 numbSets 8 v -0.050000 0.000000 0.000000 v 0.050000 0.000000 0.000000 v 0.050000 0.100000 0.000000 v -0.050000 0.100000 0.000000 v -0.050000 0.000000 0.000000 v 0.050000 0.000000 0.000000 v 0.050000 0.100000 0.000000 v -0.050000 0.100000 0.000000 vt 0.000000 0.000000 vt 0.000000 1.000000 vt 1.000000 0.000000 vt 1.000000 1.000000 usemtl Preview s 0 g square f 1/1 2/3 3/4 4/2 f 8/2 7/4 6/3 5/1 } } }

Welcome back on the Interwebz, Les. It hasn't been the same without you. :-) 

Is there a way to unclutter the body part selection pull-down with a .pz2 by for instance hiding the fingers and toes and maybe eyes from that list but not disabling them from selection by tool?

I have not figured out DAZ Studio but I sure like the schematic interface for posing body parts indirectly... it is a drawing of a humaniod figure and basic posing can be done by mousing over that rather than with tools in the preview window. I also loved that old Poser 5 script that created a GUI that was similar to the old Poser 2 interface... I REALLY liked the Poser 2 interface over the subsequent ones... less "artsy" and very easy to use while occupying very little screen space. The script GUI was incomplete but I used it with Poser 5 for years. Funny how the script interface and script library alternatives work better than the Poser UI. Really I am commited to Poser vs. d/s but wow I don't love the GUI. Tools like V4 Xara and UMM and Pose Magic and Bagginsbill's shader controler make so much more sense... it is just too bad they have to be done with control props and sometimes confusing pose files instead of being wired into the GUI!

Yes, there is.

This pose will hide the hip of the current figure from all dropdowns, but you can still select using the Hierarchy Editor or clicking in the document window:

{<br></br>
version<br></br>
    {<br></br>
    number 6<br></br>
    }<br></br>
actor hip<br></br>
    {<br></br>
    hidden 1<br></br>
    }<br></br>
}<br></br>

And "hidden 0" will bring the actor back on the menu, of course.

As you can see, I did not include a number in the pose file. Don't need one in this case, it'll just work on the selected figure.

Simple. Thank you.

One small correction to what svdl said. If you apply that pose you will NOT be able to select the hip by clicking with the mouse in the document window. Once some other body part has been  selected, the only way to select the hip will be via the Hierarchy Editor. When the hip is selected (is the active element) you will be able to manipulate it as normal with the mouse, but as soon as you select some other part you are back to needing to use the Hierarchy Editor to select the hip. At least that's the way it works for me.

Right-clicking in the document window works - in Poser 7. Haven't tested P6 or earlier.

Thanks for all the info!

Bookmarked.

Botheration!

Why didn't I find this thread 6 months ago? It would have saved me so much time.

...mumble grumble...

But thank you lesbentley, svdl and all for some great tips.

This is an absolutely AWESOME thread! WHY isn't that stickied a long time ago?!

bookmarked

Great stuff, thanks.

Attached Link: http://artcomp1.tripod .com

Bookmarked

Excellent resource.  Thanks lesbently.

great thread

Ping.  Thought I would resurect a wonderful thread.

there's probably an easier way to do this but i have found this to be helpful. let's say ur building a scene or an animation and you want to add another pose to a character from the pose library, but ur character has moved. when u add the pose he moves back to the zero position and rotation.  when u move your characers to make a new scene i find it is a good idea to move everything to a new keyframe. then when u give a character a new pose just go to his hip and press the arrow to get the different hip prameters. Encircle with the cursor any hip parameters u want to keep from the first frame (probably xtran, ytran, and ztran (maybe y rotate) and drag them to your new keyframe and the position of your character will be restored with the new pose.

Regarding the last post, can someone point out the part of the pose file to remove in order to stop a pose from moving the figure as cmcc described when the pose is applied?  It would seem that the pose must have some explicit or relative transition information for x, y and z which is being applied and could be deleted from the file to leave the character where it is while applying the pose.

I would like to know this so I can edit some unruly poses.

Klebnor

Bump. This needs to be revisited.

You can use a pose file to run a Python script:

{
    version
    {
        number 6
    }

    runPythonScript ":runtime:pathscript.py"
}

And you can combine this with all other pz2 tricks.

runPythonScriptEx apparently allows you to pass an argument to the script: runPythonScriptEx "runtime:path:to:script.py"myargument

where in the script, sys.argv[1] == 'myargument'

Mmm, yeah it's a good thread Boni. A lot of really useful stuff in there, one of the strong points of Poser's file system is all of the deep user magic tricks that are possible.

This thread is also is also very good, it's a little more singular goal focused though.

http://www.renderosity.com/mod/forumpro/?thread_id=2810484