Nice image.

If it were mine, though, I would 'dodge' the eyes so that I could see them.

I can't seem to get the blur to be masked properly, on the actual render layer, after I get this far.

I am just trying to figure out how to use my Z render as a gradient mask for the blur really.

My PS does not have a blur called dof blur, my third one down is called 'blur more'.

I have seen how the gradient mask works, I just have not figured it out myself is all.

What do you mean by 'use the dof filter'?

Poser 6 does not introduce the problem.
Poser 7 does.

If you take a PZ3 saved by Poser 6, then open it in Poser 7, then save it, that PZ3 will have the importing issues.

Now I removed my P6 when I installed P7, but I suppose that if you have PZ3 saved by P7, then open it in P6, then save it, that those PZ3 will work fine, as intended.

"If compression has nothing to do with then you explain to me why the prop comes in after I do that, and I'm really not having a go, I can't explain it!!"
Because compressed files do not import into Vue.  You have already stated that some of your files are compressed.  That is a different and independent problem.

You need to isolate which problem you are having.

Let me give you an analogy.
Let us say your car is overheating.
Now lets for example say that the problem could be a hole in the radiator, or the fan belt is broken.  Now the problem with the overheating could also be BOTH occuring at the same time, but that does not mean they are related problems(or the same cause, that is).

Either of them(or both simultaneously) are going to cause the same condition, the car overheating.  You will have to isolate the problem(especially if you are going to offer advice to others, when their car is overheating too).

A compressed file AND an uncompressed file written with the wrong path to the object are BOTH going to look the same, that is no files will be imported.  They look the same, but they are unrelated.

Now, Looking at the Python script for the uncompression routine, there are calls to rewrite the directory paths in the PZ3.  I am not a Python programmer, but it may be possible that this routine is introducing new code into your mysteriously compressed files to point them to the object.  I don't know, I am unable to simulate the (compressed/zip/Z)conditions you are describing.  I am unable to isolate THAT particular variable. 

Other than the fact that when I ran the script on an offending file, it did not fix the problem with importing the object file.  That was not a 'Nyaa Nyaa Nyaa', that was a step in isolating the problem.

That is why, I gave you an offending control prop file, that you can get to, to test.  To help isolate the problems.  Is it the fan belt, or the radiator?  I don't have access to your files to test your situation(you can describe them and the pictures you have made with them, I don't have access to those files).  I  have given you access to test files which I have issue with, but you don't want to test. /shrug. 

If you don't want to pop the hood, to see if it is the fan belt or the radiator, I can't force you to.

The file is right there(it's free, and you don't even have to log in or register to get it), run your solution, the uncompression script, and tell us if it solves the problem on your machine.  That will help isolate the issue, problem, and solution.  It is not even a bad prop, just to have in your runtime.

I am not wound up.

Incredulous, of course.

You turn off compression in Poser, and it still compresses your files when you save them?

"I'm just saying it does for me and some other people that's all"
Did you try it on the model I linked?  It would set up some common ground.  There is a problem, the first step in problem solving is isolating the problem.

And to reiterate, I know why the files are not being imported.  What I don't know is why the PZ3 files are being written differently now.  All you need to do to fix it, is to type in the full path of the object model(mesh) and Vue will be able to import it.

I am sorry if you thought this was arguing.

Well, I said back up at the top.

That I do not compress my files in the first place.  I don't have any "Z" files, ending in "Z" files.  Because none of them are compressed.  Poser does not have a habit of compressing my files, because I turned off compression when I installed Poser.

The "Z" files are compressed files.  Poser compresses PZ3 files and saves them as PZZs, it will also take OBJ files and save them as OBZ files.  When Poser compresses them.  It is not just a naming convention, the files are written differently(compressed).

Like I also said, the problem is not introduced because of compression.

It is not unfortunate for me, because I fix my files.  I know how to, and for those who want to fix their own, until the patches are available, I want to tell them how.  I told you what the problem was in your thread, on this very same topic, Fixer.  And the solution to the problem.

If you want to use a borrowed fishing pole and eat fried chicken to catch steelhead, by all means do so.  But don't expect others to catch steelhead when they do it.

I am not getting you.

The script decompresses .PZZ files, and makes them .PZ3 files.
That script, right?

And you have an empty scene?
Like you have stored a .PZZ file, but with nothing in it.
Then you decompress it, put your stuff in it, then save it?

Maybe I am just not understanding what you are doing(or saying).

You keep saying that it is not a file.  Well, they are all files.  PZZ's, PZ3's, OBJ's they are all files.

Both boxes were ticked, as you noted.

I was kind of worried about letting a script go messing around with the mesh, but no harm was done.  Well, other than not importing into Vue, that is.

Anyway, I have gone down as far down this road as I care to.
I have linked an offending file.  If you want to check it out for yourself, go ahead.  If you don't, dont.

Your script does not work for me.  I never did see the logic or practicality in uncompressing an non compressed file.  But if it works for you, so be it.

I caught my biggest steelhead while using a borrowed fishing pole, and eating fried chicken.  When I go steelhead fishing, to this day, I take a borrowed fishing pole and some fried chicken with me.

I just ran a test.

I opened up the wall section.
I saved it non compressed.
I saved it compressed.
In the same folder.

I ran the script.
The script de/un-compressed the compressed file.
The script left the non compressed file alone.

The un/de-compressed file was exactly the same file size as the non compressed file after running the script.  So I will assume that the script is clean, and does not really introduce any extraneous code.

Neither PZ3,  loaded into Vue.
Not the non compressed one.
Not the decompressed one.

Fixer,

I have no idea what the uncompress script does when it is run.
And what is happening when you run your uncompresser script against a normal non-compressed pz3?

But I suppose it may rectify the paths issue, while it does whatever it does.

I will test it for fun, when I have time.

And yes, it is mostly props, but figures sometimes don't come in either.

I don't compress my pz3s in the first place, to have to uncompress them, so I don't know.  Another poster up there says that it makes his models jaggy.

Compressed pz3s never used to go in anyway.(do they  now?)

Here is a file at DAZ, a freebie.
http://free.daz3d.com/free_weekly/download/ps_fr261_RHSWallSections.exe

The objects do not come in when saved as an uncompressed PZ3.
It is small and lightweight.

In the meantime I will test the script.

The objects not coming in or not is unrelated to the pz3 being compressed.

Poser is truncating(cutting off the front) the path that is written in the Pz3 to find the .obj file.

For example:
Some items will be written
C:3druntimeswhateverruntimegeometrieswhateverwhatever.obj.

Vue can find those objects and imports them.

Some items will be written
runtimegeometrieswhateverwhatever.obj

Vue can't find those objects and does not import them.
Poser does not have a problem with either way it is written(not really a Poser problem).

You need to go into your offending pz3 and add the C:3druntimeswhatever...to the beginning of the line of code which calls your .obj.

What is weird is that Poser is only doing this with the .obj file code.  Not textures, for example.  It writes the whole path for those, without exception that I have seen.

I suppose that if the runtime directories were all stored under the Poser directory that there would be no problem.  That is probably why the problem is only being recognized by a few users, that is to say, those who have their runtimes OUTSIDE of their Poser directory.

Thank you.

Edit the PZ3 file to have the full path name of the object.

If you have displacement as a tool, why would you even use bump mapping?

Now I am sure that render time, is probably a great reason to use bump over displacement, of course.

But if you are going to use one, why are you going to use the other?