Sun, Dec 1, 8:40 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 29 7:57 am)



Subject: Multiple Mikes Problem


JosephH ( ) posted Sat, 01 December 2001 at 11:36 PM · edited Sun, 01 December 2024 at 6:24 PM

When I load two different characters based on Daz's Michael with different morphs included in the figure, the second one loaded comes out messed up. Either with strange morphed bodyparts that dont fix, or missing stomach and hip. Any help would be appreciated!!!!


thgeisel ( ) posted Sun, 02 December 2001 at 1:49 AM

Thats called crosstalk,the same happens with 2 viccy2. go to www.nerd3d.com You can dl a "EMCfixer" for free from his dlsection that solves the problem


markdotcom ( ) posted Sun, 02 December 2001 at 2:06 AM

I believe there's also a "null loader" available; might be the same thing that thgeisel is refering to. There's a link at DAZ3D under the FAQ area (its not actually a DAZ product). Its pretty easy to use. I've never had trouble with Mike, but multiple Vicki posing is a constant battle. You just load the null figure first, then you add all your characters "through it", and it eliminates the cross-talk. It automatically adds ascending numbers to the figures and their respective body parts/morphs. You could probably do this manually, but there's really no need.


thgeisel ( ) posted Sun, 02 December 2001 at 2:42 AM

yes, its nearly the same


rbtwhiz ( ) posted Sun, 02 December 2001 at 4:46 AM

You can read about (and download) the null loader, here.

It's basically a stripped down cr2 that lists all of the actors, but has no actual reference to geometry or joints. It tricks poser into believing that "Figure 1" and all instances of ":1" (which is what is specified by the cr2 for ERC channels) already exist in the scene. It [poser] then assigns the next number in succession upon loading the figure... restoring use of the ERC channels.

Charles' EMCFixer was first, and I commend him on his solution, but the difference between ours is that his includes unnecessary information that only takes up valuable memory in poser (though the amount is negligible... it's just text). And, being built for p3/p4 figures, it also lacks left and right buttock groups. So, when you use it for Millennium figures, with ERC channels in those groups, subsequent figures will continue to follow commands from "Figure 1".

-Rob
rbtwhiz.com


melanie ( ) posted Sun, 02 December 2001 at 10:49 AM

I've never had this happen. I've used as many as three Michaels in one scene, all fully dressed and with transmapped hair, and they all work perfectly for me. I must just have a very compliant computer, because I never seem to have the problems others have with Poser. I don't even have a super computer. Just an HP Pavilion with a 40 gig hard drive and 128M RAM. I guess I should count myself lucky. I always feel bad for others when they report problems like this. I hope you can work it out. Melanie


scifiguy ( ) posted Sun, 02 December 2001 at 1:36 PM

Rob, Musclebound Mike has resulted in a fresh recurrance of this problem. The null loader (such a cool thing!) works great when first posing, but after I save the file and come back to it later, I end up with a vanished hips and all the MBM morphs on the body tab are cross linked to the first figure again. For now, I'm making sure I've morphed the bodies to my liking before saving so I don't need to use the body morph dials again later. I can get the hip back by switching genitals on and off, except it comes back distorted and the texture isn't good there anymore :( Luckily, the hip will be covered by clothes 99.9% of the time, but its still really freaky. Any ideas on what would cause this or what I should look for if I (shudder) want to try editing the pz3 file? Maybe its related to the new delta pose thing?


rbtwhiz ( ) posted Sun, 02 December 2001 at 4:31 PM

Michael is no stranger to the same problem. It's actually a Poser problem, not a specific figure problem. At first glance, it might seem a figure isn't affected... Make an adjustment to an ERC channel on the first figure that uses that naming convention, then select a group to alter manually or apply a pose from your library on subsequent like figures in the scene, and viola... cross-talk rears it's ugly head.

My hopes are that Poser5 makes the use of a null to load the figure through... obsolete.

With MBM, it's no different than any other figure... again, it's a poser problem. When poser creates the pz3, it writes figure names as they were in the scene. The ERC channels however, all point to Figure/instance 1. So, your faced with the same problem in the scene had you not used the null to originally load the figure.
Can it be fixed? Yes, albeit it must be done manually. What needs to be done is the ERC channels on subsequent figures need to have where they're pointed, fixed. That is, on "Figure #" (with instances of the same ":#") the ERC channels need to be redirected to its respective host.
Until a better solution is available, you could either use the one above or save individual poses from the scene to your library and, using the null, rebuild the scene... I know, not the desired route, but sometimes you're limited by the tools.

-Rob
rbtwhiz.com


scifiguy ( ) posted Sun, 02 December 2001 at 8:25 PM

Huh. Odd that I didn't notice that then with regular Mikes. I know I've never had the hip disappear before, but come to think of it maybe I've got clothes on them so I just didn't see it. Oh well, at least I know I'm not nuts! Thanks again for the null loader...it really is a huge help!


dewo ( ) posted Mon, 03 December 2001 at 12:29 AM

Another way of fixing this is to make several copies of the Mike-geometrie file and number them. Then assign each Michael figure in your scene another geometrie file (by calling up the cr2's in the cr2-editor and changing the geometrie-file pointer to another copy of the geometrie-file). This worked for me for all DAZ and Poser4 figures, no more missing hips and the like.


rbtwhiz ( ) posted Mon, 03 December 2001 at 4:51 AM

Glad to have helped. :)

In my testing, exploring the capabilities/limitations of ERC, I intentionally loaded figures that used drastically different geometries. What I found was that cross-talk occurs on like named ERC type channels. Loading a second/third/fourth figure containing channels that do not exist in the first, do not result in cross-talk. It's not confined to identical figures, from the same cr2. Creating duplicate meshes will not solve the problem, it can't, it's not a mesh problem... it's a cr2/Poser problem. Duplicating, then editing, a cr2 to use different Figure/instance numbers will stop them from cross-talking... because the separate figures are not competing for the same control, but who want's 2/3/4 of the same figure occupying their drives? Millennium figures consume 20+ MB each. And that still doesn't solve the issue of cross-talk should you load two or more of the same/additional cr2.

-Rob
rbtwhiz.com


dewo ( ) posted Mon, 03 December 2001 at 5:33 AM

You're absolutely right, Rob, who wants disk-space eating dublicate mashes, if it's not necessary. I just thought, I had a solution, but have apparently been wrong. So my findings might have been coincidental. Damn, I thought, I soved some Poser secret on my own, and now you come and... well, c'est la vie. But thanks a lot anyway for the response. D.


rbtwhiz ( ) posted Mon, 03 December 2001 at 8:58 PM

:)
Didn't intend to rain on your parade... It's just, with the confusion that already surrounds figure development, I had to comment on a topic I've spent a lot of time researching, and found otherwise.

-Rob
rbtwhiz.com


dewo ( ) posted Tue, 04 December 2001 at 12:21 AM

never mind, Rob, helped me & others. And, BTW, a little rain onto the parade might not be a bad thing afterall - keeps things cool. D.


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.