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
bumping to move past page 4. Sorry admins, but this site is horrendous and we have to figure out how to do this ourselves :P
Successfully added to page 5. Sorry for the spam, but this was getting ridiculous :P
They broke their own forum...
I have much to discuss and want to know about the 4.14 beta especially in regards to Filament so was actually considering starting a new thread as this one unusable, I don't want to just post in the Filament thread either as it really is to do with the beta as a whole.
getting onto page 5 does indeed seemed to have fixed it, any information on 4 if any is however lost to us. I had refrained since my other post as was asked not to try and fix it by the mods. Now we can post here however discussion back on topic on the beta would be a great idea.Hey Guys,
I'm on 4.14.0.10. It's now suddenly crashing upon start-up.
I'm sure this is a silly question, but where can I download the latest update mentioned above?
Not seeing it here, and my DAZ Central has me listed as being on 4.12.
this is the Beta thread, do you mean your release build is 4.12?
The Beta you need to use install manager AFAIK
Yes, I know it's the Beta thread. As I'm on 4.14.0.10, I'm looking to download the latest 4.14.1.22, to see if it will cure my current crashing issue. If I launch IM, it doesn't list an update avaialble for DAZ Studio, though I'm on 4.14.0.10.
Check the Download filters (Advanced Settings) in DIM, is the Public Build checked?
That did it. Thanks, Wendy!
was Doctor Jellybean actually
In 4.12 you could load an animation into the "buffer/memory" by keeping the "Iray preview" active. This meant you didn't have to load in all the stuff from the scene before it starts the next frame.
Saved a lot of time.
But in 4.14 this doesn't seem to work anymore and it takes almost an entire minute as if he has to load everything into the memory again. For every single frame.
After I perform an Iray render of a High Resolution object, the Daz Studio 4.14.1.22 Public Beta viewport reverts displaying the object at Base Resolution. This bug seems to affect only the viewport. A subsequent Iray render still renders at High Resolution, even though the viewport is displayed incorrectly. This bug occurs when I have BOTH subD and smoothing applied the the object in the viewport.
I submitted help request #360403 and attached a video demonstrating the problem.
Got the same as you. The subD gets lost after the render. Not included in the redraw. Do any transforms (no matter how miniscule naturally) and it redraws to proper look in viewport (iray previw or variant of texture shaded). So appears to be a redraw issue occuring after render. Changed one of the draw setttings to continuous - didn't help.
PC+ Subscription cancelled. Six+ months to wait is a LONG ask when there is no suprise this was coming.
Source maintenance
Update to NVIDIA Iray 2020.1.2 (334300.5582)
Added pbr_skin.mdl shader
DAZ Studio : Incremented build number to 4.14.1.12
Where do I find this new shader, I can't seem to find it.
Same here would love to know where it is
It doesn't yet have user-facing files, so there's not much you can do with it I'm afraid.
I'd like to know too. It sounds like something made for use in Filament though.
I don't know why but since 4.14.0.10 version the loading time of saved pose presets (or anything that requires read assets) to any character are terribly long, anyone have this problem?
See https://www.daz3d.com/forums/discussion/458361/improving-load-times
The cause is as yet unknown; having a lot of G8 morphs is likely part of the problem. It also affects runtime memory utilization and Daz close-down time based on my experiments.
Latest version 4.14.1.28 is even slower at exiting the application.
Attached is a stack trace of the main application thread which is spinning inside QtCore4.dll!QMetaObject::activate function (called from DzScene::RemoveNode), and using 100% of one CPU core mostly doing nothing.
Here is the log from the application which shows that clearing the scene is the culprit:
I'd like you to note in the log above that a scene with a small city block, one bus, two cars, three G8M figures, and five G8F figures took full 18 minutes to get cleaned before application was allowed to exit. That means you can't launch DAZ Studio again after you closed it because it is not really closed. That kind of "performance" is not acceptable even for a beta.
I suspect that the problem is in the way DAZ Studio is using QT connection lists -- function QtCore4.dll!QObjectPrivate::cleanConnectionLists() is what you should pay close attention to, because it will spin if the list is not dirty and it will not clean up the list which is in use. More info on that particular problem can be found here (search for cleanConnectionLists):
https://lists.qt-project.org/pipermail/development/2016-July.txt
I hope this can be fixed soon because it makes the program unusable.
It also means that opening a new scene from an existing instance of Daz takes almost as long; these days I never do that if the old scene has G8 figures (architecture is fast), I just close Daz and open a new instance, leaving the old one to close in the background.
I've noticed that loading a G8 bumps the memory Daz requires by approaching 2GByte per character. The exact number is system specific but that seems very high for a single character. I know the character morphs have been fingered for this and the log messages do show totally unused morphs being loaded. They do then appear in the character parameter pane and each of those entries probably requires a whole load of Qt QObjects so that might explain part, probably a large part, of the memory.
Maybe, but perhaps more important is that the morph widgets are apparently all set up right at the start when the G8 character is loaded. Each of those per-morph widgets sets up a whole load of Qt stuff; QActions for the +/- buttons, an edit widget for the % and something for the draggable morph control itself and, yes, all of them create a whole load of QConnections. When the character is deleted nothing seems to happen; presumably all that stuff goes on the undo stack so I don't think anything gets deleted (though obviously the UI stuff could be). When the scene is cleared however it would seem that Daz does do the delete, and that it does it in the foreground.
The log messages added after the initial release of 4.14 are signally unhelpful. Most likely they were added to debug a different problem; as your example shows it is immediately obvious that they don't help with this one! It seems very likely that characters are deleted one-by-one, so log messages saying "starting/finishing character number 'x'" (without identifying information of course) might help a lot, particularly if messages about which parts of the character, including the associated UI, are being deleted were also output.
Profiling DAZStudio would immediately identify the problem. If it is the morphs then the obvious solution is to allow the user to add the required morphs via a dialog, possibly with an option to always add selected morphs. I can't see the point of haviing all the morphs that are under Actor/People and many of the others are very very character specific. Those same morphs can be keyed on the timeline as well, accidentally doing so (by making an Object keyframe with "O" selected) massively increases the file size will no additional functionaliy. It also takes about 12 seconds to do and to undo on my system with just the G8 Basic Female. Another solution might be to construct the dialog on-demand, that wouldn't change the UI but it would be a significant slow delay when clicking on the relevant entry in the Parameters dialog.
Well, let's profile it then...
Intel's VTune Analyzer 2020 confirms the hotspot is where I said it is by just cursory analysis of the thread stack.
See attachment.
Nice tool!
If you open task manager after closing DAZ Studio you will see that RAM is being released very, very... no -- extremely slowly over a long period of time.
Attached is another profiling run.
Basically, the issue seems to be that because of:
1. Structure the CPU is repeatedly accessing is poorly aligned (not aligned to cache line boundary)
2. Structure the CPU is repeatedly accessing doesn't fit in (or is being constantly evicted from) L1/L2/L3 cache (i.e. it always has to load variable from RAM)
3. CPU internal store to load forwarding (a way to avoid save to RAM then load from RAM roundtrip) is blocked due to data misalignment and aliasing with other outstanding stores sharing the same cache line (other variables in same 64-byte block)
4. No profile-guided optimization used during development (there is a lot of branch misprediction)
The CPU core doing the cleanup is loaded 100% but it is spending 99% of time waiting for memory access to complete.
Hopefully someone who knows a thing or two about all this will take a look and fix it.
It looks like DAZ Studio is running the destructors of objects which is basically pointless at process exit. DAZ Studio should just save the user profile settings, flush buffers, and call ExitProcess instead of doing pointless memory freeing. https://devblogs.microsoft.com/oldnewthing/20120105-00/?p=8683
@RobotHeadArt:
Cleanup process when it comes to C++ objects is not really easy to avoid. Also, it is a good practice to always write code that does not leak memory and frees everything allocated. Granted, the object destruction should never take so much time -- I am pretty sure there is some threading / synchronization primitive issue here at work.
To me it seems that the underlying primitive from Qt which DAZ Studio is using (a list or a bunch of them, perhaps even singly linked with O(n) performance?) is used in a way which was not anticipated or designed for by Qt developers thus resulting in such abysmal performance. The problem doesn't seem to be specific to Qt4 (I've seen it mentioned for Qt5 as well) so it probably needs a different solution instead of just making sure you are using the latest Qt version.
I don't know if it's the new version of the beta but my fur stopped rendering in a Filament animation
It also seems that geoshells are not rendering correctly in this version.
Part of the character geometry overlaid with geoshell becomes transparent (i.e. missing triangles) in Iray when the character is moved far from the center of the scene (say -6000 on X axis). The geoshells I tested are using mesh offset of 0.010-0.020, scene lighting doesn't matter (default dome and scene or sun and sky both exhibit the same issue). Adjusting the mesh offset to larger values seems to work around the problem.
Yes; from the General Release thread with big letters to make the point (again):
https://www.daz3d.com/forums/discussion/comment/6293161/#Comment_6293161
So it takes twice as long to close a scene as it does to open it and DAZStudio does this when closing it is completely pointless; as Raymond Chen pointed out in 2012. I thought I'd posted this before but maybe someone deleted it because of the reference to Raymond Chen's boss. Sometime around 2000 that gentleman became annoyed because the word processor he used did not exit when he clicked the "X" icon, after carefully saving the document of course. Pretty soon very very good software engineers who worked on that software ensured that when someone (anyone) clicked on the "X" icon the program in question did not laboriously free every single piece of memory before exiting, rather it did what it has been asked to and exited. In fact, to draw on Chen, ExitProcess exited; forget waiting for no sticking messages.