Opportunity here - Can we get Genesis 9 to start on a nice new clean slate?
Gator
Posts: 1,319
1. Duplicate Formulas - New Genesis 9 figures with duplicate formulas rejected back to the PA to correct before releasing in the store.
2. Textures - I have some characters with some really horrendous compression artifacts from a far too aggressive level of JPG compression. Seems easy to set a minimum standard for PAs who develop figures. (I.e use minimum Photoshop JPG compression level 9-10 or equivalent in another program).
We know now the duplicate formulas causes long load times for figures. I have this problem, despite having a fast system having to wait a very long time for Genesis 7 figures to load. It's on a Ryzen 5950, Daz and my library are installed on separate Samsung 980 Evo M.2 drives, and a GeForce 3090.
On the textures, I've seen some truly horrendous texture compression artifacts, won't call out any PAs but from PAs here in the Daz store. Like the max compression was used, and it looked like you would be better off with 2048x2048 PNG files vs. the 4096x4096 JPG files.
By establishing some standards out of the gate, it will make for a much better Genesis 9 line for all of us! 
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
I like the sentiment, here are two thoughts from a consumer perspective: 1. require a minimum deviation from the base figure and 2. include a side by side image of the new figure versus the default figure. The first is because I ended up playing this game where I would overlap a base G8 on a newly purchased figure to see what changed. The second is because the standalone promo images for some figures don't give a sense of scale.
This is why I love the character .png skin texture maps that some PAs use. I can edit and resave them without loss of quality. Yep they're kind of big and resource hungry but you can re-save them out as .jpgs for final rendering.
I don't mind the duplicate formulas thing personally. When G8 takes so long to load because of too many morphs, the Windows critical error sound reminds me I've got a scene ready to render ..... finally LOL.
The file format or compression ratio has nothing to do with how resource hungry textures and/or maps are, that is just about how much space an image will take on the drive,
Any and all images opened in any program, are uncompressed when opened, and the amount of RAM they will use is calculated with; "Width (px) x Height (px) x color depth (bits) / 8 (bits) / 1024^2 = MegaBytes"
Duplicate formulas can also result from characters from other stores that DAZ doesn't test against. So, yes to fixing duplicates, but better to also set a standard for naming morphs that avoids duplicates. Perhaps vendor initials + character name or something like that.
A simple---and enforceable (if QA exists)---solution to the duplicate formulae within this store is to assign each character vendor an exclusive 2 or 3 character prefix that they MUST use on EVERY file submitted to Daz. Failure to do so results in immediate rejection until rectified. Done.
However, I have seen nothing in the past or present that would encourage me regarding this fantasy.
The problem is to do with the internal asset ID that you find in every single DSF file, that ID has to be unique to the figure and not just to one content maker, but to the whole ****in' world, no body else can use it for the same base figure.
"FBM_Bejaymac_G8F_Samay_001"
^^^^^ That is the sort of naming convention I'd like to see adopted by everybody for G9, and that has to be done in Morph Loader, can be done with the OBJ if you are making an all in one full figure morph.
Why DAZ does not have a system in place that does what you guys are suggesting automatically is beyond me, if the results can be so grave. It reminds me of the old Windows 3.1 days where the Windows kernel would let individual applications do whatever the heck they wanted and one app could bring down the whole system.
*sighs* yet another golden opportunity WASTED!!!
When we have asked for standardisation of folder structure, asset names etc. We have been told that it's up to PA's to decide where to put stuff and how to name them.
We could make our own registry of PAs/products with good naming and folder conventions. A simple shared spreadsheet would probably work.
And that's just another instance of a bad design decision that DAZ made. It seems like many times when we as users express the desire for a bug or other deficiency to be fixed, we in stead get an explanation of why the problem exists, as if that is somehow a consolation.
Back when I worked in the video games industry, we had a printout on the wall saying "It's not a bug. It's a feature." just for some giggles. Perhaps DAZ is taking such approach a bit more seriously...
If DAZ truly is abdicating control over what the PAs do, then I think we, as users, would be within our rights to try to develop a standard that expresses our expectations. It kind of reminds me of the UNIX File System Hierarchy Standard: some of its guidance comes out of technical requirements that are objectively correct, but it also clarifies other things, choosing exactly one configuration from among more that one subjective options, when none of them can be called "wrong", i.e. sometimes the actual choice is less important than consistency.
We would be within our rights to informally bestow upon products that respect this standard a seal of approval.
I would be active in it if others wanted to begin this effort.
DAZ isn't going to fix it. Your best hope is that some PA will create a program to scan directories for conflicts/errors
Scanning the directories is not enough as it's not the filenames that are the problem, but what's written inside the files.
I've tried in the past to organize my library myself, but I always invariably end up moving something that a script relies on and screwing that up. (UltraScenery was a BIG one). LOL It would be nice if Daz would set up an organizational system that the PA's were required to stick to that made more sense than, well, what we get now - which isn't much better than the old Poser days where ppl just put things wherever. And have I said how much I hate vanity folders (even tho I do it myself for my freebie props)? LOL If the internal search inside Daz Studio actually found what I was looking for, that'd be one thing, but it's as bad if not worse than the store search here. Urgh. Thankfully, I haven't run up against too many duplicate forumula errors, but I have a couple times.
Read the DSON objects. Could check for non-zero values 9on non-hidden properties) too. However, any fix would need to bear in midn that an official fix might use different names. I know this is annoying, even if it is fairly simple to fix once the issue is spotted, but it is also hugely difficult to police - it's easy to sy use prefixes but the issues are making sure theya re unique and making sure they are used.
You can use categories to organise, or link (.djl) files to set up a shadow library organised as you wish while the real library keeps the organisation required for cross-product references like those in Ultra Scenery.
Yesterday I was going through my 'Ready to Download' files on DIM in A - Z sequence and there were two files, from different PAs, and the only difference between the names was 'for Genesis 8 Female(s)' and 'for Genesis8 Female(s)'. SKUs 68683 and 69439 respectively. How in the world did they get through QA/QC even if they were going through at the same time?
Oh, I've tried that. Mostly what I get are EMPTY category folders. Since I don't know what I'm doing wrong, I just gave up on it. I spent a lot of time in categories just to get a bunch of folders with nothing (no links) in them. If categories relies on smart content, half the stuff I have HAS no metadata and half of what does have metadata is uncategorized. If that's the case and it does rely on metadata, that needs fixed too.
Correct spelling and folder names might not be on the checklist (but should be). My library is full of these misspellings too.
The attached image shows the inside of one of my own characters.
The four highlighted parts all show the same bit of code "FBM_BJM_Samay", this is the Asset ID and in this file there are 1024 instances of it.
The first two setup the ID, at the end of the file are two more that set up the ID for use in a scene, the other 1020 are for the Formula, one for every Formula in the file.
This is what causes the problems, two products that have DSF files that use the exact same Asset ID, when installed together the first one encountered loads cleanly, while the second generates code errors that show up as Duplicate Formula errors.
As Richard says it's not hard to fix, it usually takes me about 15 minutes depending on how many files I have to dig through, but I have something many of the content makers don't, knowledge and experience as I've been editing DSON files since DS4.5 first launched.