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
Chiming in here. I just updated and it went from working great, to where I just want to quit. With Just one GEN8F clothed and a simple HDRI anything you do makes the wheel spin and the CPU shoots off the charts for a minute or two. Something is very very wrong. I am going switching to non beta until this gets worked out.
Follow up: Nope the regular release is worse. I wonder what really doesnt like my setup all of a sudden. I have a 2080ti 64 gigs of 3600 memory, and a ryzen 5 3600. All has been well.
There are two approaches:
To all Daz Team, to Rob and Chris as well,
You are doing a most fabulous, unbelievable heavy work, definitely a most outstanding brilliant hard work. You know very well this is not a compliment, you and all Daz Team are the compliment for modesty and extreamly hard, exquisite quality work. I stay on latest beta all the time and only if I have doubts - that haven't yet happened - I might get the final release if needed.
I wish you all Daz Team, from the very deep of my heart Merry Christmas and Happy Holidays!
My humble appreciation for your sweat and hard work, for your patience and kind support. I realize nothing runs butter smooth in a 3D world without sweat, probably working hard beyond schedule.
God bless you all and please stay safe and healthy.
Me too .
I think you guys are actually having a problem with the newest Windows 10 update. Something sporadically is hammering my computer and I thought it might of been DAZ or Edge as they occasionally do but it's not either one. I've not tried to figure out what is wrong in the newer Windows 10 releases though.
I wasn't aware the regular release had changed recently, so what's changed on your system?
The problem is being seen on 4.14, all versions, but it was actually in 4.12 as well. I don't remember 4.12 consuming quite as much memory, or quite as much time, with each G8 but the problem does seem to get worse over time and I think everyone who has complained about it has a large collection of G8 character morphs (i.e. characters). Maybe something did change recently to make it worse, but not that much worse. The undo stack handling did change in 4.14; it wasn't possible to undo creation of new nodes in 4.12. That could certainly explain a change to the performance on exit because it will change the order in which objects are freed. It's effectively a memory thrash problem so very small changes in the order of memory access can cause massive changes in the time required.
Perhaps related to https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ ?
I just had to kill a program called "googledrivesync.exe" because it was consuming one third of my Surface Pro's limited CPU cores. The easy way to find out what has gone wrong is to run the "Windows Task Manager" (right click on the Windows task bar) and sort the columns by "CPU %". Normally there is some program at the top which has a bug in it; solution, "Kill Process" (another right click).
On Linux run "top" and laugh or cry as appropriate. I think top exists on the BSDs too (it's a BSD originally IRC) so that should work on Apple stuff as well.
If I understand the article it's the opposite; it stops apps that rely on timer interrupts to hide what is really a busy wait loop from being shafted by another app that speeds up the timer. Like the result of reducing friction using a banana skin in Laurel and Hardy. If anything it would seem to slow things down; make banana skins sticky.
TLDR: anyone have any links or advice how to best manage a Win10 install? Or are you guys generally good with Win10Pro? Know this is sort of OT, but having the least amount of issues with DS isn't really OT.
...
Am someone who is still on Win7pro today, and I picked the Window Updates I wanted manually (unnecessary telemetry stuff stayed uninstalled). Just works everyday without one issue. For years. DS and Win7 are a great team. Even in latest Beta.
Slowly looking to get a new system at min with a 3090 this upcoming year. Means can't see how to avoid Win10. Linux distro is just too much work with too many limits on what works - sadly
This entire ongoing drama of Win10 with it's unrelenting surprising new issues is just gob-smacking. Or that's how it sems to me as a non-user when I see next update knocked out something, or complicated something.
Know this is sort of OT, but having the least amount of issues with DS isn't really OT. So on that note, and given this thread attracts more technical types, anyone have any links or advice how to best manage a Win10 install? At one point there was talk of Enterprise Licenses (don't remember proper name ATM) giving you more control over Window 10 updates. But availablity was generally zero to any non-enterprise operation. Or are you guys generally good with Win10Pro?
If you go Win10 you might like to use this free tool.
https://www.oo-software.com/en/shutup10
It gives you a UI to tame Windows without the need to go into registry or group policy editor - and it explains the settings.
Example screenshot from my system is attached.
No, unless those timers changes so mess up the scheduler that the scheduler would leave threads unattended for minutes unattended which I don't think they could manage. I'm sure you've used Windows a long time such that you've encountered where you try to open the File Manager (formerly known as Explorer I think) and Windows hangs on you and nothing happens until Windows crash dumps the File Manager process. It's like that but when it happens anything else open also locks up. Edge, DAZ Studio, even Notepad (I think). Sometimes for minutes on end. Internet download speeds will crawl if you had any going at the time the freeze & slow take hold.
Recovery doesn't typically happen unless the computer is rebooted but you can't because Windows won't respond. So, hold the power button until the computer shuts off power & boot & then Windows is normal. This used to be frequent in Windows 8 I think it was but it was completely gone recently on Windows 10. Maybe it's me using a nVidia video card for the 1st time in a long while; I guess I should chanage the video driver to the 'professional stable driver' and dump the 'game ready driver'.
I always just search for Windows 10 ISO, download it from MS, burn it to USB flash drive, and new install after saving everything elsewhere I want to manually copy back over.
@jbowler I would like to clarify that Raymond Chen is explaining what a DLL (dynamically linked library) receiving the notification about main process exiting should and shouldn't do, not what the main process itself should or shouldn't do on exit. Some of what he says may apply, but as I said above, you cannot skip calling object destructors in C++ -- this process is automatic once the object goes out of scope. Attempting to work around that is invoking undefined behavior.
Proper fix for the problem is to make destruction fast (by using better algorithm), not skip it, especially if those objects are created and destroyed at other times during program runtime as well, not only when exiting.
@nonesuch00
I don't think that Windows timers behavior change have anything to do with DAZ Studio slow closing.
If I recall correctly, that issue was present even before Windows 10 2004 and in 4.12 betas.
@Saxa -- SD
As for Windows 10, my main gripe is the amount of data collection and privacy invasion enabled by default, some of which can only be disabled using Group Policy if you are running Enterprise edition.
As far as stability or issues with updates go, I was lucky not to have any serious issues. In general it is pretty stable and fast.
All of the objects in question - the ones DAZStudio is deleting when the scene is deleted - are heap allocated. The destructor only gets called when the object is deleted, if the object is never deleted the destructor is never called. This is Chen's point about DLLs detaching from a process. He makes a generalized statement about all DLL allocated per-process (not globally shared) resources; if the process is exiting those resources will be cleaned up, so don't bother doing any clean-up. Likewise as has now been observed several times deleting the current scene when DAZStudio exits seems pointless. Indeed, I often save a scene from one DAZStudio instance then open it in another without exiting the original DAZStudio instance to allow me to render the scene at the same time as editing it. The entire state of the scene is saved in the .duf on "save"; there is no need to exit DAZStudio or to delete the scene inside DAZStudio to complete the save.
Exactly. The crazy thing is, doing all this pointless freeing actually increases the memory use by paging in paged out memory. I've watched task manager when closing DAZ Studio after having loaded lots of objects, lets say 15GB is reported in task manager for the DAZ Studio process, it will actually start shooting up by a hundred MB when the close button is clicked. When I see this I just terminate the process since I know it's not doing anything productive. Windows keeps track of the process's pages and will mark them as being free at process termination without having to page them in from disk.
Yes. That distressed me the first time I saw it happening, yet I watched it all the way through; the scene deletion process was, in memory terms, a dance in which active memory goes up a little, there is a long pause, then it suddenly drops. The numbers suggest to me that this happens once for each character in the scene. The whole thing, including the VTune output, is completely consistent with a memory thrash. One annoying thing is the appearance of MiCoalesceFreePages in the trace; at the lowest level the operating system will copy DRAM data around to reduce the size of the lookup (page) table required by a process, doing this in the middle of a sequence of freeing operations or doing it when the process is about to exit is a big mistake. In the scenario in question, scene deletion on process exit, Windows does not know that the process is about to exit so it has no choice but to do all this work.
Quite so; the "DAZ Studio does not exit" problem can probably be fixed easily and this fix should be made (even if it is moderately difficult ;-) The problem of the slow load time for a complex scene and the inordinately slow "deleting the scene" remains. As users we can fix the latter by exiting and restarting DAZStudio if the exit problem is fixed, but the load problem remains.
I often cannot get my lights to work in Filament this latest build unless I save and reload the scene or delete the environment and tone mapping nodes if it's a preload
I didn't say they did, I think that it probably doesn't. I think it's a deadlock in the security code (or whatever really I don't know) doing file & directory I/O. I know Windows 7 had it, Windows 8 had it, Windows 10 (well didn't have it after in the release after the original Windows 10 release and onward) did not until just recently (at least for me).
It's very aggravating to have had a less than year old Ryzen 7 2700 with 8 cores & 16 threads I built that was beating the pants off speed wise with every other computer I ever had suddenly in the last 3 months or so get throttled so severely by something Microsoft did to Windows 10 in all releases greater than or equal to Windows 10 build 2004. Really what that sort of bad design I know not to even bother buying a Ryzen 9 5750X with 16 cores and 32 threads as Windows 10 would throttle to the point of not even having CPU performance as good as my 8 year old laptop. It's definately not Edge or DAZ Studio on my computer that is the problem.
No wonder SolarWinds was such easy pickens. Microsoft's solution is to throttle the computers so severely people will resort to using pen and paper to cipher ain't a great way to handle the problem.
The problem you describe sounds like an issue that arose when Microsoft changed the GUI of the operating system to the "Windows Explorer" "shell" (the Microsoft term, not the UNIX one). This happened around Windows NT 3.1. The problem is that the shell speeds up file search by building an index of the file contents; so Windows Explorer can be used (via the File Explorer app) to search for files containing something as well as for files named something. Building and maintaining the index requires reading the contents of many, sometimes most, of the files on the disk drives. This can significantly reduce the disk availability for other apps. I believe various versions of NT have tweaked the algorithm when when indexing happens but in the original NT 3.1 it was a disaster; the indexing would cease when disk IO was detected but then start again from scratch when the system became idle! If I stopped typing the system froze...
The indexing option is disabled by right clicking on each drive icon in "File Explorer", selecting "Properties" and unchecking "Allow files blah blah blah" at the bottom of the pop-up window.
On my Daz system I do have the option switched on for my main ("C:") drive, I want the documents in my "Documents" directory to be indeed. However I don't have any Daz stuff there apart from the program itself. The drives with the InstallManager downloads and my Daz libraries and working directories are not indexed. Indexing all those .duf files is pointless for most of us :-)
I describe this as an issue not a bug because it's simply a consequence of indexing file contents. The same issue arises with the same feature in KDE on Linux; I have broadly similar KDE and Windows systems and the file indexing is actually worse on KDE, so I have it turned off everywhere.
Somewhat ironically faster drives make the problem worse, although it takes less time. I have various network drives indexed, but they are incredibly slow because the indexer has to read the files over the network; I never even noticed that they are indexed! Indexing slow drives is also the best speed up, at least if the data is to be searched at some point.
after those last two big updates throttled mine it has never been the same
I got my Win10 only last year too
I disabled indexing on all my drives after the 2004 one and it was reasonable but the next one 20H2 hosed it again some other way I guess
@jbowler
1. You are assuming that all the objects were constructed using new. Objects can be constructed on stack and be automatically deleted when they go out of scope (on function exit)..
2. You are assuming that code deleting the objects at the program exit is not the same code that deletes them when creating a new scene or when you request memory purge via script.
In other words, you can maybe avoid this deletion on program exit, but you still have to do it for a new scene unless you want to leak gigabytes of memory so the cleanup code must be optimized, not worked around by skipping it.
I explicitly asserted that all the objects are heap allocated. They are part of the scene (that is what is being deleted), the scene persists across multiple returns to the event loop. The event loop is at the top of the stack. The objects can't be on the stack, well, unless they are under the event loop; it's possible to do that with QApplication and I regularly do that (I create my QApplication on the stack in main()) but these are the one-per-application things, not G8s in a scene. See the first warning here:
https://doc.qt.io/archives/qt-4.8/qobject.html#dtor.QObject
I'm not; I'm assuming that Daz can do exactly as Chen suggests. Check a flag to see if the process is exiting and not do pointless stuff if it is.
Yep, that's what I said, and more beside:
From https://www.daz3d.com/forums/discussion/comment/6338646/#Comment_6338646
No, it's definately not that & it's definately not impatience on my part with OS indexing systems.
So I saw a post from RGBWhizOfTheBrain (well something like that - correction rbtwhiz) and they mention major prep work to a new version of QT. That makes me have questions about DAZ Studio when the release with the QT upgrades are realized.
a) Will that be QT 5 or QT 6 that DAZ Studio is upgraded to?
b) Will that break many EOL plugins as has been often claimed in other threads in the DAZ forums?
c) Will the cause the version of DAZ Studio to be raised from DAZ Studio 4.X to DAZ Studio 5.X?
d) If it does raise to DAZ Studio 5.X version then the DAZ Studio installed for DAZ Studio 5.X Release won't remove my existing DAZ Studio 4.X Release correct?
e) If it does not raise to DAZ Studio 5.X version and it does break EOL plugins, then will only installing the QT upgraded version of DAZ Studio as a public beta break shared resources between DAZ Studio 4.X Release and DAZ Studio 4.X Public Beta?
f) Will installing a upgrade to DAZ Studio 5.X Release and leaving an installed version of DAZ Studio 4.X Release introduce incompatibilities between the two in shared resources like the CMS database?
That's all.
@jbowler
I understand your viewpoint but I would prefer if they found out why it is slow and fixed it because that would benefit "New Scene" option as well -- having to exit a program to avoid it being slow to do something is not exactly the workflow that should be encouraged.