[Daz] How do you organise your files?

[Volta]

Maybe I have a touch of OCD or something but I feel compelled to have EVERYTHING in a DIM package. If I get an asset that's not packaged that way then I create my own.

A side benefit of this for me is that since I check each one within Daz after I install the package, I know everything works for whenever I decide to use it. I also know that it's set up so that it's easy to install/uninstall/reinstall and I won't ever have to fix broken directory structures/etc after having created and tested the package the first time.

I've run into quite a few assets that I see a few screen shots of and then decide I don't like it once I actually try rendering a few scenes with that asset so I want a nice clean way to completely uninstall it.

While i'm all for good organisation i'm not to OCD levels yet, a little organised chaos is fine if i can work with it but perhaps your's is the way to go to be honest and if it works for you then great but i personal browse through files with the content library tab in most cases, so the folder arrangement is key for me, i rarely if ever use smart content any more, not comprehensive enough, too much gets lost.

This formatting you do when turning a non-DIM into a DIM package, it must be time consuming, though not more than what i'm currently attempting i expect, i wonder if you could structure a package file so that instead of installing in the conventional structure you could have it so you could DIM install into a preferred structure and still have the benefit of DIM based install and uninstall. I may have to experiment with this, nice mention.

 

[Brother Lui]

For newbs like me with few days experimenting with Daz (not even a week) and with 112 assets what I felt trying to start rendering few things in order to understand how Daz works, was a feeling of nightmare. All the mess in asset folder surely didn't show me that in Daz they doing any serious job. That wasn't a well structure folder that was a complete mess. As I understand you are organizing the whole structure by your self and your articles are helping because many will loose hours trying to find their assets to set up a scene and make 1 render. Thanks a lot for your effort.

 

[Volta]

For newbs like me with few days experimenting with Daz (not even a week) and with 112 assets what I felt trying to start rendering few things in order to understand how Daz works, was a feeling of nightmare. All the mess in asset folder surely didn't show me that in Daz they doing any serious job. That wasn't a well structure folder that was a complete mess. As I understand you are organizing the whole structure by your self and your articles are helping because many will loose hours trying to find their assets to set up a scene and make 1 render. Thanks a lot for your effort.

Thanks for giving me a prompt to update this, it's been a while and i've been using a 50/50 mine and default file structure for a while and i've got some feedback for people looking to try a user made file structure. To begin with i should say i'm currently using self sorted structures for all scenes, props, architecture, rooms and things that go in the rooms, basically if it isn't clothes, characters, poses or morphs i'm self sorting. Why is that, two reasons, it's very easy to classify props and scenes compared to character skins and morphs, an outdoor scene is an outdoor scene, easy, a curvy hispanic looking character morph is defined by both the out of the box skintone and it's morph and generally i don't want to split those up, so how do you file that character, other than by it's generation which Daz generally gets right and when it doesn't it's a typo that is fixable easily.

Now i can say that i've sorted all buildings, scenes and such that i own together in one folder i'm calling "environments" it is significantly easier to work with them, no more "architexture" BS, i've sorted first by setting, fantasy and historic, contemporary, sci-fi and finally landscape, the later is because ultimately an uninhabited landscape is viable for any context or setting i can squeeze it into. Contemporary is further split into interior, exterior and other for those strange ones that are have fully usable inner and outer areas or are for whatever reason outliers, i then split interiors by room types, bedrooms, bathrooms ect. and in the case of open plan living spaces i suffix the folder with "w/bed or wo/bed" to denote if they are viable as bedrooms without having to load the scene.

Yes this took time but once you have a format to go with every other manual install becomes a simple if slightly longer procedure of letting data and runtime do there thing and i really mean leave them the F alone or stuff won't and then filing the rest as i see fit, far better than scrabbling through large badly organised 3rd party file structures.

In time i think i'll get a unified structure for everything in daz, i'm treating people as "figures" now so inside figures there is a folder for non-human figures like the few sci-fi and fantasy models i own, the dragon, the giant and the mindflayer all go in here along with the low res fox i got at some point, then it's humans and goes on to the default daz structure mostly so far.

The most recent experiment i've done is wardrobe, i've gone with an overfolder for all wearables, then split by generation, by gender of wearer (but not for certain things, some are sexless or usable by both, and have a separate folder "general" in my case) then i 'll break down by type, so footwear for example is listed under Wardrobe\G3\Male\!Footwear!\productfoldername
Note that i use !footwear! to make that folder always appear at the top of both the internal daz directory and the windows file explorer, this way i can have non sorted and folders always below the main folders that i sort other folders into, also it means that if i happen to have an odd one like the "get well soon" set that contains bandages rather than convention clothes but functions like clothes, it can remain in the G3 folder without getting in the way of other things and will always appear lower in the directory than a "!" folder. These "!" folders are personal choice, i've got !footwear! in both G3/M and G3/F but have a separate !underwear! folder for the women, just because i don't have the number of products to warrant a separate folder for men's underwear, instead underwear and swimwear are grouped for men in my structure, no it's not perfect but it is more practical than a large number of very picky "!" folders.

my next group to split is hair props, can't sort by gender in many cases i'll find something that works, probably by type, curly, wavy, straight or w/e, i'll get there in time and try to keep this up to date, on the whole i advise people to get a handle on things before it gets out of hand, it's easier to file something away once rather than have to do what i'm doing and refile it later, yes many product providers offer subpar organisation in their products and while i love the product if you can't find it you won;t use it, which sucks when they can cost quite a lot. I would prefer that DAZ would enforce a more orderly structure if the product dev wants to sell on the daz market place, i would understand if renderosity and renderotica where less well ordered but often they aren't. Daz product devs needs to agree on a structure and bloody stick to it.

 

[Marzepain]

i created a thread called "Game Assets folder structuring approaches and dimension. Introducing the Theatrical approach." It's not completely on topic as it's not geared to DAZ, but it's related and quite generic.

I think the "Core Knowledge dimension" and "State-Action-Performance dimension" may provide some inspiration for structuring folders. Although your approach is much more fine grained, as you are hoarding assets.

The "Story Development dimension" may be helpful if you have a story to support with assets or a project where assets get "replaced" over time.

Anyway, keep up the good work!

 

[Volta]

i created a thread called "Game Assets folder structuring approaches and dimension. Introducing the Theatrical approach." It's not completely on topic as it's not geared to DAZ, but it's related and quite generic.

I think the "Core Knowledge dimension" and "State-Action-Performance dimension" may provide some inspiration for structuring folders. Although your approach is much more fine grained, as you are hoarding assets.

The "Story Development dimension" may be helpful if you have a story to support with assets or a project where assets get "replaced" over time.

Anyway, keep up the good work!

An extremely long an thought out thread you got there, while a lot of it is well beyond the purview of this thread they are very much of an ilk and deal with similar problems, worth a mention at the very least.

Things like naming conventions for files and keeping things tidy is universal when working with large numbers of lies but your list of approaches has me scratching my head, lots to consider for sure.

It's always good to get the view of someone outside of your own area of expertise, it's no secret i'm not much of a programmer, as far as organisation goes i don't generally work on the scale that you seem to be familiar with.

What i do notice however is that the complexity of the organisation needs to be proportional to a combination of both the variety and amount of content being organised, i would likely need a significantly more complex file structure for DAZ than for a modest VN, however a larger more involved game with structures like you have described could well need a more specific structure, especially considering that this sort of organisation in a daz sense will never be automated, whereas a decent workflow for a game designer may well want automated elements which would require the sort of convoluted approach that would be more than able to handle a project of significant size.

So on the whole i can see what your getting at, it's interesting and while not totally transferable or relevant to DAZ there is a hell of a lot of common ground here, thanks for the link.

 

[Marzepain]

An extremely long an thought out thread you got there, while a lot of it is well beyond the purview of this thread they are very much of an ilk and deal with similar problems, worth a mention at the very least.

Things like naming conventions for files and keeping things tidy is universal when working with large numbers of lies but your list of approaches has me scratching my head, lots to consider for sure.

It's always good to get the view of someone outside of your own area of expertise, it's no secret i'm not much of a programmer, as far as organisation goes i don't generally work on the scale that you seem to be familiar with.

What i do notice however is that the complexity of the organisation needs to be proportional to a combination of both the variety and amount of content being organised, i would likely need a significantly more complex file structure for DAZ than for a modest VN, however a larger more involved game with structures like you have described could well need a more specific structure, especially considering that this sort of organisation in a daz sense will never be automated, whereas a decent workflow for a game designer may well want automated elements which would require the sort of convoluted approach that would be more than able to handle a project of significant size.

So on the whole i can see what your getting at, it's interesting and while not totally transferable or relevant to DAZ there is a hell of a lot of common ground here, thanks for the link.

Thank you for your reply. You're the first one who said anything about it, I completely overdone it or it's not such an interesting topic for people. It's probably both.

Off course the models your DAZ folder span multiple games so you have bigger structure on your hands. I already mentioned that the "Story Development" dimension was not really relevant for your situation, but I now realize that even the "Core Knowledge" may not apply, because a model can be Character, but with a golden skin be a Award prop or with a marble skin a statue part of the location.
I rattled my brain a bit about Film and Theatre, where I "lend" the "Story Development" and "Core Knowledge" ideas from and the part relevant for you may be Casting. The Casting professionals have the similar problem with human models as you have with your DAZ models and the have dealt with it for over 100 years, but of course it's not exactly the same.
I have found Casting agencies that cast for film and theatre that search applicants on dimension like male/female, elegant/muscular/overweight or the more colorful descriptions like "imposing", "scary" or other story FUNCTION related labels.
Using something like "imposing" would enable you to open your "imposing" folder and check at a glance if your story or visual you're creating is best served with an "imposing bandit", "imposing demon" or "imposing soldier" or whatever else pops out of there.
Then you are playing the same part as Visual Director interacting with his Casting Management, Prop Master and Set Creator.
Maybe folders and files are not the ideal place to put these function labels and are these functional descriptions better put in the searchable tags of your models. Although I'm not sure if DAX supports tagging and searching on tags.

By the way when searching the web for the way Casting companies handle their categories, I found endless scamming Modeling agencies. Those are significantly less helpful in this regard.

Another angle is in visual sports like bodybuilding have body type descriptions like Endomorph, Ectomorph, Exomorph. As sport are generally more about performing then looks this probably isn't a fruitful avenue.

For non human human model categories you can draw from AD&D as those books are essentially a beastiary. I thought you mentioned something similar already, but I wasn't sure.

I hope these suggestion are a little bit more applicable for DAX. As I have much to learn about DAX I might be wildly of base here. My intention is to help, but it may not always work out that way.

 

[Volta]

Thank you for your reply. You're the first one who said anything about it, I completely overdone it or it's not such an interesting topic for people. It's probably both.

Off course the models your DAZ folder span multiple games so you have bigger structure on your hands. I already mentioned that the "Story Development" dimension was not really relevant for your situation, but I now realize that even the "Core Knowledge" may not apply, because a model can be Character, but with a golden skin be a Award prop or with a marble skin a statue part of the location.
I rattled my brain a bit about Film and Theatre, where I "lend" the "Story Development" and "Core Knowledge" ideas from and the part relevant for you may be Casting. The Casting professionals have the similar problem with human models as you have with your DAZ models and the have dealt with it for over 100 years, but of course it's not exactly the same.
I have found Casting agencies that cast for film and theatre that search applicants on dimension like male/female, elegant/muscular/overweight or the more colorful descriptions like "imposing", "scary" or other story FUNCTION related labels.
Using something like "imposing" would enable you to open your "imposing" folder and check at a glance if your story or visual you're creating is best served with an "imposing bandit", "imposing demon" or "imposing soldier" or whatever else pops out of there.
Then you are playing the same part as Visual Director interacting with his Casting Management, Prop Master and Set Creator.
Maybe folders and files are not the ideal place to put these function labels and are these functional descriptions better put in the searchable tags of your models. Although I'm not sure if DAX supports tagging and searching on tags.

By the way when searching the web for the way Casting companies handle their categories, I found endless scamming Modelling agencies. Those are significantly less helpful in this regard.

Another angle is in visual sports like bodybuilding have body type descriptions like Endomorph, Ectomorph, Exomorph. As sport are generally more about performing then looks this probably isn't a fruitful avenue.

For non human human model categories you can draw from AD&D as those books are essentially a beastiary. I thought you mentioned something similar already, but I wasn't sure.

I hope these suggestion are a little bit more applicable for DAX. As I have much to learn about DAX I might be wildly of base here. My intention is to help, but it may not always work out that way.

In many ways it does help, the sorting models are excellent for anything that isn't an "actor", props are easy to sort, be it by function, time period or both in my case the functional approach works wonders, the same can be said of sets and backdrops, you can look at it and easily characterise it as indoor, outdoor, landscape, cityscape ect. and that works fine, this can even be done with hair however it does show up a looming problem, hair can be categorized by style and length, neither is a perfect option though as many are borderline in terms of length, however in some cases hair props have morphs that make them span multiple categories, similarly most hair props have many colour options and can't be sorted in that way, as you would for wigs.

This should give you an idea of how bad it is to sort characters as they have even more difficult qualities to take into account, for starters a character pack will contain both a skin(texture package) and a morph (physical contours and dimensions), they can, and in my case often are, used independently of each other, so long as the base model is the same so for example (G3F or third generation female) the skins and morphs are largely interchangeable and can be mixed and matched. Minor issues of skins intended for models of a vastly different size of morph aside for a moment, that alone makes sorting difficult, as you need to know multiple qualities at a glance, ideally a tag system would work very nicely, not unlike the component based approach you mentioned, the problem is i don't believe this can be done very easily in DAZ by an end user, the alternative is to duplicate the files across multiple component "bins" however the added weight that would add to an already somewhat overfilled program makes me shudder just to consider it.

Even that though is a simplification, all of those character models are subject to a vast number of sliders that can control and add morphs of their own, these sliders are governed by the base model that the figure is working with, as such morphs are not kept in one location or even a consistent location by default. Even if content creators for DAZ did follow a set scheme, which they don't, you'd need to somehow reconcile morphs within the data and runtime folders, two places a wise man would not venture for risk of breaking things he doesn't understand, and morphs that are grouped with character packages.

That last point is perhaps the most frustrating and lingering problem i have with DAZ, if it's a slider it's inside data and/or runtime and i can't go prodding stuff in there without risking error messages and screwing with all of the characters tied to the base model.

It's almost as if DAZ really needs a tag based UI for certain assets, however even then the fact that there are multiple sources for assets and each major site and creator within that site uses slightly different file structures makes going for that approach just bring up the same original issue, DAZ file structures aren't standardised, something i would very much like to see and i suppose that is what i'm doing across my own small horde of assets.

 

[Marzepain]

In many ways it does help, the sorting models are excellent for anything that isn't an "actor", props are easy to sort, be it by function, time period or both in my case the functional approach works wonders, the same can be said of sets and backdrops, you can look at it and easily characterise it as indoor, outdoor, landscape, cityscape ect. and that works fine, this can even be done with hair however it does show up a looming problem, hair can be categorized by style and length, neither is a perfect option though as many are borderline in terms of length, however in some cases hair props have morphs that make them span multiple categories, similarly most hair props have many colour options and can't be sorted in that way, as you would for wigs.

This should give you an idea of how bad it is to sort characters as they have even more difficult qualities to take into account, for starters a character pack will contain both a skin(texture package) and a morph (physical contours and dimensions), they can, and in my case often are, used independently of each other, so long as the base model is the same so for example (G3F or third generation female) the skins and morphs are largely interchangeable and can be mixed and matched. Minor issues of skins intended for models of a vastly different size of morph aside for a moment, that alone makes sorting difficult, as you need to know multiple qualities at a glance, ideally a tag system would work very nicely, not unlike the component based approach you mentioned, the problem is i don't believe this can be done very easily in DAZ by an end user, the alternative is to duplicate the files across multiple component "bins" however the added weight that would add to an already somewhat overfilled program makes me shudder just to consider it.

Even that though is a simplification, all of those character models are subject to a vast number of sliders that can control and add morphs of their own, these sliders are governed by the base model that the figure is working with, as such morphs are not kept in one location or even a consistent location by default. Even if content creators for DAZ did follow a set scheme, which they don't, you'd need to somehow reconcile morphs within the data and runtime folders, two places a wise man would not venture for risk of breaking things he doesn't understand, and morphs that are grouped with character packages.

That last point is perhaps the most frustrating and lingering problem i have with DAZ, if it's a slider it's inside data and/or runtime and i can't go prodding stuff in there without risking error messages and screwing with all of the characters tied to the base model.

It's almost as if DAZ really needs a tag based UI for certain assets, however even then the fact that there are multiple sources for assets and each major site and creator within that site uses slightly different file structures makes going for that approach just bring up the same original issue, DAZ file structures aren't standardised, something i would very much like to see and i suppose that is what i'm doing across my own small horde of assets.

Instead of duplicating you could technically soft links and hard links in Windows and Linux, but you probably don't want to. It's dangerous when deleting from the console and things break, when you move them around.

In my computer science study 20 years ago a student had pissed off the teacher, but the student had put a link from his unix homedir to the root. The teacher deleted his account with rm -rF , meaning recursive delete with force and did it under full admin rights. The command followed the link to the root and started to delete everything from there. The only way to fix everything was by placing back a backup of the full system.

The linking solution aside, it seems like you have a collection of pencils and Creon's that are bundled and boxed together. The bundles and boxes are valuable to you, so you don't want to destroy them. The only solution is to order the physical as optimal as possible and add a virtualization layer on top of it. For normal people that's maintaining a list, for developers that's maintaining a database. A tag system would be a spread out version of such a database, but there are alternatives.
The simplest one is again creating a list or a database, but the problem is that filling it up and maintaining it is a lot of work. It's done by every business on the planet running an administration, but there is a reason they pay people to do that.
The modern one is indexing all your DAX models with what is a search application. That is what Google is constantly doing so they can give you the answer directly from their index on their servers.
I do think it's pretty daft that DAX has no functioning tagging system while they know their physical file system is a mess. I think 3D Max and Maya had a tagging system 20 years ago.

As a related note I'm looking into creating a layer to decouple assets from code. It's an ID-Asset path list/index so the code that want to use an asset first looks up an ID in a list and then uses the associated Asset path to get to the asset. When the assets get moved around by and artist, for instance after a release, only the path associated with the ID has to change. And that it's open is kind of important to me, so I can fix broken games without having to stomp through the code.

By the way, what I forgot to mention in a previous post is a way of categorizing archeological finds.
I had to do some archology myself on my notes, but it's these 2 links by the British Museum. There going all out on the details here.

You must be registered to see the links

You must be registered to see the links

It's actually a guide for members of the public, generally those with metal detectors.
I'm sure it's overkill for you as I assume you don't find your DAX model while digging through the English countryside.