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

This whole topic has been discussed many times here, but it's actually easier to follow the discussions over at PoserPros where Jim Burton has discussed it in his forums, and devised the method for conforming clothes to figures which have crosstalk disabled.

The definitive method was documented by Jim Burton a few months back, and Hogsoft automated it, for PC users, with a freebie called Crosstalker. As the name sort of indicates, Crosstalker will not only defeat crosstalk in P4 and PP, it will also enable crosstalk in P5 and P6. Same utility, same UI whichever way you use it. Check it out at www.hogsoft.com. (For Mac users I believe only the Python script automation route will work, a couple of people developed such scripts, but I don't know if they are all OSX compatible (i.e. don't use tkinter).

Note that in P4/PP you'll still want to include Nulls between characters if you plan to save and later reload the .pz3. The crosstalk will come back on the reload, presumably because you can no longer control the figure loading order. The workaround for this, should you forget, and end up with a crosstalk'ed .pz3, is to open the .pz3 in P5 or P6.

Note that none of the above addresses the looks-like-crosstalk effect that occurs with multiple injected figures in a scene. This type of crosstalk is caused by the readscript routine used for Daz-style injection. FII - Figure Independent Injection discovered by Maveris, which also requires removal of figure numbers but this time from the injection files, is required for this. No known automated solution exists for this as yet, but Hogsoft is working on one (I have an alpha test version).

It would be good if Larry W would look at Poser's handling of next-available-figure-number for later versions of Poser, and allow user selection of figure number handling to allow advanced control over the reuslting "crosstalk" effects. Alas the .pmd files employed in P6 looks as if they may be going in a different direction entirely - one were Poser saviours like Howard of Hogsoft can't go to help us out with Poser's functional limitations/challenges.

And heed Anton's warning about figure deletes, Poser's numbering scheme goes a little strange (understatement) if you delete something other than the last loaded figure. Some parts of Poser will still continue to use the next available figure number, some will use the now-free lower number, and some appear to use the now-free lower number but actually store the figure in the original next available figure number slot!

"Figure number less" or FII (Figure Indendent Injection) has the advantage that more than 1 injected figure can be injected in the same scene. I.e. it gets around the readscript limitation of injection only working on the first figure loaded in a scene. A big advantage if you use Mill3 figures. Only extra step (besides removing the Figure #'s of course ;-) is having to select the target figure before the injection pose is applied. But that's not a hard habit - nor a bad one - to get into. A set of tools to handle all of this for you is under development - I have them in alpha test form - but unfortunately release has had to wait due to more pressing updates.

Re Jim Burton's and Netherworks comments - I feel that I should point out that the revised way of making ERC work in P5 & P6 is also backwards compatible with P4/PPP.

It is an old bug from P5. With P5 CL made the Parameter Dial window a separate process. That's fine on MacOS (under which Poser is still developed?), but on Windows it adds oodles to the overhead. Thus what you are seeing with the "dial randomizer" is overshoot. This was improved in Poser 5 SR 4.1 (but not the initial SR 4). The original Poser 6 release was better still, but SR 1 took it back to the level of about Poser 5 SR3 IMHO. CL/EF (as against MetaCreations) have a reputation for never ever fixing bugs release to release (ie. beyond the final SR for a given release), and I also fear that this one is likely to be classified as a "design choice" anyway. So I think we are SOL. Shame, 'cos it means that Poser 4/PP is still the choice for posing on Windows! (Hopefully OSX can handle inter-task switching as efficiently as intra-task switching - something that no Windows OS ever hope to achieve.) The price we pay - along with memory management - for a old cross-platform development methodology.

Attached Link: http://209.92.41.204/Poser/index.html

One thing about SR1 versus original Poser 6, which I've not seen anyone else report, is a reversion back to Poser 5 response times in the UI. On my system Poser 5, original through SR4, was almost unusable due to huge lag, over- and undershoot when adjusting any dial, etc. Bad with just 1 figure,intolerable with 2 or more. SR4.1 finally improved this to where Poser 5 was at least usable. Origianl Poser 6 had this almost fixed. It was not as smooth as Poser 4 or ProPack, but was definitely Ok. But Poser 6 SR1 has reverted back to Poser 5 SR4.1 response in this area - or worse. Worse in that in addition to slow response, sometimes the parameter dials will not move at all, without clicking on something else first, waiting, clicking back on the dial, etc. I don't know how they could do this much damage in a 0.1 SR revision but... Also has anyone else noticed that Poser 6 (original and SR1) do not stack mouse clicks any more? In all previous versions of Poser you could click ahead on slow actions, eg. loading a figure, and each action would be serviced in turn. Not on Poser 6 - it seems to clean the mouse click queue after each command execution for some strange reason. And could they not have fixed the re-display of the parameter dial window after a Daz V3/M3 injection in SR1? Having to move the camera to get the new morph dials to appear gets old fast. (They didn't leave this in to negatively differentiate Daz products by any chance did they?)

Attached Link: http://www.wired.com/news/mac/0,2125,67749,00.html?tw=wn_tophead_4

The more things change the more they remain the same.

Actually MacOS was converted to x86 Wintel platform twice. Once (at least) internally to Apple but never released beyond the porting group, and once by a 3rd party - around the time of the let's-have-Mac-clones, uh-oh, let's-not-says-Jobs debacle. Said 3rd party effort was purchased by Apple PDQ, and the software banished to the Cupertino vaults. These were both true ports, not VM on add-in board solutions. Reportedly both ran very well.

But where does it say that OSX will run on an x86 "Wintel" platform? I couldn't find it. Merely substituting an Intel chip for a PowerPC chip in a Mac hardware platform does nothing for nobody, except presumably Apple's bottom-line. No way is the Intel a better microprocessor design than the PowerPC (or even the AMD 64-bit chip), it's not even close. It's an old and out-dated base design, and has been for years. Not decrying Intel's ability to crank speed out of that design, but its continued existency has much more to do with Micro$oft, near-monopolies and market inertia, than intrinsic merit.

Sorry, now see that you said that in your first post. But I think that was the issue, but I can't remember how I got around it. Is your expanded zip file on a different volume to the poser installation directory? If so try moving it to the same volume?

Vague recollection of having this problem years ago. I think it's a problem with ProPack not being able to find the directory. Try to take any option to specify the install directory for yourself rather than letting ProPack search for it. I think that was how I got around it....

bagoas, Yes indeed Poser has always scanned for the correct file, but never moves or reports it! To (find and) fix it you'll need Correct Reference or Correct Reference Pro. momodot, Poser - all versions - opens every file in the library currently attached when it (Poser) is initially loaded. (Why? Don't know, but it probably made sense under very early OS's, think MacOS < v5, and Win 3.1.) I think this is what people mean by "scanning." So the bigger the initial library the slower the boot time.

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

This simple utility will let you enable or disable crosstalk as you wish without any editing or preparation of your files. All the editing is done on-the-fly for you by the utility. Why do you want to enable and disable Crosstalk? Well it all depends on which version of Poser you are using, and whether crosstalk helps or hinders you in a particular scene.

It is very simple to use. And you get the very useful Hogsoft hub free too.

[ Full disclosure, I'm a beta tester for Howard, and I was involved in the development of the P4PyE technology which allows this to work with P4. But as Crosstalker is free I shouldn't be falling foul of the TOS. ]

Bend_Over, the library handle went behind the other windows in P5 too, they couldn't fix it then. But in P5 beta SR2.1 Larry W brought out the 'click anywhere outside of the library palette' feature, which had the effect of closing the library - without having to find that recalcetrant handle.

But that seems to have been broken in P6 - perhaps they could at least fix that ... if they haven't already. I've been off-'Net for a week due to a move, so not had chance to get P6 SR1 yet. Edited to fix stupid typo

Message edited on: 05/26/2005 00:40

Yep! You got it. :-) That's why the Inj appear to work fine for the head, and fail for the body. There's nothing wrong - or at least nothing that can't be worked around - with the system. But Daz' fixation on "Figure 1" will not allow them to implement Inj in the most generalised method. That means the real fix is straightforward - even trivial if you have an editor capable of recursion/global editing - but onerous if you have to edit each and every by hand.

"Due to this small size there is a loss of precission of the textures" My guess is that the reduction process causes each new reduced-scale pixel to be logically OR'd (averaged) from a number of surrounding pixels. The large size reduction would mean this was a significant number of pixels per sample. So near the edge of the texture the OR process will include in a number of pixels from outside of the true texture area. If these extra pixels are a totally different colour - eg. white - the pixels around the edge will have an (increasing) amount of the incorrect colour - white - blended in. Hence the apperance of a gap in the seam, but reality a dilution of the colouring. If texture makers would darken the area surrounding the outline, this effect would probably not be so noticable.