this isnt a huge problem but it is annoying and perplexing.

I have P6 and later versions of Poser all installed.

when P7 came out I figured I would simply cut and paste the runtime from P6 into each successive version of Poser to keep from having to re-install hundreds of products into each new version.

This didnt work.

So now I just install everything into P6 and then use the P6 runtime as the main runtime in P7 and later.
This works just fine except for one issue.
When I load some figures from that runtime into P7 and later versions the skin shaders will load on the figure in a dark blue or green sheen (which isnt noticeable in the preview renderer).
I have to manually go into each material node for each body part and adjust shader values and colors just to get a vaguely human skin tone.
As you can guess this is laborious and tedious.
The only way around this (that I know of) is to save a scene in P6 and then open that save in a later version of poser. Then the shaders render correctly.

Are there any solutions to the multiple runtimes problem that Im just not aware of yet?

When you say "the multiple runtimes problem", you're implying there is a problem known as the multiple runtimes problem, one that other users have besides you.

I've never heard of your multiple runtime problem, and as far as I know, multiple runtimes works fine for everybody.

When you say you use the P6 runtime as the main runtime in P7, do you mean you added the P6 runtime as an external runtime to P7 and you still have the original P7 "main" runtime as is, or do you mean you copied over it.

I think you must have totally borked your system by copying things you should not have copied. Not everything in your runtime is content. Some of it is software and configuration properties. Copying an entire P6 runtime into any other version of Poser is basically an easy way to ruin Poser.

The correct method to support a gigantic existing P6 content library in P7 is to simply tell P7 you want to use the P6 library as an external library. No copying is involved. Same with P8 and PPro and PPRo 2010.

If you can't tell us exactly which of the thousands of P7 support files you trashed, I'd say the best thing to do would be to re-install P7.
 

none of them are trashed.

when the copying idea didnt work I abandonded that idea and just uncluded the p6 runtime as an external in p7 and above.

I've since then (few years ago) wiped my computer back to its origional factory state and reinstalled all versions of poser so none of the files should be screwed up by that initial copying process at this point.

and by "the multiple runtimes problem" I mean that Im assuming im not the only person who has mutliple runtimes and was asking if there's a better way to do it than what I described above.

I've heard in the past that loading things from an external runtime or an older poser version (things that are not installed in the version you have open) can sometimes cause problems with certain products and this seems to be the issue im having.

just wondering if there is a fix or a better way.

Well the sorts of problems have usually to do with there being two different image files with the same name. Sometimes Poser will pick the wrong one.

I've never heard of materials being messed up, though. They're not loaded by reference the way images are.

You described a dark blue or green sheen, which you correct somehow by editing the material.

Could you talk more about that or show an example?

In particular, are you saying that when you load the same material in P6 it is different than if you load it into P7? Or is it just rendering differently, despite all the node settings being the same?

Oh, and sorry about the trashed file red herring. I wrongly assumed since you mentioned it that it was relevant.

poser is bad at handling duplicate filenames across runtimes.

an example file that always loads badly would be nice.  Do you have one ?

the first screen shot below is a particular texture set (Kirei for A3) loaded in Poser 6. The second is the same texture set in Poser 7. Its not the textures specificly but the nodes that shade the textures. A few other character texture sets that use some kind of real skin shader tree also have this problem.

The circled section shows the values that can be changed to get the texture hue close to what it should look like. The "red" value can be changed from .3 to .1 OR I can change the color mode from RGB to HSL, however in the screen shots you can see that the values are the same and yet in the two programs it colors the skin textures differently.

Im not sure if this node is where the EXACT problem is occuring but Im pretty sure real skin shaders and similar skin shaders are where the problem lies.

Aha.

This is all my fault. I'm not kidding.

In Poser 6 and before, the User_Defined node had a serious bug. The numbers that define the amount of red, green, and blue were accidentally squared. .5 becomes .5 squared, or .25. .3 becomes .3 squared, or .09.

The author of this shader was trying to subtract a specific amount of red from the texture. But they did it relying on the bug, and so they entered a much larger number than was actually needed because the User_Defined node was misbehaving.

I reported this bug to (then) EFrontier, and they fixed the bug in Poser 7.

So - any shader that relied on the bug and compensated for it is now going to act differently. The meaning of the numbers have changed to the correct values.

Now - there's nothing you can do about it on a generic basis. You just have to fix the materials.

Or - don't use those shaders. You can easily use any textures with my VSS shaders. Not only will you get rid of the problem, but you'll have a much better shader as well.

interesting....
so it was that exact node after all?
Now that I know the exact issue it should be easier to deal with. Thank you.

actually i think I already have your shader set....or someone's shader set..... but doesnt the python have to be recalculated if the primary light source changes? Since I mostly work in animations that would be an issue. Maybe I dont have the latest real skin shader product. Which is the best currently available?

anyway thanx for the info =)

Im curious. though...
how did you discover and isolate such a (seemingly) minute math bug? Do you work from the code side?

The script you are thinking about is Face_off's Realism kits which relies on light positions.  BB's system is entirely different and has no dependencies upon other external factors.  A very superior product and it's free.

Quote -
Im curious. though...
how did you discover and isolate such a (seemingly) minute math bug? Do you work from the code side?

No - I don't have access to the code.

I found it while working on a math-intensive shader to find a robust way to encode and decode higher-quality depth maps.

It was in this thread at RDNA:

http://www.runtimedna.com/forum/showthread.php?t=26700

I first mentioned it on page 3 of that thread, 2/3rds of the way down. Then we discusssed it and worked out the exact behavior on page 4.

By the way, the script posted in that thread got truncated when they moved to the new web site. Don't bother trying to use it - it isn't all there. I no longer have the code.

Quote - The script you are thinking about is Face_off's Realism kits which relies on light positions.  BB's system is entirely different and has no dependencies upon other external factors.  A very superior product and it's free.

its independant of the lights AND its free??? O_O

well....no excuse for me not to have it then lol
Ill look for it immediately.
Anyone have a direct link or at least a product name to search for?

thank you both.

LOL.

I guess you ignore my signature, eh?

I wasnt ignoring it....

I was testing you!
yes
it was a test

and you passed
good job =P

casually clicks link

If I understood this right , the original node was squaring the values for RGB. That means to get the same effect without that bug you would need to multiply the current node settings.  

If thats right I have a script that does that.