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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
You're an absolute GEM, Crosswind! Thank you, that woulda been a headache
You're welcome !
I'm now having the same issue as jbrettl, I'm trying to load an old scene file and it's just hanging/freezing despite being able to load different scenes, and previous DAZ iterations also loading no worries.
How do I find out what prop might be making it hang?
The last entries of the log before it freezes are:
2025-08-18 19:34:42.555 [INFO] :: Locking viewport redraw...
2025-08-18 19:34:42.555 [INFO] :: Viewport redraw locked.
2025-08-18 19:34:42.578 [VERBOSE] :: Native format content directories: 3
2025-08-18 19:34:42.578 [VERBOSE] :: Poser format content directories: 3
What props do you have in the scene? Easiest way to find out is to load each one at a time in a new scene and see which one is problematic
Yeah that's what I'm attempting to do at the moment, the hard part is it's a big scene!
I wanted to check though, is Poser stuff still useable? I know 3Dlight is on the chopping block, so I wonder if Poser might be in the same boat if something from that is in the scene?
There was an issue with certain Poser assets, but that has been fixed a few builds ago. So it should be fine.
I've found it! And it seems to be to do with bone chains in the same way?
The set was GeeSee3D "Professors Office", and the props in question were the blinds, the power strip and the power cord... all of these have either the cords or the pull-strings on the blinds be made up of a million bones so you can pose them like a snake.
These were the logs from the sections where the prop is being loaded to when it crashed:
Blinds:
2025-08-18 20:06:22.336 [INFO] :: Prepare asset load (merge): /Props/GeeSee3D/Professors Office/Props/PO Blinds.duf
2025-08-18 20:06:22.336 [INFO] :: Locking viewport redraw...
2025-08-18 20:06:22.336 [INFO] :: Viewport redraw locked.
2025-08-18 20:06:22.360 [VERBOSE] :: Native format content directories: 3
Power Strip:
2025-08-18 20:07:46.761 [INFO] :: Prepare asset load (merge): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Strip.duf
2025-08-18 20:07:46.761 [INFO] :: Locking viewport redraw...
2025-08-18 20:07:46.761 [INFO] :: Viewport redraw locked.
2025-08-18 20:07:46.794 [VERBOSE] :: Native format content directories: 3
2025-08-18 20:07:46.794 [VERBOSE] :: Poser format content directories: 3
2025-08-18 20:07:46.794 [VERBOSE] :: Other import format content directories: 0
2025-08-18 20:07:46.794 [INFO] :: Begin asset load (merge): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Strip.duf
2025-08-18 20:07:46.797 [INFO] :: Determining missing assets...
Power Cord:
2025-08-18 20:11:16.565 [INFO] :: Prepare asset load (open): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Cord.duf
2025-08-18 20:11:16.565 [INFO] :: Locking viewport redraw...
2025-08-18 20:11:16.565 [INFO] :: Viewport redraw locked.
2025-08-18 20:11:16.602 [VERBOSE] :: Native format content directories: 3
2025-08-18 20:11:16.602 [VERBOSE] :: Poser format content directories: 3
2025-08-18 20:11:16.602 [VERBOSE] :: Other import format content directories: 0
2025-08-18 20:11:16.602 [INFO] :: Begin asset load (open): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Cord.duf
The computer wasn't reading anything obsurd in terms of CPU, GPU or memory useage, it just stopped responding and that was it.
If theres any other info that I can get that is more useful, let me know!
Confirmed. It may be related to the same issue with an another product, which has been reported.
Was this an issue in the previous version of the Alpha, or was it introduced in the latest update?
The issue seems to result from the same cause, i.e. multiple node levels more than 20+ on a figure.... but it's hard to tell if the same issue could be reproduced in the previous version as we had no chance to give it a test after updating to the latest Alpha version.
I can confirm my scenes with the props that I am now having issues with did work fine in the previous Alpha. It was only after the last update that it started failing.
The field names are not exposed to the end-user, and the diect editing of the database is not supported. Even knowing the names, filename as the actual filename and default_filename as the one to show in the content pane does not sound wholly unreasonable. Actually changing the column names, let alone modifying the structure, would obviously be a compatibility issue
default_filename was designed to keep the original file name of a product item and DUF file from LOCAL USER. Then filename can be changed by the user without breaking metadata linked to Content Tyep and Category, etc. etc..
This logic has been reasonably working in DS 4.x. Relabel feature surely breaks this logic ~~ From a perspective of database architecture, a new filename data field could've been added to support this new feature, and of course, Copy / Paste and sorting behaviors have to be properly enhanced.
Okay ~ anyway, we have to wait for the fix ~~
How do you know what it was designed for? And even if it was designed for that, it could still be repurposed if that was less drastic than other options.
I know that by experimenting various tests as per my exp. of using large DB as well as checking the routines in cms. Logics in cms are not complex ~ Even if there were any really needed "repurposing", the DB design could've be more rational ~~
You are inferring rather than knowing, and it is about details that are not visible in a way supported by Daz. Going off-piste you can't really complain about the lift service.
Anyway, key finding is the fact. Comitted SQL shows everything ~~
I recently got myself a 5090 and found that 4.23 wasn't compatible with the card so I had to grab the 4.25 alpha. Has some improvements, but as you expect, a lot of bugs.The viewport itself feels way more laggy than the stable 4.23 version. Heavier scenes get to the point of being hell to pose. Is there any way to use 4.23 or maybe even 4.24 with the 5090 card being usable?
Unfortunately that is impossible. As for rendering with a 5090, you have to go for DS 2025 Alpha.
Just has the Alpha crash with this ewrror
"Access violation - code c0000005 extThread+0x14: 00007fff`664c4804 c3 ret"
I googled it the google AI resonded with this...
The specific error message "extThread+0x14: 00007fff664c4804 c3 ret" tells you the approximate location of the error within the extThreadfunction of the program. The0x14offset specifies that the error occurred at a location 20 bytes away from the beginning of theextThread` function
This kind of error is usually due to one of the following reasons:
Stale or invalid pointers: Your program might be trying to use a pointer to access memory that has been deallocated or is otherwise invalid.
Out-of-bounds array access: You might be trying to access an element beyond the valid range of an array, according to a Stack Overflow post.
I was working on a character that had a simple hair and bikini fitted to it.
Nothing else in the scene yet, I hadn't gotten that far.
Just the character, hair, and bikini.
RTX 3060 12GB GPU Driver version 580.97
AMD Ryzen 7 3800XT CPU
all NVME Storage
No over clocks or "auto-boosters" of any kind enabled.
That's too bad. I think I'll return my 5090 and grab a 4090 then. It's just too much of a headache to use DS 2025 right now. especially when all the scripts I use no longer work.
You can create in 4.x and render in 2025
2025-08-18 09:22:38.008 [INFO] :: Clearing the scene...
2025-08-18 09:22:38.013 [INFO] :: *** Scene Cleared ***
2025-08-18 09:22:38.013 [INFO] :: Determining missing assets...
2025-08-18 09:22:40.737 [INFO] :: Setting textures...
2025-08-18 09:22:59.668 [WARNING] :: \src\sdksource\cloud\dzcloudtasknotifier.cpp(204): peer performed orderly shutdown errno=0
2025-08-18 09:25:07.384 [WARNING] :: \src\sdksource\cloud\dzcloudtasknotifier.cpp(204): peer performed orderly shutdown errno=0
2025-08-18 09:27:26.662 [WARNING] :: \src\sdksource\cloud\dzcloudtasknotifier.cpp(204): peer performed orderly shutdown errno=0
This is as far as I am getting loading more complex scenes since the last update.
There have been three cases reported of items with a deeply nested skeleton (Parent>Bone1>Bone2>....>Bone20+) hanging in this latest build - did your scene have anything like that?
Hello everyone,
Since the alpha update, I can no longer load my persona (created long before and working without any issues on the previous version). After checking, the problem seems to come from the OOT hair (4in1 Sporty Ponytails for Genesis 9).
The issue has been tested and reproduced on two different PCs.
Is anyone else experiencing the same problem?
I didn't check all of the models, but the long ponytail has over thirty bones in a chain - this build seems to fail to load items with twenty+ bones in a chain, so this is probably expected. Daz is aware of the issue.
I'd managed to narrow it down and find the culprit prior to reading this (long curation time). It was a set of ropes by SY. Any similar type of model (deeply nested skeleton) will not load, regardless of whether it's in a new scene or an old one. Hope they come up with a fix soon. Should I bother reporting this elswhere or just be patient and wait for Daz to sort it out?
It's a known and reproducible issue, so there is probably no need for an additional report at this stage.
The problem is nvidia iray tests can't be done in 4.x, and it would be a pain to alternate between them for lighting issues. Also, I'm ot sure if stuff like mesh grabber will carry over to the 2025 paid version. I already have to do this with my scripts, and it just seems easier to go back to what works by returning the 5090 and grabbing a 4090 for cheaper