Renderosity Forums / Poser - OFFICIAL
Welcome to the Poser - OFFICIAL Forum
Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 26 1:43 pm)
Subject: Open letter to DAZ Developers
Hi Maveris. I tried your your crosstalk solution in Poser 4.0.3.126, using 2 instances of Posette (P4 Nude Woman.cr2). In these circumstances it did nothing to prevent crosstalk in the SuperHero FBM. That's not to say it doesn't work for a V3 and M3 combination (I don't have V3 or M3, so can't check that), or in another Poser version. On the other hand If the root of the problem really is the figure number (:#) I don't see why it should not work for Posette.
From what I understand of the "Crosstalk" issue... it also has a great deal to do with the PBM's and FBM's and the way they are named as well. I truly wish there was a "simple" fix to the cross talk issue without having to force the consumer to edit files or reload a "null" figure. Just my 2 cents... Lee
Maveris, I too tried your solution - at least I think I did - in ProPack and Poser 5. In both cases the crosstalk-like symptoms were still present. FBM dials only worked on the first figure loaded not the second one, and the next time I adjusted any dial on the second figure that figure became a duplicate of the first. What I did: Edited Victoria 3 sr1.cr (the Base character) and BreastGone and BreastSize8 Inj and Unhide .pz2 files in !Daz folder to remove all instances of ":1" replacing them with nothing. Then I loaded 2 copies of the modified V3 Base character, and injected BreastSize8 and BreastCone into both figures. Regardless of the order I did this, I got the crosstalk-like effects described above. I repeated in Poser 5 - which doesn't suffer from the normal crosstalk, with the same result. So did I implement it correctly? Was there another step that you did beyond this? I sure would like to make this work, as I've been chasing this for a while, and had already tried every combination of :0, :2, unique names, etc, that I could think of. I'm prepared to believe that entering no :1 at all could well force the Poser code into new areas with interesting results, but in my case at least, removing the :1's had no descerible effect whatsoever. Thanks,
Again, I'm speaking somewhat out of my domain, so don't take my words as anything but the rattlings of a freak:) But, I do believe that V3 required it to be the first character loaded in order to benefit from the injection system. Perhaps this must be done after you inject and save your figure? eric
Content Advisory! This message contains nudity
Mav, Yes, I believe so. There are no :1's in Pose!V3 Chest-Breast INJBreastGone.pz2 (there never were) or !DazVictoria 3DeltasInjDeltas.PBMBreastGone.pz2 or !DazVictoria 3ChanVisUnhide.PBMBreastGone.pz2. Just checked each file again. Then I load V3 (base) twice, then I inject BreastGone into both. Then selected Figure 2 (the second V3 loaded) Body but twisting the BreastGone FBM dial has no effect. Same dial on Figure 1 works on the first loaded V3, and if I then touch any dial on second V3 crosstalks to that one too. Re your point on editing only the Inj and Unhide files (vs. the .cr2 file) that is what I had expected to find - when/if I could get it working on my system. Grrh! Gotta run now, will try again but probably not until after the weekend. Thanks for your help.
Using Poer 4.0.3.126 on a PC. Wow! It does seem to work. My first experiment was to strip the figure numbers out of Pesette, load two instances of the figure and see if the native SuperHero FBM still crosstalked, they did :( My next experiment was with a simple cube figure. I made an FBM, striped the figure numbers out of the cr2, then made a delta injection pose by cuting the morph channel out of the cr2 and placing it in an appropriate pz2, leaving just an empty targetGeom in the cr2. When the delta injection pose was applied to multiple instances of my figure the FBM worked fine without any crosstalk :) What's more, further experiments sugest that it is not necessary to strip the figure numbers out of the cr2, IT IS SUFFICENT TO STRIP THEM OUT OF THE PZ2! Maveris, it seems that what you have here is a major discovery. I must stress that I was applying the pz2 manualy not using readScript, but I would expect the same results using readScript. So why does this work when injecting a morph channel, but not when the complete morph channel is already present in the cr2? It is perhaps a bit early to make definitave statements on any of this, I think a lot of investigation still needs to happen before we have this nailed down, but my guess is this, and all of what follows is just assumption: When a cr2 that has been striped of figure numbers is loaded Poser adds figure numbers to all the relivent parts, and the important part for an FBM is the slaving code
valueOpDeltaAdd
Figure 1
BODY:1
MasterChannelName
deltaAddDelta 1.000000
Even if the figure numbers have been striped out of the slaving code I suspect that Poser adds them back when the figure is loaded. My guess is that when a morph channel is injected Poser does NOT add figure numbers unless they already exist in the pose file. As to why slaving code with figure numbers causes crosstalk, and slaving code without them does not, I'm at a loss for any explination.
Hi lesbentley, You're right, after a few experiments I notice that only the INJ file make the problem. I also think that the problem is the readscript call... I think that Poser make only a copy of PZ2 of file as is... So if poser read "Figure 1" in the INJ file (and "Figure 1" exists in the scene) it write "Figure 1"... And cause cross talk :(. But if the INJ file haven't refereces to a specific Figure number... Poser assign the value of the figure selected and avoid cross talk. About why cr2 that have already morphs inside don't work... I investigate... And hope to find a solution. Many tanks for your time, Mav :)
"Many tanks for your time, Mav :)" It's me who should be thanking you, you have made what may be the most important crosstalk discovery since the NULL Figure. Well you seem to be right, I made a delta injection pose with the figure number "2", loaded 3 instances of the figure, then applied the pose to figures 1, 2, and 3 in sequence, the morphs in figures 1 and 3 were the ones suffering crosstalk, locking at the value set in figure 2. I did another experiment setting the figure number in the pose file at 9, this time none of the three figures suffered from crosstalk (because there was no figure 9 in the document). So it seems to be as simple as that, the crosstalked figures are reading their values from the master channel in the figure with the figure number that the pose file TELLS them to read it from. This also sugests the reason that crosstalk occurs at all, IT'S A BUG IN POSER. Poser does not update the figure number in slaving code correctly. At first it seemed that poser did not update the number in the slaving code at all, but after a few more experiments I found instances working with multiple figures in the doc where the code was updated, but with the WRONG FIGURE NUMBER! Phew, nothing is ever simple in poser.
I'm thinking that when Poser normally executes the readscript it sees the figure number :1 and assigns the FBM to Figure 1 (regardless as to the current figure's number). Because if you switch the figure in figure 1 the new fiigure gets the FBM from the readscript so it's not the first figure loaded that receives it, but the figure occupying the :1 slot - ergo it is interpreting the number. But the readscript code is old enough (Poser 3) to not do the correct analysis of the figure # to see if it really does point to the current figure (which I'm guessing was added in Poser 4 along with all the ERC, etc). However perhaps if no figure number is present at all, as in Maveris' BIG discovery, it has to determine an actual figure number in order to be able to proceed and thus gets the right figure number for the current figure. Why would this code be there in readscript when the ERC relate number stuff wasn't? This code to compute a missing figure number would have been needed for legacy purposes back when Poser first started accepting multiple figures - which I suspect preceded Poser 3 and readscript - Poser 2? - to handle figures saved under earlier releases without a figure number. Thus this piece of code would have been included with readscript when it was developed. Just a theory. ;-) Now if I can just get it to work...
Re post 19: To expand a bit on what Poser (I'm talking Poser 4) does with figure numbers, here is what i did: I edited a cr2 with a figure number of "1" so that the figure number in the slaving code was "900". I loaded 3 instances of this figure, then saved them back to the pallet with the names 1, 2, and 3. On examining them in a text editor 1.cr2 had a fgure number of 1 throughout. 2.cr2 had a figure number of 2, except in the slaving code which still had a figure number of 1. 3.cr2 had a figure number of 3, except in the slaving code which had a figure number of 2. 2 can you beleave that!?!
My last post was posted before I saw les' last post - but I think we're consistent in our assertions. You may well be right about crosstalk being a bug - that might also explain why it was one of the few legacy things fixed in Poser 5 it is was just a simple coding error. But either way, "the Maveris solution" causes Poser to execute different code which has the performance attributes that we desire - YEA!!! "It's me who should be thanking you," No. Everyone should be thanking Maveris - and undoubtedly will sooner or later! That still leaves the question of mixing injection and non-injection figures in same scene, but I assume a judicious mix of Null and 'the Maveris solution' should do the trick? Now - any ideas on how to stop scaling from crosstalking? LOL Anyhoo, what are you going to call this discovery Maveris? I think you should get the privilege of naming it.
Mav, I have it working! Les' code segment showed up my stupid error :-( I'd global changed the :1 but missed the Figure 1 line as I'd mis-read as Figure :1. Duh! So it works! For me too :-O Actually I think the only files that needs changing are the DelatsInj ones, no? All the others just affect the parameter dials, which always seemed to show up, and disappear correctly before, so why change them now? If so it'll be a relatively simple edit - and small files at that, so any editor can cope. And this is such a big boost for Daz, I wonder if they'll do an update for V3 and M3 to include?
Hi, The bad news is... When you save the scene (with my solution) Poser write right Figures and actors references (I see inside pz3 file)... But when you load the file Poser have a cross-talk again :( The good news is... layingback you are RIGHT!!! the solution is a mix with Null figure. I think that Poser read the pz3 file in top down method, so make an error and reassign the value of Figure. You need to use the Null figure between your character. Mav :) P.S. In my experiments if I use the Null figure only the dials of the injections don't work.
Very nice work here, Mav.
LB, see? I knew if I just took long enough to finish, someone else would figure it out! LOL!
Just a couple questions:
Mav, when you say, "if I use the Null figure only the dials of the injections don't work," I'm a bit confused. Is this when loading a saved pz3?
Does this method kill conforming clothing morph-chasing?
Works in P4 and P5?
Migal, procrastinate, procrastinate, yada, yada ;-) OTOH, that excuse has now vaporized :-O Mav is just referring to using Null the old way, without TMS. BTW, still no name for your method yet Mav? How about FII - Figure-Independent Injection? Mav, The need for Nulls in order to re-open a saved file makes sense. In the same way that Rob W's original Null tutorial states that you need Nulls between each figure for crosstalk prevention to last through a scene save and reload, you'll need it here in Poser 4/Pro Pack. This is to prevent the old-style crosstalk (not the ERC version covered by TMS/FII). Reason is, I assume, that in both cases (FII and Null crosstalk) we're utilizing the order of figure loading to avoid symtoms of crosstalk - in effect tricking Poser into behaving. In a re-load of an existing scene we no longer have that ability, Poser will just load the way it wants, by Figure, and 'old-style' crosstalk prevails. I plan to test P5 today, but my hunch is that it will work fine there - and not need the Nulls to prevent crosstalk after save/load of course. But even if we need Nulls between figures in P4/PP we're still way ahead. We'd have needed Nulls anyway using say V2, and now we can use smaller lighter Injected characters like V3 in exactly the same way. Good deal. I wonder if there is a way to fix a saved .pz3 using FII in which you forgot the Nulls? I guess not, without a lot of hand editing... lb
OK, tested in Slow Poser (Poser 5) and it works just like it does in Poser 4/ProPack, except you do not need Nulls as Slow Poser has no crosstalk capability. So you can save and reload and the injected morphs still work as FBMs without problem. Which answers my own question from the last post. I guess if you mess up and forget to put Nulls in in Poser 4/ProPack and you discover that you need to edit later, you'll just have to open in Poser 5 for further editing rather than Poser 4.
Did a few last experiments. And I can confirm that the only code that needs to be altered is the lines indicated by Mav and les back on #16 & #17. That is for each .pz2 file that starts with "InjDelta." in the !DAZVictoria 3Deltas folder, change each instance (there will be several per file) of code such as: valueOpDeltaAdd Figure 1 chest:1 to valueOpDeltaAdd Figure chest (obviously "chest" could be "abdomen", "BODY", etc.) That's all that needs changing. The orginal .cr2 is fine, and the other various Hide., Unhide., etc. files in the !DAZ folder don't contain any valueOpDeltaAdd code so can be left untouched. The above is for Victoria 3; Michael 3 or other Injected charcter files may differ, but the concent remains the same. Legal disclaimer stuff: Your mileage may differ, no posters to this thread are responsible for damage done to your Daz models, your PC or your sanity should you attempt to do this. Consider making a backup copy of your !Daz folder before attempting any edits. Yada, yada, you know the drill.
Attached Link: http://www.renderosity.com/messages.ez?ForumID=10139&Form.ShowMessage=1438921
OK, figured out how to edit the 400+ files for V3. Might still have been quicker to do by hand, but at least this way any of you that are interested can do it too :-)But as this was getting a little techie, not to mention lost back here in post 181 on a slow server day/week, I posted it in the Poser Technical Forum.
Link to the new post is above.
lb
I think I followed this, but I want to understand the final outcome: Maveris mentioned that if the scene is saved, and then re-loaded, that Poser (*?) has the crosstalk problem again. But then he mentioned that adding Null figure between each would avoid the crosstalk. I thought that Null figure by itself avoided crosstalk, in which case I don't understand how Maveris discovery helps? Next question, suppose I am using Poser 5. Under what conditions would this technique be helpful? Or is it only an issue with Poser 4s crosstalk bug? Hmm. this makes me wonder something else. Is the cross-talk only because the figures have the same name? I mean, if I had two identical figures, that had been edited so they had different names, would that help avoid crosstalk? What I'm really wondering here is whether there is some utility / Python script that would help with this whole mess. Something like: every time you want a duplicate of a figure, the utility copies it, but changes whatever it needs to change, so that Poser won't treat it as a clone - instead will treat it as a whole new, unique, figure.
ADDENDUM: for super-conforming clothes, if I understand them correctly - I haven't made any yet - the utility would also have to make a modified copy of the clothing, which uses the new figure name for all its channel references. Another idea: suppose there was a magic utility that could make whatever changes you wanted to a copy of a cloth cr2. I've seen repeated mention here and there of Poser 5's crosstalk-fix making some variant of ERC no longer possible. I'm wondering if this fact could be worked around by having the right external utility, that did edits to a cr2 file that would be too tedious to do by hand? Ok, now I know its time for me to go to bed, but one last random neuron firing: Suppose there was a utility that MERGED a human figure and a set of clothes into a single CR2. And maybe a single OBJ - I haven't thought this through yet. The idea here is to avoid the need to "conform" one figure to another: make the clothing part of the figure, as if it were one of the built-in clothed figures. (Even though the clothing originally comes separately -- I'm talking about an add-on utility to Poser that merges them together.) Would such an approach have any advantages? I did one experiment where such a merger (that I did by hand) seemed promising - in getting a long dress to respond properly to thigh and shin rotations. Not as good as the morphs some cloth-makers provide these days for sitting, etc - but it was an interesting "cheap" approach.
The point of Figure Independent Injection is that it solves two problems at once: It allows more than just the first figure in a scene to be injected (unlike stock V3/M3/Freak) and it simultaneously defeats crosstalk, without null figures.
However, if a scene using more than two figures is saved as a pz3 (Poser Scene) file, crosstalk will exist upon reload unless there are nulls between the figures. So it might be a good idea to use nulls with FII, especially if your Poser is prone to crashing.
The primary drawback of an FII figure is that it is incapable of crosstalk unless saved as a pz3. This doesn't matter if the scene is going to be naked people. But, it means clothing morphs cannot chase a base figure's morphs, because that is an aspect of crosstalk. And since M3's love muscle is a conformer, like a clothing item, it will not follow M3's FBM's if M3 is converted to FII. This does not mean a clothing model's (or love muscle's) morphs will be disabled. They will still work. They just won't work automatically in Poser 4/PP. They'll need to be set to match, manually, which shouldn't bother P5 users because P5 doesn't crosstalk, anyway.
This might be an improvement, I've got to do some more checking, but my first try shows when I loaded thus: Loaded figure 1 Loaded figure 2, conformed to figure 1 Loaded figure 3 Loaded figure 4, conformed to figure 3 I got the results: Figure 1 took "1", as expected, slave channels are also all 1 Figure 2 took "2", slave channels are all set to 1, correct cross talk Figure 3 took "3", slave channels are all set to 1 (in other words, to bad cross talk) Figure 4 took 4, slave channels are all set to 3, correct cross talk. Where when I used a normal figure with the body number :1 and Figure 1 the difference was the last figure slaved from 1, instead of 3. So, what I'm seeing is an improvement, but as the second figure is still crosslinked to the first, no solution. The main difference is now figure 4's morphs are slaved to figure 3, rather than figure 1, which is correct, but as figure 3 is still slaved to 1 there is still "bad" crosstalk. Incidently, if you run the FBM on 3 nothing happens to 3 (as 1 is controlling them) but 4 responds to them! This is in Poser 4, BTW. Actually, I'm suprized it makes any difference. ;-)
I'd like to see two versions of injection figures, FII and regular. But, that's a lot to include in any package. And we'll find out soon enough if any of it matters in DAZ Studio. I heard rumors of selective crosstalk and memory management that would make injection unnecessary.
You wouldn't know anything about those rumors, would you, Jim-the-DAZ-merchant? :-)
Bit out of step here - entered a long reply yesterday, but 'Rosity took a powder just as I clicked Post :-( Short version: M3's LM doesn't really need to conform, it loads into the correct position to just Parent to M3's Hip. ToolmakerSteve's idea for a Magic Utility is do-able, but problem is the acceptance for a stand alongside utility will be small, and a Python controlled one limits you to just ProPack which is a small market (Poser 5 version would be unecessary/different). Plus, I would expect Studio to have a work-around, given that it Daz's figures which have this problem. Migal's idea of FII and non-FII is a viable one, but it won't come from !Daz, esp. if Studio does have a workaround... Can be done by user by simply editing the readscript calls to a new directory structure in a separate copy of the CR2's. Perhaps if enough PBoost users want FII, then maybe instead we can persuade Howard to add !Daz folder to the swap-able list in the product, then you'd swap out the FII !Daz folder for the standard one, and vice-versa.
I intend to do both, LB.
Yeah, M3's LM can be treated like a prop. The problem with the thing is that it has matching morphs for certain FBMs, because those FBMs change the shape/position of M3's hip actor. Without chasing or manually matching dials, you end up with the LM detached or embedded in some cases.
There has to be a song in there somewhere.
TMS,
Slight misunderstanding. This thread does not make a hypothesis that stripping figure numbers out of cr2 files or regular pose files helps crosstalk or much of anything. Instead, it stipulates that stripping the figure numbers out of the ERC "magic lines" section of a delta injection file called with readscript will solve two problems: 1. It will allow multiple figures in a single scene to be injected. 2. The resulting injected morphs do not suffer crosstalk between figures.
I posted a freebie at PoserPros today that is an example of this thread's theory functiong exactly as explained.
Privacy Notice
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
Hi, First of all sorry for my poor english. I hope you can understand this post. I really appreciate the DAZ figures (high quality at low price) so please don't misunderstand: this is not an attack to DAZ Developers. Cross talking is my problem and I think that many users have this problem. I read all about it (I think) and I really say Thank you to Rob Whisenant and Charles Taylor for the informations. I appreciate the evolution of the Millenium figure (Inject morphs system) but I have the same problem: I can't handle the full body morph in a scene that have V3 and M3. After few experiment (I'll try to use the Null figure without solution) I think that I discover a very simple and plain solution: The main problem are the declarations of the figures and the deltas headers, for example you have "Figure 1", "actor BODY:1", "actor head:1" and so on... Poser keep an index when you load a figure... :1 for the first figure, :2 for the second, etc. So I make a little experiment: I delete all the reference from the cr2 (figure) and the pz2 files (Inj, Rem, hide and unhide)... So a declaration like: . . . actor rShin:1 { channels { targetGeom PBMAnkleSpandex { name AnkleSpandex interpStyleLocked 0 valueOpDeltaAdd Figure 1 BODY:1 PBMAnkleSpandex deltaAddDelta 1.000000 valueOpDeltaAdd Figure 1 BODY:1 PBMSpandex deltaAddDelta 1.000000 indexes 124 numbDeltas 815 deltas { . . . is saved as . . . actor rShin { channels { targetGeom PBMAnkleSpandex { name AnkleSpandex interpStyleLocked 0 valueOpDeltaAdd Figure BODY PBMAnkleSpandex deltaAddDelta 1.000000 valueOpDeltaAdd Figure BODY PBMSpandex deltaAddDelta 1.000000 indexes 124 numbDeltas 815 deltas { . . . With this modification (files without specific number reference) you don't have cross-talk because Poser assign the right number to the right figure. I don't know if this is the only solution... or if this solution is the best solution. It's also totally possible that the DAZ method is correct and that I'm deadly wrong... But please, if you think that this work, made an upgrade for us. (I don't think that is impossible... Simply replace "Figure 1" with "Figure", "actor BODY:1" with "actor BODY", etc.). Sincerely, Mav :)