All I ask is that Vendors Use The same folder name for each catagory on their products.

13

Comments

  • SpitSpit Posts: 1,604
    edited December 1969


    The poser runtime structure was a mistake and it was recognized fairly early on. Unfortunately, certain things within Poser relied on this structure, and workarounds proliferated until SM decided to drop the reliance on it. The way it should have been done was one folder for each "product" and all support files for that product went in that folder. SHOULDA, COULDA, WOULDA.


    Under the right environment though, this can actually happen. And I have exactly that. :-P


    Kendall


    I have that too, but I do it myself. I only use MetaData for Genesis and DS4 specific stuff. And even there it's because I HAVE TO and it's becoming unwieldy the more content I get. I like it fine for Shaping and Parameters but for anything else it's near useless to me compared to the way I've set up my content in DS3 and in my several runtimes.


    Metadata doesn't really fix 'the vendor thing'. Try looking in Smart Content by Product. Yeah, there are some product names but there are vendor names instead of product names too. It's not consistent.


    Also I have, for example, a freebie from a DAZ PA to go along with a DAZ product but it doesn't have MetaData. What are the chances it gets totally forgotten and never seen again if I rely on MetaData. All I got was crashes when trying to make my own in 4.0 for it. The more gaps in the MetaData in the area I'm using it, the less useful it becomes. Besides DAZ isn't the only place to get Genesis and other DS4 content.


    ps. I currently have 411Gigs of stuff in runtimes (doesn't count the stuff installed in content dirs and My Library) and there's no way I'm going to metadata all of that. Oh and my product directories (which hold everything related) are named "productname_vendor"


    ps2. The Poser runtime was only a 'mistake' because the Poser developer didn't know how magnificently popular the program and content would become years later. Do you have a clue how long ago Poser began?

    d

  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Spit said:


    The poser runtime structure was a mistake and it was recognized fairly early on. Unfortunately, certain things within Poser relied on this structure, and workarounds proliferated until SM decided to drop the reliance on it. The way it should have been done was one folder for each "product" and all support files for that product went in that folder. SHOULDA, COULDA, WOULDA.


    Under the right environment though, this can actually happen. And I have exactly that. :-P


    Kendall


    I have that too, but I do it myself. I only use MetaData for Genesis and DS4 specific stuff. And even there it's because I HAVE TO and it's becoming unwieldy the more content I get. I like it fine for Shaping and Parameters but for anything else it's near useless to me compared to the way I've set up my content in DS3 and in my several runtimes.


    Metadata doesn't really fix 'the vendor thing'. Try looking in Smart Content by Product. Yeah, there are some product names but there are vendor names instead of product names too. It's not consistent.


    Also I have, for example, a freebie from a DAZ PA to go along with a DAZ product but it doesn't have MetaData. What are the chances it gets totally forgotten and never seen again if I rely on MetaData. All I got was crashes when trying to make my own in 4.0 for it. The more gaps in the MetaData in the area I'm using it, the less useful it becomes. Besides DAZ isn't the only place to get Genesis and other DS4 content.


    ps. I currently have 411Gigs of stuff in runtimes (doesn't count the stuff installed in content dirs and My Library) and there's no way I'm going to metadata all of that. Oh and my product directories (which hold everything related) are named "productname_vendor"


    ps2. The Poser runtime was only a 'mistake' because the Poser developer didn't know how magnificently popular the program and content would become years later. Do you have a clue how long ago Poser began?


    Yup, sure do. I was in the 3D industry LONG before Poser had even started. And the Poser structure type, was a known problem WAAAAY back in the IBM mainframe days where that organizational file structure originated. By the time Poser had rolled around, delineating file types and uses by filesystem position had been abandoned long before.


    Kendall

  • GeddGedd Posts: 2,473
    edited July 2012

    Spit said:

    The poser runtime structure was a mistake and it was recognized fairly early on. Unfortunately, certain things within Poser relied on this structure, and workarounds proliferated until SM decided to drop the reliance on it. The way it should have been done was one folder for each "product" and all support files for that product went in that folder. SHOULDA, COULDA, WOULDA.

    Under the right environment though, this can actually happen. And I have exactly that. :-P
    Kendall
    I have that too, but I do it myself.

    Yes, I do also.. and isn't it a pain beyond what most people are willing to go through?

    Spit said:
    Besides DAZ isn't the only place to get Genesis and other DS4 content.

    Yes, changing the DAZ structure is only the first step, and for content from other places scripts would be helpful in reorganizing content to a new format.

    I currently have 411Gigs of stuff in runtimes (doesn't count the stuff installed in content dirs and My Library) and there's no way I'm going to metadata all of that.

    I reiterate my belief that metadata will not fix an underlying problem. However I do believe after the underlying problem is fixed metadata could be very useful. Hopefully scripted solutions will continue to evolve to fill this gap.
    <------>
    How much of that is objs and other items that aren't needed if you are working in DAZ. There is a lot of replica of data that is totally useless for *most* DAZ users. I understand that objs are usefull for doing content creation like morphs etc.. but they should be separately accessible like the uvmaps are. I personally move the readmes out of that and rename them to something that might make a modicum of sense when running 'search.' Readmes are another area that take up space but are useless in their current format for many people.

    The Poser runtime was only a 'mistake' because the Poser developer didn't know how magnificently popular the program and content would become years later. Do you have a clue how long ago Poser began?

    Have to agree with Kendal on this, I tried P1 and quite because of exactly this. I kept hoping it would get fixed but each time I checked back it never had. I have spent the better part of 6 months trying to wrap my brain around this and redo my inventory so I can be productive and am nowhere near where I can focus on producing items and artwork.

    I had to convince myself to pause working on trying to 'fix this' and take the time to try and do a render for the new users render contest. I would like to enter more contests, put some freebies up, etc.. but to me, this is more important as I am non functional in what my brain perceives as an unnecessary convoluted mess.

    Post edited by Gedd on
  • SpitSpit Posts: 1,604
    edited December 1969

    Yup, sure do. I was in the 3D industry LONG before Poser had even started. And the Poser structure type, was a known problem WAAAAY back in the IBM mainframe days where that organizational file structure originated. By the time Poser had rolled around, delineating file types and uses by filesystem position had been abandoned long before.


    Kendall


    Well, I guess the people who used Apples didn't know that. It's always easy to look back in hindsight. You knew such and such back then so obviously everybody else on the planet knew it too. I'll always be grateful to Larry Weinberg for giving us Poser.


    As for the runtime format, it doesn't matter anymore. We can now put absolutely everything in Character. You can relate the texture mats to the clothes by putting them inside the clothes folder which you can put inside the folder for the figure the clothes are for. Same with the props and accessories. You can mix pp2 and cr2 in the same folder if you wish. You can even put the DAZ mats in with the poser mats and not have to switch to the studio folder which is the way I've been doing things for a while now until Studio4 where I feel I've lost a lot of control.


    Metadata is great for those with a modest amount of content or those fairly new who can build up their content over time or those who use mostly DAZ stuff. Go for it. As I said, I'm fine with it for shaping and parameters and DS4 lights and shaders. The other stuff doesn't really do me much good.

  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Spit said:

    Yup, sure do. I was in the 3D industry LONG before Poser had even started. And the Poser structure type, was a known problem WAAAAY back in the IBM mainframe days where that organizational file structure originated. By the time Poser had rolled around, delineating file types and uses by filesystem position had been abandoned long before.


    Kendall


    Well, I guess the people who used Apples didn't know that. It's always easy to look back in hindsight. You knew such and such back then so obviously everybody else on the planet knew it too. I'll always be grateful to Larry Weinberg for giving us Poser.


    As for the runtime format, it doesn't matter anymore. We can now put absolutely everything in Character. You can relate the texture mats to the clothes by putting them inside the clothes folder which you can put inside the folder for the figure the clothes are for. Same with the props and accessories. You can mix pp2 and cr2 in the same folder if you wish. You can even put the DAZ mats in with the poser mats and not have to switch to the studio folder which is the way I've been doing things for a while now until Studio4 where I feel I've lost a lot of control.


    Absolutely, it doesn't matter anymore to the software. However, the legacy remains and continues to affect Poser, and to a degree DS. For the most part, DS ignores the Poser Runtime. Once the geometry and morphs are converted and stored in the data directory, DS works mostly from there. This is why I keep saying that DS *could* go completely DB oriented as the DS users don't use the Poser stuff once the initial work is done. DAZ's support for Poser is the reason that the Runtime persists in Content for DS users. Poser users (on the whole) refuse to move forward, and any attempt to move away from the Legacy Runtime is met with extreme resistance. SM is having a bear of a time getting even a fraction of the Poser base to accept weight mapped figures at all.


    Metadata is great for those with a modest amount of content or those fairly new who can build up their content over time or those who use mostly DAZ stuff. Go for it. As I said, I'm fine with it for shaping and parameters and DS4 lights and shaders. The other stuff doesn't really do me much good.


    There isn't enough Metadata in use, or available, right now for anyone to see any of the power that it can provide. The fact that physical files exist is a limiting factor on the full exploitation of the power that the Metadata can provide. Also, the reliance on storing things in the filesystem is a huge detriment. Especially in the fact that it allows the users to muck with the structure. The users, in the general case, shouldn't need to know anything about the content structure. Nor should a user be allowed to modify the data unsupervised by a control interface. E-V-E-R. If everything were stored in the database, then folks couldn't complain about "I don't like how that folder's name looks on my disk" and on and on, there'd be no folders for them to see. Just content.


    Kendall

  • SpitSpit Posts: 1,604
    edited December 1969

    Gedd said:

    Spit said:
    I currently have 411Gigs of stuff in runtimes (doesn't count the stuff installed in content dirs and My Library) and there's no way I'm going to metadata all of that.


    I reiterate my belief that metadata will not fix an underlying problem. However I do believe after the underlying problem is fixed metadata could be very useful. Hopefully scripted solutions will continue to evolve to fill this gap.
    <------>
    How much of that is objs and other items that aren't needed if you are working in DAZ. There is a lot of replica of data that is totally useless for *most* DAZ users. I understand that objs are usefull for doing content creation like morphs etc.. but they should be separately accessible like the uvmaps are. I personally move the readmes out of that and rename them to something that might make a modicum of sense when running 'search.' Readmes are another area that take up space but are useless in their current format for many people.


    Yes, it is a pain to do but it also helps me to know what I have and as the content grows my organization of stuff such as props and scene stuff matures.


    And, yes, those geometry objects take up their own space but it only becomes a space waste if I actually USE the stuff and a data file is created. I always installed to a temp dir and installed the ds version to same so the textures wouldn't duplicate. (Not now with DS4.) The readme's I mainly trash. Yes, I glance at them. I keep the vendor name as part of the main product folder. The templates take up more room than the readme files anyway so I only keep those that there's a chance I might use for texturing.


    A scripting solution would be great--but I'm not holding my breath for a quick solution. This is my stuff. I've spent money on it. I've spent time on it. I want to see it, touch it, and know where it is. And especially I want to know that everything is accounted for which simply isn't the case in DS4 yet.

  • SpitSpit Posts: 1,604
    edited December 1969

    There isn't enough Metadata in use, or available, right now for anyone to see any of the power that it can provide. The fact that physical files exist is a limiting factor on the full exploitation of the power that the Metadata can provide. Also, the reliance on storing things in the filesystem is a huge detriment. Especially in the fact that it allows the users to muck with the structure. The users, in the general case, shouldn't need to know anything about the content structure. Nor should a user be allowed to modify the data unsupervised by a control interface. E-V-E-R. If everything were stored in the database, then folks couldn't complain about "I don't like how that folder's name looks on my disk" and on and on, there'd be no folders for them to see. Just content.


    Kendall


    Yeah, I see that. Perhaps the cloud is in our future. But you will find some resistance to that. We're not a bunch of worker bees in a corporation who know exactly what data is needed when. Nor are we (well we could be both) just looking through a few dozen games we own that reside in the cloud and deciding which one we want to play now. Even mp3's can get a bit out of hand as far as quantity is concerned thus we have playlists we create ourselves. But if you're like most people, you like to browse a bit else you get stuck playing the same things over and over.


    And we're not just 'users' as you put it. We're not mucking around. We're creative and that mucking often gets the creative juices bubbling. Serendipity and inspiration are very important and poking around in our files can do more than mechanically hitting a random button over and over and over until you're sick of it. Get a kid dressed, add hair, put him in the woods, bend him over a little rock. What does he see there? Michael is watching TV but there's something in the corner he should be paying attention to. Sometimes doing the odd thing like putting a sci-fi object in the middle of a medieval scene works if you've run out of ideas and decide to browse through your runtime full of props and find something you haven't used yet in a folder you forgot about.


    I made my living programming and the clients were definitely 'users' who didn't care about data, only that when they wanted this or that screen the information would show up. We care about our figures/morphs, hair/clothes, textures, poses, and scenes and that's why we buy it. So where ever this may go, to be successful we have to be kept in mind. Yeah, we're not automatons. Though It might be novel for while, it would get boring pretty quickly.

  • Kendall SearsKendall Sears Posts: 1,886
    edited July 2012

    Spit said:

    There isn't enough Metadata in use, or available, right now for anyone to see any of the power that it can provide. The fact that physical files exist is a limiting factor on the full exploitation of the power that the Metadata can provide. Also, the reliance on storing things in the filesystem is a huge detriment. Especially in the fact that it allows the users to muck with the structure. The users, in the general case, shouldn't need to know anything about the content structure. Nor should a user be allowed to modify the data unsupervised by a control interface. E-V-E-R. If everything were stored in the database, then folks couldn't complain about "I don't like how that folder's name looks on my disk" and on and on, there'd be no folders for them to see. Just content.


    Kendall


    Yeah, I see that. Perhaps the cloud is in our future. But you will find some resistance to that. We're not a bunch of worker bees in a corporation who know exactly what data is needed when. Nor are we (well we could be both) just looking through a few dozen games we own that reside in the cloud and deciding which one we want to play now. Even mp3's can get a bit out of hand as far as quantity is concerned thus we have playlists we create ourselves. But if you're like most people, you like to browse a bit else you get stuck playing the same things over and over.


    And we're not just 'users' as you put it. We're not mucking around. We're creative and that mucking often gets the creative juices bubbling. Serendipity and inspiration are very important and poking around in our files can do more than mechanically hitting a random button over and over and over until you're sick of it. Get a kid dressed, add hair, put him in the woods, bend him over a little rock. What does he see there? Michael is watching TV but there's something in the corner he should be paying attention to. Sometimes doing the odd thing like putting a sci-fi object in the middle of a medieval scene works if you've run out of ideas and decide to browse through your runtime full of props and find something you haven't used yet in a folder you forgot about.


    I made my living programming and the clients were definitely 'users' who didn't care about data, only that when they wanted this or that screen the information would show up. We care about our figures/morphs, hair/clothes, textures, poses, and scenes and that's why we buy it. So where ever this may go, to be successful we have to be kept in mind. Yeah, we're not automatons. Though It might be novel for while, it would get boring pretty quickly.


    With respect to our purchased 3d content, we are most definitely 'users.' There's no reason that we should be poking around in the internals of the content. If one needs 'inspiration' on creating another model, then one can look at the wireframe from inside of DS or Carrara (which uses the CMS and Metadata, BTW). If the content were in a DB and it was brought up from a consistent interface (consistent in that there were no errors in "finding pieces" from being deleted from the filesystem) that allowed for searching then there would be no reason to poke. Storage in a DB with metadata would make the content infinitely more searchable and usable than any filesystem based methodologies. Look at the CMS already, there is the info tab, and the Notes/Keywords tabs that allow much more information storage, and more fine grained searching than any filename/folder based method is ever going to allow. And the CMS is pretty basic as far as Metadata systems go.


    Kendall

    Post edited by Kendall Sears on
  • FixmypcmikeFixmypcmike Posts: 12,281
    edited December 1969

    Incidentally, there's no need to have this "loss of control" or duplication with DS4 -- I don't duplicate my texture files (and that's the majority of the space occupied by content, whether in DS or Poser format). You can still use multiple runtimes, you can still keep the textures in one place, neither DS nor Poser requires the Geometries and Textures (and Data) folders to be in the same runtime as the content libraries. You can organize things the way you like without breaking metadata several different ways:
    (1) Use categories instead of the filesystem to organize -- you can even import your existing organized runtimes and convert them to categories with exactly the same structure quite easily.
    (2) Do your file and folder rearranging inside DS4 -- then the CMS will know the new locations and the metadata will still work
    (3) Edit the file paths in the metadata -- if you have a problem doing it within DS4, you can just edit the metadata files directly -- they're plain text and the structure is pretty obvious.

    I agree that there needs to be an automated method of generating metadata -- its usefulness is greatly limited by only partial coverage.

  • DaWaterRatDaWaterRat Posts: 1,640
    edited December 1969



    I agree that there needs to be an automated method of generating metadata -- its usefulness is greatly limited by only partial coverage.


    I'd be happy with a simple editor for the database I could open outside of DS4, so I can edit multiple folders without having to stop and re-open the Content DB Editor for each folder/category, and so that I can scroll through to double check how I have something set up (like if I included a space or not in a folder name), again without closing the DB editor with DS4, and then re-opening it.


    Every time I try to open the db using open office, it crashes. :)

  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969



    I agree that there needs to be an automated method of generating metadata -- its usefulness is greatly limited by only partial coverage.


    I'd be happy with a simple editor for the database I could open outside of DS4, so I can edit multiple folders without having to stop and re-open the Content DB Editor for each folder/category, and so that I can scroll through to double check how I have something set up (like if I included a space or not in a folder name), again without closing the DB editor with DS4, and then re-opening it.


    Every time I try to open the db using open office, it crashes. :)


    ValentinaDB is not Openoffice compatible, nor compatible with much. I'll see what I can do about a quicky CMS DB viewer/editor.


    Kendall

  • DaWaterRatDaWaterRat Posts: 1,640
    edited December 1969



    I agree that there needs to be an automated method of generating metadata -- its usefulness is greatly limited by only partial coverage.


    I'd be happy with a simple editor for the database I could open outside of DS4, so I can edit multiple folders without having to stop and re-open the Content DB Editor for each folder/category, and so that I can scroll through to double check how I have something set up (like if I included a space or not in a folder name), again without closing the DB editor with DS4, and then re-opening it.


    Every time I try to open the db using open office, it crashes. :)


    ValentinaDB is not Openoffice compatible, nor compatible with much. I'll see what I can do about a quicky CMS DB viewer/editor.


    Kendall


    That would be awesome. :) I used to do data entry, so typing directly into the database would probably be much faster for me. And I get tired of all the windows, pop ups and tabs (not to mention the asset type window wanting to close on me if I move my mouse just barely outside of it's boundaries.)

  • GeddGedd Posts: 2,473
    edited December 1969

    ... With respect to our purchased 3d content, we are most definitely 'users.' There's no reason that we should be poking around in the internals of the content. If one needs 'inspiration' on creating another model, then one can look at the wireframe from inside of DS or Carrara (which uses the CMS and Metadata, BTW). If the content were in a DB and it was brought up from a consistent interface (consistent in that there were no errors in "finding pieces" from being deleted from the filesystem) that allowed for searching then there would be no reason to poke. Storage in a DB with metadata would make the content infinitely more searchable and usable than any filesystem based methodologies. Look at the CMS already, there is the info tab, and the Notes/Keywords tabs that allow much more information storage, and more fine grained searching than any filename/folder based method is ever going to allow. And the CMS is pretty basic as far as Metadata systems go.

    Kendall

    Ok, I agree with a lot of what you've said before, but as far as databases go we have *vast* differences here. I won't go into my background as it isn't important here other then to say I've been playing with this long enough to be come a bit opinionated about it.

    Databases blow up. It's a fact. I don't use iTunes or Microsoft's media players because when they blow up they take all of the metadata with them and you are *sc*r*wed*

    Adobe learned this with Photoshop (along with other companies) and they like Mediamonkey with mp3's write the metadata to the files. When the database blows up, it doesn't take anything with it. One simply reloads the db and the db re-reads the folder/file structure and rebuilds itself in minutes. If a single or multiple atomic unit(s) re: file or folder structure is corrupt, it is much easier to have the db catch this after a clean reload and reread of the underlying file/folder structure, and warn/eliminate from import without it breaking the overall structure. A single damaged atomic unit can totally destroy the older format databases requiring an import of a huge db file which also may be damaged (rather than individual items indexed, which can be handled in a much more discrete manor.) If there is an individual item in a database structure that goes bad it can bring down the whole db. Modern dbs don't fix this by making the db stronger because they've found out that is virtually impossible. They do this by making it easy to reread the underlying folder/file structure so one can do a wipe of the db and reload/reread and be back up and running in no time.

    Databases which contain all of the data are a pain in the a** to backup. With the modern structure of separating the underlying data from the database and using the database data as an 'index' of the underlying information, one has total flexibility in backing up part or all, and much more flexibility in restoring same. Backing up is easy, you back up your files. One doesn't even need to worry about backing up the database in these cases and don't need to be a db administrator to back up or restore dbs that follow this protocol.

    As far as poking through it, I have to agree with Spit. Some people have to poke through the internals of something to really be able to interact with it on a certain level. That level is what helps those people create. While I agree that the internals shouldn't be exposed in areas where new people who are just getting their feet on the ground will stumble into it and blow up their system, more advanced and/or adventurous people should have access to their system. This is an area both Microsoft and Apple have wrong in my opinion (although Apple less so.) Microsoft traditionally has exposed too much too soon so that the average user blows up their system unintentionally way too often, whereas apple seals much of it away behind a curtain which creates it's own issues for people who need to be able to modify things but aren't full time programmers etc..

    The metadata model follows a modern format in that it doesn't import everything wholesale into itself but rather indexes the content and for this I am glad. Something that goes hand-in-hand with this though is an exernal file system for the metadata itself like individual xml files which store all of the metadata for a given collection of atomic units (a file for a vendor's specific product, textures, cameras, poses, etc) which can be easily read, stored, backed up and... that other programs can be created to modify and manage. A good example of this is XBMC which stores all of the metadata of the media files in xml formats that other programs can 'scrape and tag' your media files, writing to the xml file XBMC reads. These programs are totally unconnected in any direct way but work together seamlessly. Expanding functionality requires no special programming knowledge of XBMC's API but rather uses any programming the programmer is familiar with to read/write XML files. This is the future of databases.

  • HokuleaHokulea Posts: 0
    edited December 1969

    I started with the free version of DS2, followed by the free version of DS3, before buying DS3 Advanced, and finally the paid upgrade to DS4 Pro.

    A recurring theme through all of these iterations of DAZ Studio is that content organization and management is an absolute nightmare. Especially for a noob like me. In DS4, I don't see the sense of having both a "Smart Content" tab and a "Content Library" tab. Neither one is a satisfactory solution to content management IMO.

    I am so frustrated that I haven't installed the bulk of the content I have purchased in DS4. As such, it doesn't make sense for me to buy any additional content. While I realize I can go into the Content Library and create categories and subcategories, it truly baffles me why it is necessary to do so. Nor does it make sense to me that I have to peruse the readme files for everything I install just to find out where in the hell it is.

    My biggest gripe is the lack of documentation for DS4 as well as Bryce 7. The User Guide for DS4 is still incomplete after over a year and the Bryce 7 User Guide has been a "WIP" for over two years now. While I have downloaded a slew of video tutorials for DS4 and Bryce, they are by no means a substitute for User Guides in PDF format.

    Though I have installed various versions of both DAZ Studio and Bryce, I never seem to get beyond first base as far as using them goes. Even after spending hours poring through forum posts and watching videos. Then there's the issue of not being able to access any product documentation on the old ArtZone Wiki. All these factors combined are quite discouraging.

  • KeryaKerya Posts: 7,244
    edited December 1969

    Hokulea: I am using DS since 1.2 ... LOL
    Anyway, DS4 doesn't stop me using "View as Tree". Content Tab, the little icon with the lines in the upper right corner.
    Tree always makes sense to me. But I am installing to a Temporary folder and rename folders to my wishes, so I really do know what is where.

  • GeddGedd Posts: 2,473
    edited July 2012

    Hokulea said:
    ...I am so frustrated ... While I realize I can go into the Content Library and create categories and subcategories, it truly baffles me why it is necessary to do so. Nor does it make sense to me that I have to peruse the readme files for everything I install just to find out where in the hell it is.

    Thank you Hokulea, you have summarized exactly what I have been trying to say very well.

    Hokulea said:
    My biggest gripe is the lack of documentation

    Here, I reiterate.. a well written product/interface should not need documentation for the basic functions. And though I love Blender, it definitely goes for that also. (Btw,.. this is the area Kia's interfaces (Poser etc..) and products like Carrarra tried to address with things like tabbed areas. None quite got it right for various reasons imo, but they tried. Well done interface design is not easy but it is important. Apple does great interface designs, they just lock the internals away a little bit to securely imo.

    Though I have installed various versions of both DAZ Studio and Bryce, I never seem to get beyond first base as far as using them goes. .. quite discouraging.

    And this is the problem. Lost business, lost opportunities, lost members of the community, and all of the ideas, products and beautiful artwork they would contribute.

    Post edited by Gedd on
  • SpitSpit Posts: 1,604
    edited December 1969

    ... With respect to our purchased 3d content, we are most definitely 'users.' There's no reason that we should be poking around in the internals of the content. If one needs 'inspiration' on creating another model, then one can look at the wireframe from inside of DS or Carrara (which uses the CMS and Metadata, BTW). If the content were in a DB and it was brought up from a consistent interface (consistent in that there were no errors in "finding pieces" from being deleted from the filesystem) that allowed for searching then there would be no reason to poke. Storage in a DB with metadata would make the content infinitely more searchable and usable than any filesystem based methodologies. Look at the CMS already, there is the info tab, and the Notes/Keywords tabs that allow much more information storage, and more fine grained searching than any filename/folder based method is ever going to allow. And the CMS is pretty basic as far as Metadata systems go.

    Kendall

    Kendall, you seem to think that an excellent search function would be the equivalent. It's not. To search you have to have some idea of what you're searching FOR. I don't want to have to be reduced to searching for SKIRT, BLUE, PLAID, SHORT, wearable by AIKO3 or CHAIR, SCI-FI, NO ARMS, SWIVEL. Nothing would kill this 'industry' faster..


    -------Interesting technical stuff snipped--------


    As far as poking through it, I have to agree with Spit. Some people have to poke through the internals of something to really be able to interact with it on a certain level. That level is what helps those people create. While I agree that the internals shouldn't be exposed in areas where new people who are just getting their feet on the ground will stumble into it and blow up their system, more advanced and/or adventurous people should have access to their system. This is an area both Microsoft and Apple have wrong in my opinion (although Apple less so.) Microsoft traditionally has exposed too much too soon so that the average user blows up their system unintentionally way too often, whereas apple seals much of it away behind a curtain which creates it's own issues for people who need to be able to modify things but aren't full time programmers etc..


    Thanks for seeing my point, Gedd.

  • GeddGedd Posts: 2,473
    edited December 1969

    I do agree with Kendell that a well done CMS could be valuable, like tags in Photoshop/Elements, etc.. Metadata is going to be key for most people finding what they want as we go forward and our data gets more numerous and complex. The underground structure will become something that the average user will more often then not ignore. But... that underground structure needs to be well maintained and accessible for those (users, creators, add-on developers, aspiring add-on developers and creators, etc...) that want access to it.

  • SpitSpit Posts: 1,604
    edited July 2012

    Blogs and bookmarks use tags too and they're not always useful. Sometimes a tag (or a new category) will come to mind long after everything you already have has been marked and you start marking new data with that tag. That gives you holes that are never filled in your searches. You need to know your data and to be able to access it from outside the metadata structure to fix problems such as those.


    I think Gedd and I are basically saying the same thing here.

    Post edited by Spit on
  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Gedd said:
    ... With respect to our purchased 3d content, we are most definitely 'users.' There's no reason that we should be poking around in the internals of the content. If one needs 'inspiration' on creating another model, then one can look at the wireframe from inside of DS or Carrara (which uses the CMS and Metadata, BTW). If the content were in a DB and it was brought up from a consistent interface (consistent in that there were no errors in "finding pieces" from being deleted from the filesystem) that allowed for searching then there would be no reason to poke. Storage in a DB with metadata would make the content infinitely more searchable and usable than any filesystem based methodologies. Look at the CMS already, there is the info tab, and the Notes/Keywords tabs that allow much more information storage, and more fine grained searching than any filename/folder based method is ever going to allow. And the CMS is pretty basic as far as Metadata systems go.

    Kendall

    Ok, I agree with a lot of what you've said before, but as far as databases go we have *vast* differences here. I won't go into my background as it isn't important here other then to say I've been playing with this long enough to be come a bit opinionated about it.

    Databases blow up. It's a fact. I don't use iTunes or Microsoft's media players because when they blow up they take all of the metadata with them and you are *sc*r*wed*

    Firstly, those are not examples of databases, but of archive format app storage containers. For the purposes of this discussion (CMS et al) we need to restrict the discussion to SQL databases (ValentinaDB, etc) not the poor excuses of databases that individual apps have foisted on people. The CMS, which is the context here, uses a full on SQL database system, including the control services (hence the need for the TCP communication layer.)


    Adobe learned this with Photoshop (along with other companies) and they like Mediamonkey with mp3's write the metadata to the files. When the database blows up, it doesn't take anything with it. One simply reloads the db and the db re-reads the folder/file structure and rebuilds itself in minutes. If a single or multiple atomic unit(s) re: file or folder structure is corrupt, it is much easier to have the db catch this after a clean reload and reread of the underlying file/folder structure, and warn/eliminate from import without it breaking the overall structure. A single damaged atomic unit can totally destroy the older format databases requiring an import of a huge db file which also may be damaged (rather than individual items indexed, which can be handled in a much more discrete manor.) If there is an individual item in a database structure that goes bad it can bring down the whole db. Modern dbs don't fix this by making the db stronger because they've found out that is virtually impossible. They do this by making it easy to reread the underlying folder/file structure so one can do a wipe of the db and reload/reread and be back up and running in no time.


    Again, you cite an application specific storage container, not a DBMS. Two completely different worlds.


    Databases which contain all of the data are a pain in the a** to backup. With the modern structure of separating the underlying data from the database and using the database data as an 'index' of the underlying information, one has total flexibility in backing up part or all, and much more flexibility in restoring same. Backing up is easy, you back up your files. One doesn't even need to worry about backing up the database in these cases and don't need to be a db administrator to back up or restore dbs that follow this protocol.

    As far as poking through it, I have to agree with Spit. Some people have to poke through the internals of something to really be able to interact with it on a certain level. That level is what helps those people create. While I agree that the internals shouldn't be exposed in areas where new people who are just getting their feet on the ground will stumble into it and blow up their system, more advanced and/or adventurous people should have access to their system. This is an area both Microsoft and Apple have wrong in my opinion (although Apple less so.) Microsoft traditionally has exposed too much too soon so that the average user blows up their system unintentionally way too often, whereas apple seals much of it away behind a curtain which creates it's own issues for people who need to be able to modify things but aren't full time programmers etc..

    The metadata model follows a modern format in that it doesn't import everything wholesale into itself but rather indexes the content and for this I am glad. Something that goes hand-in-hand with this though is an exernal file system for the metadata itself like individual xml files which store all of the metadata for a given collection of atomic units (a file for a vendor's specific product, textures, cameras, poses, etc) which can be easily read, stored, backed up and... that other programs can be created to modify and manage. A good example of this is XBMC which stores all of the metadata of the media files in xml formats that other programs can 'scrape and tag' your media files, writing to the xml file XBMC reads. These programs are totally unconnected in any direct way but work together seamlessly. Expanding functionality requires no special programming knowledge of XBMC's API but rather uses any programming the programmer is familiar with to read/write XML files. This is the future of databases.


    While some of your points are valid as stated for their context, your thesis is contextually invalid at its foundation. The CMS is not some MS-Access level "pray that it works" excuse for a database. It is a full on SQL RDBMS in the same level of SQL-Server, Oracle, DB2, FirebirdSQL, MySQL, etc. It has all of the facilities that those others do, however, DAZ doesn't ship the real goodies with DS4. The chances of the CMS underlying format exploding are small, as connecting software don't touch the storage files; they only request the information from the SQL service.


    As for "poking around in the content": most of the content, as shipped, works. There are notable issues as there will be with any manufactured product (defective cars, toasters, candles). In most cases, it is the user screwing around with the environment that causes most problems. Why do you think that Microsoft has put so many obstacles into the new versions of Windows? The users are too prone to screwing with things they have no business being into in the first place. The problem is that these same users are unwilling to admit that it is their own stupidity that caused the problems that they experience in the first place. Too often, the user blames the software, developers, or the retailers for their own mistakes.


    If the content were to move to a relational model inside of the database, then many of the issues that are currently faced by users would disappear. There are many work-arounds in play that are accepted as "just the way it is done" that don't need to be the way they are. However, I'm not going to write a long dissertation on those as they've been hashed out before in more professional venues and require more background knowledge than can be assumed available in a public forum.


    Part of DAZ's problems have always been that they expose professional level tools to amateurs -- partly thinking that the users will "poke around" at the advanced features. They don't. We've had 3Delight forever, and few knew, or cared, that they had full Renderman at their disposal with SSS and all. Yet, Poser finally gets partial SSS years later, and everybody is all abuzz. There are features in 3Delight that are available to DS still to be touched. Take a look at Maya, 3Delight is used from there as well. DS has access to the SAME TECH that is available to Maya. DAZ has given a RDBMS to the same crowd, and again, few understand, or care, the power they have been given. There's the Genesis system -- same thing: professional level tool, amateur users.


    We need to move beyond the "Poser" mindset. DAZ has provided professional tools, not toys. Maybe, just maybe, folks need to start thinking more like professionals -- OK, maybe that's too much to ask: maybe "pro-sumers" then?


    Kendall

  • GeddGedd Posts: 2,473
    edited July 2012

    ... Firstly, those are not examples of databases, but of archive format app storage containers.

    Kendall

    I respectfully disagree. I said I would not put up qualifications before because I think it only distracts from the point. However, I have done database design and taught it on multiple levels. I will not go further into posting my resume as I still think this simply distracts from the point but I would suggest that your version of the purpose of a database as container for all the data rather than as an indexing system (which uses relational and object oriented 'databases' to perform it's task) is rather dated. What do you think any system that manages metadata is? It is a database. Just because it doesn't contain the data that the metadata refers to internally has no bearing on it's base or constituency. These 'archive format app storage containers' a totally invalid description btw, use um.. lets see, mysql, postgress, ruby, etc, etc, etc... This discussion reminds me of the discussions between hierarchical proponents and relational db proponents where the hierarchical proponents would argue that relational db's were not *real* databases.

    Btw Kendall, I do recognize you have a programming background also and am not discounting that, nor trying to compare backgrounds I only mention mine to say that I am not coming from a totally uneducated perspective. I also recognize your right to disagree with me.

    Post edited by Gedd on
  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Gedd said:
    ... Firstly, those are not examples of databases, but of archive format app storage containers.

    Kendall

    I respectfully disagree. I said I would not put up qualifications before because I think it only distracts from the point. However, I have done database design and taught it on multiple levels. I will not go further into posting my resume as I still think this simply distracts from the point but I would suggest that your version of the purpose of a database as container for all the data rather than as an indexing system (which uses relational and object oriented 'databases' to perform it's task) is rather dated. What do you think any system that manages metadata is? It is a database. Just because it doesn't contain the data that the metadata refers to internally has no bearing on it's base or constituency. These 'archive format app storage containers' a totally unvalid discription btw, use um.. lets see, mysql, postgress, ruby, etc, etc, etc... This discussion reminds me of the discussions between hierarchical proponents and relational db proponents where thehierarchical proponents would argue that relational db's were not *real* databases.


    The contextual difference is the access level: "Direct Application Access" vs "Brokered Access" It is a proven fact that access through a control interface that is dedicated to its task is inherently more stable and reliable than access directly through an application where data storage and integrity is inherently a secondary (or lower) concern.


    The arguments about the strengths/weaknesses of Filesystem Based vs Database storage are as old as the RDBMS. And are invalid here, as those arguments presume no user intervention in the data storage. Here, that is EXACTLY what we're talking about. Users getting into and changing data outside of the system.


    If we really wanted to get into it, I could advocate an Oracle, Informix, DB2 custom partition level paradigm that would completely isolate the data. I'm not, as the users have enough of an issue with what they have.


    Kendall

  • GeddGedd Posts: 2,473
    edited December 1969

    Well I would love to go into this more, but we already have gone off the deep end as far as most of the community here are concerned so... we just have differences of opinion. If we ever meet in a programming/db design convention type environment maybe we can pick this up again over a beer ;)

  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Gedd said:
    Well I would love to go into this more, but we already have gone off the deep end as far as most of the community here are concerned so... we just have differences of opinion. If we ever meet in a programming/db design convention type environment maybe we can pick this up again over a beer ;)


    Absolutely. We could blame DAZ, as they're the ones that gave us a RDBMS to play with in the first place :-)


    Kendall

  • GeddGedd Posts: 2,473
    edited July 2012

    Deleted because it was boring ;p

    Post edited by Gedd on
  • GeddGedd Posts: 2,473
    edited July 2012

    You know, with all that we kind of got off track. The real issue is people having problems finding stuff, things that a given individual might find redundant or usless being thrown into the mix, etc...

    All of this is not a software problem. The software is fine. It is an organizational problem of data that is managed by the software. The solution seems to lie in trying to produce standards, come up with some form of encouragement for PA's to follow that standard, and automating tasks related to sorting and organizing the underlying data, since not all will follow said standard. These are pertinent to what people have been discussing here I think.

    The nice thing about the current setup is that a lot of organizing of the data can be done by programs/scripts outside of and separate from DAZ.

    Post edited by Gedd on
  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Gedd said:
    Deleted because it was boring ;p


    No it wasn't boring. That story isn't quite the whole thing... the idea was dropped due to the Anti-trust suit. It was deemed BIG TIME in violation.


    Very interesting time that was. BTW, "Be" did that and it was AWESOME!


    Kendall

    PS
    Vague on purpose :-)

  • GeddGedd Posts: 2,473
    edited July 2012

    I loved Be :)

    I think I have a copy of it kicking around still. Also, I believe there is an open source followup to it but forget what it's called. Don't have time to play with that and everything else I want to though.

    Post edited by Gedd on
  • Kendall SearsKendall Sears Posts: 1,886
    edited December 1969

    Gedd said:
    You know, with all that we kind of got off track. The real issue is people having problems finding stuff, things that a given individual might find redundant or usless being thrown into the mix, etc...

    All of this is not a software problem. The software is fine. It is an organizational problem of data that is managed by the software. The solution seems to lie in trying to produce standards, come up with some form of encouragement for PA's to follow that standard, and automating tasks related to sorting and organizing the underlying data, since not all will follow said standard. These are pertinent to what people have been discussing here I think.

    The nice thing about the current setup is that a lot of organizing of the data can be done by programs/scripts outside of and separate from DAZ.


    Or changing the paradigm. :-)


    OK, so that's not likely to happen in this demographic... One can still hope. :-)


    Kendall

  • PendraiaPendraia Posts: 2,524
    edited December 1969


    Part of DAZ's problems have always been that they expose professional level tools to amateurs -- partly thinking that the users will "poke around" at the advanced features. They don't. We've had 3Delight forever, and few knew, or cared, that they had full Renderman at their disposal with SSS and all. Yet, Poser finally gets partial SSS years later, and everybody is all abuzz. There are features in 3Delight that are available to DS still to be touched. Take a look at Maya, 3Delight is used from there as well. DS has access to the SAME TECH that is available to Maya. DAZ has given a RDBMS to the same crowd, and again, few understand, or care, the power they have been given. There's the Genesis system -- same thing: professional level tool, amateur users.


    We need to move beyond the "Poser" mindset. DAZ has provided professional tools, not toys. Maybe, just maybe, folks need to start thinking more like professionals -- OK, maybe that's too much to ask: maybe "pro-sumers" then?


    Kendall

    Great discussion guys...some parts of it are over my head but interesting to read none the less.

    Since DAZ has included Shadermixer as part of pro more people are aware and have shown an interest in the ability to use shaders in DS. Up to that point many knew that the capability was there but didn't have the knowledge to access it easily. With Shadermixer that has made things easy enough that even someone like myself(no maths background to understand the math behind it) can access parts of it through experimentation. That's not to say that I wouldn't like to see more documentation, but I do think that it has opened up shaders in DS to more people by giving them a visual interface in the form of the bricks.

    We are gradually seeing more shaders emerge from Shadermixer as people have time to experiment with it. To be honest I think that when DAZ added it they were thinking that people would experiment and discover ways to do things that they hadn't even thought of yet...

    I think that without the UI in the form of Shadermixer this wouldn't be happening. Isn't this evidence of what you have both been talking about earlier in the thread about the importance of a good user interface?

Sign In or Register to comment.
Rocket Fuel