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
I can confirm I was having issue with Daz dropping from an active program to a background task upong shutdown which prevernted launching Daz again until old instance was ended by Taskmanager. Disabled the Octane plugin (not just not used it) and now daz is back to normal. Sounds like some sort of mismatch between Daz shutdown process and Octane plugin. Will leave it disabled until Otoy or Daz put their hand up to fix it.
David
Make sure you bug report it ideally to both Daz and OTOY. Squeaky wheels get grease.
_
Hallo,
Is there any known issue with "Post SSIM " on and "Image Series" render?
I try to render a animation, containing 120 frames, and using "POST SSIM" on, but only the first frame will be rendered, all other frames dropping out as a black frame.
Without POST SSIM it seems to work, but of course, consuming twice the time.
_Ranting outloud
Well I get too comfortable with the DIM, making purchases firing it up and hit the download. So the other day I didn't even notice the updates, just figured it was regular product updates. I am a slow learner after all. I wish application updates were highlighted or starred or anything to remind you its a major update! anything to let me know things are about to really change.
I had Daz opened while performing the downloads and installs (not knowing I was updating Daz Studio). Lost some time on the scne as I left for a few hours came back and started trying to add stuff to my scene. Much to my horror everything was telling that file path does not exist. Heart failure...................
Restarted and everything normalized, that's when it hit me that you guys had an upgrade in the Dim I had overlooked.
Guys not everyone out here is a rocket scientist, Most of us are just artist trying to create! Do not forget your target audience varies greatly.
_Rant completed
At the moment it is an experimental feature
https://www.daz3d.com/forums/discussion/comment/5534296/#Comment_5534296
Thank you for the script! Latest DS is now closng and terminating when shutdown. As others have noted it looks to be the OctaneDS plug-in that is the cause.
<edit>
Having chcked on the OTOY forums I have posted a bug report there.
Theres defiantely a problem when this version of DS shuts down. I used to be able to shut DS down and relaunch straight away now I have to wait and wait and wait . Will this be fixed soon.
Actually there does - I used to be able to shut DS down and relaunch straight away now I have to wait and wait and wait its really annoying until I get fed up and end it in Task manager - will this be fixed any time soon please?
FWIW, I just appended the new "-instanceName daz3d#" CLI option to the DAZ Studio shortcut's "Target" property. I think that basically restores old behavior for me as far as being able to launch multiple processes is concerned. You can name it whatever you want, but the '#' in the instance name is important as it automatcally assigns a new instance number. When a new instance opens, you will see the instance name in the title bar (e.g ."[daz3d1]", "[daz3d2]", etc.) I attached a picture of my shortcut setting as an example.
Can almost guarantee you that this is a symptom of a problem (Daz Studio itself or one of its plugins not shutting down in a timely fashion) that has been plaguing your system for quite some time. It's just that DS is now designed to detect this behavior and respond in a way (delaying the start of a new process until the old process has fully cleared) that avoids file read/write errors.
What this update is exposing is that there are a number of plugins (at the very least the Octane and Iray renderers) that have previously unrecognized (at least officially - Iray has been an unofficially known offender about this for years) issues with shutting down when expected.
For me, it's always been how much memory the scene was using. Or, perhaps, it's not so much the absolute amount of memory allocated for the scene but the number of individual DSON object allocated for the scene, such as each node object. The more memory the scene was using, the longer it takes the DAZStudio.exe process to exit while I can see the process memory working set extremely slowly decrease in the Task Manager.
It's as if I'm seeing delete/free() being called at shutdown (or opening a new scene over an existign scene) on every new/malloc() that was called.
I use Command_S for File>Save. This was not happening with the earlier version of 4.12.
I get that all the time. I click Command_R for Render, and I get the message that the Renderer is already in use. I click OK, and it starts to render anyway.
If it's a known problem with Iray then why deny it's happening, and why design the new version to detect the behavior because as user we are going to notice and consider it a bug.
OK, here's something else that's been going on. When I start DIM, [Macintosh version 1.4.0.17 64-bit] I get a supposed set of Default Install Sets. (See screen shot.) I've mentioned this before, but no one has ever responded to it. So, today I thought I'd go ahead an install it. It took a very long time.
After that, I got the Install Errors message. (See Screen Shot).
When I looked in the Items Installed section of the DIM, I got the Installed Failed messages. (See Screen Shot.) This has not happened to me before. I then deleted those failed installs.
Now, if I restart the DIM, I get the same Default Install Sets dialog which sits over the regular DIM. I can dismiss it by clicking on the red button.
Then, if I look in the regular DIM, I see that some of the items from this Default Install Sets, now appear, such as the Shadow Thief, Rocker Outfit, HDR Outdoor Environments, DM's Memorial DS [whatever that is]. I've included more Screen Shots.
So, can someone enlighten me? What is going on?
(You may need to open some of the screen shots in separate windows in order to see all of the wording clearly.)
It isn't a question of "how", it's a question of "where". A .duf file saved into a folder somewhere in your Content Library (the better way to do it) will not be exactly the same as the same file saved to some random other folder, e.g. your Desktop, or somewhere else in your Documents folder. The texture (and possibly data?) folder paths will be different — save into your Content Library, and all file locations will be saved properly as relative folder paths starting from the Content Library base folder. Save anywhere else, and every path will be an absolute location on that physical storage drive on your computer as it is now.
I know it isn't much of a difference, but "it was only a little change" is something traditionally said by computer users (and programmers!) right after Something Nasty™ happens. Because the crash is associated with saving, that difference might be important. And the "relative folder" thing is important too, because that way, it doesn't matter where your Content Library is; if you have absolute paths, and you have to move or re-install your content to another drive, or another computer, those absolute paths will break if they're pointing to a folder that never existed (or doesn't exist any more) on that computer.
No, the paths to Connect Library were actually different (moved it to free up space but apparently I only updated the path in the beta). Fixed now, and problem solved. Thanks!
No one has ever denied that it is an (intermittently) existing problem. It's the core reason why so many experienced DS users are in the habit of process killing DS from Task Manager as a goto solution for when things don't seem to be working right.
Because it technically is a bug since it leads to situations where multiple instances of DS would be reading/writing to the same set of config files at the same time. Which directly contributes to unexpected application crashes and file corruption.
Seriously the mouse wheel thingy is not fixed...
Yeah - I created a ticket for that from the last release and actually worked with their QA regarding my specs and how it happens, but it looks like it didn't make this release. I'm kinda missing 4.10 now.
Mouse wheel thingy?
Since version 4.11 if I use the mouse wheel rather the the on screen "magnifier" to close up to a characater or scene, the iray preview render looks all distorted and pixelated. DS displays a fatal error window after closing. It does this on both my laprtop & desktop.
Erm - I asked and was told no DS didn't take a while to shut down so yes it is being denied.
I said normally there isn't a problem with DS shutting down.
So when can we expect an actual update on the highlights threads for this release? The only one completed is the DS 4.12.1.109 version, that's two versions ago!
Sorry but when I asked
Has this version got a problem with not shutting down properly? you said
''No, it doesn't.''
All I'm trying to establish is should this be ticketed as a bug or is it as RayDAnt says something that has been going on for a while or is it a problem that just I have?
I think it may come down to wording ... from what I can see Daz Studio does not have an issue clising. However, certain 3rd party plugins can prevent the complete closing of DS, so the issue lies with the plugin not doing something in order for it to close or communicate back to the main program, etc.
It is in progress.
OK but it would have been nice to have been told that rather than a simple 'no'.
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.
Go into your Draw Settings for Iray and adjust and change the Manipulation Resolution to Normal. Same thing was happening to me too.