The DUF file size versus DAZ file size

plokn

Filing my old DAZ scene files in DS Pro4.5 nearly doubles their size. I understand they still are reliant on the info in the data folder so what does all these additional mega bytes do for a Studio user besides burn up hard disk volume?

wancow

I'm guessing, but since they added the ability to use Genesis in Poser via DSON, I think that might have to do with it.

plokn

Thanks, I may have to beat a hasty retreat back to DS3.

Bejaymac

When you save a scene in DS4.5 it's looking for the items in the scene to already be in the DSON file format (DUF loader & DSF asset files), because it then doesn't have much to write into the DUF file, so you end up with a small DUF file.
With a scene made from an older DAZ scene file or from Poser content or from a stand alone mesh, then you don't have any DSON DSF asset files for any of that, DS4.5 has to convert it all into DSF files and write it all into the data/auto_adapted folder, at the same time as that it writes the location of the original files into the DUF file, that way if you ever lose the files in the auto_adapted folder DS has a chance of being able to rebuild the scene, it's all of that extra data that's giving you the large DUF scene files.

If you've ever lost your data folder, then you know what a nightmare it is to repopulate it to get your scene files working again, DS4.5 saves you from much of that headache (only works on DUF scene files), as the DUF scene file tells DS where the original Poser files were, and so long as they are still there it will repopulate the auto_adapted folder while it's loading the scene file.

mjc1016

Bejaymac said:

When you save a scene in DS4.5 it's looking for the items in the scene to already be in the DSON file format (DUF loader & DSF asset files), because it then doesn't have much to write into the DUF file, so you end up with a small DUF file.
With a scene made from an older DAZ scene file or from Poser content or from a stand alone mesh, then you don't have any DSON DSF asset files for any of that, DS4.5 has to convert it all into DSF files and write it all into the data/auto_adapted folder, at the same time as that it writes the location of the original files into the DUF file, that way if you ever lose the files in the auto_adapted folder DS has a chance of being able to rebuild the scene, it's all of that extra data that's giving you the large DUF scene files.

If you've ever lost your data folder, then you know what a nightmare it is to repopulate it to get your scene files working again, DS4.5 saves you from much of that headache (only works on DUF scene files), as the DUF scene file tells DS where the original Poser files were, and so long as they are still there it will repopulate the auto_adapted folder while it's loading the scene file.

So, you are implying that by converting items, like clothing and props to weight-mapped/DS files we can trim the scene file size by a very significant amount (converting stand alone/old character base meshes to weight mapping has enough problems/headaches to not really make it worth it...)

Bejaymac

mjc1016 said:

So, you are implying that by converting items, like clothing and props to weight-mapped/DS files we can trim the scene file size by a very significant amount (converting stand alone/old character base meshes to weight mapping has enough problems/headaches to not really make it worth it...)

Never convert Poser figures and conformers to TriAx, they don't bend any better (in some cases worse), and the INJection system doesn't work with them, leaving you with a major headache that even a masochistic nutcase like me doesn't enjoy.

Props with no rigging can be saved using "figure/prop asset", it's then a DSON format file in it's own right with no reference to the original.

The biggest issue for DUF file size is using a DAZ scene file in DS4.5, they can cause huge file sizes and that's in the compressed version. As a comparison I loaded V4.2 into DS3, injected all of the DAZ morphs I own and saved it as a DAZ scene file, the resultant file was 8.9 MB. I them loaded that DAZ file into DS4.5.1.41 (I'm using the Beta) and saved it as a DUF scene, it took a couple of minutes to save and gave me a compressed DUF of 46.4 MB. I then closed & restarted DS4.5 to clear it's "cache", and loaded V4.2 from her CR2 and injected all of her morphs again, saved it as a scene and got a compressed DUF of 1.14 MB, that's about 22 MB uncompressed.

So your actually better off rebuilding your scenes in DS4.5 from the original files rather than using a DAZ scene file.

EDIT

After a spot of file comparison the problem appears to be morph related, when I saved V4.2 in DS4.5 it had a long list of "Writing Assets" in the progress window, that is all of the channels with deltas in them being turned into DSF files and the channels get removed from the DUF, that way it works just like Genesis. But with the DAZ version I only got one "Writing Assets" and that was for the mesh & rig, all of the morph deltas are stored in the DUF file. So it's no wonder the DUF files are huge, it's got all of the deltas from the figures, conformers, props etc in your scene.

Richard Haseltine

Last I looked the .duf file will also include any AutoFit converted clothing on Genesis in full, even though it was also writing files to the Data folder - in that case, if you are going to reuse the item, it probably is worth saving the converted clothing as an asset. Essentially if it isn't an asset, or if it's been changed from the asset as stored, then it will be in the .duf file and/or the auto_adapted folder.

Bejaymac

Haven't had that one Richard, but then I usually auto-fit to the default Genesis and then "Figure/Prop Asset" it, then clean up the face groups and WM before I use it in anything.

Something I did notice, is that when you save the CR2 version of V4.2 in DS4.5 the DSF files get written into the "data/auto_adapted/blMilWom_v4b_68498" folder, but the DAZ file version gets written into the "data/auto_adapted/legacy_blMilWom_v4b_68498" folder, so it looks like they are deliberately keeping the two types separate.