I disagree with the metaphor. I have a single runtime (around 90gb), properly organised so that everything is in sensibly-named folders, in a structure that makes sense to me. Every link in the content is correct, thanks to D3D's tools, so everything loads rapidly without ever having to search for stuff. I make use of the Favourites feature to keep track of the content I'm currently working with. So for me the metaphor is this: the Runtime is my library, the Favourites tab is the collection of 'books on the writing table'. I'm pretty sure this will continue to work fine for me in the 2020s…

Deecey posted at 5:44PM Sat, 21 December 2019 - #4373978

OOOOPS ... meant to say snarly, not bagginsbill. Apologies LOL

Snarly hereby has permission to hit me with a wet noodle. :-P

Very kinky, but I suppose everyone has to have a hobby! Besides… I consider being mistaken for BB to be an honour :)

SamTherapy posted at 5:33PM Sat, 21 December 2019 - #4373998 ...

Why does this happen to some textures and not others? Why is it only ever head textures? How come resaving from Photoshop corrects it?

It's down to the answer I gave at the beginning of the thread, where I pointed out that the diffuse colour map is sometimes used for other purposes too, which can cause the map to 'inherit' the wrong gamma. I gave the example of the map being used for the bump channel too, but it could just as easily be used for the specular and transparency channels, with the same result.

In the example texture you have since posted, it contains the transparency map for the eyelashes, and when used for that purpose the gamma is properly set to 1.0. Each texture map can only have one gamma setting applied, thoug, so when it used for two purposes one of them will be wrong (as i previously said). EZSkin resets the gamma in those cases, so that the gamma for the diffuse channel is correct and that of the other channel is wrong instead.

Resaving the texture with a new name makes it a different texture map, so it doesn't inherit the bump/specular/transparency setting of the previous map. You can now use one map with a gamma of 1.0 for the transparency, and the other with a gamma of 2.2 for the colour.

I don't profess to know the answer to this as I don't have enough information about the shader setups involved, but I'd like to suggest a possibility.

In older shaders, and even some new ones, the same texture is used for both diffuse colour and bump map. Now, the Poser texture manager can only have a single gamma setting for each texture, so one or the other (diffuse / bump) will have the wrong setting. Now, in such cases EZSkin resets the gamma settings for you, and although that still means that one of them will be wrong, EZSkin ensures that the diffuse colour is the one with the correct setting. perhaps it is correcting things for the colour map at the expense of the the bump map (which tends to be less noticeable, in my opinion)?

Now I have to find where Snarly's EZSkin prefs are at, since the new install kindly trashed all of those.

C:Users>[name]>AppData>Roaming>Poser Pro>11>ezskin3

As well as saving the scene inventory files, the utility will also save a scene file (.pz3), and it needs you to enter a name for the scene file.

FightingWolf posted at 6:30PM Fri, 22 November 2019 - #4370988

AmethystPendant posted at 12:18PM Fri, 22 November 2019 - #4370947

Does the eye surface on the one that doesn't work have any maps (probably reflection). If so make sure they actually exist on your drive in the place poser expects them to be

Unfortunately I'm going to just mark this as one of those crazy problems with no reasoning. This morning I discovered. that If I apply EZskin on the eyes on one model, for example v4 then the eyes show up correctly. That's not the crazy part. The crazy part is that after i do that. I can open up any V4 character that I've created either old or new and the eyes will show up correctly without me applying the Ezskin.settings. So yeah... Crazy stuff.

Without knowing the exact order in which you're doing things it's hard to be definite about what's going on, so treat this comment with caution.

Anyway, one of the things EZSkin does is call the Poser API method 'ResolvePendingTextures', which forces Poser to make sure it has the full path to all textures (it often doesn't). Depending upon what order you are doing things, what textures are being used and what might be in the Poser cache, it could be that this call is making things work where they weren't working before. Or it might have nothing to do with the problem :)

I'd also recommend a great plugin for EZSkin 3 from Bopperthijs, called 'CyclesSkin'

Find it at: https://www.sharecg.com/v/85846/browse/9/Plug-in/Cycle-based-plug-in-for-EZskin3-poser11-only

quietrob posted at 7:35AM Tue, 19 November 2019 - #4370641

Downloaded! I already have a scene to try it out on. Thanks SnarlyG! You're the best!

I haven't uploaded yet :) You must have grabbed the old version...

'Tis done...

EClark1894 posted at 10:54PM Sat, 16 November 2019 - #4370404

Think it might work for me? Or too old?

Too old, most likely. I can't be sure about that, maybe somebody who still uses it can chime in?

EClark1894 posted at 10:36PM Sat, 16 November 2019 - #4370400

BTW, Snarly, FWIW, I wasn't asking anyone to build it for me, just asking if it was possible to be done.

Well Semidieu made the Advanced Material Manager script, which pretty much had a replacement Material Room. It wasn't exactly what you've asked for, but it does show that these things are possible.

Of course, there aren't many script writers out there who are a skilled as he was so i don't think it would be very easy, but certainly possible.

EClark1894 posted at 10:03PM Sat, 16 November 2019 - #4370393

No offense, Snarly, but based on that argument, there'd be no reason to ever improve the Material Room. Poser's Material room nodes stay full size, so you can't just lay them out and connect the nodes as needed. That's what zooming in and out would provide. I don't mind using the compound nodes to make things nice and neat, and I'd like to do e able to do that.

PS: Your arguement does hold water in the level of difficulty and length of time. Maybe there's some way to shrink down the node size?

That's nonsense, Earl. I'm sure the developers will give the Material Room some love when they get around to it, because they'll be paid for their efforts and it will benefit all Poser users. But you specifically said about doing it in Python, which means some poor sod giving up a chunk of their life to make it. Tell you what, I'll build a zoomable one for you, for $3,000, which is about what it would be worth for me to give up that much time. Let me know?

it is certainly possible, and has been done before, but why not learn to use the current Material Room to its full potential? Using Compound Nodes will keep it all neat and tidy, and everything will fit on one screen without any need to scroll or zoom. It'll certainly be quicker (half an hour) for you to do that than for a script writer to spend a lot longer (weeks/months) writing a new Material Room…

Sam, you're one of the pillars of this community and I hope we have the pleasure of your company here for a very long time indeed.