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
I won't use any of them until they can work in poser also.like they did before daz4 came out.
...OK, so lets say for the sake or argument (and I paid for the ten minute version), one who is working in 4.5 and can load any previous filetype (even .daz) which upon saving gets converted to .duf (hopefully without the shaders getting messed up in the process). Meanwhile lets say a new environment set is released that is in .duf format. Now, as I am using 3.1.2.32 Advanced 64bit basically this says to me the application will not be able to read the file if I try to load it, correct?
So, the way I interpret this is it means if I don't upgrade to 4.5 (the new "beta" of the Studio app.) I just wasted my money on the new set.
This is what is termed in the automotive and durable goods industry as "planned obsolescence" .
Another reason for the switch to .duf, a standardized, documented format for writing importers for other applications.
...interesting as I have been able to load .daz content created in 3.x in 2.3.3. It just meant some things like lights (most of which used the new built in UE lights) didn't work and shaders (that relied on the UberSurface/HSS) needed to be tweaked. to work correctly.
Okay, let's say for the sake of argument that a new environment set is released in .daz format created in 4.0.3.37. You wouldn't be able to open that in 3.1.2.32, either. It's not the switch to .duf that makes DS scene files not backwards compatible, .daz files never were. .duf files will be backwards compatible, so if you use 4..5.0.114 you can open scenes made in 4.5.0.137.
Are you sure about that? .daz files created in 3.x?
Thats kinda what i thought as well. Nothing "too" major.
-MJ
Are you sure about that? .daz files created in 3.x?
Maybe not, but if the product has a .pp2 i can load the prop from that if necessary correct?
My only issue would be loading a prop from a .daz file(3.x or later) or the now .duf file?
This is another reason im purchasing less and less Daz3D content as it is increasingly becoming platform dependent.
-MJ
I just tried to open a scene I created in January in DS4.0 in DS3.1.2.32, and got the expected "this file cannot be opened because it was created in a later version" message. I believe you are mistaken.
Maybe not, but if the product has a .pp2 i can load the prop from that if necessary correct?
My only issue would be loading a prop from a .daz file(3.x or later) or the now .duf file?
This is another reason im purchasing less and less Daz3D content as it is increasing becoming platform dependent.
-MJ
There's no problem, then -- you can still load the Poser versions regardless of what format the DS version is in (which you couldn't load, whether it was .daz or .duf).
...that is not always the case.
For example Jack Tomalin's Disconsolation was created in 3.0 yet I could still open it in 2.3.3. Again the light set would not work as it was UE based and some shaders needed adjustment but, the set itself loaded fine.
...but that is s full scene created and saved in a later version. I already know this. I'm referring to individual content files.
Also if .duf becomes the only file type available and no .pp2. available, then the content becomes exclusive to the Daz Studio application. This is what I am concerted about.
This post may've had bunk assumptions. :)
A content file is either a scene or a script - neither of which should work in DS2 if saved from DS3.
...but that is s full scene created and saved in a later version. I already know this. I'm referring to individual content files.
Also if .duf becomes the only file type available and no .pp2. available, then the content becomes exclusive to the Daz Studio application. This is what I am concerted about.
But the big problem in DS has always been the portablity of scene files. If you bought a product that contained a DAZ scene, there was always a chance that the PA or Vendor created the scene or lights in a newer version of the program that what a customer had on his desktop. Even it is was a point revision ahead, it would not load unless the customer upgraded the application. This seeks to address that. Generally you want to upgrade to get additional functionality, not to load lights or a room. The big thing about duf and DSON is portablitiy.
I like DUF because like already said, I can build a scene on one computer and send it to another to render and not worry about the arcande daz data folder stuff. That was the main selling point for me and it has worked to save me a lot of time.
I don't hand edit text files, but in the future being able to open up a file generated in daz 4.5.1 on a computer that has 4.5.0 will also be useful.
And for the record you can open a .daz file in 4.5 and save it as a .daz file if you want to. Its an extra click or two but there is nothing stopping you. Not sure that .daz file will work in anything other than 4.5 though :)
Yeah, I'm curious about that.
Hypothetically, it seems possible for those daz to be saved in the oldest useful version that Daz has enough information about.
If it doesn't now, perhaps that could be added as another option, named something like "save ver. 2.whatever] daz file".
And, showing my ignorance of of a good portion of file-type lore:
Some Poser scenes have models and textures.
But it sounds like the daz and duf never contain them.
Which would imply that they would be outside the daz and duf .
So the only potential uses, for importing duf and newer daz, would be light setups compatible with one's older version, position data and so forth.
Am I utterly wrong?
Interesting! In 1967 I was a college sophomore and had my first programming course (FORTRAN). Up until then I was heading for a career as an electrical engineer. However, I had quickly determined that I really wasn't "grok"ing the concept of circuit design.
However, programming was a perfect match for the way my brain worked. I only had two programming courses my whole career (FORTRAN and COBOL) but taught myself a dozen different assembler languages and a similar number of high level languages. I memorized the detailed instruction set behavior for an equal number of CPU and CPU chips. I became a top expert in some of them and was teaching programming to space center and other government employees.
Then after about 30 years my brain just seemed to burn out. As new languages appeared I was just not interested. I kept asking "why?" "Why is this language necessary?" "Why do I need to spend all this effort to learn yet another subtly different language that could in most cases be done equally well in an existing language?".
What's more, I became disillusioned with the inevitable change in programming culture. Back in the old days one was presented with a problem and one came up with solutions that often required in depth analysis of the fundamentals of the problem that gave you an unparalleled breadth of understanding of all the issues surrounding this problem and challenged you with trying to extract the salient issues to reduce the solution so that it would fit in a computer of the day. A task not unlike fitting 4 pounds of Crisco into a 3 pound can.
The change to high level programming languages was intended to avoid having to rewrite program code to accomodate different CPU and operating system structures. What I saw happening was the dependence on CPUs and OSs was minimized but was replaced by dependence on browser and existing subroutine libraries. The subroutine libraries are by design, generalized machines. Their internal workings are a mystery because nobody actually writes documents to that level anymore. Error reporting is reduced to "Gack, I can't handle this so I'll ignore it!" The poor programmer is now reduced to playing "Whack-a-Mole" with the ever shifting, muddy foundation of the library, browser or OS du-jour. Spending 5% of his effort on the problem algorithm and 95% of his effort on making it work, and continue to work, in the morass of unstable environments.
UNIX was a great idea and it lies at the heart of all the biggest machines and networks but all the sprout up sub-species have been a distraction.
And the biggest cultural change I observed was the opening up of computer programming to the unwashed masses. Now, any idiot that can create a "Hello World" program in Basic thinks they're a programmer. That might have been OK when computers were strictly one user, one thread and unnetworked. But I know from experience that writing a sophisticated program that behaves properly in multi-CPU, multi-thread, multi-user, virtual, networked environments requires thinking in 5 dimensions. Sure there are subroutine libraries that are supposed to make that task easy but as I noted above they are generalized solutions and don't always exactly fit the job. AND you're dependent on how well they were written and how prescient their creator was in being able to predict how it would be used. Ever wonder why unpredictable, mysterious "blue screens" and "hangs" happen? I know why, and it's a dirty little secret the average programmer hasn't got a clue to and cannot solve by themselves.
Yep, I burned out about a decade ago. Blew a fuse, melted a few billion brain cells. Now I just sit back and draw pretty pictures and let the minions at DAZ scurry around like ants under the magnifying glass of a 7 year old discovering the burning power of the sun! 8-o
duf = Daz Universal Format?
or something else?
Disconsolation's !Pre_all.daz was created in DS 2.3 according to the file info pop-up. The presets are .ds (DAZ Studio 1/2) not .dsa (DAZ Studio 3+).
DAZ User File, as far as I know.
I thought it was an editorial comment on the quality of my art.
Merging with another thread on same topic
.daz and .duf files contain references to textures. .duf files can be anything from material presets to full scenes. Being able to build importers for .duf is one of its advantages over .daz files.
Hmm. Does this mean in the future we'll have to rely on infallible file and folder naming conventions to be sure what the files in our content library do? "That file says it's a full scene, so it should be one." "This folder says "Light Sets" so it shouldn't contain props." It was (potentially) bad enough when we went from the variety of self-explanatory Poser library file types to just "scene" and "script" types with the first version of D|S. If a .duf file can truly be anything, then it could be anything. Alphabet-soup filenames, which I see with distressing regularity, will be a nightmare to figure out.
Maybe it's just me, but my fingers are still smouldering from the last few "good ideas", so I'm cautious.
If the CMS is working you should get an overlay on each thumbnail identifying its type. If you move files around on your own and break the CMS, as I do, then on your own head be it.
< rolls eyes > And I'm one of the people who must uninstall the CMS when updating a new D|S version. If I leave the CMS installed, D|S will not run. I tried with 4.5 to see if anything was different this time, but no.
I guess that is what we should call "progress"?
Hmmm... when I was writing my little essay in post #48 above, it reminded me of something that a wise colleague told me nearly 4 decades ago in my early days of programming. Describing the efforts of that time to obscure machine differences with layers of conversion software and machine independent languages he said: "It doesn't solve the problem, it just moves it further away so that it looks smaller."
I've come to learn that that observation has been applicable to several situations I've seen over and over again in my career. I've watched the battle between centralized and distributed computing oscillate back & forth several times. I've seen script languages attempt to simplify compiled languages but end up becomming just as complicated if not more so than what they replaced. I've seen communication protocols attempt to encompass hardware differences but in the end introduce complexities of their own. I've seen the availability of memory and processor speed increase exponentially yet because of complexities introduced by layer upon layer upon layer of compatability and security issues the throughput improvement is only linear. Yet we continue to build on mud, a house-of-cards with unskilled laborers.
Somehow the band-aids keep it together but I'm watching for the incident that pulls the lynchpin.
I think we should all be wary of solutions that only make the problem look smaller.
Wow, in '67, I turned 9.
I've always loved electronics and computers. My AAS degree is in electronics, BS and MS degrees in Computer Science.
Programming used to be easier -- If your program misbehaved, you had a problem in your code or didn't understand the problem. Now, most likely the problem isn't in YOUR code.
"What do you mean you want me to rewrite this display in version 3? We're on version 6 and should be thinking about 7!"
We've remarkably similar careers; I took ONE course and learned Fortran IV while nominally working on an EE degree. And then I dropped out and got a job converting 1440 Autocoder to IBM 360 PL/I. And like you, after numerous versions of assemblers, high-level languages, scripting languages, some panel definition processes, and way too many communications protocols, I burned out.
I got just far enough in C to be able to fix compilation errors of open-source code I was porting to my systems, looked at C++, and my mind just refused to have anything to do with it.
I'm waiting for the bubble-gum that holds the bailing wire together to dry out and start fracturing.
As for the future - just look at my tag line.