Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Incorrect. There's many software companies, such as Adobe, which has advances in software but you can still drop in filters and plugins from previous versions so people don't lose their investments and time waiting for new versions of plugins... and hope the developer does update their plugins.
The software really needs to be written so that plugins, especially when they are calling the same methods that have not been depreciated, still run without needing recompilation. Things such as this speed adoption of software and allow for people to quickly upgrade; constantly recompiling and changing formats slows it down. The nature of your software is modular; as a software developer, there's really no excuse for the constant changing and recompiling that DS does. Those plug in modules really need to snap in place and run, if those calls are still available to it.
Like Richard said, it's only semi true. I've had several Photoshop plug ins and filters stop working in newer versions over the years. In fact CS6 won't run one of my favorite sets of filters. I have to keep a previous version installed to be able to use them.
New versions of Poser, ZBrush, Vue and many many others have plug ins, filters and scripts that need to be updated to work in newer versions. It's nothing unique to DAZ Studio.
Coldrake
Thank you that was a well explained answer Richard :)
Where did you find the update for Reality. I cannot find it on his website?
%-P
From the "GET DAZ STUDIO 4.5! See why you should do it today!" thread;
I just wanted to confirm that I'm building new versions of Reality, version 2.5, that are compatible with Studio 4.5. In fact they are already been built, I'm testing them and then sending them to the testers for a wider verification.
If everything checks out I should have the update, which is free, available on Monday. I will send a mailer to let people know about the update.
Cheers.
Coldrake
After installing the new release of Daz Studio Pro I checked the plugins and dzautoriggercontrol is listed red... I checked my dlls and it wasn't updated since 10/20/2011..... not sure if this one is needed or will be updated later... or is this a problem with my own upgrade installation??
If you had the Dynamic Clothing Control (the paid add-on), you need to reset that and install it. The installer won't reinstall the basic Dynamic Clothing plugin if the paid one is there, even if the paid one is an older version.
Thank you.... that was it!
Coldrake
I'm psyched for Monday. Now I just need to figure out what I want to render first. :D
well that's great news. I just installed 4.5 and really wanted my Reality back at work. Happy to hear it is on its way. HOpefully the testing goes well.
I need Gen X. AAAAGHHHHHHH!!!!!! Where is it? Without Gen X no use of DAZ for me. I don't use Genesis as it, I only use the iconic shapes of Genesis (third and fourth generation). I don't see any Gen X for DAZ 4.5 :( I guess I have to wait.....
See this thread:
http://www.daz3d.com/forums/discussion/5878/
See this thread:
http://www.daz3d.com/forums/discussion/5878/
THANK YOU!!!
I hope I didn't miss anything but...anyone knows if "INFINITO" will be affected by 4.5?
There is a link on the forums here to download the latest Infinito DLL, it has been updated to work with 4.5, I'll see if I can find it before you do :)
Here is the link : http://www.daz3d.com/forums/discussion/5973/
Reality will be released failry soon, perhaps after the weekend, and Dimension3D is working on GenX and the DSF Toolbox.
Even without the update of GenX for 4.5 you should still be able to use everything you have already converted.
DAZ_Spooky: I am not sure you get what your customers are telling you in general. We all like enhancements but if the cost of deploying the enhancement outweighs the benefit, then the enhancement is not going to be in anyone's best interest (especially DAZ at this point). Users are spending a lot of time updating content, updating plugins/shaders, working around bugs, etc. All of these activities are unplanned disruptions to our workflows. It is costing us time and time, as they say, is money. Do you understand?
For 4.x updates, most of us would gladly have simply settled for quality and performance enhancements without any new features that require plugins to be re-compliled. ANY focus on new features is going to de-focus resources away from quality improvements. For example, was DAZ even going to consider solving the duplicate-ID issue in a way that is transparent to users? This is about DAZ making good solid decisions that truly have the customers' best interest at the top of the list. "Surprise and Delight" is not only about features.
Back on the specific topic, are you certain that there is no workable plugin architecture that will allow for linking a modified base to existing plugins without recompiling the plugins? My advise is for DAZ to think long and hard about this before the next major upgrade.
The Duplicate ID issue was a bug in older versions of DS, not catching duplicate IDs. I imagine the only way to fix it invisibly would have been to leave the bug, which may well have made it impossible to fix other things. I suppose they could have done what my script does, but on import - however, there are occasions when my script fails and there may be more if it was applied to all files instead of only those that throw the error, and of course running the fix each time would affect performance.
My understanding was that they did consider it. The bug in 4.0 came to light when Carrara 8.5 revealed the problem. Instead of adding the bug to C8.5 and perpetuating it in DS 4.5, they chose to fix it, no doubt because a one-time need to update content (and people like me have been posting these updates as they've occurred, so others wouldn't have their work disrupted by having to do them all at once) was deemed to be better than the long-term problems that would result from leaving the bug in place.
Richard: Perhaps this was not a good one, but I was looking for an example to illustrate my point and this was the first example that came to mind. This post is primarily about the importance of focusing on fundamentals derived from a clear understanding of customer wants and needs.
As for duplicate-IDs, most of the warnings I see result from loading dsf files I generated for myself in the past few months. As I understand it, DAZ had identified and fixed 10s if not 100s of defects prior to the RC1 release. If not for the focus on new features (which are now causing us so much extra work), could there have been a release with a defect fix for duplicate-IDs and many, many others much earlier? Could we have had more optimization for 3Delight earlier? We certainly all appreciate your work to provide a solution, but I think many of us are annoyed that a studio user had to provide it (vs. having a transparent solution baked into a DS4 quality upgrade).
Ah, thanks a lot!
Man, Alessandro really works fast O_O
DAZ_Spooky: I am not sure you get what your customers are telling you in general. We all like enhancements but if the cost of deploying the enhancement outweighs the benefit, then the enhancement is not going to be in anyone's best interest (especially DAZ at this point). Users are spending a lot of time updating content, updating plugins/shaders, working around bugs, etc. All of these activities are unplanned disruptions to our workflows. It is costing us time and time, as they say, is money. Do you understand?
For 4.x updates, most of us would gladly have simply settled for quality and performance enhancements without any new features that require plugins to be re-compliled. ANY focus on new features is going to de-focus resources away from quality improvements. For example, was DAZ even going to consider solving the duplicate-ID issue in a way that is transparent to users? This is about DAZ making good solid decisions that truly have the customers' best interest at the top of the list. "Surprise and Delight" is not only about features.
Back on the specific topic, are you certain that there is no workable plugin architecture that will allow for linking a modified base to existing plugins without recompiling the plugins? Here is something else to consider: by relying on an architecture that requires plugins to be re-compiled, it makes it highly impractical for any users who rely on plugin use to participate in a beta release program. My advice is for DAZ to think long and hard about this before the next major upgrade.
Thank you that was a well explained answer Richard :)
Yes, but it's slightly missing the point.
It's great to jump up and down and wave your hands around with glee about all of the "advancement" that's happening in the product, but when the price of that advancement is so much disruption and inconvenience for users and plugin developers alike, somebody needs to ask the hard questions about cost vs return and the impact on both the supportability and the desirability of developing for DAZ Studio.
We're not even talking here about re-compiling to use any extra features in the later version. This is re-compiling just so that the plugin continues to work at all! That's quite an overhead to impose on developers.
And just remember ... in the current DAZ Software Development Methodology for Studio ... all of this is (probably) going to happen again and again and again and again and again ... every single time that a new version is released. It is truly excruciating!
My suggestion is that the SDK should be frozen until at least 5.0 and some serious thought given to implementing a mechanism that allows some form of backwards compatibility with previous plugin versions so that the next beta program can actually mean something! One way to achieve this might be a proxy, or compatibility layer, that exposes the object model for 4.5 but internally maps those calls to their equivalents in the new 5.x object model. In other words, the API itself becomes a plugin, and all plugins talk to the API "plugin" instead of directly to DAZ Studio. The exact method of implementation needs thinking about, but this would allow older plugins to continue working until they could be updated.
In other words, DAZ should spend some time thinking about supportability and stability before pushing out another boatload of new features ... but I bet they don't :(
DAZ did freeze the SDK in the later stages of DS2, and for the whole of DS3 (there were no updates that required a recompile of plugins, though some plugins did have minimum version requirements). 4 has only now, with 4.5, received a formally released SDK so it's too soon to say whether they will achieve the same for the rest of the 4.x updates.
Will you be releasing the codes that the developers need to so their products are fully compatible with DS4 and Genesis? I have purchased Animate2 and some Dreamlight content that I can't use because these developers say that the "code" they need is not available.
Is this something that was fixed in 4.5?
AniMate 2 is already included in the DS installers, just enter your serial number. And yes, the final SDK has been released.
DAZ_Spooky: I am not sure you get what your customers are telling you in general. We all like enhancements but if the cost of deploying the enhancement outweighs the benefit, then the enhancement is not going to be in anyone's best interest (especially DAZ at this point). Users are spending a lot of time updating content, updating plugins/shaders, working around bugs, etc. All of these activities are unplanned disruptions to our workflows. It is costing us time and time, as they say, is money. Do you understand?
For 4.x updates, most of us would gladly have simply settled for quality and performance enhancements without any new features that require plugins to be re-compliled. ANY focus on new features is going to de-focus resources away from quality improvements. For example, was DAZ even going to consider solving the duplicate-ID issue in a way that is transparent to users? This is about DAZ making good solid decisions that truly have the customers' best interest at the top of the list. "Surprise and Delight" is not only about features.
Back on the specific topic, are you certain that there is no workable plugin architecture that will allow for linking a modified base to existing plugins without recompiling the plugins? My advise is for DAZ to think long and hard about this before the next major upgrade.
Amen Brother! I second that emotion. More steak, less sizzle.
Sorry, but I couldn't make sense of this at all. Who is the "they" in this case, DAZ or the developers? Are you saying it is not clear if future updates by DAZ will freeze the SDK or change it and render the plugins useless again?
Sorry, but I couldn't make sense of this at all. Who is the "they" in this case, DAZ or the developers? Are you saying it is not clear if future updates by DAZ will freeze the SDK or change it and render the plugins useless again?
I'm pretty certain Richard meant DAZ. I doubt DAZ have any intention of further revising the SDK in Studio 4. On the other hand, if a major error came to light in the SDK, or there was a major commercial requirement that came to light requiring an SDK change, then that might cause them to revise their plans (which is exactly the same situation faced by any company offering a plugin interface to their products).
I think people are underestimating the effort that goes into releasing code. Yes, in theory you could just throw the current build out of the door, but for a company like DAZ that invites being swamped by users complaining about bugs, non-implemented fixes, lack of new features and so on. Doing formal releases was part of my job description for many years and even if we were working in a far more critical environment than DAZ, with far heavier regulation, many of the necessities will carry over. If DAZ aren't to shoot themselves in the foot with a release they need to 1) run their test suite (which might literally take weeks), 2) log the status of every module, 3) make certain the paperwork is complete on what has been fixed and what hasn't. When we did a release, development work ground to a halt for weeks, and that was with up to 150 engineers available to throw at the issues.
Equally the nature of the new features being implemented may have meant the overhead of separating fixes and new development would have been intolerable. The DSON interface is likely to have fairly deep penetration into the code, potentially meaning that work would effectively have to be done twice. That's not an overhead that's really acceptable.
And just to emphasize Richard's point, I had a series of saved out character .dsfs which the Duplicate ID issue was preventing from working in 4.0.3.47, but which Studio didn't recognise as an error. And Richard's script doesn't work on those files. So ignoring the bug would have left me with unusable files.