.duf scenes unexpectedly changing to wrong image references: ways to reduce the issue

sriesch

Due to the way .duf scenes use relative file references, it is possible for a .duf scene to suddenly start using the wrong image files (Diffuse parameter for example) the next time you open it.
While I don't see any solution, knowing how and why it happens can allow you to dramatically reduce the chances of the problem occurring, so I wanted to pass on the information I have been given and what I have learned to try to help and hopefully avoid a bit of potential pain.

THE SHORT VERSION: Duplicate partial paths and filenames within mapped Runtime/Content folders trigger the problem. Do everything you can to make those partial paths as unique and unlikely to match as possible.

THE LONG VERSION:
Basically, anytime you reference an image file, if the file is in a mapped Runtime/Content folder or one of it's subfolders on down, when you save a .duf scene, the only the end of that file path is saved. So if the image is in "C:/My Content/Runtime/Textures/SomeArtist/MyImage.jpg" and "C:/My Content" is mapped, it will write to the scene file as "/Runtime/Textures/SomeArtist/MyImage.jpg".
When the .duf scene is loaded, the file is searched for by looking through your mapped content directories in the order that they are mapped. It will check Studio folders, and the Poser folders in the same order that you see the folders listed in the Content Library, appending "/Runtime/Textures/SomeArtist/MyImage.jpg" until it finds the image. As an example if you have the following mapped:
C:/My Content
C:/My Content Again
C:/My Content Another
It will look for:
"C:/My Content/Runtime/Textures/SomeArtist/MyImage.jpg" then
"C:/My Content Again/Runtime/Textures/SomeArtist/MyImage.jpg" then
"C:/My Content Another/Runtime/Textures/SomeArtist/MyImage.jpg"
returning whichever is found first, which may be the wrong one.
This problem can show up immediately when saved and reloaded a scene. This problem can also show up later in a previously working scene without you even touching it simply because you installed completely unrelated content, and that new mapped Runtime/content folder suddenly starts getting seen instead of your original mapped Runtime/content folder.

WHERE YOU ARE MOST LIKELY TO SEE THE PROBLEM:
Because content that I have seen in the DAZ store and for free typically seem to have image files stored in subfolders named after the artist and/or product name, so far luckily the chances of the problem happening in that content seem much lower than with .duf scenes you may personally create. (you would have to have two artists with the same name, or same product, or a name and a product that match, AND the duplicate filename. It can happen, but probably won't happen often, unless of course people start distributing products that don't follow that tradition.)
If you create your own .duf scenes for yourself, you want to place all your images in a subfolder that includes something to make that partial file path unique. One suggestion I have been given is to use the name of the scene, something like "C:/MyLibrary/Runtime/Textures/My Images/Scene Name/An image.jpg" where "C:/MyLibrary" is a mapped directory. Once again this doesn't eliminate the problem, it just reduces the chances of encountering it.

OTHER SOLUTIONS THAT MAY NOT WORK FOR YOU:
One way to avoid this is to save any image files you reference outside of mapped Runtime/Content folders. This will force the .duf to save the entire path and filename, but of course this means that if you move the file it won't find it, so presumably if you are distributing content or ever plan on moving it this isn't an option, nor is it a solution for content you purchased or got from others that probably doesn't use absolute file references.
While the problem would also not be seen if you have only a single mapped Content folder, or single mapped Runtime folder, this may not be a practical option; in any case, if the problem exists with purchased products that have conflicting path/filenames, you wouldn't be able to merge those conflicting products into the same runtime anyway.

Hope this helps a little. Of course if anybody has suggestions on ways to completely avoid the problem, instead of just making it happen less often, that would be better.

refsocrd1_aefdbd2b3a

Actually the "relative reference" is inherent in the entire Runtime structure.

If you edit a Cr2, for example, you'll find the exact same thing.(notepad will open it, but i recommend notepad++)

And you may want to verify the issue by editing the DUF file(by default they are compressed so you'll need to open with winrar, winzip, 7zip etc, then put in the text editor).
From your example you'd literally have to have two or more texture/geometries/etc with the exact same structure, right down to the file names, but in different directories/runtimes
Haven't come across one single instance of this.

This sounds more like a Runtime problem then a daz/duf problem.

A simpler solution is to create a single texture runtime and map it.
This way daz/poser is only looking in one directory and you're less likely to have this problem.

Here's the structure:
x:/[MappedDirectory]/Runtime/Textures

Now depending on the content creator, you may need to add a libraries folder, or other folders specifically for this.

I've downloaded stuff from all over the web and have texture files in my pose folder, as well as any where else within the runtime.

Generally this is why i don't install content directly to the final working directory but to a swap file on my desk top, then move stuff around as necessary.

Makes finding stuff a lot easier for both daz and when i need to search for a particular piece of data.

hope this helps.

sriesch

refsocrd1 said:

And you may want to verify the issue by editing the DUF file

I already have verified it in duf files, that's how I found the issue in the first place. I thought it would make sense to put all my custom materials for each .duf scene in a folder called "custom materials" in the folder next to the scene so I could find it. I have since renamed the files to avoid the problem, but I think what I originally had was these two files, copies of the original product's SkyCarHull_03.jpg texture and edited to add appropriate customizations:
C:\sean\3D graphics\drawings\back in port\custom materials\SkyCarHull_03.jpg
C:\sean\3D graphics\drawings\into the storm\custom materials\SkyCarHull_03.jpg
In these two mapped DS native content folders:
C:\sean\3D graphics\drawings\back in port\
C:\sean\3D graphics\drawings\into the storm\

I haven't tried the same thing in Poser (so Mods, if it makes sense, you can rename the thread to say it's "poser and .duf scenes"...)

I briefly considered merging hundreds of runtimes to avoid the problem, but then realized that the only places where the problem existed would be the exact same places where runtimes COULDN'T be merged due to duplicate filenames; it would only find, not fix, the problem, and in a pretty painful way for me. And if I can find and fix them, It would no longer be necessary to actually do the merge. I decided it didn't make sense for my situation. If one was starting out from scratch and preferred a single runtime to multiple runtimes after weighing the various advantages and disadvantages, this would indeed be a way to prevent creation of conflicting files, and to identify any conflicting files in products before a problem happened, although if the problem were encountered one would have to decide what to do with it then anyway. Although I haven't decided what to do about it yet, I may be able to devise an easier way to identify any conflicts.

I'm curious about how you do the swapping of runtimes, I don't think I fully understand how you are doing that. (from the standpoint of somebody who uses the Content library to organize and locate content, and might quickly burn though dozens of pieces of content testing ideas to see if they would work in a scene.) You aren't actually installing and uninstalling every individual products every time you want to look at or use an article of content, or are you?

SpottedKitty

Sean Riesch said:

I have since renamed the files to avoid the problem, but I think what I originally had was these two files, copies of the original product's SkyCarHull_03.jpg texture and edited to add appropriate customizations

Renaming the customised files should have been the very first thing you did — the files, not the locations they're in. Apart from the path confusion, it's much too easy to overwrite the original uncustomised file and lose it.

This is a very, very old problem dating from the very first Poser versions when there was only a tiny fraction of the amount of content available now. Every now and then you would come across a texture or mesh file simply named "shirt.jpg" or "table.obj" sometimes not even placed in a Textures or Geometries subfolder. Those early versions of Poser would indeed sometimes see what appeared to be the same file in several places, and grab the wrong one.

Usually it was caused by people not really thinking about (or not understanding) the Runtime file structure. This is properly understood now, so the problem is pretty much nonexistent unless you happen to install one of these ancient messed-up items.

refsocrd1_aefdbd2b3a

Sean Riesch said:

refsocrd1 said:

And you may want to verify the issue by editing the DUF file
I already have verified it in duf files, that's how I found the issue in the first place. I thought it would make sense to put all my custom materials for each .duf scene in a folder called "custom materials" in the folder next to the scene so I could find it. I have since renamed the files to avoid the problem, but I think what I originally had was these two files, copies of the original product's SkyCarHull_03.jpg texture and edited to add appropriate customizations:
C:\sean\3D graphics\drawings\back in port\custom materials\SkyCarHull_03.jpg
C:\sean\3D graphics\drawings\into the storm\custom materials\SkyCarHull_03.jpg
In these two mapped DS native content folders:
C:\sean\3D graphics\drawings\back in port\
C:\sean\3D graphics\drawings\into the storm\

Getting a better picture here.
i Think i know what the actual problem is.
you may have mapped to low.

i ran a quick test on this in daz just to see if could replicate.
Parent content directory:
c:\documents and settings\chris\desktop\beer and cheetos

Texture folders(unmapped for initial test)
c:\discussionforumtestfolder\textures\wtf1\custom materials
c:\discussionforumtestfolder\textures\wtf2\custom materials
i just used a plane with a picture on it.
the resultant duf created this reference
"image_library" : [
{
"id" : "Waterlilly.jpg",
"name" : "Waterlilly.jpg",
"map_gamma" : 0,
"map" : [
{
"url" : "/C:/discussionforumtestfolder/textures/wtf2/custom materials/Waterlilly.jpg",
"label" : "Waterlilly.jpg"

I then mapped the folders and resaved. mapped at c:\discussionforumtestfolder.
"image_library" : [
{
"id" : "Waterlilly.jpg",
"name" : "Waterlilly.jpg",
"map_gamma" : 0,
"map" : [
{
"url" : "/textures/wtf2/Waterlilly.jpg",
"label" : "Waterlilly.jpg"

Then i mapped down to the actual folders,that was when it happened.
The references at that point was

"image_library" : [
{
"id" : "Waterlilly.jpg",
"name" : "Waterlilly.jpg",
"map_gamma" : 0,
"map" : [
{
"url" : "/custom materials/Waterlilly.jpg",
"label" : "Waterlilly.jpg"

It had nothing to do with duf or daz, i was mapped to low.
Take the mapping up one notch and i bet it'll take care of it.
in my case it needed stopping at textures, in your case it'll be at drawings.

This is part of the reason that you don't have to map below the parent directory if a runtime is present.
That is c:\balderdash\runtime.
You only have to map to balderdash, not runtime.

I'm curious about how you do the swapping of runtimes, I don't think I fully understand how you are doing that. (from the standpoint of somebody who uses the Content library to organize and locate content, and might quickly burn though dozens of pieces of content testing ideas to see if they would work in a scene.) You aren't actually installing and uninstalling every individual products every time you want to look at or use an article of content, or are you?

I'm crazy, but i'm not u.s. government crazy.
Here's a post i did on another forum a while back explaining runtime structure, daz file structure, and my insanity.

The poser structure:
Everything goes in a runtime folder.
Whether the runtime is a sub folder or just put on a drive doesn't matter.
And the programs don't care if parts of content are in one runtime or another.
As long as the directories are mapped.

Here's the basic layout of what a runtime should look like
x:\{Mapped directory}\Runtime\Geometries
x:\{Mapped directory}\Runtime\Textures
x:\{Mapped directory}\Runtime\Libraries
x:\{Mapped directory}\Runtime\Libraries\Camera
x:\{Mapped directory}\Runtime\Libraries\Character*
x:\{Mapped directory}\Runtime\Libraries\Face*
x:\{Mapped directory}\Runtime\Libraries\Hair
x:\{Mapped directory}\Runtime\Libraries\Hand
x:\{Mapped directory}\Runtime\Libraries\Light
x:\{Mapped directory}\Runtime\Libraries\Materials
x:\{Mapped directory}\Runtime\Libraries\Pose
x:\{Mapped directory}\Runtime\Libraries\Props
x:\{Mapped directory}\Runtime\Libraries\Scene
*these two folders actually get renamed to Figures and Expressions, respectively, inside daz and poser

As you can see, there are three primary directories within a runtime folder.
Geometries: Where all the OBJ files should be.
Textures:Where all the Shaders should be(poser materials are seperate)
Libraries:where all the clickable stuff goes.

Folders within textures and geometries should never be moved any where but to a rutime\textures, or runtime\geometries folder respectively.

The libraries sub folders should have the following:
CAMERA: CM2
*CHARACTER:CR2
*FACE:FC2
HAIR:HR2
HAND:HD2
LIGHT:LT2
MATERIALS:mt5 and mc6 predominately. These are poser material files, and generally don’t work in daz.
POSE:PZ2
PROP:PP2
SCENE:PZ3
*The two directories get renamed to Figures and Expressions respectively within the programs.

Now here's the rub.
Any of those file formats can be in any of the directories, including the base Libraries folder.
And you may have duplicate named files in multiple folders.
Such as hairs appearing in hair, character or prop.
They are generally different items.
One is an HR2, the next a cr2 and the other is a pp2. and may function differently.
You'll literally have to test each accordingly.

Basically as long as the content is visible in daz or poser, and it works, the companies don't seem to care how it's placed.

Moving things around....
As i said any of the file types within the libraries sub folders, can generally be placed any where within the libraries folder. including the libraries folder itself.
The exception is when there is actually a named folder beyond the basic ten.
Such as the Morphs or python folder.
In most cases those are additional information for certain content.
It may be a script for adding morph dials to a corset, or python scripting or or or.
For the most part you want to maintain the relative placement.
That is, wherever it falls within the runtime, it needs to stay there.
Doesn't matter if it's in another runtime, as long as that runtime is mapped.
Such as the morphs folder may be in runtime.
It needs to stay in runtime, and not be placed in a sub directory.
If it's in Runtime\libraries, it needs to stay within the libraries sub directory.

Currently i'm working on consolidating the Geometries, textures, and the random folders into parent folders.
Geometries is in Objects, textures are in textures, and the random folders is in crazy freaking content creators folder.
Each maintains the required structure as far as it needs, with nothing more there.

Now as far as putting the content in the correct place, hair in hair etc, that is completely up to you where to place it.

What i'd recommend is to start with a desktop folder to put the exe, zip, dim file into.
once there, restructure accordingly, but don't move anything to your working directories.
Save it as a new zip/rar etc so you don't have to use the Exe later, or go through the work again.
This is something else i've been doing as i clean out a failing drive.

There is one last thing to keep in mind.
Uninstallers usually don't work after this kind of customization.
so you'll have to manually uninstall the content.
That is where the readme's come in, as most have a file list.

If you significantly change the layout, you may want to make your own file list to refer back to in the event of needing to remove it.
Another point, don't map the desktop folder, even if it asks you to.
This folder shouldn't contain anything after you move the content to your working directory(s).

And lastly if you are feeling rather ambitious, you can always edit the cr2 files and change where it draws the files from.
You may actually need to do this for somethings as the references in the cr2 are very specific. but you won't know until it breaks.
don't worry about it unless something breaks on ya.
If you do decide to start messing with this, always make a back up of the initial file first, then edit in any text editor.
I've found that notepad++ works the best for this.

Daz doesn't care as long as the folder is mapped, and contains daz content(ds, duf, etc)
It'll pull up any folder name you want to use.
The only exception is the DATA folder, don't mess with that one, leave everything in there in there.
Any change appears to break content.

I won't go too far into my structure at present.
Predominately instead of having stuff strewn all over the place, i've consolidated it down.
so now if i want t a pair of earrings that was originally in props, that went with a particular outfit, it's in with the outfit.
And so are the mat pose files.
For example
Let's take the leather corset from billy t for v4(rendo), the electricity texture set is a sub directory of the clothing, as opposed to bein buried in the pose folder somewhere.

Just like the materials of daz content are sub directories of the content(sometimes a bit broken though, but easily corrected).

The one last thing i'll leave you with is

WRITE DOWN A PLAN!!!

Figure out how you work, and how you want to layout out your content for maximum production.
But write it down and stick with it.
You'll find it easier and get a lot more work done, as opposed to looking for stuff.

Think it's time to write a tutorial about runtimes daz files and organization.