I have brought in items from Poser 6 and some don't show up. Am I missing something? I save as and name the item..then open vue and import it. This has always worked for me and yet with some items you can't see them and it doesn't show in the list. Can someone point me to a tutorial or something so I can see what I'm doing wrong?
Thanks,
Marque

There's a bug with Poser 7 and Vue 6 due to a bad E-Frontier api.  E-on is making a fix for this

Right but I'm using poser 6 not 7. Some things from poser 7 did pull in but since there was no consistancy I went back to 6.

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

You could also try uncompressing your Poser content, that works for me and solves all my import issues except with Poser 7, I still get some issues with that!

p6 compresses? How do I uncompress?
Thanks

There's a script within Poser to use: **Window/python scripts/Utility funcs/Uncompress files

**Be sure to tick the 2 boxes as well!

Not promising it will solve your problem, it does for me but hasn't for others but it's worth a try!
Don't forget each time you install new stuff to run it again!

Figured out how to uncompress. V4 comes in now but is jaggy, will try again with poser7.

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.

farkwar: I've had this discussion many times with Iloco and others, I don't dispute what you say or others, what I am saying and have said before that running the uncompress script WORKS FOR ME and I know it's worked for others too!

You know it is just possible that there could be more than one reason for props not coming in and it is mainly props this affects not figures!

And where's the harm in trying something as quick as running a little script? If it solves the problem great, if not, well what have you lost, 2 minutes of your valuable time!

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.

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.

Farkwar: I think you're confused with what I mean by the uncompressing [no disrespect intended].
I'm not talking about when you save anything in a scene; that is, I'm not talking about "file compression" in your preferences as you seem to have tested!

I'm talking about the obj compression in Poser itself, you just need to run the uncompress cript and make sure you have ticked the 2 boxes, once you have done that close Poser and open it up again, then do your test and save "without" file compression!

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.

It's not the "file" I was talking about, when running the script you need to have an empty scene!
Anyway, it works for me, I'm sorry it didn'y for you!!

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.

Obviously I'm not making it clear, that is a failing of mine I know!
Poser has a habit of saving everything in your runtime as compressed files with a "Z" on the end, so an obj file becomes an obz file etc.
The uncompress script decompresses them from obz back to obj etc.
It's this "Z" extension that "seems" to cause the problems I get most of the time but not all the time.
Others disagree with this and that's fine, I have no problem with that but it doesn't change the fact that it works for me and others [dlk30341] for example!!
Again if it doesn't for you, well that's unfortunate but at least you gave it a try which is all any of us can do with issues like this!

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.

Look Farkwar, I don't know why you're getting so wound up, I also turned compression off on Poser but it still compresses them so I don't know why ok!

As I said before it's not my fault if something works or not, I'm just saying it does for me and some other people that's all! The original poster Marque above has also stated that after doing this, V4 came in where it didn't before even though it wasn't perfect, she did still come in though!!

If you want to get a rag on about it, that's up to you, I'm not here to make enemies, I can get mine to work ok so I'm happy!
Feel free to go kick the cat or something to cool you off but don't rail at me because I disagree with you and because neither of us know why some things work and others don't!
After all it's not the first time and won't be the last time this sort of thing happens differently for people!
Look at Poser 7 for instance, works great for some and crap for others, go figure, that's life!

I don't get it either, thefixer is trying to help me not start and argument.  Thanks for your ideas I will keep at it. Appreciate your tips. 

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.

ok let's step back here so it doesn't get worse than it is because I DO NOT like conflict, I'm a coward deep down ;-)

When I save a pz3 my Poser DOES NOT compress the file, that's not what I was saying.
What I was saying is that when I put new stuff into Poser from a zip file, it appears that Poser for what ever reason puts them in "z" format, note appears!
I have to admit to not checking that bit properly! The reason for which should hopefully come clear below!!

Now let's go back to Vue6Inf, I only have problems with P7, if I bring stuff in from P6 I don't have an issue, now this is the contentious bit!
If I have a prop that doesn't come in then I can go back into Poser, run the script, resave my pz3, import into Vue again and the prop comes in!
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!!

Now the picture in question is in my gallery here called "Pygar", the Nest and the Angels hair didn't import, the M3 figure did, I ran the script in Poser and they came in next time!
Maybe, just maybe it's a coincidence and I've grabbed at it but really if it works, what else can I do? I'm not going to say it doesn't just to please others and likewise I'm not going to say it works if it hasn't! Why would I lie, what would I have to gain by leading anyone up the wrong path???

I know I'm not an expert on the inner workings of either programme, they are tools for me, nothing more, just like any other toll I might use, I don't need to know how a spade breaks the earth to use it!

No offence intended in any of my post, I would dearly like to move to using P7 instead of P6 with Vue6Inf but until this import issue is solved I can't take the chance a prop doesn't come in when I'm working on a customers cover or something!
I hear what you're saying and I'm sure your method works, I don't dipute that, never have if you go back through the thread, but I'd have to go through a lot of stuff to make sure I get eveything I might use in an image and I just don't have the time for that!

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.

the fixer's fix didn't fix my problems, but I think, farkwar, thta if you do a search of your puter, for .obz you will find you have quite a few compressed files that you ddn't know you had in your runtimes. Love esther

Thanks for making me check it.

In Poser's runtime, yes.

In my runtime, no.