Here is something that might be usefull to people who make conforming clothing. I'm not sure if this is a new discovery or if I am reinventing the wheel, but I have not heard of this before.

This is a way to load a conformer and have channels within it automaticly slaved to any figure that already exists in the Poser document, further the conformer will not suffer crosstalk with any other figure in the document. In other words this is targeted crosstalk between two figures only. This method works for me in Poser 4 and 5, I do not have Poser6, so I can't test that.

The method:

1. The internal names of the master and slave channels should be diffrent. I'm not sure if this first point is necessary, but it's the way I did it, and I can't be bothered to check if it works when the names are the same.

2. An actor (body part), any actor, of the figure that is to act as a master must be selected before the conformer is loaded. Note, it is not sufficent to select a figure from the dropdown menu, an actor must be selected.

3. The slaving code in the conformer must NOT contain any figure number (eg 'Figure 3') or actor number (eg 'hip:3'). Here is an example of the syntax I use for the slaving code:

                  valueOpDeltaAdd<br></br>                             _NO_FIG_<br></br>                            chest<br></br>                               Morph<br></br>                       deltaAddDelta 1.000000

What seems to happen is that Poser will update the slaving code when the conformer is loaded to match the figure and actor number of the of the figure that was selected before the conformer was loaded. Thus if the figure selected when the conformer is loaded is the fifth figure loaded, then the above slaving code will be updated to:

                 valueOpDeltaAdd<br></br>                             Figure 5<br></br>                            chest:5<br></br>                             Morph<br></br>                       deltaAddDelta 1.000000

Although in this example both the master and slave channels are targetGeom (morph) channels, almost any channel types may be used.

The upshot of of coding the conformer in this way is that if you have a breast morph in the conformer and you want it to follow a breast morph in a particular character in your scene, then all you have to do is select a body part of that character before loading the conformer, it does not matter if you have 10 identical (or diffrent) characters in the scene, just select the one you intend to conform to and when the conformer is loaded and conformed it will crosstalk with that character, and that character only.

This method can also be used with joint controled morphs (JCM). If you have a JCM in the characters shoulder named Bulge slaved to 'yrot' (Bend) in the characters ForeArm, you can slave a corrisponding morph in the conformer's shoulder to the Bulge morph, or you could slave it 'yrot' in the characters ForeArm. This works fine in P5, but note that in P4, whilst the conformer will behave correctly without unwanted crosstalk, if you load two character figures with the same JCM, the characters will crosstalk (unless you use a NULL Figure or some other method).

What this method is in escence is a way to set the figure and actor number of the slaving code in a figure that you are loading so that it matches the figure and actor number in some figure that already exists in the open Poser document. The consequence of this correct asssignment of numbers is is that the new figuer will crosstalk with its intended master and no other figures.

I have had some correspondence with Nerd and it looks like I have reinvented the wheel, the code I use is virtually identical to that which Nerd uses in in his Super Conforming figures, the diffrence is that I use 'NO_FIG' and Nerd uses 'conformingTarget' in the Figure line, the essential point is that we both leave the numbers out of the code. From what Nerd said I get the impression that it may be necessary to use 'conformingTarget' in P6. Ah well, there goes my big chance for 15 minutes of fame, at least in 2005.

There's still 2006 to look forward to. ;)

Is Super Conforming figures a script?

No, it's a way of making conforming clothes so that they automatically follow morph settings in the figure (where possible). The technology is in the CR2.

Attached Link: http://www.nerd3d.com/modules.php?name=Content&pa=showpage&pid=12

" *Is Super Conforming figures a script?*" No, see attached link for definition.

I tried with NO_FIGURE, and that also works. Even in multiple character scenes. Seems like you'll have to name a non-existing figure to have it work. BTW, this is in P6. Works in P5 too.

svdl, thanks for confirming that this works in P6.

Attached Link: http://www.hogsoft.com

" " Is Super Conforming figures a script?" No, see attached link for definition. "

Agreed, No. But Hogsoft has a free utility (PC only as it runs outside of Poser) called Crosstalker that will do the work for you on-the-fly during posing. Select the character after determining its figure number, load the clothing via Crosstalker and use the generated version with the right figure number.

Crosstalker is free because Jim Burton, not Howard invented the technique - or rather re-invented it it would seem, somewhere between Charles and Les ;-)

Crosstalker has the corollary built in too, you can use it to stop crosstalk on a clothing item when you don't want to.

Render mostly nudes? Crosstalker is still very useful - extending the technique for stopping clothes interacting with a character, and you can prevent 2 characters from interacting / crosstalking too. Note this doesn't cover Daz Inj/Rem figures - for that you need FII. Later for that one... and not free. (Hey, the man's got to eat ;-)

And best of all Crosstalker uses Hogsoft's P4PyE (Poser 4 Python Emulation) so you can have Crosstalker work in Poser 4 as well as Poser ProPack / P5 / P6.

I've been told repeatedly that the JCMs in The Girls conforming Catsuit only work in P4 because it requires the cross talk only found in P4.
If I read this thread right it sound like you may have found a way to make it work in P5 and maybe P6 to. Woooot!

Attached Link: http://www.renderosity.com/messages.ez?ForumID=12413&Form.ShowMessage=2583804

Just a follow up to my prior post - FII, Figure Independent Injection - support is now available in PBooost 2 as an optional plug-in. And it is free with the product, even the upgrade, for a limited time. See Hogsoft's recent post in Product Showcase. FII means that you can inject morphs for all Mil3 figures in a scene, not just the first one loaded. And all without crosstalk-like symptoms.

And hate to bust the bubble on the original entry (further, that is), but my experiments showed pretty clearly that no matter what you put in place of it; "Figure 1" would be inserted by Poser the next time you saved and re-opened. That in a nutshell is the biggest problem with practically all crosstalk solutions; they work great while you have the scene open, but if you ever decide to save it then re-open it, everything goes haywire.

Have you tried putting Null figures between each base figure (not the clothes) while you create it? This usually forces Poser to go through the same steps during the reload. It seems as if the Null breaks the "chain" of figures, and forces Poser to treat each figure almost independently.

Re post #12: Nomuse, you are right on some points, but seem to be mistaken in your conclusion. First let me clear up a point of semantics and posible confusion here. By "actor number" I mean the number that follows the colon in the actor name (:#). There can be multiple "figure numbers" in a poser file. There is the figure number that (sometimes) occurs in the occurs in the 'name' line of the 'figure' section (eg "Figure 3"), this is also the name/number that will be displayed in the dropdown Figures List. There are also the "figure numbers" that occur in slaving code, theoreticly there can be many diffrent "figure numbers" in a figures slaving code, but in a pz3 the "figure number" should match the actor number in the slaving code block, so if "hip:3" then "Figure 3". These "figure numbers" in the slaving code need not match, and have no direct causal relation the figure number in the 'figure' section.

---

Now after that diversion, back to conformers. When you load conformers as in my post #1, and save the scene to a pz3, a "Figure #" line will have been inserted in the slaving code for each conformer. The number will not necessarily be "1". In fact the number will be the actor number of the figure that the conformer is conformed to. Thus the "figure numbers" in the slaving code of the conformers will be the correct numbers to slave them to their respective characters. In other words when you use the method of post #1 you can save a pz3 with figures and multiple conformers, and when you reopen the pz3 (scene file) all the slaving will still be in operation. Also after using the method, you can save a character and its associated conformer to a pallet, load multiple instaqnces of the cr2, save a pz3 (scene), exit Poser, restart Poser, relode the pz3. The targeted slaving will still work for all conformers! About the only thing you can't do is save the conformer to a pallet without its associated character figure, this will break the slaving, and turn it back into a normal conformer. I have now done quite extensive testing of this method in P4 and P5, it has not failed yet, even with 6 characters and 6 conformers in the scene, and multiple save and reload to/from pz3. - - - - - -

In the above graphic, made in P4, the character figure has a breast morph "Morph1m", the conformer has an (amost) matching breast morph "Morph1s". The morph in the confromer (Morph1s) points to the morph in the character (Morph1m). The conformere were constructed and loaded as per post #1. The scene was saved to a pz3, Poser was closed and restarted, the pz3 was loaded. The breast morph in each conformer responds correctly to a change in the breast morph of the character. This targeted slaving works, and without any unwanted crosstalk. I anyone still doubts this I urge you to try the method exactly as described in Post 31. It does work! - - - - - -

Re post #13: Layingback, one of the strengths of this method is that NULL Figures are NOT needed! Though of course it does nothing to fix character to character crosstalk in P4, it only works between conformer and character. Whilst Jim Burton's method is a great discovery, and certainly has its uses, as it can be applied in the Poser interface as an after the fact fix, it does suffer certain draw backs. One of these is that if a channel has bore than one mlock of slaving code, the fix will only work on the last block, I assume that this limitation also applies to Hogsoft's utility, as you say it is based on jims method. I refer you to posts 5 and 6 of Jim's thread at Poser Pros. For this reason, and others, I concidder the method in this thread as more universal. Though it must be applied in the making (or modification) of the conformer, where as Jim's method can be applied to preexisting conformers without the need to edit the conformer itself. Thus jim's method is good is good for distribution to people who already own a conformer, where as the above mrethod is the best (IMHO) when constructing a new conformer.

I'll have to read this again more carefully, perhaps embark on another series of tests. I am suspicious, however -- I discovered several things that appeared to work but on examination proved to be co-incidental. Unfortunately there seems to be no way to "look inside" Poser when it is running and see what it is actually using for relationships between figures. All we can really tell is what Poser writes to a saved scene. My experiments proved to my satisfaction that; A) Poser will always assign the figure number (aka Figure 1, Figure 2, et al) in the order in which figures are read into the scene. Thus, you can force the order if you carefully edit a PZ3 (making sure the figure you want as Figure 1 is indeed the first figure to appear in the PZ3). B) Poser will look for the first occurance of the donor channels; I believe it looks first to see if any previously loaded figure with the correct actor number appears (aka hip:2 stuff), however, I can not confirm this. I do know that given any excuse Poser will "hunt" and find whatever occurance matches. In either case, the actor number on the donor entry (aka the "figure 2, hip:2" stuff will ALL be edited by Poser to match whatever channel it decided was meant to be the donor. In view of these findings, I can state with reasonable certainty that I can make a scene containing a given master-slave relationship that can be reliably opened and saved multiple times without "breaking" the behavior. I can also state with the same degree of certainty that I CAN "break" this scene by deleting a figure then adding a new one to the scene. Until and unless we can control the end-user's desire and ability to edit the scene, we can not proffer any crosstalk solution as panacea. This is, however, all in P4. I have not determined how P5 or P6 operates differently. I would be interested in a clear discussion of exactly what Curious did to "fix" the crosstalk issue.

Quote: "In view of these findings, I can state with reasonable certainty that I can make a scene containing a given master-slave relationship that can be reliably opened and saved multiple times without "breaking" the behavior. I can also state with the same degree of certainty that I CAN "break" this scene by deleting a figure then adding a new one to the scene. Until and unless we can control the end-user's desire and ability to edit the scene, we can not proffer any crosstalk solution as panacea." In the above, do you mean make a scene in poser, or make a scene then edit the pz3?

Attached Link: Conf.zip

Nomuse, the reason I asked the question in my last post is that if you think you have a sure fire sequence of adding and deleting figures that can break the scene I would like to try it out. Just tell me what order to add and delete the characters and conformers, and I'll give it a go.

I have tried loading 3 characters, then 3 conformers, deleting the middle character and conformer, then loading a new character and conformer, then saving and relaoding the pz3. This did not break the slaving in any of the conformers, but it's always posible that there is some sequence of loading and deleting that will break it. So I you think you know a sequence that will break it, I'm keen to try it out!

I am also attaching a link with the character and conformer I used in my experiments. Note that the morph in the conformer slaves directly to the morph in the character. The character you want to conform to MUST be selected before the conformer is loaded. The morph in the character is slaved to a FBM in the body, but you should NOT use the FBM in P4, use the morph in the characters chest. In P5 you can use the FBM. They are P4 figures, so you should have the geometry on disk.

Message edited on: 03/01/2006 20:13

Quote: "I would be interested in a clear discussion of exactly what Curious did to "fix" the crosstalk issue." As far as I know crosstalk occurs because P4 fails to update the actor and figure number correctly in the slaving code blocks when an item is loaded, and as far as I know P5 fixes this by updating these numbers correctly. I am not absolutly certain of this, but that's how is looks to me.

Mm. I think a better wording might be that P4 tries once to follow the actor relationship described in the ERC slave channels. If it fails, it will "hunt" for matching channels in any other figure. If it fails there, it will delete the ERC slave channels completely. I am still confused about what P5 does. Does it perhaps fail promptly, and not go on a search through the scene for a potential matching channel? I hear different reports. Some people tell me two figures with FBMs can now be loaded into a scene without crosstalk. Others tell me the figures WILL crosstalk, even in P5. The one thing I am certain of is that tracking down ERC problems is a pain in the neck. I've gotten really, really tired of loading test scenes, having them fail in strange ways, loading new scenes, crashing Poser, etc.

nomuse, Is it possible your "confusion" is because there is more than 1 form of "crosstalk" - or at least more than 1 set of symptoms? (Although I believe that there is at least 2 separate code issues at play). Crosstalk of the "classic" variety was defined by CL as a "bug" and fixed in P5. But Mil3 figures with their readscript based injection suffer exactly the same symptoms at the UI in their FBMs as the "classic" crosstalk. But in this case it is caused by the readscript process. This variety of crosstalk is still present in P5 & 6. The only way to "fix" it that I know of is the FII (Figure Independent Injection) changes to the readscript Delta files. FII support is now available as a plug-in to PBooost, but Stephanie Max is developed with FII built-in, if you want to experiment. SMax was developed by Migal, and is/was a free download from Netherwork's site, but requires Daz Stephanie (1). But there is always JCM Calf Injection morph for V3 from Migal's new site, which was the proof-of-concept for FII. (Migal by the way first noted the "propter" prop-named-as-actor trick at PoserPros as an aside to the FII discourse threads, as he developed it for SMax.) Further potential user confusion follows from application of FII in P4/PP which triggers the "classic" crosstalk on the reload following a save in P4/PP - unless Nulls are employed at creation time. But note that opening such a saved file in P5/6 will work, no "classic" crosstalk present. Ergo "classic" crosstalk and readscript induced crosstalk are different at the code level. (I suspect the readscript variant is due to readscript development predating the multi-figure/multi-figure number implementation in Poser - and just got missed in the update, intentionally or accidentally, because when used as designed readscript never needed to worry about figure numbers at all as by design it only ever loaded a figure into a virgin scene.)

Let us avoid confusion. "Crosstalk" is any communication -- desired or undesired -- between figures in a Poser scene. The above discussion, however, was entirely on the behavior of ERC channels; a very specific set of code originally developed for full-body morphs. ReadScript and Python-aided methods had not been previously discussed in this thread (nor was the "built-in" slaving code that Poser uses for the "grasp" channel in hands). In original P4, one "good" crosstalk is that a conforming clothing item could "see" the master FBM dials in the figure, and thus take on the same morphs. Unfortunately, this same communication meant if you loaded two figures with FBM, both would take on the same morphs. I am told P5 does not replicate the latter behavior. I am told, however, that P5 does replicate the former behavior. This sounds very suspicious to me. Also, I have ERC-controlled rotations in one of my products, and gallery evidence that these rotations are not being used by at least one P5 user. I will have to commit to more tests but I am willing to believe that in the ordinary circumstance P5 slave channels NEVER point "out" of the figure they are contained in. Hence, the development of ERC injection poses by Jim Burton and others; these do not edit the "broken" ERC channels, but they add to the scene a new channel with a user-desired relationship. In reference to "breaking" a P4 ERC relationship, it is as simple as this. Load two figures containing a master dial -- say, FBM "Superhero." To the second figure, conform a clothing item containing ERC slave channels. It will follow the morph in that second figure. Save the pz3. Close. Re-load. When the scene is reloaded, the ERC in the clothing will still point at the second figure. Well and good. Delete the second figure. Save, close, reload again. Regardless of whether you conform or not, the clothing's slave dials will now point at the first figure (since there is no longer a "figure 2, BODY:2" Poser will hunt until it finds a matching "Superhero" dial in "figure 1, BODY:1" I admit, this particular scenario is not itself a problem. But it shows the basic problem -- load order is paramount. If your scene has been edited in any way, you can never quit Poser without causing unexpected behavior the next time you open the scene. By the by, to reach the above pronouncement took two weeks, loading somewhere close to a hundred scene. My method was to document every number and relationship in a scene, load it, document what behavior was in the scene, save, inspect the pz3 in a text editor to see what numbers had changed, restart Poser and load the scene again, rinse and repeat. As part of that experimentation I tried null figures, I tried conforming or not conforming, selecting before loading and not selecting before loading, inserting null or special characters in place of "figure N" or "BODY:N", even deleting some of these lines completely. You must take this kind of care; Poser is just random enough that it is entirely possible to "discover" that the file works perfectly if one only adds "I am a wombat" at the top of the pz3. It takes a great many tests to determine that your result was merely co-incidental, and Poser works just as well (or badly) without that phrase. I do not mean to dump on any discovery. As a clothes maker and prop rigger I would love to have control over the ERC relationships in a scene. I am all for any experimentation that leads to that result. I am just suspicious of easy results, having gone down this path far too many times before.

I was rasing the non-ERC aspect 'cos it does generally cause confusion. I was not trying to confuse, nor underestimate the amount of research that you've done. > But it shows the basic problem -- load order is paramount. On this we agree! > I am told P5 does not replicate the latter behavior. ["bad" crosstalk between similar figures] Agreed. > I am told, however, that P5 does replicate the former behavior. ["good" cloth to figure crosstalk] This sounds very suspicious to me. Only for simple clothing, it does not work, leastways for me, for clothing using ERC ("super-conforming" clothing). But I do agree that if it did work for ERC clothing it would be strange ;-)

Well...I can make one simple test. Some of my own stuff has conformal channels (in the interest of creating even more confusion, "Conformal" is what I called a technique of ERC-controlled rotations -- for instance, I linked the body handles on a skirt to both buttock and thigh on the base figure). In any case, is a quick matter to see if these operate in my own copy of P5.

As far as my experience goes crosstalk is fixed in P5 period! Try loading multiple instances of Posette in P5, the SuperHero FBM will NOT crosstalk. Again I must make a point of semantics, and admit to contributing to the confusion. Crosstalk is by definition unwanted interference between channels, thus my use of "Targeted Crosstalk" in the title of this thread was missleading and technically incorrect. It should have been "Targeted Slaving". In my defence I can only plead that I thought this would be understood by a wider audience. So in the correct sense of the terms P5 does fix crosstalk.

---

Code injection is another matter, again in the correct sense of the terms crosstalk is fixed in P5. However we must look at which figure, actor, and channel the injected slaving code is targeting, this may not be the figure that contains the slaving code, and this may be interprited by some as "crosstalk" (a bug), when in fact it is "targeted slaving", ie the slaving code is targeting the figure, actor, and channel that it says it is targeting, usually but not necessarily "someActor:1". Perhaps I am saying more than I can conclusively prove here, but this is how it looks from my experience. In regards to injection, try this experimrnt in P4 or P5. In Posette, delete all the data from the channels that are slaved to "valueParm SuperHero", but leave the empty channels themselves. Save this as "Test.cr2". Construct a delta injectoion pz2 from the original Posette, but edit the slaving code to target an actor number of "3": valueOpDeltaAdd Figure 3 BODY:3 SuperHero deltaAddDelta 1.000000

Save this pz2 as "Figure 3.pz2". Load 3 or more instances of "Test.cr2" in Poser 4 or 5 (probably works in P6 as well). Apply the "Figure 3.pz2" to all the figures. They will all respond to the "valueParm SuperHero" channel in figure 3. This is not crosstalk (in the correct sense), it is targeted slaving. The slave channels are slaved to the figure that the injected slaving code tells them to be slaved to! Note that in this instance I am not talking about what happens if you delete figures and save and reload files. That is a seperate issue, and in this instance I suspect quite likley to break the slaving. The point is that in this type of injection where Figure and actor numbers are injected the slaving does what it says on the tin. In this case it slaves to a figure with an actor number of ":3". As to what exactly will happen if an actor number of ":3" does not exist in the scene, and if this is the same in all versions of Poser, I leave it to others to discover, I am too old, and life is too short! Note that there is another type of targeted slaving, where the currently selected figure will be the target, and that is described in post #1. Last point. In this discussion, we must make a clear distinction between slaving code that is loaded, and slaving that is injected, as there may be diffrent results in each case.

P.S. I would like to acknowledge that both Maveris and Jagger, were seminal to my belated "discovery" of the method, and to much of my understanding of these issues. Particularly this thread by Maveris, in which most of the ideas are either explicit or implicit.

I was not aware that Migal had come up with the "propter" idea.

This sounds like a useful variant of the "ERC injection" poses. I am, by the by, perfectly satisfied that you or I can get a scene working the way we want it to. What makes me cry, as a Poser content provider, is being unable to keep another end-user from getting themselves into a tangle. I may be in a bad mood today anyhow -- I've finally figured out how to properly pose a microphone cable on a mic stand (or any similar wiring setup) but I just can't see it as being a plausible method for the average user. (Just to drag this thread thoroughly off-topic, it involves pre-posing an easy-pose cable, exporting the obj, bringing it back in, then running a cloth sim that uses only the strip of guide polygons I built into the cable as a dynamic element. The result; a cable that is wrapped around, sags between wraps, lies on the floor at the free end, and doesn't "deflate" from the sim.)

Les, Having researched it, Migal's discovery was similar, close, but no cigar. His was related to making MATs work on a prop by changing the type to actor. Same means, different ends. Here's his post from PoserPros: PostPosted: Fri Mar 05, 2004 4:18 am Post subject: Add User to Ignore List Reply with quote Just as an aside... You can do MATS for unparented props, if you first refer to the prop as an actor in the pz2, like this: actor Sphere_1 { }

Attached Link: Poses for Props - a tip!

Layingback, As I remember it, I was the first to publish this method of poses for unparented props (which is diffrent from Proptors). But the method was entirley based on a discovery of Migal's. I just extrapolated it to props. Above is my original thread.

Re post #21: Nomuse, Let me point out that post #1 is a method to allow you to load a conformer and have its morphs (or other channels) slaved to any figure in the scene. It is not, and does not clame to be a method to allow you to change which figure the conformer is slaved to once it is loaded. With this in mind, I tried your "breaking" method. 1. loaded two instances of a figure with an FBM (same figure as in my zip). 2. Loaded and conformed Leotard (same figure as in my zip) to figure 2. 3. Saved pz3, closed Poser 4, reopened Poser 4, reloaded pz3. All well and good, slaving still working. 5. Deleted figure 2, Saved, closed, and reloaded pz3 again. Results: The breast morph in the character has no effect on the conformer, even with various "nudges" such as moving the camera, or selecting and moving the chest of the conformer. On examining the pz3 we see why. The slaving code has been stripped out of the conformer at or before save time! Conclusion: This did not break anything! the conformer was suposed to be slaved to figure 2, but as figure 2 nolonger exists this is not possible. Poser obligingly stripped out the slaving code, thus removing the possibility of it slaving to the wrong figure. Even if this "breaking" had "worked" I feel it is rather a big ask to expect that the conformer should be slaved to a character that does not exist in the document. I would concidder breaking to be something that caused the conformer nolonger to be slaved to its associated character, when both the conformer and character still exist in the scene, but other figures have been added and/of deleted, and saves/reloads to/from pz3 have taken place. Quote: Regardless of whether you conform or not, the clothing's slave dials will now point at the first figure (since there is no longer a "figure 2, BODY:2" Poser will hunt until it finds a matching "Superhero" dial in "figure 1, BODY:1" If you say this happens with a normal conformer, I have no reason to doubt your word, but it does not seem to mappen with the method described in post #1, inconjunction with your procedure from post #21.

I finally got P6. After having done the tests, I can confirm that the method and syntax from post #1 workes perfectly in P6. In post #2 there was some question as to wether "NO_FIG" would work in P6, it definatly does! Now the only question is to wether everything still works in P7. I see no reason why it should not, but you will have to confirm that for your selves, as I don't plan on upgrading to P7 any time soon.