Digital Art Zone

 
   
5 of 8
5
All I ask is that Vendors Use The same folder name for each catagory on their products.
Posted: 13 July 2012 10:24 AM   [ Ignore ]   [ # 61 ]
Active Member
Avatar
RankRank
Total Posts:  993
Joined  2003-10-09
Kendall Sears - 10 July 2012 11:58 AM


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. tongue laugh


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

Profile
 
 
Posted: 13 July 2012 10:31 AM   [ Ignore ]   [ # 62 ]
Power Member
Avatar
RankRankRank
Total Posts:  1829
Joined  2006-02-17
Spit - 13 July 2012 10:24 AM
Kendall Sears - 10 July 2012 11:58 AM


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. tongue laugh


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

 Signature 

Any opinions expressed in this post are those of Kendall Sears and may, or may not, be more, or less, valid than any other opinion.

The contents of this post are intended for the DAZ forum only, do not re-post any portion to any other forum without his permission.

Profile
 
 
Posted: 13 July 2012 11:16 AM   [ Ignore ]   [ # 63 ]
Power Member
RankRankRank
Total Posts:  2322
Joined  2011-11-16
Spit - 13 July 2012 10:24 AM
Kendall Sears - 10 July 2012 11:58 AM

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. tongue laugh
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 - 13 July 2012 10:24 AM

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.

Spit - 13 July 2012 10:24 AM

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.

Spit - 13 July 2012 10:24 AM

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.

 Signature 

Just because I may have a strong opinion doesn’t make it any more (or less) correct than any other, just that I feel passionately a particular way at that moment.

Profile
 
 
Posted: 13 July 2012 11:42 AM   [ Ignore ]   [ # 64 ]
Active Member
Avatar
RankRank
Total Posts:  993
Joined  2003-10-09
Kendall Sears - 13 July 2012 10:31 AM

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.

 

 

 

 

Profile
 
 
Posted: 13 July 2012 12:06 PM   [ Ignore ]   [ # 65 ]
Power Member
Avatar
RankRankRank
Total Posts:  1829
Joined  2006-02-17
Spit - 13 July 2012 11:42 AM
Kendall Sears - 13 July 2012 10:31 AM

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.

Spit - 13 July 2012 11:42 AM

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

 Signature 

Any opinions expressed in this post are those of Kendall Sears and may, or may not, be more, or less, valid than any other opinion.

The contents of this post are intended for the DAZ forum only, do not re-post any portion to any other forum without his permission.

Profile
 
 
Posted: 13 July 2012 12:12 PM   [ Ignore ]   [ # 66 ]
Active Member
Avatar
RankRank
Total Posts:  993
Joined  2003-10-09
Gedd - 13 July 2012 11:16 AM
Spit - 13 July 2012 10:24 AM

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.

Profile
 
 
Posted: 13 July 2012 01:20 PM   [ Ignore ]   [ # 67 ]
Active Member
Avatar
RankRank
Total Posts:  993
Joined  2003-10-09
Kendall Sears - 13 July 2012 12:06 PM

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.

 

 

Profile
 
 
Posted: 13 July 2012 03:48 PM   [ Ignore ]   [ # 68 ]
Power Member
Avatar
RankRankRank
Total Posts:  1829
Joined  2006-02-17
Spit - 13 July 2012 01:20 PM
Kendall Sears - 13 July 2012 12:06 PM

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

 Signature 

Any opinions expressed in this post are those of Kendall Sears and may, or may not, be more, or less, valid than any other opinion.

The contents of this post are intended for the DAZ forum only, do not re-post any portion to any other forum without his permission.

Profile
 
 
Posted: 13 July 2012 04:28 PM   [ Ignore ]   [ # 69 ]
Administrator
Avatar
RankRankRankRank
Total Posts:  8421
Joined  2007-11-06

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.

 Signature 

PostgreSQL CMS FAQ

Product Updates: Non-Genesis/G2 DIM Zips starting July 2013
Non-Genesis Items with Metadata
Plugin Version Numbers for DS 4.5
Updated Genesis Products

Profile
 
 
Posted: 13 July 2012 06:46 PM   [ Ignore ]   [ # 70 ]
Power Member
Avatar
RankRankRank
Total Posts:  1381
Joined  2006-07-04
fixmypcmike - 13 July 2012 04:28 PM

 
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. smile

 Signature 

DAZ Gallery * * *DA Gallery

Profile
 
 
Posted: 13 July 2012 06:49 PM   [ Ignore ]   [ # 71 ]
Power Member
Avatar
RankRankRank
Total Posts:  1829
Joined  2006-02-17
DaWaterRat - 13 July 2012 06:46 PM
fixmypcmike - 13 July 2012 04:28 PM

 
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. smile


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


Kendall

 Signature 

Any opinions expressed in this post are those of Kendall Sears and may, or may not, be more, or less, valid than any other opinion.

The contents of this post are intended for the DAZ forum only, do not re-post any portion to any other forum without his permission.

Profile
 
 
Posted: 13 July 2012 07:06 PM   [ Ignore ]   [ # 72 ]
Power Member
Avatar
RankRankRank
Total Posts:  1381
Joined  2006-07-04
Kendall Sears - 13 July 2012 06:49 PM
DaWaterRat - 13 July 2012 06:46 PM
fixmypcmike - 13 July 2012 04:28 PM

 
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. smile


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.  smile  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.)

 Signature 

DAZ Gallery * * *DA Gallery

Profile
 
 
Posted: 13 July 2012 09:44 PM   [ Ignore ]   [ # 73 ]
Power Member
RankRankRank
Total Posts:  2322
Joined  2011-11-16
Kendall Sears - 13 July 2012 03:48 PM

... 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.

 Signature 

Just because I may have a strong opinion doesn’t make it any more (or less) correct than any other, just that I feel passionately a particular way at that moment.

Profile
 
 
Posted: 14 July 2012 01:01 AM   [ Ignore ]   [ # 74 ]
New Member
Total Posts:  20
Joined  2009-02-13

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.

Profile
 
 
Posted: 14 July 2012 01:11 AM   [ Ignore ]   [ # 75 ]
Addict
Avatar
RankRankRankRank
Total Posts:  5569
Joined  2006-02-20

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.

 Signature 

I like Bryce, DazStudio, Poser and Vue ... in alphabetical order. And I would probably like Carrara too, if I could find the time to become acquainted with it. Peace?

Profile
 
 
   
5 of 8
5