Redacted

cridgitcridgit Posts: 1,757
edited December 2022 in Daz Studio Discussion

Whoops, all gone.

Post edited by cridgit on
«1

Comments

  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • fixmypcmikefixmypcmike Posts: 19,583
    edited December 1969

    A couple of quick comments from my first read-through -- I'll try to go through it more carefully later.

    1) I don't like having a separate category for Earrings -- they should just be accessories for Ears. Similarly, Rings should just go under Hands, or if they must have their own category, then a category for Fingers would make more sense.

    2) I don't think you should have separate categories for PZ2 or MC6 under Materials -- it should be irrelevant for the purposes of metadata whether the actual files are in a folder with .pz2's, .mc6's, or in a DS-format content folder.

  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • fixmypcmikefixmypcmike Posts: 19,583
    edited December 1969

    cridgit said:

    The reason I have put .DS, .PZ2 and .MC6 in separate folders is that DAZ Studio shows all three and if they are all in the same folder I'd only know which one to use based on the extension (which would have to be set to visible in DAZ Studio). If DAZ Studio would recognize these three as the same and only display one of them, we wouldn't need to do this. I know this happens already for DS and PZ2 in the same folder but often these files are in different folders and the user would need to rearrange the files (which I think is a bad idea for 99% of the community).

    I don't mind putting them all in the same folder, but we need to be aware of the implication. What do other people think?

    Cheers

    Ah, okay, makes sense. I always install to dummy folders and only keep the sets I need, but you DO need some way to indicate the 'preferred' set if you keep them all.

  • kitakoredazkitakoredaz Posts: 3,526
    edited December 1969

    I understand, If I want to change root category grouping much,it cause more problems.:)
    (so I thinki it is better the root grouping is more strictly divided, obj and other files,
    we can not talk about obj and many preset files at same time)

    Now I think,, I can talk about how assigned files to the category which decided already,
    or about new child category.

    and my interesting is almost about wardrobe and accessory ,attachemet categorize.
    they decide how my character look.

    these items are in category about character appearance.

    and the most important things for me to categorize wardlobes,
    is how cordinate figure easily from many suitable choise.
    in other word how cordinate and cover parts of body is first decided.

    each innner parts>> outer parts>> then apply accessory.

    my suggesiton.

    Glove should be child of wardlove category.

    if glove is accessory has sense in real life categorize, but I think it is better in wardlove category.
    because I cordinate as body parts, first I set almost every item which coverd body.
    Gloves has many type, but it covered most of hands and arms part.

    I think accessory category should be small item and it can easily changing as you feel.
    rings, bungles, or neck,,

    but gloves decide about how your arms parts looks. if you change it, the looks
    change significantly.

    and it covered a most of hands or arms.

    eg abiout game character, glove is one parts of costume.
    of course the glove category need child category full arms or hands.

    I want categorize how I can easily cordinate.:coolsmile:

  • kitakoredazkitakoredaz Posts: 3,526
    edited September 2012

    and one more thing,,,

    there is scene and sets category for each props .
    I think everytime, why there is not full-set for wardlobe category?

    that means it is category for full cordinate sets of the products.
    if you click the pointer file, it load every items for cordinate figure of the products.
    now we have sub sets files.so if vendor make the sub sets file for their products,
    I think we can load it at once.

    it is pity that I can not fit-to ore parent every items when I load sub sets now,
    but I think it seems easy to auto-fit some items and parent items at once
    by other preset files (or script).

    so if bendor provide sub sets for all items, and for auto-fit files,
    we wil categorize them in smart contents.
    If I choose products sets and one click icon, which can load all items of the products,
    it seems great,,,

    edited
    (now I find the way to make sub-sets with auto-fit!!)

    Post edited by kitakoredaz on
  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • kitakoredazkitakoredaz Posts: 3,526
    edited December 1969

    Thank you ^^

    then, I understand I can make category freely, but if every user change category as they like,
    vendor products information and their categorize items,seems difficutl I think,,
    (I hope, not so tweak meta-data or categorize by myself^^;
    if the products was good categorized with rule,, and have right
    meta-data,
    and without no bug,,)

    before I hope layer looked products series.

    that need strict categorize and the category decide maybe basic size or length or thickness of the each item.

    I hope if I choose one category, I can change more freely
    without big poke through, that is like character making in 3D games.

    I can freely change and choose items if I keep category,,
    now if I change underwear,, it may cause big poke through,,,

    so I think if user so many change category by himself, it can not decide
    guide line for layer look,,
    (though it is only one who hope the layer look costume series,,)

    but I thought if vendor make each items in the size, with guideline of categorize for layer look products series,
    if DAZ can make new line up,,,,:)

    and I made many products full costume sets, today,,why I do not hink that before^^;
    iti is so useful!!!

    yes,, I make category 1 under the wardlobe, as you say! of course!
    and 2 under the my category> fullset

    (I made it by subsets,, but it is same as sciene,, in ds 4.5)

    and make compatibility with genesis,, so I can find it so easy,,

    next I made reference in the original product , and make new comatibility base
    under the product base then declare it as fullsets,
    it seems goes well , I can serch my full preset in "product" too,

    but some case the file name disappear in content database editor. why?
    I am a little scared so I removed reference from the products.:roll:

  • cridgitcridgit Posts: 1,757
    edited May 2022

    Redacted

    Post edited by cridgit on
  • kitakoredazkitakoredaz Posts: 3,526
    edited September 2012

    sorry out of topic ^^; clear and delete image,,

    I hope more people talk about meta-data ,how categorize is tbest for user.

    ==============
    it seems better do not use this topic for my question,, (more important for another user
    to talk about meta-data categorize,,)

    I just stuck picture when the name has gone,,(before)
    and change name and try again (once I closed ds,,) corrected

    Post edited by kitakoredaz on
  • KatherineKatherine Posts: 329
    edited December 1969

    Hi Guys,

    DAZ now has an official standard for metadata and we will be releasing all products, as well as updating current products to this standard. We would like the community to be aware of this and I will be uploading documentation this week for you. We have done extensive testing on the layout and categorizations and feel that this will allow us to put out metadata that is acceptable to most users. Those who wish to categorize differently in their own database will also have documents teaching them how to do this. Within the next day or so, I will be posting a link here for your reference. In the meantime, you can see the Categories and the Content Types here:

    Default Categories
    Content Types

    I am sure there may be a few things we have forgotten or left off, and can add these in as needed, but after working for over a year to standardize this, we will not be changing the base format. We don't have the time or resources to change the store content multiple times. :) While I know these will not suit everyone, they have proven to be the most acceptable and intuitive to our test groups.

    I will be glad to work with anyone doing metadata for the community. I have noticed several people working on things and we appreciate it. It is my goal to get the tutorial we have online ASAP (Thanks to one our community members for helping with this), and this will allow anyone to learn the ins and outs of Metadata and how and why things get set as they do. :) There are actually several technical reasons behind typing and categorizing content to ensure a well organized database and metadata that works. :)

    As soon as I have the link live, I will post it in here. Thanks again for all your interest and help so far. It is very much appreciated.

    Kat

  • linvanchenelinvanchene Posts: 1,382
    edited September 2012

    Hi Guys,

    DAZ now has an official standard for metadata and we will be releasing all products, as well as updating current products to this standard. We would like the community to be aware of this and I will be uploading documentation this week for you.

    This is very interesting news. Especially having official information and instructions available for everyone will help giving a better understanding why things are done the way they are.

    - - -

    Since the products are being updated I believe it is also very important that detailed instructions about those topics closely related to metadata are included:

    - What is considered "User Data"?
    - What is considered as the "Local Database"?
    - What is considered as the "Product Database"?

    - What is the exact functionality of the "Keep user data" checkbox that can now be found when importing metadata.

    - Which data is saved in the local database and which in the product database.

    - How are the "local database", "the product database" and the "User Data" linked together?

    I have posted more detailed question in another thread that still have not been answered by anyone:


    http://www.daz3d.com/forums/discussion/6123/#80081

    A complete understanding of the process needs to be there to be able to answer questions like:

    How is the checkbox "synch local and product database" in the content DB editor linked to the checkbox "Keep user Data" when new metadata is being imported.

    Are there options to declare metadata on a product level as user data? Is there a toggle off or on switch somewhere on a product level that I can say keep the changes I made to this product put please replace the changes for that product with the new updates the DAZ team made?

    - - -

    Can someone of the DAZ metadata team please have a look at them to see if they are covered in the guide you plan to make available.

    I hope you guide will cover this topics. If not I hope it can be updated to cover those questions.

    Only if the community gets a a complete understanding how metadata is tied into DS4.5 it will be able to use it efficiently.

    Post edited by linvanchene on
  • KatherineKatherine Posts: 329
    edited December 1969

    I'll make sure those get answered in the document. My team is working on the metadata updates, so I am involved in the whole process as well. :)

    Kat

  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • jakibluejakiblue Posts: 7,281
    edited December 1969

    Exact definition of what EXACTLY the difference between "set" and "scene" are, would be helpful also. :-)

  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • linvanchenelinvanchene Posts: 1,382
    edited September 2012

    Cridgit,
    Once again your work, dedication and feedback is invaluable!
    I really really hope DAZ does still take the time to read, think and react to the very important suggestions, questions and remarks you made. I agree with most points and will comment just on those that I think need further thought and attention by the metadata and also the DS software team in general.

    This cannot be stressed enough. The decisions that are made now will affect thousands (hopefully) of users in the future.

    This post turned out longer than I thought. I hope you can find some useful suggestions as well.

    I tried to give many examples and also suggest three new ways of being able to select folders in the different "Smart Content" and "Surfaces", "Paramter", "Shaping", "Light", "Camera" tabs to make full use of metadata categories.

    - Ctrl Click and mark orange several subfolders so that all assets in those subfolder are shown.
    - Alt click one folder to select only those files that are on the selected level but not show those that are in the subfolders.
    - Shift Selecting several folders to create Average Quantity Selections that show only those assets that are placed in both categories and hide those contents of the selected folders that are only available in one of the selected.

    I will also go on to suggest that the "Tag" system of the content DB editor is put into place to be able to search with tags.

    As a bottom line all suggestions made about setting up the metadata system also have to take in consideration how the categorization is displayed and can be used in DS.

    A huge distinction should be made between metadata as a folder structure in the different tabs and the way the metadata could be used as a search function in "Smart Content".

    - - -

    What the world really does not need are other "QWERTY" types of decisions that years later turn out to be rather uneffeciant but are kept being used because now it is to late to change it.

    To give another expample for me it is complety not understandable how one ever had the insane idea to organize the poser library in a way that splits up a "Product" and puts the figure files in one folder three and the material files in another folder three.
    Have you ever tried to find all material settings to Generation 4 clothing that were produced by different texture artists?
    An easy task if you have only 10 Products and are starting out. Impossible when you have installed 1000+ products.

    I stress this not to start a flame war because it shows a very different kind of organization that is featured in the DAZ studio library:

    Thinking on a "Product" level.

    All assets of a "Product" are kept together so you can quickly apply and remove them without having to change into a different top level folder.

    In the DAZ studio library you can simply add a clothing item to the scene and then all material settings are conviniently to be found in a subfolder one level below.

    To me this kind of thinking is what should help solve the rest of the categorization issues.
    Do not ever split up files again that should be kept together.

    Unless! and here comes one important characteristic of metadata:

    One asset can be put into as many metadata categories that it fits.

    If a chainmail shirt can be used as armor and as a shirt just make a checkmark in both categories.

    Just remember the times when library cards where used to put the reference cards (metadata) into different sections while the book (DAZ studio library assets) stayed in one place.

    cridgit said:



    5. Move all subcategories from Animations/By Region/Partial Body into Animations/By Region. The Partial Body subcategory doesn't add any value, as any "by region" asset affects partial body by definition. Then drop Animations/By Region/Full Body because all full body animations will be under By Function.
    Actually to me it seems rather important that there is a quick way to see all Animations (or Poses in the other folder) that affect the Full Body or the Partial Body. Lets have a look at your example:

    /Animations/By Region/Full Body
    /Animations/ByRegion/Arms
    /Animations/By Region/Feet
    /Animations/By Region/Partial Body/Fins


    How would you now be able to select all Animations that affect Partial Body types?
    Lets say you want to see all animations that are for the Arms, Feet and Fins at the same time?
    One can argue that probably one never wants to see all Partial Body animations at the same time. But well maybe someone just wants to.

    To me the proposed default categories give me that option by being able to select the Partial Body top level folder:

    /Animations/By Region/Full Body
    /Animations/By Region/Partial Body
    /Animations/By Region/Partial Body/Arms
    /Animations/By Region/Partial Body/Feet
    /Animations/By Region/Partial Body/Fins

    But in both cases I would not be able to select all poses that are in the subfolder Arms and Feet but not those of the subfolder fins.

    And that now is not a problem of how metadata functions but of how DAZ studio fuctions.

    It would be nice to be able to Ctrl Click and mark orange several subfolders so that all assets in those subfolder are shown.

    Example: Ctrl click
    /Animations/By Region/Partial Body/Arms
    /Animations/By Region/Partial Body/Feet
    And all those files are shown.

    /Animations/By Region/Partial Body/Fins

    are not shown.

    It would also be nice to be able to Alt click one folder to select only those files that are on the select level but not show those that are in the subfolders.

    Example
    Alt Click
    /Animations/By Region/Partial Body

    shows all files that are placed on just the Partial Body level. All files in subfolders like
    /Animations/By Region/Partial Body/Arms
    /Animations/By Region/Partial Body/Feet

    are not shown.


    I cannot stress enough how usefull the function to show only items placed on the selected level would be.

    Especially in the shaping tab there are now several functions that cannot be seperated out indivudiually because they were added in a top level folder and later some subfolder was added.

    Example:
    Shaping Tab
    Please tell me how I can select only those files placed in the folder:
    Torso/Female/RealWorld
    If I select that one all subcategories of the subfolders
    Torso/Female/RealWorld/Morph Kits
    are also showing.

    If there is no way to show only the items of the current selected level it is very important that there are no files placed in the top level category when there are later sub categories added.

    Example:
    Under no circumstances put any files into
    /Animations/By Region/Partial Body

    If files would be put there one would currently have no way to select them without showing all files in the subfolders.

    cridgit said:


    10. Environments are what used to be called Sets, i.e. like a move set where you place your actors and props. Drop environments/Skydome as skies are under Props/Landscape/Sky.


    Me thinks its not a question of either or but a case of they belong into both so users can find them wherever they are looking.

    If I want a Sky just as background prop I will be happy to find it there.
    But if I am searching my runtime for fitting environments I will be happy to have the sky also show up in the Environments folder.

    If the Sky would not show up in the Environments I would probably not remember I purchased it because when I am setting up scenes I just check the Environments folder.

    Metadata gives the option to adjust the strict limitations of file placement of the DAZ studio libraries and gater to organization preferences of a vast amount of different users that think and categorize differently.
    It takes the DAZ metadata team only seconds to make checkmarks in different categories that also fit the asset.
    This time invested will help different users who think differently to find assets in different places.

    cridgit said:


    11. Drop the subcategories under Figures/People/Female and Figures/People/Male. I'm sure there are many many people who categorize their figures differently, so stopping at Male/Female is probably sensible. I'm happy to keep Fantasy Sci-Fi, Real World and Stylized if that's what most people use. Please share so we can make a decision.

    Actually that is kind of a sore point to me with the new categorization system.
    Let me explain how I used to do it:

    All morphs and shapes go into "People".
    All skin textures go into "Characters".

    Why are those two categories important?
    You have "Character" textures that come without morphs. So if I am setting up a new scene my first place to go was always the "Character" folder in "Product" view. There I was able to find all characters.
    The "People" folder I used in "File" view when I was looking for things like elf ears, fins, horns, tails etc

    Then I used the subsystem Fantasy Sci-Fi, Real Word and Stylized to further make a difference.
    Those do seem rather important to me.

    Example:
    Some characters come with elf ears. I put them into "Real World" AND "Fantasy Sci-Fi".
    That way I was able to find them when I look into either subcategories but they would not show up when I was looking for anime, toon characters that only show up when I select "Stylized"

    And last but not least the separation between male and female.

    If I was looking for a male fantasy character I was able to find that one by looking in
    Characters/Fantasy SciFi/male

    Now I am not at all pleased to see only

    Default/Materials/Feminine
    Default/Materials/Masculine

    To me this seems like a loss in quality. BUT it could also be that this is just my personal user preference.
    How deep should the categorization go. It is an important question you raised at point 1.
    Let the user have the option to customize.

    Guess now I would have to set it up this way

    Default/Materials/Feminine/Fantasy SciFi
    Default/Materials/Feminine/Real World
    Default/Materials/Feminine/Stylized

    Default/Materials/Masculine/Fantasy SciFi
    Default/Materials/Masculine/Real World
    Default/Materials/Masculine/Stylized

    Now there is just another problem that wasnt here before:
    Where do I fit character textures for Fantasy SciFi characters that could be both male or female?

    Before it was simple I selected:

    Characters/Fantasy SciFi
    and it would show up. If I needed a more gender specific character texture I would then continue to explore the subfolder:

    Characters/Fantasy SciFi/male

    Now how else could we do it?

    If we have

    Default/Materials/Feminine
    Default/Materials/Masculine

    why not also add

    Default/Materials/Fantasy SciFi
    Default/Materials/Real World
    Default/Materials/Stylized

    So now we are at the next junction of an important feature that it would be nice to have in DAZ studio:

    "Average Quantity Selections" (In german Schnittmenge)

    Example:
    A material is categorized as Default/Materials/Masculine and Default/Materials/Fantasy SciFi

    Give the user an option to show all those materials that fit into both categories but hide those that are only to be found in one by "Shift" Selecting to create Average Quantity Selections.

    For example "Shift" selecting both

    Default/Materials/Masculine
    and
    Default/Materials/Fantasy SciFi

    would only show materials that are to be found in both those categories but not show any other materials that cannot be found in both.

    The Tag system
    In the content DB Editor there is allready an option to assign tags to assets.
    If we would start to use this efficiently this would be another way to give the users the option to actually search for assets.

    To put it differently each asset would then be assigned different tags like "feminine", "Fantasy SciFi", "Weapon" that can be used in combination to show specific files by using the "Search" function.

    At this point in time I really think the metadata team should start to think heavily to start implementing the "Tag" tab of the content DB editor.

    To me it seems the feature is there. It is just a question if someone is willing to make the effort to implement it as well.

    Yes, more work for the allready stressed metadata team. But isn´t the basic idea that if one person spends an hour setting up metadata for a product properly in the future thousands of people can benefit from that work done. And that is what we the customers pay for in the end, isn´t it?

    cridgit said:

    17. Add Poses/Fits for hair and clothing fit poses AND morphs. Yes, we can put fit poses and fit morphs into the same category because then the user only needs to look in one place. Does the user really care if its a pose or a morph? No. I’m happy to hear if anyone disagrees and think we MUST keep morphs out of the Poses category

    Well actually there is that one thing that is quite annoying. There are poses that also apply a morph when selected.

    Examples:
    Gorilla for Genesis automatically applies the Gorilla shape with the pose.
    The W.A.S.P. automatically applies the M5 V5 shapes with the pose.

    Now if I see a pose in the "Pose" tab that I like and select it I often ended up going shouting "NOOOOO" a few seconds later because the morph was also applied. Of course one can undo but I then started to put all those poses that also apply morphs with the poses into a separate category.

    Then I will remember to also press select when clicking the icon to apply the pose so an option window pops up where I can uncheck the morphs of being applied as well.

    I can see that with hair this is less of an issue. I can see that there poses and morphs are more or less the same. But then there comes the question of consistency.

    Generaly speaking:

    To me it is important to make a distinction between files that just apply poses and those that apply poses AND morphs at the same time.

    In general as a user I agree very much with you on all the things you wrote about apply inject remove. We do not have to understand how it is done. The important thing is if something is added or removed. But then again on that topic I have not enough knowledge to tell if there is some point to make a difference between inject and apply, morphs and poses in each case.
    To me it only seems important to make a difference when the behaving is different (like in the case where morphs and poses are applied.)

    What is important to me is the structure of the folders. I do not want to search for the remove option in a different folder tree then the apply option.

    I prefer
    Product/Apply
    Product/Remove

    and do not like this structure at all

    Apply/Product
    Remove/Product




    25. Shaping is an interesting one because it can contain a huge number of morphs (e.g. all the morphs++ packages). I believe users want to keep morphs organized by region, e.g. head, body, eyes, visemes, expressions etc. Within the the default Apply, Inject and Remove subcategories proposed by DAZ, I recommend creating subcategories by region. However, as a user I might want to inject a morph and remove it, then inject another one and remove it. If this is the case, it would be better to organize inject and remove morphs by region so I can select the head then inject/remove without having to change categories continually. You can see the difference with the yellow labels (+Shape and -Shape). I'd like to know what people think of this concept.

    For the time being, add Shaping/Inject/Body with subcategories Arms, Feet, Hands, Legs, Lower Torse, Upper Torso. Add Shaping/Inject/Head with subcategories Ears, Expression, Eyes, Lips, Lower Face, Mouth, Nose, Tongue, Upper Face, Visemes. Duplicate this structure in Shaping/Remove.

    Me also thinks that this is very important. I do not want a top level folder Inject Remove but a top level folder of the pose / morph and then a sublevel folder to remove it again.




    29. Many many products come with multiple materials split into subfolders, e.g. by type (DS, PZ2, MC6) or by resolution (hi-res, lo-res) or otherwise (Default/Ubershader/Ubersurface/Elite HSS/SSS, P5/P6/P9/PP, Gloss/No Gloss, Shader/No Shader) etc. What is the best way to categorize these different materials? Do we create subcategories by the above types within the Materials category tree? If we put everything in the same Materials category, the user will not know which is which.



    Also another sore topic from me.
    I am not a poser user and all those unwanted material options confuse me.
    BUT I may be a carrara user in the future and may be greatful for any material options that are in the future included for both DS and Carrara. So what to do with them?

    There should be some serious thought put into this. Again the solution may be with a "Tag" Filter system that lets the user show up only some material or file types. For example it should be easy to implement a function to just hide all .mc6 files in smart content and maybe as well in the DAZ studio library.

    I think it would be unwise though to start a double categorization for all poser / carrara files.

    I started to do that first. Dumping all poser material files into a /Materials/Poser folder but I later realized that because I was doing that I might never be able to share my metadata with other people because it might upset them if they actually want those poser materials in the same folder.


    30. Where do we place vehicle or mechanical weapons e.g. fighter jet, submarine, tank, catapult, artillery? What would a suitable Weapons subcategory be?

    As noted earlier things can be placed into different categories.
    I started to use "Themes" for things like that.

    Theme Combat with Area subfolders like Land, Air, Water, Space
    or weapon type subfolders like Melee, Guns, Swords, Staves,

    For example:

    Themes/Combat/Area/Land
    Themes/Combat/Weapons/Swords


    Now again remember that things can be placed into more than one category.

    Example Jetfighter:
    Make one checkmark in Default/Transportation/Air and the other checkmark in /Themes/Combat/Area/Air



    29. The Fabricator and related add-ons. I'd like to keep the Fabricator assets together and not split them up across the Shaders subcategories.

    I had a good laugh when I read that one.

    This was one of the first times when I filled bug reports last december about metdata.
    In surfaces tab there were different categorizations named "The Fabricator" and there was "Fabricator" with subcategories.

    Back then I wrote quite a long rant about how important it is to think of addon products and how they will be implemented in the future.
    Should all fabricator addons be added into a subfolder of fabricator?
    Will later users still know what "The Fabricator" is when they buy a shader product and will they know to look in a subfolder there or will they just search for the shader product name and not think to look in a "Fabricator" subfolder?

    What the metadata team ended up doing was at first to add all addons as subfolder to the fabricator but then later on stopped and added them as separate folders.

    So thats the result now: A mix between both instead of either or.

    I guess this is a fitting last example. It is not enough to just look at the product in question. It is very important to keep in mind past products and future addons. Does it all fit together nicely?

    - - -

    In short

    There should be made more effort of actually using the ability of metadata that it is a reference that can be placed into different categories.

    Implementing the Tag System of the Content DB Editor can give the option to search for assets that fit different categories.
    Implementing keyboard shortcuts like Ctrl, Alt and Shift can give the option to display the contents of several, just one or an Average Quantity Selection of categorization folders.

    It is very imortant that now it is deceided once and for all how to handle it. To me it really seems better to take some time to listen to feedback and then start the colossal task of fixing or redoing metadata for ALL existing DAZ content instead of just implementing another "QWERTY" type of solution that will years later impact whole generations of content users.

    I know this was once again a very long text to read through. I hope you found some useful suggestions.

    Post edited by linvanchene on
  • jakibluejakiblue Posts: 7,281
    edited December 1969

    Put the "pose" folder that contains the MATS for an outfit, inside the outfit folder. And do the metadata from there. That way, you are not scroll-scroll-scrolling, or changing to another folder, to find the MATS that go with something. (this is for DS,not poser)

  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • zigraphixzigraphix Posts: 2,787
    edited December 1969

    Great thread. Here are a few of my thoughts:

    7. (and 14) Anatomy vs. Props/Anatomy… do people think of these as props? I tend to think of anatomy e.g. wings as something different from a prop. Attachment, possibly.

    9. Brilliant.

    10. Environments -- what's the difference between these and props? From a user's point of view? Is a building a Prop or an Environment? This needs to be made clear or eliminate this distinction. #23 - I thought these were Environments? Is the distinction that Scenes have multiple items loaded, including lights and cameras? That still feels like an Environment to me.

    11. Agreed on dropping fantasy, etc. subcategories. Those should be themes.

    26. I would leave visibility in utilities.

    17. Fits -- should these be in poses at all? This confused me terribly when I first started using DS. I don't care if they're implemented as poses or morphs-- doesn't it make more sense to call them .../Presets/Fits?

    25 - Shaping vs. poses - visemes and expressions tend to feel like "poses" to most users, not "shapes." Think of a "shape" as something that will be the same for a character in multiple scenes, but a "pose" as being something that will change from scene to scene. How the asset is implemented isn't as important as how the user will want to use it.

    27 - Some armor is probably attachments (do they still exist?) or accessories or something-- what about a protective face mask? This is another area that needs clarification.

    28 - I see "with shoes" poses as a a pose variation, probably needing to stay with the comparable pose. But I don't think I have many of these products, so I may not be the best to answer this one.

    29 - This is a major issue, because newer users are not going to know what they have for plugins, etc. "Quality" indications of some kind would be good. I think I'd prefer some kind of indication on the asset icon, similar to how the icons currently indicate that they are a prop or whatever.

    30 - Think like a user. If it's made to go with a specific vehicle, it needs to be found near the vehicle.

    31/32 - I found the Inj/Rem thing very confusing when I started. I'd select a figure, double-click Inj, and apparently nothing would happen. On the other hand, if I hadn't done that first, I'd try Apply and again nothing would happen. I have a terrible time teaching people to use these. Whatever is done about these, they need to be more clear somehow about what you do with them. Ideally Apply would automatically Inject the morph with the same name, and REM would only be visible if the selected item had the morph injected. I realize that's a code change, not a metadata standard change, but it needs to be dealt with in a way that makes sense to users.

    33 - Probably because the UV maps are sometimes different, but I could certainly live without this. If the mat will only work with a specific figure, it should be configured as such. Otherwise, it's up to me to decide if something looks "masculine" or "feminine" on my figure.

    34 - Utilities, isn't it? Or some other kind of supporting asset? You don't click on these, do you?

    35 - Lights that change a scene need to be in their own location, and I'd rather it isn't called "Shader," even though that's what they are from a technical perspective. (Cameras are shaders too, after all.) Default/Lights, please. Lights that are just props go in Props. Maybe lights that do both should be categorized in both places?

    36 - Magnets need to be their own category, and it should be somehow related or near INJ morphs.

    37 - I'd say Materials/Skin. If people don't like that for BEO Ripper, etc., then the whole category should change to Materials/Figures.

    38 - I have a Props/Tools category that covers a lot of these items. I also have a Props/Money category, and Props/Stationery (which is probably where I would put paint). Eiderdown would go under Props/Furniture, handkerchief would go in Props/Accessories, Horse Blanket would go in Wardrobe (assuming it conforms to a horse). Plume and pouch would be accessories. Bathwater/Shower spray I put in an Effects/Water category, personally, along with Effects/Fire, Effects/Magic, etc. I guess these could go in a Props subcategory.

    39 - Fabricator etc, including my own Quilts & Calicos, Pattern Magic, etc…. Most of the time, they aren't actually shaders, but are presets for the DS Default Shader or HSS, etc. Granted, the word "Preset" isn't any more helpful than "Shader." Couldn't all these go in Materials? Beyond that, I personally like having them sorted by type of surface. Fabricator itself would go under Fabric, as would many of the other Fabricator sets. Gemologica kind of points up the problem with Glass as a subcategory name, I admit. "Transparent" would be more descriptive, but wouldn't cover semi-precious stones very well. Then again, those could go in Stone.

    More questions:

    What's the difference between Animals and Creatures? Could they both be Creatures? That seems the more inclusive term.

    Is a vest worn over a shirt, but under a jacket, "outerwear"?

    If we have "Default/Wardrobe/Footwear," why do we also have "Default/Wardrobe/Socks"? Why not Default/Wardrobe/Footwear/Socks?

    Do elbow ruffles go on Arms/Upper or Arms/Lower, or do we need "Elbows"? (cf Knees)

  • zigraphixzigraphix Posts: 2,787
    edited December 1969

    Addendum: if something can't be used because something else has to be used first, e.g. shader presets that require the shader to be applied first, Apply morphs that require INJ to be used first, gray out the item until it can be used, and show something about the prerequisite to the user, or automatically apply the prerequisite.

  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • linvanchenelinvanchene Posts: 1,382
    edited October 2012

    cridgit,
    Thank you very much for taking your time to read through this.

    cridgit said:



    As a bottom line all suggestions made about setting up the metadata system also have to take in consideration how the categorization is displayed and can be used in DS.

    A huge distinction should be made between metadata as a folder structure in the different tabs and the way the metadata could be used as a search function in "Smart Content".


    Agree on point #1. Its all about the *user* not the internal design of the software. Sometimes we forget that and try tog et the user to adapt to technicalities.

    Not sure I understand #2?

    Well basically I wanted to say that metadata has two functions:

    1) The path structure of the "Categories" is responsible of how metadata is displayed in the different "Tabs" like Parameters, Shaping, Poses, Surface, Lights, Camera.

    If the Categories are not set up in a smart way it will be very difficult to use the tabs in a meaningful way.

    2) In the "smart content" tab metadata serves as an alternate way to search for content. By using the Tag system in a meaningful way and maybe also with the keybord shortcut keys I suggested, Ctrl (Category combinations), Alt (specific category selection) Shift (Average Quantity Selections of the selected Categories) one can find in theory those specific assets one needs without browsing through thousands of products.




    I cannot stress enough how usefull the function to show only items placed on the selected level would be.

    Especially in the shaping tab there are now several functions that cannot be seperated out indivudiually because they were added in a top level folder and later some subfolder was added.

    Example:
    Shaping Tab
    Please tell me how I can select only those files placed in the folder:
    Torso/Female/RealWorld
    If I select that one all subcategories of the subfolders
    Torso/Female/RealWorld/Morph Kits
    are also showing.

    If there is no way to show only the items of the current selected level it is very important that there are no files placed in the top level category when there are later sub categories added.

    Example:
    Under no circumstances put any files into
    /Animations/By Region/Partial Body

    If files would be put there one would currently have no way to select them without showing all files in the subfolders.



    Hmmm, I'm not completely with you on this one. I agree it could be useful to toggle recursive on/off. Currently, Smart Content is recursive while Content Library is not. Personally I find the recursive view much better. From my perspective, the guideline is you place assets in subcategories when it is clear which subcategory they belong to, but leave them in the parent category when it is not clear. Otherwise you force people into having too many subcategories or the dreaded "Other" subcategory.

    I could argue that parent-child folder is a hierarchical relationship and therefore everything within a child or descendant subcategory is related to the current category. Therefore, by definition the recursive view makes sense. I can support having this as an option (a toggle button) but taking away this feature removes a very powerful user experience, IMHO.

    I also would under no circumstance want to remove the "recursive" view in all tabs that feature metadata. That contents of folders that are on lower levels are also displayed is what makes browings like that so much more powerful than the folder view in the Content Library.

    BUT because of the "recursive" view there are several implications what a smart folder structure is and what not.

    Danger number 1 really is that some categories cannot be selected individually anymore when more and more Child levels are added.

    We really have to look ahead a few years and imagine how things will look like when we have several 1000s of products installed. The more child levels are added the more difficult it will be to find any assets that are placed on higher levels. Also we have to keep in mind that many of the assets that are placed in the shaping and paramters tab cannot be found in the Content Library. So there is no alternate way to look at them in a normal folder structure. So I guess this problem goes beyond just the metadata team but also concerns all those who set up the categorization for morphs and shapes.

    If I would have to set a some rules when making metadata categories they could be:

    1) There always has to be a parent category.
    2) NEVER put any assets in the parent category
    3) All assets go in child categories one level below the parent category.


    Again the examples:

    Torso/Female/RealWorld (Parent Category)
    Torso/Female/RealWorld/Morph Kits (Child Category)

    /Animations/By Region/Full Body (Parent Category)
    /Animations/By Region/Partial Body (Parent Category)
    /Animations/By Region/Partial Body/Arms (Child Category)
    /Animations/By Region/Partial Body/Feet (Child Category)
    /Animations/By Region/Partial Body/Fins (Child Category)

    Now implication of the this folder structre wher you can also see the content of Child Categories when selecting the Parent Category is that each Child Category might also end up being a Parent Category at a later point.
    This is what happend in the Torso/Female/RealWorld example.

    At first Torso/Female/ was the Parent. Torso/Female/RealWorld was a child. All fine. No Problems so far.

    Then at a later point an addon morph product was released. Torso/Female/RealWorld/Morph Kits now became a Child of Torso/Female/RealWorld

    The very dire consequence is that now all morphs placed in Torso/Female/RealWorld cannot be dislayed without also displaying all child morphs in Torso/Female/RealWorld/Morph Kits

    Now the question seems how could this have been prevented?
    Well it could not have been. The problem is allready there from the beginning because of the nature of the level structure that content of all children is displayed as well..
    The rules I suggested cannot be followed if later Childs are added below Partents.
    The rules may be useful when it is about setting up a categorization for a single product that will not have any addons.

    If there are addons it might be useful to add addtional level on the same level as the original child level and not transforming child levels into new parents.

    It is allready quite inconvinient now to find the original morphs. Imagine what happens when Morph Kit 2,3,4,5 and so on are released. There soon will be hundred morphs with no option to only display the ones in the parent folder.

    I agree with you that it is not an option to remove the Recursive view. But there has to be some kind of toggle system as you suggested implemented as soon as possible.

    Thats why I suggested giving some functionality to the Ctrl, Alt and Shift keys when selecting categories in the different tabs.

    @ Tags

    I do recognize that the Tag system is allready being used. But unfortunately very restrictive.

    My suggestions would be that:

    All Categories of an an asset are also added as tags.

    That way one can also enter multiple categories in the search field to narrow the displayed items down. This is much more faster than actually clicking through the smart content tab and searching around where an item has been placed.

    The most important thing to remember is that any folder or level structure is a limitation in itself. Metadata is like a clould of data that should be able to be arranged in many different ways depending on the task at hand.

    If Tags and the Categories are the same one can search for combinations of Categories by entering Tags.

    Now this way the folder structure is not important anymore and becomes flexible.

    Lets have a look at some examples

    All female character skins get the tag Materials feminie. All elf ears are asigned the tag elf then in theory I should be able to find all female characters with elf ears.
    You can try for yourself if currently that is fully working My search only spit out one product but I do know there are a lot more characters with elf ears I purchased. Let´s be fair I know that the metadata team had their hands full with a lot of things.

    Lets look at a current example:
    Nautibikini Skirt

    It has been assigned exactly one Tag. Nautibikini Skirt.
    The most basic functionality is there. Users who are searching for Skirts can also find it. But those who enter the combiniation Swimmwear and Skirt because those are the normaly used categories will not find it.

    The category assigned was Wardrobe/Swimmwear/Bottoms

    So what I am suggesting to also add the Tags Wardrobe Swimmwear Bottoms Bikini Skirt
    The more Tags that fit the better.

    At the moment the tags are mostly only the name of the product and the name of the asset.

    Again at the moment it may seem rather redundandent to add the categories used also as tags. But as soon as you have 1000 or more products with metadata you will see how incredible powerful the search function then could become. Instead of clicking through the smart content tab users can then just enter the words they are looking for in the search field. And again it will be the combinations that make this more useful than just browsing by categories.

    - - -

    I hope that cleared up what my intention was. I am sorry I always write so much. English is not my native language so I try to give as many different examples to really bring my point across.

    I hope the DAZ team can find a solution to select some Categories in the Tabs with Alt or to toggle on off some switch if the content of Child Categories is also displayed.
    If the suggestion to add the Categories as Tags would fall on open ears I would also be happy.

    Post edited by linvanchene on
  • cridgitcridgit Posts: 1,757
    edited December 2012

    Whoops, all gone.

    Post edited by cridgit on
  • zigraphixzigraphix Posts: 2,787
    edited October 2012

    Rats. I really thought I posted a response to this earlier, but it doesn't seem to have shown up. :(

    cridgit said:
    Hi zigrafix, thanks so much for sharing your thoughts. Hopefully I've responded to everything.

    I've left a few open question for you/other people to respond to, but overall I think we're about 90% aligned.

    Cheers

    zigraphix said:

    7. (and 14) Anatomy vs. Props/Anatomy… do people think of these as props? I tend to think of anatomy e.g. wings as something different from a prop. Attachment, possibly.


    There are Content Types for both Props and Attachments (I'm still waiting for someone to explain those confounding convoluted content types to me). But the discussion here is more on categorization (which is separate from content types). Clearly we have props, but the question is whether it is worthwhile creating a new root level category called attachments, or can we make peace with the fact that we find "attachments" in Props? Naturally I'm resistant to creating additional root categories. How important is having a separate category this to you?

    When it comes to items that get conformed or parented to figures, I believe Content Types allow DS to replace an item of the same Content Type automatically. E.g. if the character is already wearing a hat, and the hat is an accessory attached to the head, another head accessory would replace it. Perhaps this only happens with Wardrobe items. I also don't know if this feature is turned on or off by default in DS-- I turned it off several versions back.

    cridgit said:

    zigraphix said:

    10. Environments -- what's the difference between these and props? From a user's point of view? Is a building a Prop or an Environment? This needs to be made clear or eliminate this distinction. #23 - I thought these were Environments? Is the distinction that Scenes have multiple items loaded, including lights and cameras? That still feels like an Environment to me.


    An Environment (I call it a "movie set" in my mind) is like a stage - where you place your props and where your actors perform. A Prop is a static/inanimate object that is used to help tell the story (e.g. a gun) or to add some atmosphere to the scene (e.g. a chair or carpet).

    Simple buildings which you'd simply place into the scene for effect, are props. They are there to provide atmosphere and are often off to the sides or at a distance. There are many freebie examples of such buildings e.g. a barn or a cottage or a simple apartment block. You could perhaps place actors and props next to such buildings, but not inside them or around their exterior. Most building models however, are more complex and have interior or exterior spaces and structures where you can place props and actors. These are what I would call "environments" because they serve a difference purpose - rather than merely decorate the scene, they create the "stage" within which the action takes place. Looking through the DAZ store "Cityscapes and Buildings" category looks to me like all those buildings are Environments.

    See my comment above for the difference between Environment and Scene.


    I think this distinction is vague. I maintain this distinction in my library currently, and I'm often uncertain where to put items. I'm not saying it shouldn't be a distinction, but it needs more clarity. Take a look at Merlin's Tea House, for example. Is it a prop or an environment? What about the version that loads with all the props in place? What if just the teahouse is loaded within the tea garden? I tend to keep all the related props with the scenery in my library currently, but it's problematic.

    cridgit said:

    zigraphix said:

    17. Fits -- should these be in poses at all? This confused me terribly when I first started using DS. I don't care if they're implemented as poses or morphs-- doesn't it make more sense to call them .../Presets/Fits?


    That's what I used to have, but since we moved all the other Presets subcategories (Lights, Cameras, Materials, Poses, Morphs) into root categories, I don't want to create a new Presets root category just for Fits. And somehow it doesn't feel worthwhile to put Fits as a root category. How about Utilities/Fits? That way we're treating Fits the same way as Visibility - you grab it when you need it.

    Utilities seems good.

    cridgit said:

    zigraphix said:

    29 - This is a major issue, because newer users are not going to know what they have for plugins, etc. "Quality" indications of some kind would be good. I think I'd prefer some kind of indication on the asset icon, similar to how the icons currently indicate that they are a prop or whatever.

    Also a very good suggestion. Linvanchene suggested tagging and you're suggesting icon decoration. I think decoration will work for PZ2/DS/MC6 but when you get into hi-res/lo-res or gloss/no-gloss or shared/no-shader etc. then this method might not work.

    My gray-out suggestion might also be applicable. For PZ2/DS/MC6, the regular Content Library offered a good solution-- items of the same name within the same folder would appear as one icon and the DS version would be used, if available. I'm not sure which would be used out of PZ2 or MC6 if both were available and there was no .ds script-- probably PZ2, as it would likely be more compatible. I'd like to see the Smart Content tab work the same way-- if there are multiple presets with the same name, just show the most compatible one.

    This doesn't solve the problem of high vs. low quality versions, etc. If a specific shader is needed (see below), some indication on the icon and/or gray-out should make that clear.

    cridgit said:

    zigraphix said:

    30 - Think like a user. If it's made to go with a specific vehicle, it needs to be found near the vehicle.


    Ok that makes sense. Let's leave it open a bit longer and see what other suggestions come through.

    Actually, I take it back. A weapon intended to be mounted on a vehicle should have a compatibility with that vehicle, and should probably show under Accessories or Attachments when that vehicle is selected.

    cridgit said:

    zigraphix said:

    31/32 - I found the Inj/Rem thing very confusing when I started. I'd select a figure, double-click Inj, and apparently nothing would happen. On the other hand, if I hadn't done that first, I'd try Apply and again nothing would happen. I have a terrible time teaching people to use these. Whatever is done about these, they need to be more clear somehow about what you do with them. Ideally Apply would automatically Inject the morph with the same name, and REM would only be visible if the selected item had the morph injected. I realize that's a code change, not a metadata standard change, but it needs to be dealt with in a way that makes sense to users.


    As far as I know as a professional armchair content-creator this is not a code change but a content issue. Some content does load required morphs whereas some doesn't. Of course we can't update all the old content, but the better quality products do this for you. Also, the readme file is supposed to explain such dependencies.

    I really like your later suggestion about graying out certain options. Not sure how practical that is to build into the software, but the idea holds water.

    Which reminds me... the Readme file should be accessible from within DS-- just launch the default text reader when the user double-clicks.

    As for content trying to load and failing-- it should give the user a warning if it can't perform the desired action, not just fail silently. And if it performs an action that is invisible, it should probably display a message to the user (with an option for experienced users to turn that off.)

    cridgit said:

    zigraphix said:

    33 - Probably because the UV maps are sometimes different, but I could certainly live without this. If the mat will only work with a specific figure, it should be configured as such. Otherwise, it's up to me to decide if something looks "masculine" or "feminine" on my figure.


    Ok this has been cleared up. Masculine and Feminine are for people textures because there are so many of them. Skin is for all other (non-human) figure textures such as dogs, cyborg, whales and butterflish.

    What are you going to do for textures that go on Creature Creator and such?

    cridgit said:

    zigraphix said:

    34 - Utilities, isn't it? Or some other kind of supporting asset? You don't click on these, do you?


    Yes you do actually, to load the Puppeteer morph mixing palette. Its not the sort of thing you use very much so I suppose we could put into Utilities, although logically it belongs with Shaping. I'm still on the fence ...

    I thought Puppeteer was for mixing poses. No?



    36 - Magnets need to be their own category, and it should be somehow related or near INJ morphs.



    I've gone ahead and put these in Shaping/Magnets. Can everyone sleep comfortably at night knowing that?

    Works for me.



    38 - I have a Props/Tools category that covers a lot of these items. I also have a Props/Money category, and Props/Stationery (which is probably where I would put paint). Eiderdown would go under Props/Furniture, handkerchief would go in Props/Accessories, Horse Blanket would go in Wardrobe (assuming it conforms to a horse). Plume and pouch would be accessories. Bathwater/Shower spray I put in an Effects/Water category, personally, along with Effects/Fire, Effects/Magic, etc. I guess these could go in a Props subcategory.



    I have Props/Tools which I supposed could contain some of them. I have Props/Office instead of Stationery (its broader) and I don't have Props/Accessories - maybe that's a good idea because the Accessories root category contains "wearable" or "attachable" accessories. There is an Environments/Effects category but that would be for environment-related rather than prop-related effects. For example, waterfalls and rain would be environmental, whereas fire and drops would be prop-related.

    I used "stationery" instead of "office" because I have a lot of school scenes, but I'm not bothered if it's "Office" instead.

    There probably ought to be Props/Effects/Water, Props/Effects/Fire, etc... for water sprays, candleflames, etc.



    39 - Fabricator etc, including my own Quilts & Calicos, Pattern Magic, etc…. Most of the time, they aren't actually shaders, but are presets for the DS Default Shader or HSS, etc. Granted, the word "Preset" isn't any more helpful than "Shader." Couldn't all these go in Materials? Beyond that, I personally like having them sorted by type of surface. Fabricator itself would go under Fabric, as would many of the other Fabricator sets. Gemologica kind of points up the problem with Glass as a subcategory name, I admit. "Transparent" would be more descriptive, but wouldn't cover semi-precious stones very well. Then again, those could go in Stone.



    Hmmm, Materials instead of Shader. I must admit I've thought that before because as I understand it the only difference between Material and Shader - as I understand it - is that a material is a texture + surface settings for a specific UV mapped object, whereas a Shader is more general and can be applied to any surface. Anywho, what of the idea of dropping the Shaders root category and moving all those assets into Materials? Anybody have an opinion?

    I think I'd want to move them all into Materials, but it needs careful thought. The differences are:

    - A MAT pose or .ds Materials Preset script or MC6 usually applies to a specific object and affects multiple material zones.
    - A .ds shader preset or MT5 changes parameters of an existing surface-- if the surface doesn't have those parameters, nothing happens. However, in DS a .ds script usually applies a new shader if needed... but the Poseworks products didn't do that (I think).
    - A shader adds new parameters to a surface, e.g. sub-surface scattering. Possibly MT5 files ought to go into this category, because the material room does let you add new parameters to a surface. The Poseworks products are good examples of this. ALSO, just to make things confusing, custom cameras and lights are also "shaders," but they get their own root categories currently. And I think most new users find the word "shaders" completely non-intuitive.

    Again, if a script tries to set a surface parameter and can't, because it doesn't exist, it should warn the user, not fail silently. And, just as with INJ scripts, if a shader adds parameters but doesn't actually change anything about how the object renders, applying it should probably show a popup to the user (which can be disabled by more experienced users).

    Edited to add: a key point is that Fabricator and other shader presets that can be used on any surface need to be indicated as compatible with ANY object. I don't know how to do that with the current metadata tools.



    What's the difference between Animals and Creatures? Could they both be Creatures? That seems the more inclusive term.


    Animals are real animals whereas creatures are stylized or fantasy (non-real) animals. I agree we could put all real animals in Creature seeing as that's a broader term, but are people happy looking for their lambs and goldfish among all the demons and wyverns?

    I would be fine with that. I'd rather have the "imaginary" nature of the critter be dealt with as a theme or tag.

    What about toon animals? Robot animals?



    Is a vest worn over a shirt, but under a jacket, "outerwear"?


    Vests go in Shirts, as they can be worn alone/under a shirt/over a shirt. To be honest I'm not super-fond of "Outerwear" but understand it is necessary for coats and jackets. I'm still not convinced we really need any legwear in Outerwear, but I can let it go because I know where to find them.

    Chaps are outerwear on the legs. I think armor would be, too.

    Regarding vests, if they have Content Type "shirts," they'll replace a worn shirt if the user has that feature turned on. Are we talking about the same definition of "vest"? I know the British usage includes undershirts, but I'm talking about a "waistcoat." Or outer corsets, for that matter. Things that usually go over a shirt.



    If we have "Default/Wardrobe/Footwear," why do we also have "Default/Wardrobe/Socks"? Why not Default/Wardrobe/Footwear/Socks?


    Footwear has replaced Shoes (so think "shoes") whereas Socks is for socks, leggings, tights, pantyhose and stockings.

    But this is my point. Socks are also footwear... and many items are a combination of both, or it's not easy to decide whether they are socks or boots. They may even be called something like "leggins." I ended up combining the two categories after struggling with this for several hundred items.



    Do elbow ruffles go on Arms/Upper or Arms/Lower, or do we need "Elbows"? (cf Knees)


    We don't have "Elbows" and "Knees" subcategories so these just go in the parent category - Arms and Legs respectively.

    I've been putting the MFD expansion elbow ruffles on the upper arm, I think... because IIRC, that's where they actually attach. But I could be mistaken. I've never been all that happy with that solution. Next level up is ok, I guess.

    Post edited by zigraphix on
  • gingercakes47gingercakes47 Posts: 382
    edited December 1969

    Just to keep my eye on this thread. Very interested in this development.

Sign In or Register to comment.