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
It's all of the above. This is a longstanding issue that effects certain users more than others (due to factors like what mixture of solid-state vs. spinning magnetic storage drives you use with your system) that should be bug reported whenever encountered. Especially if it impacts your user-experience with the program (which it now most definitely will due to the recent changes Daz has made.)
I just rolled back to the old version of 4.12.
Did you try restarting your computer and then - prior to attempting to launch Daz Studio - uninstalling and then re-installing Daz Studio via DIM? Because the symptoms you mentioned sound suspiciously like a side-effect of DIM attempting to update DS while DS was still running (which will result in a mixture of two different release's binary runtimes being jumbled together.)
Under what circumstances would an add-on need to continue to run (or still be in memory or however you mean) when the user exits DS? If there are no compelling reasons--which I don't really think there are but would like to hear if there are--then DS should just kill the add-ons when DS is closed.
Plug-ins might need to store data, clean up temp files, release memory. DS doesn't know why a plugin hasn't closed.
Sure, I can see those scenarios. But from @scorpio's test: "I just timed it and it was almost exactly 5 minutes, where my CPU usage dropped when I first closed the lowest it got to was 4% then it climbed and fluctuated between 7-8% until it shut completly." That seems like a very long time to store data, clean up temp files, and release memory. I opened/closed DS, didn't even bring up Octane's windows, just a quick open/close, and DS was still in memory. I didn't time it, when I get a chance I will, but what possible data would an add-on need to store, etc. in that scenario? Open/close. Done. Still in memory.
Given the reports of Octane issues at shutdown - these are questions for Otoy to address, not something Daz can do anything about.
Step #1 - check your log file. The answer very well may lie there. See what's described to be going on during/immediately after those seconds/minutes of delay between "closing" DS and the entire process tree actually shutting down (every line in the logfile is timestamped to help troubleshoot in situations exactly like this.) Many plugins like Iray are actually full-fledged programs unto themselves that are designed to make a graceful exit only after all their underlying tasks have completed. But since they are implemented as plugins, they are at the mercy of DS to properly communicate to the end user that there is something that they are still doing/need to do.
Looking at the log it does seem to be Iray that is preventing it from closing. But this does not explain the second instance in the Task manager.
Not only is DS taking a long time to shut down twice today I have noticed a second instance of DS in the task manager.
One instance closes within a few minutes but the second has not, its still open over 20 minutes after closing DS, I am not opening more than 1 instance of DS at a time, DS is sometimes not closing completly at all.
After readin this I've been checking my task manager. The shutdown period seems to depend on the complexity of the scene but mine are averaging around 30 - 40 seconds over the past couple of days. I'm running the 4.12.1.117 beta without Octane installed.
Wich one is it? All I see in the draw settings is delayed or continious or optimized or full can you post screenie:)
The suggestion vanished WTF??
I can't open multiple Daz windows after updating it to the current build. The previous one was working fine, and I updated it through DIM. Whenever I try to open a new window of Daz it just highlights the already opened one.
One needs a script to create additional instances. See this post for more info, the script is at the bottom:
https://www.daz3d.com/forums/discussion/comment/5112696/#Comment_5112696
Why is it so in this build? Or is that default for a long time? I installed Daz manually without DIM and I needn't need to use any such scripts then. Is it just due to installing via DIM? I also need to name the instance for some reason. This is some ridiculous setup to launch Daz.
It has been since 4.12.1.40, and it applies to standalone installers as well as the DIM package.
Not entirely true. If that were the case I wouldn't be here first thing as soon as it messed up. Maybe it's a glitch or not I still have it on my laptop and my girlfriend's both on which I can easily open multiple instances of daz without any additional work. Whatever they were thinking before implementing it, it's a totally wrecked up move. Reinstallation of Daz didn't help at all (without DIM, I had to, since that script eventually made me loose my Daz layouts and everything, gladly CMS and content directories were unaffected.)
In the last Daz version I can easily open multiple windows of Daz.
EDIT: Why the heck would they also remove links for previous releases? Looking for the v4.12.0.86 release to test it out on a different system.
Actually, it started in the previous version: 4.12.1.16. See the previous post
https://www.daz3d.com/forums/discussion/comment/5003831/#Comment_5003831
The purpose of the new method (script to create instances) is for a safer and more reliable setup. Using the script to create instances only take a few seconds, and they can then be executed from shortcuts. There are plenty of applications which don't allow multiple instances, e.g. PhotoShop.
Copying from a post I made elsewhere:
You can create shortcuts for different instances of DS that you set up with the script DoctorJellybean links above. For example, run the script and set the optins like this to create a new instance called renderMule (I was thinking of using it as a renderer), taking its settings and UI from the General release (you can pick a different version or existing instance in the dialogue). I should probably have picked one of the clean options too, so it starts as a clean copy of the chosen target. Don't check launch, we are going to make a short cut for that. The other two options are for passing additional arguments and for setting a file for the instance to load on launch (say a default scene with cameras already set up, if the instance was for making new scenes).
Click Accept and an alert pops up showing the command line - click Copy to put it on the clipboard.
Now right-click on the Desktop (or wherever) and select New>Shortcut. Paste the copied command line into the location box and click Next, then name your shortcut (e.g. DS RenderMule). Now you can use that short cut to launch the RenderMule instance of DS, and it will copy its settings and UI from the General release.
@DoctorJellybean I can relate to why it can be and is a safer/reliable setup. And maybe some users even asked for it or find it useful. And then there will also be some users who wouldn't. This was something released in a public beta, I don't understand why there was a need to implement it into a general release. Considering the amount of newbie users there might be, I just had to waste 2 hours to find what it was and all, since I don't frequent the forums here or keep up to date with the news related to Daz and beta builds.
1-2 hours were then wasted in trying to also find a workaround which did not involve the script. Again, really don't see the need to implement it into a general release when the option to disable it or whatever kind of option they are *going-to implement in the future for it, wasn't there yet. If it were just the case of instances and all, it could have just done it in secret and maybe included the default settings for it, when Daz would normally launch (when this whole thing wasn't present)
All this thing with the script and all seems like at-a-glance for advanced users and not for anyone who installs Daz for the first time or is still new with it and comes from the old build.
On the side note, having to name the instances is like a thorn stuck in your finger, which just keeps bugging you. And then it shows up on the title bar too. And also creates a new icon in the taskbar. And an additional (unnecessary) shortcut. Not that I mind all those things or anything of the sort, but honestly it could have been implemented in a more sophisticated way for which a new user or anyone wouldn't find it any different from the previous way Daz would launch. Overall, it just needlessly makes the process of working cumbersome. Of course it's a one time setup, but this is something a normal user wouldn't have had a need to be doing or indulging in.
EDIT: @Richard+Haseltine I already know of it, that's why I said it's a one time setup. Regardless of one time or not, it shouldn't have been necessary at all.
Still getting this - according to task manager I've got 2 DS running (I'm not running this script so that you can have 2 DS open at once) is this normal behaviour?
There should only be one if you don't have any instances. Which version are you using?
4.12.1.117
It's because the existing method of allowing multiple instances (having no limits on the number of identical DS processes launched) was leading to program instability since they were all actively reading/writing from the same set of configuration files simultaneously. In the past this didn't matter so much since most of Daz Studio's popular workflows didn't need much in the way of intermediate file storage to operate. But with the rise of things like advanced scripting and 3rd party plugins, safe temp file access has become much more critical. Hence the need for a change.
If you saw my original recent comment, nevermind!
It has been taken up with the Developer of the Octane plug-in and he was able to recreate this hang situation with Daz, but says that the Octane plug-in has already closed by the time Daz hangs:
https://render.otoy.com/forum/viewtopic.php?p=382375#p382375
It doesn't matter which level of Octane plugin that I use with Daz, the effect is the same on v4.12.1.117.
The only thing that changed was the Daz level: earlier versions close fine with Octane plugin installed.
ALL: Does this need a ticket to Daz?
Yes, if you want Daz to look at it.
I've been having a massive problem with this build with Daz not closing or some phantom version remains open and if scenes are saved and then you try to render Daz will cause my PC to have to be reset It does it with the public build and the beta versions so 4.12.1.117 oh and pressing shift - k does nothing to turn off the keyboard movement
Beeing a software developer myself, I understand the problem of starting multiple instances of a program that was meant to be run only once. But I didn't understand the current solution. I have seen two workarounds here, the -instanceName option and the script. But what did you mean with "safer and more reliable"? Is it reliable in a way that we can start mutliple instances without risking the instances destroying each others data? Or is it only "more reliable" with a risk still remaining?
And if the solution is save, isn't it possible to implement automatic instancing in DS itself instead of forcing the user to manually add command line options or calling scripts?
That. Previously multiple instances shared the same data, files, settings, etc.