Heya, I'm letting my CPU cool down from a long bout of Max, so I thought I'd post some observations I've made over the months on building conformers (clothing, generally) I build all of my conformers using the basic concepts in Bloodsong's Painlessly Easy Conforming Clothing tutorial which I'm sure is reproduced in her book, but I still haven't gotten one. nudge I take some extra steps, though. Section A) Building the base conformer: I never start with an existing clothing item, and always use the base figure now. ALWAYS turn off IK when loading a figure to make a BC. Follow Bloodsong's steps in her tut. Also make sure the figure's hip isn't moved at all before you memorise. It's usually a good idea to 'restore figure' before you do anything, because that turns off all the k settings the CR2 loaded with. That can fix the hip being offset unless the person who made the CR2 set the initial K as the static. Along with all morph channels and inkyChains, I always strip out all occurences of inkyParent and nonInkyParent. I always remove the second figureResFile line, because it's completely unnecessary. Remove the geomChan and alternateGeom stuff from the hip, if present, and the genital actor altogether unless you mean to build a conforming condom or posable show pouch at some point. Actually, the latter you can do with only a bodyHandle anyway. Remove the stupid tab before the setGeomHandlerOffset at the bottom of the file. Poser puts that in and the indent is improper. Just because Poser wrot ethefile doesn't mean it is perfectly formed B^) Sometimes I will replace all tabs with 8 spaces, just because I hate tabs. But that's me. All of this will give you a very clean BC file to start from. Save it and keep it holy. Section B) Making specific conformers form the BC Okay, Bloodsong's tut says to plug in the figureResFile and go. Well, sure, but that can leave you a bigger CR2 than you need, and worse, a lot of channels (that use memory in Poser) that you don't want. So here's some stuff to do... Think of your figure as working from the hip OUT. So the hip is the middle and everythign is steps away from it. This is how Poser thinks of it. You need the hip, and you need everything between the hip and up to and including your geometry. You need actors one past your geometry. You do not need anything past that. NOTE that means if you have gloves, you need all the way to the finger3 parts. AND you need the neck but NOT the head. Why the neck? Because it's one past the chest. If you're doing one glove to package with sparkly socks and a mutilated nose morph, you need the Collar of the opposite side, too. Without it things will not fit because your endpoints will work out wrong and not balance. You do NOT need any body parts more than one off. If you have no hip geometry, you do not need anything on the other side of the hip. A halter top does not need buttocks or thighs. A boot does not need an abdomen. HOWEVER, a pair of trousers which DOES have hip geometry DOES need an abdomen. To avoid confusion with any of bloodsong's terminology, from here on in, JP affectors means the twisty, jointx, and stuff like that (these appear right before the rot channels), while child JP affectors will mean things like lShldr_twistx (these appear higher up near where morph dials go and above the zOffsetA stuff. Now, the trick is, once you have removed all these other, nonexistant actors, you still have several actors that can be cleaned up and cut the channels. First off, remove the geometry handlers in the declaration blocks (the first instance ofthe actor block near the top). So if your shirt ends at lForeArm and there's no geometry for lHand,the lHand declaration should look like:

actor lHand:2
        {
        }

That's it. Next, remove the affectors in those parts. Each actor's affectors affect only IT, not any other actor. That means, usingthe example above, your lHand actor shold have all the twistx_lForearm channels, smoothScale_lForeArm channels, and twistx channels removed. Each of those channels uses up memory in Poser. Clear out channels that aren't needed. NEVER remove the rotation channels or the Offset channels. Good idea to leave in the trans channels too, even though you can't see them except for the hip. I usually DO remove the scale channels and taper channel, because it's silly to scale something with no geometry. If you do this, you can also remove the smoothScale channel from the actor they join to/are parented by. If you don't, you can theoretically use the scaling and tapering as a way to slightly alter the parent actor, but an MT is better for that because it's more exact. Do NOT remove the affector channels form any actor that HAS geometry. You need that stuff. Of course once you load up your conformer and set the materials, Poser will put the silly tab before setGeomHandlerOffset back and will add the stupid other figureResFile line, but you can always clean these back up afterwards. Actually, I usually save it to another CR2 and rip out the parts it added and stick them in my original copy. Same with adding MTs.

Thanks for the tips on conformers, I haven't got into making conformers yet, but it's on my list of things to do. I have a rather diffrent philosophy on tabs and spaces, I find that a library file that uses spaces comes out signnificantly bigger, for example the default Posette weighs in at abuut 1,587KB on a diet of tabs, but if you let her eat spaces she's 2,247KB, thats a diffrence of 660KB, much too fat in my opinion. P.S. Any of you conforming experts know why Posette will not conform properly to Posette, even zeroed and with the inkyChain's removed?

I've tried the Bloodsong base conformer method more than once, but it hasn't worked for me yet. Maybe I should print this topic and try, try again. I could do without having to mangle clothing CR2s each time. Thanks for the info.

diet of tabs Hmm, haven't seen Tab for sale in ages B^) (Urr, if it wasn't in the UK Tab was a diet cola from the 70s and early 80s that I think is gone the way of the Dodo now. It didn't have a non-diet version, like Fresca (a diet grapefruit soft drink that is still around) EB, you should look at her book! (and then buy it B^) even zeroed and with the inkyChain's removed Did you memorize her after zeroing? Make sure the hip isn't transed? Etc? Check your BC CR2 to make sure the static, k, and initValues are all 0. You're right aboutthe tabs taking less space thing. Though the difference is like 128 bytes once it's ZIPped B^)

EB, you should look at her book! (and then buy it B^) You're right, I should... While you're making observations, what exactly does memorizing do? I've only ever come across it in this context, but I have no idea what it actually does.

Sets the current key to be the static.

Should eludicate despite the headache... Setting the static sets where a figure goes when you 'Restore Figure' - and it affects how it conforms.

Ooh... light bulb comes on over head Thanks. I hope your head stops throbbing soon. Looks as if mine is just about to start.

Thanks Dodger, I went throught the file and zeroed all the initValues (and having missread your advice) the staticValues, that seemed to fix it. I will also set the "static" to zero, now my eyes are working straight. What is the relation between initValue and staticValue? It seems like one sets the other but I never worked out which way the controls flowes, I am guessing that "static" is a switch to either lock one of these peramiters, or to lock the update from one to the other.

I hope your head stops throbbing soon. Looks as if mine is just about to start Turn off that lightbulb, it's hell on theeyes L From what I can understand: initValue is the value it loads up with. If there is no k 1, initValue is the value it has. static is the value that 'Restore Figure' resets it to (most CR2 have the same values for both) the k values are the values set for frames, where k 1 is the first frame, k 2 is the second frame, and so on. These frames are offset by the curently selected frame when a pose is loaded, but not, as far as I know, when a CR2 is loaded (i.e., a CR2 can have a full animation pose in it, but will load as if frame 1 was currently selected, while a pose applied will apply the pose as if k 1 were actually k 1+currentFrame-1, if that makes sense. Al of these values defer to limits if limits are on, and forceLimits 1 (or 4, silly as that is, or 2 or 3, anything over 0 and possibly under 0 though I haven't tested if Poser considers -1 to be true), will make limits be on whether the user intends it or not.

Dodger,I was not entirly convinced by your answer, a "normal" channel does not have a 'staticValue' and so must restore to the 'initValue'. The 'initValue' is not the value on load up, in "normal" channels the load value is the second number in the first keys line. I have just found that this is not necessarily so for some of the hidden channels, but channels never seem to get their load value from initValue, in any circumstaces, even if the keys block is entirly missing. I decided to do some experiments to see wether 'staticValue' was the value actually restored to in the channels that have this line, rather than the initValue as in "normal" channels. The answer appears to be no. Initial setup:

                yOffsetA originY
                        {
                        name GetStringRes(1028,45)
                        initValue 0.111
                        hidden 0
                        forceLimits 0
                        min -100000
                        max 100000
                        trackingScale 0.004
                        keys
                                {
                                static  1
                                k  0  0
                                }
                        interpStyleLocked 0
                        staticValue 0.222
                        }
        origin 0 -0.333 0 

The file was loaded into Poser 4, and the OrigenY dial changed to 0.444, then file saved to pallet. The channel now looks like this; yOffsetA originY { name GetStringRes(1028,45) initValue -0.333 hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 0.004 keys { static 1 k 0 0 } interpStyleLocked 0 staticValue 0.444 } origin 0 0.444 0

Now a Restore>Element is done. The OrigenY dial now reads '-0.333'. Conclusion: The value restored is the one in 'initValue', NOT the one in staticValue! So the question is still open. What is the function of 'staticValue' and 'static'?

The initValue of the yOffsetA channel seems to inherit its number from the 'origin 0 -0.333 0' line (near the bottom of the block), probably as soon as the file loads. This is new to me as pose channels, targetGeom, and valueParm, never seem to change their initValue except by Memorize. The staticValue seems to inherit the number entered on the dial, though wether directly or not I don't know, it might get it via the origin line, this seems likely to me. Perhaps strangest of all the k value for yOffsetA in a saved file always seems to be zero.

Oh, I was takling only about static not staticValue Though I don't know that these are the best channels to be working with, as xOffsetX channels are Joint Parametres which 'restore' and 'memorize' don't seem to have an effect on. Might be better to test with actual dial channels instead.

Sorry Dodger, I seem to have misunderstood what you were saying.

unless i've misunderstood the technique described, i don't believe that references to all the actors between the hip and those actually used in the conforming piece(s) are necessary. i've made numerous conforming items that included only the BODY, and the parent of the first actor and the child of the last actor, and even the parent & child might not be (always?) necessary. i've already made a pair of mid-calf sandals that include only the BODY, shin, foot and toe actors. referencing the thigh was not necessary. my conforming armband included only the BODY, collar, shoulder & forearm, and my conforming bracelet included only the shoulder, forearm & hand.

what's probably happening is that the parts of the conformer that fall within the blend zones of either parent or child of the respective actors in the base figure must reference those actors. since the shin part of the sandals falls well within the green 100% zone, outside the thigh/shin blend zone, no reference to the thigh is needed.

i don't believe that references to all the actors between the hip and those actually used in the conforming piece(s) are necessary In this case, 'necessary' is a matter of degree. I've done both, and I always get better conforming when I use the same root and work all the way out from it than when I root it as its first part or it's imaginary parent part. So while a conformer will work, I've had much better luck avoiding mesh breakage, etc, with things done the root-to-one-past-extremity method.

As far as my experience goes, the channel parameters are: - "initValue": The initial value of the channel. The channel is set to initValue, when you use an "Edit > Restore" menu command, or when you option/alt click the dial name/dial slider. By default, initValue is 0. To store a new initValue for a dial in Poser, you set the dial to the new value, and choose menu "Edit > Memorize > Element". Poser copies the actual dial value to the initValue parameter. - "static" and "staticValue" define, whether a channel is animatable or not. An animatable channel has "static 0" (off), and the staticValue is omitted or ignored. A non-animatable channel has "static 1" (on), and the actual channel value is stored in the staticValue line. By default, the deformer channels (trans, rot, MTs, etc.) are animatable (so static=0 and no staticValue). The "offset" channels are non-animatable (thus static=1 and staticValue available). You can make any channel static (non-animatable), but you can't make an offset channel animatable. The "geomChan" channel (sets alternate geometries) can be static or not. In the Poser 4 skeleton figure, the hand shapes are animatable, so the geomChan has static=0. In the "P4 Nude Man" figure, the geomChan (chooses the hip geometry) is static, because it is set by the "Genitals" menu, and shouldn't be animatable. - "k" lines: The keyframe data stores the key index, and the actual channel value (if the channel is animatable). The key index is a base zero index (like the delta index of a MT), it starts with 0 for the first frame. Line "k 0 1.2" means, the channel value in the first frame is 1.2. More frames add more "k" lines. When a channel is static=1 (non-animatable), the channel value (dial setting) is stored in "staticValue", and existing "k" lines are ignored (but not removed). When a channel is static=0 (animatable), the channel value is stored in the "k" lines, and an existing staticValue is removed (IIRC). - The "offset" channels are very special. When a library or document loads, Poser copies the origin coordinates to the three "offsetA" channels (first block of offset channels), and the inverse (negative value) of the origin to the "offsetB" channels (second block of offset channels). The offsetBs are the exact inverse of the offsetAs, so "0" becomes "-0". Poser uses the channels as templates to store the origin data, so the channel values are always replaced by the respective origin data at runtime. The offset channels are only required, if the object needs a defined rotation center (for rotate & scale channels). The offset channels are always static, i.e. the origin coordinate is stored in the staticValue (and initValue) parameter. Unfortunately, the offset channels behave not very consistent: Changes of the origin data in the Joint Editor are stored in the "origin" parameter and the staticValues of the offset channels. But when the Joint Editor is open, you can make the offsetA channels visible in the dial palette, and set the channel values. However, changing dial values aren't correctly updated. Since the offset channels are always static, the origin data is not animatable. Some of my models need dynamic rotation centers, so I searched for a method to create animatable origins. I found out that every Poser object has two (static) origins by default. Obviously, Poser uses the offset channels to create its own origin. Thus, you can add a second set of rotation/scale channels, to rotate/scale about two different centers. And since Poser uses channels to create the origin, you can write ERC-code to modify the origin dynamically. The code adds a dial, for example "xCenter", so you can set the x coordinate of the origin. The basic version of the code needs 2 channels for one dimension, more complex variants need 4 channels per dimension (plus one optional master channel).