Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Well it's an extension of what I was talking about actually. I hadn't delved into this part but yes. Good user interfaces are like a pool with a shallow end and a deep end. Some people never go into the deep end and are happy, others go straight for it. But the part that you are referring to is also an important constituent, expanding the functionality of the deep end by giving it a nice slope. In the Linux/Unix world, new functionality was provided fastest with a command line interface that wasn't easy to remember or comprehend for the casual to semi pro who didn't use that functionality regularly and understand the workings behind it (API's and scripting fall into this category.) This is always the fastest way to slap together new functionality, and adapt it in a fast changing development cycle. However, GUI's are a critical step in moving that functionality to a wider audience. Early GUI's in any product or function's life cycle is subject to a lot of change and refinement. Refining that GUI is an ongoing process who's goal is to move the functionality to an ever wider group of people. As a product matures, the GUI stabilizes some but should never become totally stagnant. Too much change overwhelms casual users, not enough renders it obsolete. It's a balancing act. I should point out that this varies in a given software package depending on what part of the GUI we are talking about. The basic interface is the first to stabilize, whereas there are often areas at mid level stabilization and complexity,) low level (stabilization, higher level functional complexity) and no (stabilization as GUI doesn't exist, highest potential functionality for those who can operate in this playground (scripted/API)) at any given time.
Another point you bring up is that at each stage of moving functionality to a wider audience, it increases the people who can use the product creatively rather than simply working on the underlying technology. That is, some of the best shaders will come from artists who either can't or don't want to be bothered working on the underlying framework or wrestling with overly technical procedures.
And, if it's hard to understand.. it's a failure on the part of the person trying to communicate the idea, so I apologize for that :)
Okay, I get it. Blame users for 90% of the problem and DAZ (and Poser) for the rest. Impugn the artists among us and those who have paid good money for their content and wish to have a certain amount of control over it. Impugn users as non-professional because many of them neither need nor want to deal with the technical issues that DAZ has so generously given them yet at the same time ignore the benefit to the community and field of those who have delved into that 'heavy' technical stuff.
Oh, and ignore the fact that DAZ actually knows its customers and the value of each one. From the artist who wants the program to be so easy to use that it essentially disappears while he's in The Zone to the curious and/or hungry ones who want to produce content and become vendors themselves. From those who view 3D as part of the means to an end to those who believe mastering the technical aspects of using 3D in all its glory is the only way to go. Every single one of them is valuable to DAZ.
Insulting or not at least you understand that we are a demographic. Please tell that to Microsoft who's one-size-fits-all save-the-user-from-himself (sounds familiar) win7 has not only kept the stupidity of assuming all tif and jpg files are photos but won't allow you to sort them in thumbnail view in Explorer.
I weep for the future if the 'credentialed' ones continue down this path.
Okay, I get it. Blame users for 90% of the problem and DAZ (and Poser) for the rest. Impugn the artists among us and those who have paid good money for their content and wish to have a certain amount of control over it. Impugn users as non-professional because many of them neither need nor want to deal with the technical issues that DAZ has so generously given them yet at the same time ignore the benefit to the community and field of those who have delved into that 'heavy' technical stuff.
Which is it? "neither need or want to deal with technical issues" or "wish to have control over"? The two are somewhat, if not completely, exclusive of each other.
Also, DAZ didn't give anyone the technical issues. They existed long before DS was created. Studio created it's own areas to try to NOT get involved with the Poser areas. It was the users that dragged DAZ into that arena, thank them. Studio could easily support the content without the Poser areas, but the users didn't want to split the content, nor maintain two areas.
I'm advocating putting the content into a format that keeps the "artist" from ever having to deal technically with it ever again. No more bad/ugly paths, all related pieces readily available by reference, only 1 area of the disk ever being used by the content data. You've turned my argument around.
Kendall
Exactly because the community is made of (actually a range) of types, this approach would be doing some a big favor while creating a problem for others.
----------------------------------
(passes out the happy cactus juice and chocolates)
Everyone's opinion is valid on what works for them, and no one should feel that they need some special credentials to have a valid opinion on something such as design concepts they feel would work for them. On an equal note, anytime a discussion falls into a p*ssing match on who has what credentials, it's usually lost all value ;p
Exactly because the community is made of (actually a range) of types, this approach would be doing some a big favor while creating a problem for others.
But it would be safe to assume that those that it would cause problems for are those most capable of working through the problems. No? Someone like myself, and probably you, would have few problems getting at what we needed in the base situation. At the same time, we'd need to extract the data, work with it, and then submit it back to the DBMS for inclusion into the DB. During the submission process, validation is done by both the schema (field types etc), as well as by any integrity checks installed to keep incorrect data from being introduced. A bit of a safety net for those "Oops" times. What programmer, or admin, hasn't typed a wildcard too early in a filename and immediately wished that there was a check in place to stop that delete from happening? :-)
Kendall
I have to agree with Spit here Kendall, separating users from getting direct access to their data isn't the answer imo.
I think the answer might be scripts/apps which automate cleaning up some of the data outside of the DS environment. I use one program to tag my audio files and another to play them. This separation of functionality and tools works for me. Locking stuff up in a given application means I couldn't have this dynamic environment.
I think the important thing here is, the framework that works for banks doesn't fit environments like this like driving a backhoe to the grocery store isn't really a good fit.
Everyone's opinion is valid on what works for them, and no one should feel that they need some special credentials to have a valid opinion on something such as design concepts they feel would work for them. On an equal note, anytime a discussion falls into a p*ssing match on who has what credentials, it's usually lost all value ;p
By 'credentialed' I mean Microsoft.
BTW, I'm a she.
I was a programmer and know how users can be but I also know that there will always be users and feeling antagonistic towards them is counterproductive. And because I also taught Poser I understand that there are users who, especially when starting out, are actually afraid of doing something wrong, of breaking the program. They need to feel comfortable and secure. My first Poser lesson was having them make a 'mistake' that I told them to do without telling them it was a mistake then letting them laugh at the consequences and see it really wasn't so terrifying to do something wrong. Yadda yadda.
Hehe, sorry bout that, hard to tell w nicks... I use 'he' in the generic sense like 'you guys' for male/female.
Lol, thank you. I haven't tried Tree view yet since the content tutorials I've seen have specifically mentioned not to use it.
As a new DS user, I have to say that I do like how content is organized in "Smart Content" more than "Content Library". I find Smart Content easier to understand and use. I also think the metadata concept makes a lot of sense as far as content organization goes. The problem lies in how that metadata is structured as regards to consistency between products and vendors.
Case in point is the recent PC freebie "Steam Truck Red Bizon". I don't remember what forum thread it was on but I did copy part of the post to use as reference:
"The metadata don’t work because there are wrong paths (as in the attached mage) in the DAZ_3D_14606_Steam_Truck_Red_Bizon.dsx file.
With a editor, like for example Notepad++, open this file and remove
Petipet/
from every
making it
"
For Smart Content to work, vendors need to follow defined metadata naming conventions that result in a consistent user experience.
I felt I had to jump in here: did those tutorials say why not to use View As Tree?
To explain where I'm coming from, I arrange my content in a similar way as Kerya does, and I've used the same system in D|S 1, 2, 3 and now 4. In fact, I've been with D|S longer than that, I used a few of the beta versions before v1.0 came out. Long before Smart Content and the CMS was even a twinkle in the eye of the DAZ programmers. Never used Categories, never used Smart Content, never missed them. The system I've worked out over the last several years works for me, letting me find content mostly fairly easily and quickly. The only problems I have are in the parts of my old Poser runtimes that I haven't yet completely switched over to my manual arrangement.
Of course, this is completely incompatible with Smart Content, its metadata, and the CMS. If I were ever to switch over, I'd probably have to scrub my entire very large content collection, re-install, and get used to a very different workflow. Apart from the non-DAZ content, which mostly doesn't have metadata. Apart from all my freebies, ditto. Apart from all the old DAZ stuff I still use, ditto. (Remembering all the time that none of this will ever appear in Smart Content anyway unless someone creates metadata for it.) I'm happy with my current setup, I see no need to change.
The manual system is an alternative to Smart Content, that's all. One that doesn't depend on a database that can corrupt, or a CMS service that is known to be finicky about the systems it'll run on. The only drawback is that it's a bit of a headache to convert a large existing content collection: and it helps a lot if you don't use Poser (I never re-installed Poser after my last computer upgrade) or Carrara, or any other program that expects the Runtime to be set up so Poser can understand it.
But it would be safe to assume that those that it would cause problems for are those most capable of working through the problems. No? Someone like myself, and probably you, would have few problems getting at what we needed in the base situation. At the same time, we'd need to extract the data, work with it, and then submit it back to the DBMS for inclusion into the DB. During the submission process, validation is done by both the schema (field types etc), as well as by any integrity checks installed to keep incorrect data from being introduced. A bit of a safety net for those "Oops" times. What programmer, or admin, hasn't typed a wildcard too early in a filename and immediately wished that there was a check in place to stop that delete from happening? :-)
Kendall
So in your future only people that know about databases are able to correct errors?
And there will be errors. Daz can't even be consistent about DazOriginals - not talking about PA items.
Do you have the dream home? Some rooms are in Environments Architecture, some are in Props Architecture ... do you really want to rely on a human to put things in a consistent way in the same place?
I don't.
I am not a special specialist like you. With Poser files I can correct errors myself. With a "everything in a database" I would have to rely on others.
Not a nice scenario, not at all.
But it would be safe to assume that those that it would cause problems for are those most capable of working through the problems. No? Someone like myself, and probably you, would have few problems getting at what we needed in the base situation. At the same time, we'd need to extract the data, work with it, and then submit it back to the DBMS for inclusion into the DB. During the submission process, validation is done by both the schema (field types etc), as well as by any integrity checks installed to keep incorrect data from being introduced. A bit of a safety net for those "Oops" times. What programmer, or admin, hasn't typed a wildcard too early in a filename and immediately wished that there was a check in place to stop that delete from happening? :-)
Kendall
So in your future only people that know about databases are able to correct errors?
And there will be errors. Daz can't even be consistent about DazOriginals - not talking about PA items.
Do you have the dream home? Some rooms are in Environments Architecture, some are in Props Architecture ... do you really want to rely on a human to put things in a consistent way in the same place?
I don't.
I am not a special specialist like you. With Poser files I can correct errors myself. With a "everything in a database" I would have to rely on others.
Not a nice scenario, not at all.
Of course not. For those not technically capable, product updates and fixes would provide the primary methodology for fixes. For those who are capable, a control interface would be used to make changes. Also, there are fewer places/ways for database errors to occur. The majority of errors are with paths being wrong/bad. In a database this is not possible -- there are no paths if there are no physical files. The schema/tables only allow specific types of data to be stored. There are also ways to provide for integrity checks upon insertion.
Kendall
OK, if you give me access to it (i.e. a tutorial how I can fix things) it does sound a bit better. I like Daz, really (or I wouldn't be here), but I do trust their ability to "overturn the cart" from time to time. ;)
I still prefer things to work in DazStudio and Poser. ;)
Herein lies the problem, the control in this case refers to the person creating the interface. For anyone who had a VCR, think of how many had blinking 0:00 clocks because the 'engineers' couldn't design a user friendly and consistent interface for something as simple as setting the clock. On top of this, if one has to go through a 'control interface' they are limited as to what that interface allows them, which often prevents addressing the real problem that some engineer through no fault of their own but through the limits of our ability to preconceive every possibility, didn't design for. Add to that the push for getting things on the market that means they go out half baked and often never get fixed... not a scenario I want to be caught in.
In an open structure, We can write tools that can modify things without having to go through a specific application. If that appication is corrupt and won't start, we can potentially fix the underlying structure, restart/reload the application and reinitialize it. The method DS uses for managing content is in my view correct. It follows more modern formats for dealing with the type of data it deals with (different then bank transactional data for instance where a more controlled database is necessary.) The solution lies, I believe, in external tools and better standards.
Personally, I wouldn't change a line of code in DS itself, other than to expand the types of 3D content and other applications it can work with. The base program as I envision it would act like a hub for managing 3D content that could be used in a variety of environments, by a variety of tools, but would do this in an open flexible way.
All of this is of course an opinion, and by definition no better than anyone elses.
The other related issue is that we only have finite resources to work with. If DS developers take on the task of trying to provide this 'controlled interface' it will eat up those resources at an unprecedented pace. I have seen this first hand as a major issue, possibly *the* major issue, in software development. If their resources are tied up there, they don't have them available to maintain much less expand functionality of the product in an ever changing dynamic environment. The result typically is that the product becomes less relevant to the environment it exists in and dies.
Sometimes we need to let go of some of the control to become flexible enough to survive and grow. Let others join in, like the open source community aims for. Not necessarily going totally open source, but learning from the example of how keeping an open framework that others can 'easily' develop tools to play in our playground can vastly expand functionality for free essentially.
Btw, my opinions are © Gedd @ DAZ forums. If one wishes to quote them all or in part, please do so with attribution. They may not be great, but they are mine ;p
Data, Runtime, and ReadMe's are special folders in a DS-format content folder. Outside of those folders, you can move DS-format content anywhere.
Hello, thanks to all whom have posted here on the subject, it's been an interesting read for I too have been curious about my content folders and restructuring them for ease of accessibility but I wasn't sure of what folders were safe to touch and which one's are a no fly zone.
So the Data, Runtime, and ReadMe folders in the DS-format content folder, these i gather are the default install destinations and not to screw up any additional future installations, don't move or rename anything in these right?...
...however, it is safe to move, rename, delete anything else in the folders outside of these?
Cheers
You woke up a 3-year-old thread.
But it's a topic that still needs discussion. Seriously, characters, figures, people. WTF?
The metadata should be based on a more clearly defined hierarchy. Or a relational model. Something needs to be done because today it's a mess and it's not working.
Consistent naming conventions need to be established and then made into industry standards. And since DAZ Studio is the free option with a fairly large userbase, I would think that DAZ has one of the best chances of making it work. I would say that 90% of technical problems are due to carelessly applied and not well thought out rules that end up becoming LEGACY standards with no real good reason for it. What we have now is a standard of "None". Everybody has to modify their own metadata, rename their stuff so that it works for THEM, but no real standard ever develops.
Right now, half the world is stopping on green and going faster on red. One third of us are making lunch on yellow. This is not working.
Yeah I was a little reluctant to post anything since the subject was a relic, I only just recently installed the software and noticed in some of the video tutorials how nicely set out their folder structures were compared to my mess. Thinking surely they customized theirs, so why not do the same to mine... I'll just leave them as is if it causes DAZ to throw a wobbly.
Cheers.
If you are using Studio and installing with DIM (DAZ Install Manager) then it's best not to change names of folders or move things around in case there's an update. If things are moved/renamed DIM can't know how to uninstall the old version and you could end up with a worse mess.
Before DIM I had everything organized the way I wanted it. After DIM it's so easy to install and update, but I can't find anything anymore. :)
I used to rearrange/rename folders, but now I just use Categories for that and leave the files in place.
Thanks for the input guys, i've been grabbing some free stuff around the forums and I found they're are just content unpacked within a folder with no installer exe and can't be installed via the DIM, these are more or less the folders I am looking to rename and move to a custom folder so I can monitor them.
I wont even think of tampering with the DIM installed ones :)
For example, after importing the content into their respective parent folders, I'd like to move them from there to a customized folder labelled "## Imp Ext ##"
In other words, from this...
C:\Users\Public\Documents\My DAZ 3D Library\Runtime\Libraries\Character\Snoopy\TheDawgyDawg
... to this...
C:\Users\Public\Documents\My DAZ 3D Library\Runtime\Libraries\Character\## Imp Ext ##\Snoopy\TheDawgyDawg
Cheers.
Yeah, that's fine. :)
I do that with freebies and stuff from other sources too.