I got this P5 material... I believe it was a freebie at RDNA... I think it is called "Reflective Chrome"... I REALLY like it, I use it very often... Problem is, I want to soften up the refection map... So I uncompress the thing so I can find the map location...

See above pic to see why I'm confused.

I do have P4 installed, not on the C drive, but I gutted the runtime. I just verified that it is not in there, nor is it in the P5 runtime.

If P5 can't find a map when you use a material, is it the same as when you apply a pose?
Or does it just pick another with the same name?
I can't recall EVER having a problem with this file.

HMMMM

What poser does if it doesn't find a map at the specified location it does a file search through your tecture dir for the map and grabs the first one. Sad thing is if you have lots of references like this it can take a while for a poser file to load. There is a utility that goes through your files and corrects these wrong path locations which greatly speeds up file loading.

I've had to point to a few textures before when applying MAT poses. Typically, it takes longer than usual, and that little window pops up. Here, there isn't any pause, the material is applied almost instantly. Guess I'll have to investigate a little further.

The utility is Correct Reference. A very nice utility.

What is happening is that Poser is searching through first your Poser 4 runtime, and if it can't find a picture file called "reflection.jpg", it then searches through your P5 runtime and loads the first map it finds called "reflection.jpg". Use the search function on your computer to search for "reflection.jpg", and see if you have one, or pssibly more than one. Use Correct reference. It is a freebie and will fix these problems for you.

I only have poser 4, but I guess it's the same in poser 5. This is really (IMHO) a Poser bug, when you save a cr2 Poser saves an abslute path to the map files. Some people have said that Poser will search your Textures folder, it WON'T if an absolute path is used like in the graphic in post #1, in that case it will only look where the path points. Poser WILL search the Textures folder and its sub-folders if you specify a relitive path. Assuming that the "reflection.jpg" is somewhere under Textures in your tree, backup your file then edit the "reflectionMap" line to read:

reflectionMap ":reflection.jpg"

Just for information, when Poser searches for textures as described in prior posts it searches the entire Runtime, starting at the begining. Everything, that includes Python, even the dll's, all of the !Daz stuff, and even searches past the Textures folder if it doesn't find it. That's why it takes so long...

So Poser doesn't panic when it finds a bad texture path. It only gets worried after it searches the texures folder and doesn't find that filename. That's what takes all that time. Does it do the same for missing .obj's? Or is that of a different logic? I know it has had issues there.

Poser's "logic" when loading an OBJ is as follows: 1) Look for the .OBJ file in the exact relative path given in the CR2 (etc.) including the capitalization of the path and filename. 2) If it isn't there, panic. Spin the user some line about being short of memory so that they panic, too. Attempt to escape during the confusion. 3) There is no third thing. :D

3. delete some random figure that's already loaded in the scene.

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.

I don't think it's random - it always seems to accurately divine and delete the figure on which you've done the most work since the last save ;-) It does not care about capitalization in the .obj path on a PC.

2. Poser 5 on the mac will actually ask politely where the missing obj is if it doesn't find it ... :)

So will Poser 5 on the PC-- something to do with the latest service release? Did it twice last night on a Lory obj that didn't include her name. No crash, but I must admit it was shaky afterwards-- not enough to stop a render though. Emily