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 keep ending up in situations where Studio hangs and ends up in a "Not Responding" state and all I can do is open the task manager and kill it. Numerous things seem to cause it. Sometimes it can simply be from clicking in the viewport after I had the program minimized whilst searching the internet for textures or other such stuff I would like to add to my scene.
Other times, I just have to scroll the mouse wheel inside one of the panels. For example the Surface pane. I just click on one of the options then scroll the mouse wheel and, occasionally, it will cause DS to become "Not Responding".It can be any of the panes, not just the Surface pane.
Very frustrating to work on something for hours just to have the program randomly lock up.Especially if I hadn't gotten the opportunity to save my hours worth of work before hand.
I Would also like to see something done to make dforce fail a little more gracefully.Dforce sim failures lock up DS frequently for me aswell.Normally a rather lengthy pause during the sim occurs, then an explosion, then DS locks up.
How long does it "hang"? Some tasks can take a while as there is a lot to do, but I don't see why scrollling a list would do so (unless it was a video driver issue, which might also apply to the issue when restoring).
With the 4.12.2.6 Public Beta I had a instance of DAZ Studio 'hang' for over two hours after I closed it. I had to use the task manager to stop it when my attempts to start DAZ failed.
Also, these weird problems like IceCRMn has had and with DAZ Studio 'seiziing up' itself and my computer have gotten worse with that latest public beta as if they've changed some code in that regard (I know they have because they are using the new iRay SDK).
How much system memory do you have? And is your OS loaded on a more expensive TLC-based SSD like a Samsung 970 Pro or a less expensive MLC-based SSD like a Samsung 970 Evo? or even just a spinning disk drive? These sound like the sorts of issues that crop up if you have a lot of pagefile usage (what happens when system ram hungry apps like Chrome or DS are kept open over long periods of time) going on on a system with inadequate physical system ram to cope and a less than stellar disk technology hosting the OS.
I've had multiple instances of the current daz beta hanging when I try to load a new scene after closing and reopening the program. Process is as such:
I've waited over 30 minutes to see if it would right itself, but it does not. I close out that instance of Daz beta via task manager and then I go back in and reload the scene.
And then today I loaded the beta and when I loaded the scene I've been working on none of the menus would show all the submenus' properties. I had to actually drill down to each submenu in order to see those parameters.
To make things even weirder, when I tried to use morph loader I got the attached error message. I opened the 4.12 pro release from 2 prior and it morph loaded there just fine. So there are definitely some bugs left to work out :/
32 GB of system ram, OS is on an 100GB PNY SSD2SC120G1SA754D117-820 SSD drive.Studio assets are all on a 4TB My Book(USB3). The Studio program is on the SSD.
I haven't seen any issues from keeping Chrome open for hours, but Chrome has a known memory issue on Windows 10 anyway.Microsoft said it was on their side and rumor has it, it's been fixed in the next OS update though.
https://www.windowslatest.com/2020/06/18/google-chrome-will-finally-use-less-memory-on-windows-10/
The only program I use that locks up like this is Studio.
I neither have nor make the time to do much of anything else though.For me, my computer is a Daz Studio appliacne that comes with a news reader and a way to search for other stuff I might want to use in DS.
I've left it hung for several hours a fwe times just to see if it recovers on it's own.I never has.I usually have to kill it.
Tempting providence, but I don't think that has ever happened to me. If you can find a sequence that generally triggers the issue please post it, or open a support ticket - unfortuantely, issues that seem random are a pain to track down and resolve.
Had another "Not Responding" event just now while dforcing a dress.
I attached the MS Visual Studio Debugger to it and it came up with
"...
The thread 0x2188 has exited with code 0 (0x0).
The thread 0x2dd0 has exited with code 0 (0x0).
The thread 0x24b0 has exited with code 0 (0x0).
WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): recv failed errno=10054
Exception thrown at 0x00007FFFA660A799 in DAZStudio.exe: Microsoft C++ exception: DzCloud::RecvFailed at memory location 0x000000003250F1F8.
The thread 0xc68 has exited with code 0 (0x0).
The thread 0x2de4 has exited with code 0 (0x0)"
Here's the output from the Debug window in a text file.It's mostly just a log of all the symbols loaded/not loaded with a couple errors at the bottom.
...and the last line on the DS log was
2020-07-04 12:23:14.147 WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): recv failed errno=10054
You may have mentioned it already, but what GPU model do you have and how confident are you in how it is cooled? The most promising looking bits to me in those error reports is the mention of memory location read errors. Which could either be caused by VRAM limitis being exceeded by potentially balooning "side" GPU tasks like dForce simulation or the least thermally stable VRAM chip on your card causing read/write errors under certain prolonged use scenarios.
The latter is actually a much more common cause of seemingly random crashes in Nvidia GPU accelerated multimedia creation apps (like Daz Studio) than people realize, in large part because Nvidia doesn't believe in putting temp sensors on VRAM chips. And consumer level Nvidia GPUs tend to have their VRAM chip performance settings tuned for gaming performance (as a rule, gaming workloads are much less physically taxing on VRAM chips than compute/Iray style rendering ones.) Something that may be worth trying is slightly downclocking your GPU's WRAM speed and seeing if that makes a longterm difference in the frequency of mysterious DS crashes on your system.
I have a DAZ Studio scene that hangs DAZ Studio several hours too after I close DAZ Studio. Now sure what the cause is but as I use Ultra Scenery and Ultra Scatter or well as 6 instances of DAZ Horse 2 in that scene I think it's related to DAZ Studio waiting for some of the instances' used resources to be dealloced but they never are; possibly because they weren't properly alloced in the first place such that they would need to be dealloced.
Instances work for me on the very latest beta, i.e. 4.12.2.6
I have only started eight instances and everything works perfectly, as they should.
Depending on your hardware resources, you might run even more than eight, if needed.
"..\DAZStudio.exe" -instanceName #dazstudioinstancenameyouwish
that's part of a shortcut, instructing the app to run the desired instance.
Equal problem here, already raised a ticket. It seems the more objects are in your scene (I sometimes use more than 20 characters), the longer it takes DAZ Studio to clean up the memory. I just wonder why.
I don't think it's an hardware issue on my side:
I'd like to specify a program close time (e.g. 5 minutes) and after that, DAZ Studio should just save the scene and program settings and then exit no matter what. Don't understand why that shouldn't be possible.
The company Daz had to jump to build new the program ( studio 5 ) can optimized all core of processor CPU instead of useless fixes.
That, ignoring the comment about "useleess fixes," ignores the fact that many processes do not lend themselves to multi-threading.
Do tell...
I wonder if they do Q/A.
--ms
split studio 5 to 2 builds .
1 -with animation
2 - without animation (to Unwanted using movement tools ,Their works are limited to still image )
This catched my curiosity... Why make two separate editions? If you don't want to use animation tools, simply don't use them.
Also, even if you don't make animations, you still need animation tools to fully use things like DForce hair or clothes, FluidOs or other tools that needs to "calculate" something along time.
All DAZ3D needs to do is to fix all the animation tools (hopeful soon enough) keeping only one "version" of DAZ Studio. Splitting it in two will only bring more chaos on the bug fixes.
i don't mean DForce hair or clothes .
just animation bar .
without animaion bar function we get build has Fixes Bugs faster than with it .
Without animation bar you are getting into trouble with some of the DForce clothes ...
That's right. Some poses cannot be achieved by starting from memorized pose, because body parts (arms and hands usually) will intersect the clothing and other body parts. Animated dForce simulation is necessary and intermediate positioning of body parts is necessary along the timeline.
I've been using this beta since it was released months ago and it generally works - at least it fixed some of the problems I had with previous releases such as crashing to CPU when trying to render an image sequence. However, I'm increasingly noticing odd behaviour with the viewport - it seems to have a mind of its own. Tool bars rearrange themselves as do my tabs. I have to put them back where they belong (according to my layout).
Odd things happening with selections too - suddenly the selected node will not be highlighted so I keep clicking thinking that I have missed it with the mouse cursor. Also, I often use Alt-Left-Mouse click to return parameters to default values but these days, I need to click twice or more to make that happen. Same with adhusting the bone pose - sometimes the sliders don't react on first try so I have to try again and again. It is natural for me to assume finger trouble but I have started to eliminate that possibility by taking note of my actions.
The development staff is already small; how would splitting the product into two versions get fixes out faster?
Do you ever force quit DS from the task manager, if so see this thread
https://www.daz3d.com/forums/discussion/comment/5884856/#Comment_5884856
No - in fact I make a point of waiting for DAZ Studio to clear out of memory by watching it in the task manager after I close (never force quit). Depending upon what is in the scene, it usually takes about a minute or two to clear and shut down completely. I've heard horror stories of it taking 20 minutes or even hours but my average is about 90 seconds.
I get some strange dForce behaviour here. Can someone of you guys confirm this?
With this set up and when I try to remove the dForce modifier, I only get the message that an error occurred and in the log it says it can't find a dForce modifier in the model but if you start the simulation it still collides with the character despite the log saying that there is no modifier in the figure. Also, if I load a scene with a character that got morphs made this way in a session before, adding the modifier and set to static does literally nothing and the object clips right through the character and/or only collides with clothes/items attached to the figure.
So it kinda seems, or at least on my machine, that dForce has a problem with objects/figures that have morphs stored in the scene file instead of asset morphs being used.
Morphs stored in the file, rather than as morph assets, can also fail to project into fitted clothing etc. on load. This is a long-standing issue, but it may be worth reproting your finding https://www.daz3d.com/help in case that helps them to track down the root problem and resolve it.
Ah, interesting! Didn't know that morphs saved in the scene file are a problem. I usually use morphs like this quite often until I get the final result I'm happy with and then boiling it all down to a proper asset morph. Other times I just use quickly made morphs to fix some issues where doing it with dform would take longer than just doing the fix externally and importing it as fixup morph.
dforce objects are meant to collide with all visible to simulation geometry regardless of whether they have the static modifier or not, without the modifier I believe they
operate using the default settings for a static modifier. I have also noticed some models not colliding until I specifically give them a static surface modifier though, I know it happened with the gen 8 female dev load but I haven't tested in a while.