Hi there,
did you see that poser pro saves the relative path not the absolute path.  How is Vue supposed to know where all the textures etc are in the external runtimes.  the old poser used to save the absolute paths.  Is there a way to fix this without manually adjusting each pz3, or am I doing something wrong?
Love esther

Is it only saving relative paths for the default or current Runtime -or- for all Runtimes used?

It may be that Poser's search feature is supposed to overcome pure relative paths according to added Runtimes.  Sounds a bit like what I'm doing for iPP.  I don't have Poser Pro so cannot test any propositions for validity here.

 it would be fine if it was just saving relative paths for the default pathway as that is how the old poser 7 used to behave.  However it is saving a relative path (incorrectly of course) for every texture and obj in the pz3.  I can only surmise that poser must search through every runtime to find the correct textures etc.  And what happens if two things are the same name?  
(I wonder if this is why poser is so slow when I switch from the render view back to the preview view, maybe it is searching for and reloading all the textures again?)
this is very distressing as I use vue with poser a lot!  I know there are work arounds, but not really for my normal workflow and things that I want to do with it.
Love esther

This has been a much requested fix to Poser because people want all freebies and products to only have relative paths in them. Nobody stopped to think about Carrara or Vue trying to search runtimes. They just fixed Poser Pro's deep search and path save feature.

I think that it is a good idea as well but it does require that you have all of the needed Runtimes added or it will not find the references - as one should expect.

And this isn't good for other support which doesn't reference Runtimes like iPP and now Poser Pro.  Interesting situation with this.

 there should be a preference to choose!!!
love esther

That would be the best compromise here: have a setting that uses Poser 7 or Poser Pro style referencing.

Have not tried this myself with Vue and I assume you might be on a Mac. But you might try putting all textures and geometries in the default PPro runtime like I have.

PPro will find them there, and I assume Vue will too. If you think this method will slow down poser as it has to go back to your main runtime for textures and object files, the use a program like make symlink (which I believe I got for free) to make symlink folders of the texture, reflection maps and geometries folders out to your various runtimes. That makes all references to files it is looking for back the main runtime as these function as smart alias directories under OSX.

If I know estherau, that might be a Herculian task.  Iirc, she has many, many Runtimes.

 Well I was thinking I could just merge all my external runtimes into the one poser pro runtime, but still leave all the external ones for creating my Cr2s  and working in poser.  Then when vue looks it would find things in the correct place.  It would waste a hell of a lot of space, and it would mean everytime I create a new external runtime, I would have to remember to do the mergey thing as well, however at least vue would work with poser.  I feel sad though that poser has lost what was great funcionality.  
I can't understand why they still even have the option to make external runtimes and add them.  what's the point if the pathways aren't correct.  You might as well organize everything using their collections facility.
Love esther

I broke my runtimes off originally by character and other items by categories: like buildings and vehicles. Finally felt I was wasting space by having the same hair texture and geometry sets in several runtimes as one example.  So I put all textures, geometries and reflection maps in the main runtime. Keep in mind I manually install all content and place it under folders that make sense to me. But that broke WW2. as it wants the geometry file in the same runtime as the CR2. So that is why I symlinked everything in the first place. I even have a symlinked geometry and texture folder on my desktop where I drop all new content and then place the cr2's, etc in their appropriate runtime. Works like a champ for me. But might not be right for everybody.

 i use kaveman's ditto gui for installing my runtimes when I do merge them.  So I have one external runtime called V4 and another called boxing and another called sport etc.  I have a lot of content.
But I think rather than just moving some stuff, it will be far easier for me to just hit ditto each time I create a new runtime and put it all straight into the main poser runtime as well.  that way I will have my poser stuff taking up twice as much space as it used to (unfortunately) but at least vue will work I think.  This will never be undoable as the pz3s cannot ever be converted back to absolute pathways ever again.  It is tragic.
I am soooo upset about this.
Love esther

Quote -   This will never be undoable as the pz3s cannot ever be converted back to absolute pathways ever again.  It is tragic.

Just keep Poser 7 installed and reopen and save your stuff with it if you want absolute references.

That sounds like a plan. :)

Nice idea but sadly i already tried this...
If i use poser 7 then what happens to that gamma which i so wanted to look at imported into vue keeping poser shaders.
even worse poser 7 doesn't like the relative path either because then it thinks the path starts in the poser 7 folder.
love esther

See, this is what three straight days of 5 hours sleep does to you - it adles the brain.  That is so true here.  You may need to stick with the merging of your separate Runtimes into the main one then.  I would definitely discuss this issue with SM directly since it seems to be something of an oversight on their part - Carrara, Vue, and other software are assuredly assets to their assets so they might not want to invalidate them (and I'm not sure that these other software will get about rectifying this themselves all too quickly).  You may also want to mention this to E-on so that they are aware of the change in referencing.

Quote - Nice idea but sadly i already tried this...
If i use poser 7 then what happens to that gamma which i so wanted to look at imported into vue keeping poser shaders.
even worse poser 7 doesn't like the relative path either because then it thinks the path starts in the poser 7 folder.
love esther

I dunno. Why don't you do a test PZ3 of a cube with Gamma on it and see if Vue even recognises the gamma correction? I'm certainly not going to defend Poser 7 but Poser 6 can find my stuff no matter which runtime it's in using relative paths as long as the runtime has been linked properly. Just one more reason Why I prefer Poser 6. That and it imports to Vue and Carrara pretty consistantly.

 yes I could certainly try a cube.
I did tell smith micro but I got an automated response about what to do if your pz3 won't import into vue that talked about compressed files etc which is not my problem.
I don't know if e-on knows about this but you would think they would wouldn't you.
You would think these two software companies would realize how they help one another and communicate better.  I only got into poser in the first place because I had vue and wanted to populate my scenes.
Well I better go and buy a new 1 TB harddrive to put all my poser stuff on, because I am going to need it I think.
Love esther

Don't be too quick about that new drive. This is one thing that can easily be solved using PoserPython.
I'll find some time over the weekend to write a little script that'll convert the relative paths in your .pz3s to absolutes. I'm going to use Python so it'll be cross platform.

 You really think that is possible?  That would be totally awesome.  It couldn't convert once the pz3 is created because all paths then start with the word runtime. It would have to save a pz3 itself somehow instead of saving via poser.
Love esther

With svdl, all things are possible (in Poser with Python scripting)! ;)

I know. Here is how the script will work:

• it'll open the .pz3 as a text file
• it'll scan it line by line;
• when it encounters a line with ":runtime:..." it'll search for that entry in an in-memory dictionary;
• if not found (dictionary will be empty at script startup), it'll search for the file in all linked runtimes, and add the absolute path to the dictionary;
• it then replaces the relative path with the absolute path in the dictionary.
• and saves out the line.

It'll take an original .pz3 and write out a new .pz3 with absolute references.
THe script will run from inside Poser, since it then can access the list of linked libraries.

 that sounds good.
Love esther

I'll find some time over the weekend to write a little script that'll convert the relative paths in your .pz3s to absolutes. I'm going to use Python so it'll be cross platform.

Sounds great! I'm encountering the same problem also and that script would be a huge help!

 my communication with smith micro so far:-

 
Dear Riesa,
The reason we chose to make all paths relative was to facilitate moving the main Runtime out of the Poser folder. Poser Pro can locate files regardless of their location (although it may take a bit longer in some cases) but this does admittedly create issues with applications like Vue that use an older version of the Poser SDK which can't properly locate all required source files without absolute paths. This is unfortunate but we're working with e-on to provide an updated SDK wich should allow them to create a Vue update which better handles files created in Pro.

Just to be absolutely clear, there's no way to force Poser Pro to write absolute paths in PZ3s, nor do we intend to allow this; for the moment Vue users will need to continue creating PZ3 files in Poser 7 to ensure compatibility. I very much apologize for the inconvenience but this should be a temporary situation. 

Regards, Colin Gerbode
Technical Support

The thing is though that in the previous versions of poser the path was relative for the main runtime which can easily be merged with the new poser.  All one has to do is first merge the new runtime into the old runtime so no old things will overwrite the new things, then copy that runtime back into the new version of poser.

Not only do the relative paths slow everything for people with multiple runtimes, but when object files or texture files have the same name, poser is going to make mistakes.  I am very sad that you are not allowing the absolute paths.   

 Dear svdl  this is how the paths are written in mac pz3s to work properly with vue:-

SAM HD:Applications:PoserAll:Poser_Victoria4:Runtime:Geometries:DAZPeople:V4_2remap.obj

textureMap "/Applications/PoserAll/Poser_Victoria4/Runtime/textures/ThorneWorks/Tanith/4_v4TanithM.jpg"

bumpMap "/Applications/PoserAll/Poser_Victoria4/Runtime/textures/ThorneWorks/Tanith/4_v4TanithB.jpg"

do you suppose that poser changed so that other software that they don't have deals with such as carrara and dazstudio will be struggling to import?
Love esther
 

Quote - do you suppose that poser changed so that other software that they don't have deals with such as carrara and dazstudio will be struggling to import?

One possible reason this was changed for PPro is the network rendering feature (as paths could easily be different on the render machines).
Another possibility is that it makes it easier for PZ3 to be shared within an organisation where the content will likely be setup differently on each artist's machine.

The consequences for other software that imports PZ3s, is that they now need to emulate Poser's search algorithm for all content location not just for files that could have relative paths in previous versions (which was everything but PZ3s).

I have a program that may help you if you drop me a pm I will see what I can do with it .

Poser doesnt need to search as such, it just needs to append the relative path with the runtime paths and test for file existance , althougyh Poser file searching will find it even if its in the wrong place .

This is exactly what my software does.

First it tests the path given (good for absolute paths only of course), then the path is stripped down to the relative path (where possible) and all available runtime paths are prepended to test.  If that fails, and content is being loaded, it checks the folder wherein the content resides.  If it's a scene or content, then the appropriate runtime folders are searched (textures/reflection maps for images files and geometries for obj files).  I don't do a full Runtime folder search as that would be ludicrous. ;)

 from smithmicro:-

I'm sorry to be the bearer of bad news in this case- but explicit paths really caused a lot of problems, especially in non-scene files (CR2s, PP2s etc.) Although using only relative paths does allow for confusion if source files have the same names and file paths- which they shouldn't if the content is properly created and set up- I hope you can see a bit of our point of view. It was also essential to make all paths relative as a part of allowing the main content Runtime to be located outside the Poser Pro folder (to satisfy Vista's access constraints, among other reasons.) 

Now, as to the issue with Vue- we have provided e-on with our updated SDK some time in the past, and I think they have created updaters to Vue that use the new SDK, which should resolve the problems you've seen with Pro scenes. It's probably a good idea to ensure that you've got the latest Vue build installed. We'll also follow up with e-on to ensure that they have in fact made such an updater available. 

Again, I do apologize for the inconvenience but I hope you can see the logic involved in our decision, even if you don't agree with it.
Regards, Colin Gerbode
Technical Support

The weird thing is that full folder searches don't have to take that long. I'm working on a little project in .NET for poser library management, and one of the features is that it can search for available Poser installations on the entire system.
The disks on my system are fast (2x WD Raptor in RAID 0 + 1 SATA-II 300 GB + 1 SATA-II 750 GB), but loaded with folders, applications and data. A full drive scan for anything called Poser.exe or PoserPro.exe takes less than half a minute.

 sounds very interesting.
I have another question which i should know the answer to but I can't remember. Maybe it is related to this topic.
After I render, when I switch back to the posing window there is always a considerable delay.  Is poser relooking for textures during that delay?
love esther

svdl, but what about everyone else. ;)  My boot drive has 330,000 files on it and data drive has 490,000 files.   Probably 50,000 folders between them.  And I consider this moderate.  Someone with 10 drives with 1,000,000 files on each is going to take a long time - at least in respect of finding references.  Drive speed matters but so does the number of files.  Windows is notoriously slow when dealing with many, many files.  MacOS is much better in this regard.

Quote -  sounds very interesting.
I have another question which i should know the answer to but I can't remember. Maybe it is related to this topic.
After I render, when I switch back to the posing window there is always a considerable delay.  Is poser relooking for textures during that delay?
love esther

You should do a background render to get the full benefit of Poser pro. But anyways, I think the delay can be memory optimization. That is, when not rendering to the background, you don't need to see the viewports updated, so that part of memory is freed to be used for the renderer.
That's my theory, anyway.

*It was also essential to make all paths relative as a part of allowing the main content Runtime to be located outside the Poser Pro folder (to satisfy Vista's access constraints, among other reasons.) *

I never liked Vista..... probably never will.

Quote - *It was also essential to make all paths relative as a part of allowing the main content Runtime to be located outside the Poser Pro folder (to satisfy Vista's access constraints, among other reasons.) *

I never liked Vista..... probably never will.

Agreed. ;)

What I've encountered is that files in the same location as the 'program files' (whatever it's called in Vista) are read-only.  This is rather ridiculous.  I had to make a special update to my plugin to write preference/data files to the Users folder to circumvent this limitation since these files are normally stored in where the plugin is installed (in the Cinema 4D plugins folder).

With Vista, it may be that the Runtimes actually exist outside of the Poser install.  Nice move, Microshit. ;)

"What about other users"

Ths search facility ran within half a minute on a system with over 1,500,000 files. The computer and the drives are quite fast, admitted. And I could speed things up for systems with multiple drives - one worker thread per drive, threads running in parallel (searches are not CPU intensive).

About the program files folder being read-only, that's actually a good move. Altering your program executable should only be possible in unusual situations (such as a signed update from the vendor). Unix/Linux based systems usually protect their executables too.
I like the idea of separating executable, config/preferences and data into separate locations with separate access control.
Under Vista it is sort of mandatory.. Under XP, it has been recommended best practice for years.
I do not like Vista, but not for this reason. There's other reasons (graphical bloat, DRM crap).

Unfortunately, nobody was listening to MS about this. ;)  Even Cinema 4D is encountering similar issues since it stores preferences and browser files in the program install folder.  I rectified this in my plugin by simply looking for the Users folder and copying/referencing my preferences and other data files from there instead on Vista.

I think that the 1GB stolen by OS, Draconian hardware requirements, and DRM crap - as you so eloquently put it ;) - are some of my main reasons for avoiding Vista at this stage.  My computer, being less than a year old, should be fully up to hardware specs - but then one never knows.

 You know smithmicro probably has no idea how much poser content some people have in their external runtimes.  

Hehe.... I doubt Smith Micro even knows what an external runtime is with all the software that company has absorbed!

 you may be right.  So hmmm, how many eyelashtr.jpgs do you think are in all my runtimes, and silver.jpg and concrete.jpg and wall.jpg etc  and is poser pro just going to take the first one it finds then once it possibly can't find this in the default poser runtime?
love esther

there are relative paths in poser that are worse than just starting at runtime . Some of the file referances seem very cryptic , but actually start at runtime:textures ..

Its fine for Poser , but nasty if you want to import 8in another application.

Smith micro is quite correct though , any third party application should be able to evaluate those paths . Its an excellent reason though NOT to have duplicate names in your runtimes that are not identical files .

Well, but, erm, uh.  The problem is that neither SM nor the user has real control over filenames used by content - this is something that the content providers must work out.  And there aren't many guidelines enunciated in this regard.

I would think that as long as the relative path is not "eyelashtr.jpg" but instead ":Runtime:textures:BoobasFiles:eyelashtr.jpg" there will be no troubles in finding the correct file.  But it does depend upon two things: Does Poser do this specific test before doing a blind search (we hope it does) and will content creators be so kind to make their references this clear?

Naming was a concern with the package I released at DAZ too. They suggested prepending a code before each and every filename, since "body.jpg" or "sword.obj" are far too generic.

The people at DAZ suggested using a short (3 to 4 letters and/or numbers) prefix for everything. I used my screen name, so you'll have texture files like svdlBody.jpg. The chance that Poser picks the wrong texture/geometry then will be far, far less.

So there are guidelines (sort of).

By the way, each and every object I've ever made has been run through CorrectReference and contains the correct relative paths to geometries and textures. As a content provider, I pride myself on delivering trouble-free and user friendly content, either free or commercial.

Might be something for the marketplace testers - check for generic filenames. Or maybe they already do that.

if the resolved pathname exists then it is used , no searching done , but it looks like Poser searches the default runtime , then the others in the order they were added. In python thats poser.Libraries().     Then Poser searches , and may the good fairy sprinkle you with happy dust if you have many silver.jpg or anything else that arent exact duplicates.    

Content providers could use Daz Studio to test file referances , because it doesnt search , if the file isnt where the relative path says you get an error .

In that case, as long as the path is unique (per my BoobasFiles example), then it shouldn't matter in which Runtime it looks.  That is, if the same textures exist in multiple Runtimes distinguishable by their unique paths, it should resolve to one of them as it does its reference checks.  As you say, if the reference isn't found or is incomplete, then may the fates smile upon you.

An interesting question arises: Does Poser still use absolute references to files outside of any Runtime (say a texture image file from another source stored someplace which you picked yourself)?  I would hope and imagine that this is the case.

I should note that in my case, being that my plugin isn't running from Poser, I have two strategies for reference resolution.  Users add all of their Runtimes to my 'Runtime Explorer'.  If none exist, they are prompted during scene import to add at least one.  If Runtimes exist, they can limit the check/search scope by enabling Runtimes - only the enabled Runtimes are used in resolution.  Or, if none are checked (or all checked) the resolution goes from top to bottom of the Runtime list (which is rearrangeable as well).

This strategy can reduce import times when dealing with many Runtimes wherein the user knows those of interest for the importing scene.

 Any luck svdl?
love esther

Sorry, been more busy than I expected. Will try to finish the script tonight.

 I thought it might have had some glitch where it wouldn't work.  No rush.
Love esther

Here's the script. Save as ConvertToAbsolute.py in a convenient location (I suggest a subfolder of the :Runtime:Python:poserScripts:ScriptsMenu folder).

The script will ask the user for the .pz3 file to convert, and it'll create a new .pz3 file with 'Absolute' appended to the file name, containing only resolved absolute references.