Daz started to crash on render - no changes.
Jappa123
Posts: 4
Hi, something weird happened to my Daz studio, basically every scene with more than 1 figure crash at the beginning of render.
I've been playing around Daz of months never had any problems like this, yesterday everything was fine and today I can't render scenes which I was able to render yesterday.
Some details:
- Tried to update GPU drivers - didn't fix the problem.
- After daz crash internet browsers also freezed and go white/not responding, overall whole PC after crash feels kinda "delayed" - all this is random sometimes there are some issues after crash sometime don't.
- Got few interesting "errors" after crash once browsers show "out of memorry" and once Daz show something like you have wrong opengl version 1.11 should be 1.13 (don't remember correctly)
It's looking like some memorry issues since I can render scenes with 1 figure without problems but it was working just fine yesterday with 3 or more figures.
Any idea what happened? Thanks!
Specs:
RTX 2060S
16GB ram
Ryzen 7 3700X
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
That is a seriously old version of OpenGL. I've got version 4.6, and 1.13 is from like 2001 or something. Are you on Windows 10?
EDIT: By the way, if you need to check what version of OpenGL you're using, in DAZ go to the top toolbar and select
"Help/Troubleshooting/View Log File". Then do a search for "Opengl", and I assume it will tell you what version it sees. And it may even give a hint to the problem
Ye, I'm on Windows 10, about OpenGL i don't remember exact numer, I know there was like small difference like 0.0-0.3 or 0.00-0.03 but only got this error once.
Currently i rendering scene with 3 characters... somehow, only thing i did was free some HDD space, didn't notice it's almost full.
Looks like i manage to fix it, seems like daz needed some free hdd space, and it was almost full, didn't notice it. Feel a little dumb right now...
This is what to look for in the log;
2021-03-15 17:19:59.945 OpenGL features for current hardware:
2021-03-15 17:19:59.945 OpenGL provider: NVIDIA Corporation
2021-03-15 17:19:59.945 OpenGL renderer: GeForce RTX 2070 SUPER/PCIe/SSE2
2021-03-15 17:19:59.945 OpenGL version: 4.6.0
"No Changes" - Windows 10 has not been updating itself?
You sure about that? Not sure that your PC would crash with low hard drive space. Yeah, stuff would slow down, but crash? Maybe it's trying to write some cache to the HDD when it's rendering or something, but not sure that would cause a crash. Basicially a render is READING from exisiting HDD space into RAM, not writing.
But anyway, hope that fixes it.
With 16GB's of RAM (using the drive for more) and if using C-drive for everything, running out of space would be a good candidate for crashing.
So you're thinking the OP ran out of both system RAM and hard drive space simultaneously? Would a couple of characters take the entire 16GB? Seems like a lot of RAM for a couple of characters, but maybe with G8's or something?
On W7, freshly started OS, with only DS running and one lightweight G8 character, lightweight clothing and lightweight hair with 3 spotlights takes 9.7GB's which goes up to 11.1 when rendering. With 3 characters... 16GB's would not be enough to hold everything in RAM and the drive having no space to use as an extension of RAM => Crash.
Thank you for help guys, can confirmed that after freeing up some space everything is fine.
Glad you got it working. Though I'm still scratching my head on how 2 or 3 characters could do such damage in terms of using all 16GB of system RAM.
I loaded 3 random G8 figures, applied hair and outfit (see attached). Looking at the RAM usage in Task Manager for D|S, the total was about 2.8 GB. Nowhere near 16GB. At this rate I could add 5 more of the same (total of 18 characters or something like that) and still be below 16GB.
I must be missing something obvious. I suppose if you're using super hi rez textures, and/or have other apps in the background using a lot of RAM it might be an issue, but still a few characters shouldn't be that resource-intensive should they?
BTW, when I hit Render the total RAM usage gets up around 11GB (this is the one where the OP said the crash happened when render started), but still significantly below 16GB with 3 characters. Maybe there was a bunch of other stuff filling up RAM at the time? Which is why I'm always so interested in the Task Manager graphs to show what's going on with the system during renders.
Okay, well I loaded 3 more characters into the scene with same clothing and hair, for a total of 6 characters, and when I hit Render the D|S RAM usage climbed up to around 15-16GB. And then DAZ crashed. But I have 64GB of RAM on my machine. And hundreds of GB of spare disk space.
I'm more and more convinced that there's a bug in the latest General Release D|S (4.15.0.2).
It looks like you used one character, one set of clothing, one hair and copied the rest.
No, that's three separate G8 characters, loaded twice each, and I loaded the same clothing and hair on each, no copying involved. Unless DAZ is smart enough to realize that it's the same clothing and hair on multiple characters and links them to a single instance?
If the poses and shapes match then yes, I think DS will send only one version of the mesh - it certainly won't duplicate the same texture, and it's generally the textures that eat the RAM.
Ahh, okay. So if it knows not to instance them, but rather link them to a single instance, then it's three separate characters, with three separate textures/morphs, one hair and one clothing. But for some reason, when I had the six characters it used more RAM upon loading and rendering, which kinda implies that it doesn't link them?
I dunno. I guess we'll see if the OP comes back later and says he's still getting the same problem or not.
It may not spot that the mesh is the same - it knows they spring from the same object, the posing and shaping are just modifiers on top of that, but it may not compare the modifier stacks since it would be an unusual event for them to be identical and not instanced. Maps, however, certainly are instanced - you can see that if you use the Image Editor dialogue to change one (e.g. up the tiling) and do a render - you will see that all the uses of the map have the new tiling.
Edit: on reflection it is unlikely that DS would be made to compare the geometry modifier stacks, since that is potentially a vertex-by-vertex job.
Okay, so heres a rendered image with three separate characters, each loaded twice, a single clothing loaded to each, plus three have a second set of clothing loaded on them, and a single hair loaded to each. And the total D|S RAM usage during render is almost exactly 16GB. And I changed the face color of the third character on the far right, and the character behind is the same character, but you can see it doesn't inherit the new face color, which means even though the characters and maps are the same, they are stored separately.
So yeah, loading a character twice means that there is RAM used to separately store each characters' textures, and maybe also the meshes.
Anyway, I think this horse has been beaten enough, but I'm curious to see what the OP's ultimate findings might be.
How did you chnage the face colour? Adjusting the Surface settings won't affect the map, and so can be instanced, while actually chnaging the map itself would mean they were no longer instanced. If you changed in the Image Editor dialogue then yes, you would quite possibly be right about the maps not being instanced.
I used LIE.
LIE creates a new image, in the temp folder (it is recreated in each session), and replaces the original image reference with a reference that resolves to that new image. As a result it is no longer an instance of the original image and has no bearing on how DS handles multiple instances of the same image. I was referring to the Image Editor dialogue, not the Layered Image Editor.
Ahh, okay, got it, thanks.