I just tried a mapped filder, a virtual folder, a product, and a category - all worked to open their targets in the Content Library pane. have you checked the end of the log file (Help>Troubleshooting>View Log File) for errors?
May we please we get a Cancel option for dforce during the "Spring of Node" part?
I'm 45min in and it's at 12% so this one obviously isn't going to go well but I have no way to stop it.
Waiting for a couple hours or more for this to fail isn't much fun, and I didn't save my work before I tried this so I'll lose hours more work if I force close Studio.
I'd rather just be able to halt the dforce sim as close to instantly as possible and move on.
edit:
It finally ended the Spring of node part and immediately went unresponsive.
Then Studio kept resizing itself to smaller square in the top left of my screen then snapping back to full size.
May we please we get a Cancel option for dforce during the "Spring of Node" part?
I'm 45min in and it's at 12% so this one obviously isn't going to go well but I have no way to stop it.
Waiting for a couple hours or more for this to fail isn't much fun, and I didn't save my work before I tried this so I'll lose hours more work if I force close Studio.
I'd rather just be able to halt the dforce sim as close to instantly as possible and move on.
edit:
It finally ended the Spring of node part and immediately went unresponsive.
Then Studio kept resizing itself to smaller square in the top left of my screen then snapping back to full size.
It did this numerous times.
I ended up having to end it in the task manager.
This has come up on previous occasions - making the process an event loop, so DS is checking for button clicks etc., in what is a very short loop would emormously slow the process for the sake of what should be the few occasions that a finished item has a lot of short edges to report.
These are things that did'nt become morphs ... just extending a wall up a little where you can't scale becasue the door would scale too or pulling out a side of a wal for the same reason.
exporting as an object looks like it freezes it which means I should make the changes and then export the wall and then import it it.
But as noted in 424 the changes stay. So daz should activate the part of the mesh grabber replacement that handles that in 424 in 25 . . that wouldn't be giving away the plug in.
See
Added support for legacy file IO to the “Geometry Sculptor” tool
DAZ Studio : Incremented build number to 6.25.2025.26119
I don't know how far back Legacy stretches, however.
I have no idea how many items will fall apart in 2025. But these changes were like using mesh grabber to pull out a quad to fix a poke through etc.
Does that imply that you have to be a Premier member so you have access to the Geometry Sculptor tool? What if you are just a base or Daz+ member who owns and uses Mesh Grabber in DS 4? It sounds like that still means that non-Premier users still won't be able to render their DS 4 scenes that have Mesh Grabber deltas in DS 6. If that's the case, this isn't really very great news.
I was trying to put soap foam bubbles on my motorcycle by dforce siming some of the older "foam bubble" props I have.
The mesh on the one small "test subject" didn't look that bad. Basically just an oblong glob with a soap bubble shader preset.
I knew it was in trouble when it started reporting Spring calculations the moment I clicked the to start the sim.
I wanted to stop it then because I knew it would fail but couldn't.
Maybe the time penalty would be worth it if we can stop dforce sims when it's obvious they are in trouble and won't be successful.
Or have dforce throw an error and stop if certain criteria are met. Like too many short edges or something like that.
I'd rather have it refuse to entertain my experiments than lock up and and lose the whole scene.
Sometimes older items dforce extremely well, sometimes they fail spectacularly.
Not just soap bubbles, but many of the old poser dynamic clothes work better than new items made specific for dforce.
The SVDL clothing is a great example of this.
So I'd like to keep the functionality to apply dforce to older items, but still want a way for the Spring of Node to be an early warning that things won't go well and give us an option to quit now or continue and accept our fate if we do.
Edit>Preferences>CMS Settings tab, the Content Cluster location. Though I would suspect it has been changed somehow, before the first of the installations that is still showing, so that would not be the location of your original database..
My first thought too but it hasn't been changed; it's still there
The smart content is in the CMS database, perhaps that's the only thing in there. My CMS had not been damaged, rather the Smart Content itself was damaged and a bug in the DS6 Alpha exacerbated this. This was the cause of the problem:
I bought it immediately before the problem started and after I had installed it the problem was there. Eventually I figured out what was weird about the CMS and deinstalled it. End of problem.
The behavior is that Summer installs Smart Content with tags _at the top level_, Figures, Materials, Shapes or something like that. This is all I could see apart from "Default" which appeared in place of "Lost+Found"; I was mighty confused. No other Smart Content I have puts anything at the top level. I have over 10,000 DIM installed zips (some made by Content Wizard). For all of these the content is under "Default" and in both DS4 and DS6 that top level node is removed from the Tree View showing only its Children. This does not happen after installing Summer; the Tree View shows "Default" and the new top level nodes.
Boy did it take me forever to work that out; two days.
DS6 did not help because it no longer removes empty nodes from the Tree View. In my normal workflow this renders Smart Content frustrating non-productive. In DS4 I click on, say, a G9 and I see only the top level nodes containing G9 content (somewhere). With Summer installed that means (because Summer is 8.1F) suddenly I see the world it was in Spring. Same for G8... In DS6, nope. Summer even shows when she has nothing to display.
The Summer problem itself is a product issue. The DS6 bug may seem minor but it truely toasts Smart Content. I want to see what I can apply to a character, a sofa, a kilt, a sporran etc. I don't need and I don't want to see things, like shapes for a light or environment settings for a sporran, that simply aren't there. It worked fine, well, moderately well, in DS4 and I'm pretty sure it worked earlier in DS6.
These are things that did'nt become morphs ... just extending a wall up a little where you can't scale becasue the door would scale too or pulling out a side of a wal for the same reason.
exporting as an object looks like it freezes it which means I should make the changes and then export the wall and then import it it.
But as noted in 424 the changes stay. So daz should activate the part of the mesh grabber replacement that handles that in 424 in 25 . . that wouldn't be giving away the plug in.
See
Added support for legacy file IO to the “Geometry Sculptor” tool
DAZ Studio : Incremented build number to 6.25.2025.26119
I don't know how far back Legacy stretches, however.
I have no idea how many items will fall apart in 2025. But these changes were like using mesh grabber to pull out a quad to fix a poke through etc.
Does that imply that you have to be a Premier member so you have access to the Geometry Sculptor tool? What if you are just a base or Daz+ member who owns and uses Mesh Grabber in DS 4? It sounds like that still means that non-Premier users still won't be able to render their DS 4 scenes that have Mesh Grabber deltas in DS 6. If that's the case, this isn't really very great news.
I hope this isn't the case.
Mesh Grabber is one of the plugins I can't live without.
I've not tried to use scenes I've made in 4.24 with it in the ALPHA, just working with new scenes in the ALPHA so far and I'm not a premier sub so I don't have geometry sculptor.
This has come up on previous occasions - making the process an event loop, so DS is checking for button clicks etc., in what is a very short loop would emormously slow the process for the sake of what should be the few occasions that a finished item has a lot of short edges to report.
It's a problem because the time to add the text to the TextView widget (or whatever it is) is large, this is a common problem in IO. The TextView widget (or whatever) is entirely in the event loop so the messages completely saturate the event loop. DAZ hangs, the widget displays all of the messages (well after they were originally emitted assuming dForcing is in the background) and then we can cancel!
Fix: QMutex. Check the mutex every time round the loop. Set the mutex from the event loop, check it in the "very short loop" (believe me it is a lot longer than checking a QMutex!)
Supplemental fix: just don't output, hum, 10,000, 100,000 lines to a window? Sure, I know you want them in the log file (though I only ever check the one with the word "shortest") and that takes a serious amount of time, even on Windows. But to a window? Who will ever look at that? It's not even paint drying, which is, in fact, incredibly interesting.
I guess I should post one of my log files?
Same for cancelling the mighty dForce (how many reports have I submitted to Microsoft?) QMutex. The answer to all your background processing issues.
These are things that did'nt become morphs ... just extending a wall up a little where you can't scale becasue the door would scale too or pulling out a side of a wal for the same reason.
exporting as an object looks like it freezes it which means I should make the changes and then export the wall and then import it it.
But as noted in 424 the changes stay. So daz should activate the part of the mesh grabber replacement that handles that in 424 in 25 . . that wouldn't be giving away the plug in.
See
Added support for legacy file IO to the “Geometry Sculptor” tool
DAZ Studio : Incremented build number to 6.25.2025.26119
I don't know how far back Legacy stretches, however.
I have no idea how many items will fall apart in 2025. But these changes were like using mesh grabber to pull out a quad to fix a poke through etc.
Does that imply that you have to be a Premier member so you have access to the Geometry Sculptor tool? What if you are just a base or Daz+ member who owns and uses Mesh Grabber in DS 4? It sounds like that still means that non-Premier users still won't be able to render their DS 4 scenes that have Mesh Grabber deltas in DS 6. If that's the case, this isn't really very great news.
Non-Premier mebers have the extra step of converting to a morph in DS 4, though I am not clear if that requires an extra tool for some vesions of Mesh Grabber (I don't own any of the older versions). But yes, Geometry Sculptor is the only "Mesh Grabber" that will work in DS 2025.
Edit>Preferences>CMS Settings tab, the Content Cluster location. Though I would suspect it has been changed somehow, before the first of the installations that is still showing, so that would not be the location of your original database..
My first thought too but it hasn't been changed; it's still there
The smart content is in the CMS database, perhaps that's the only thing in there. My CMS had not been damaged, rather the Smart Content itself was damaged and a bug in the DS6 Alpha exacerbated this. This was the cause of the problem:
I bought it immediately before the problem started and after I had installed it the problem was there. Eventually I figured out what was weird about the CMS and deinstalled it. End of problem.
The behavior is that Summer installs Smart Content with tags _at the top level_, Figures, Materials, Shapes or something like that. This is all I could see apart from "Default" which appeared in place of "Lost+Found"; I was mighty confused. No other Smart Content I have puts anything at the top level. I have over 10,000 DIM installed zips (some made by Content Wizard). For all of these the content is under "Default" and in both DS4 and DS6 that top level node is removed from the Tree View showing only its Children. This does not happen after installing Summer; the Tree View shows "Default" and the new top level nodes.
Boy did it take me forever to work that out; two days.
DS6 did not help because it no longer removes empty nodes from the Tree View. In my normal workflow this renders Smart Content frustrating non-productive. In DS4 I click on, say, a G9 and I see only the top level nodes containing G9 content (somewhere). With Summer installed that means (because Summer is 8.1F) suddenly I see the world it was in Spring. Same for G8... In DS6, nope. Summer even shows when she has nothing to display.
The Summer problem itself is a product issue. The DS6 bug may seem minor but it truely toasts Smart Content. I want to see what I can apply to a character, a sofa, a kilt, a sporran etc. I don't need and I don't want to see things, like shapes for a light or environment settings for a sporran, that simply aren't there. It worked fine, well, moderately well, in DS4 and I'm pretty sure it worked earlier in DS6.
This is delibeate behaviour - if the Default category is the only top-level category then it is hidden, and you see the second tier categories like Lost and Found; if there are other top-level categories then they and Default are shown, and collapsed.
These are things that did'nt become morphs ... just extending a wall up a little where you can't scale becasue the door would scale too or pulling out a side of a wal for the same reason.
exporting as an object looks like it freezes it which means I should make the changes and then export the wall and then import it it.
But as noted in 424 the changes stay. So daz should activate the part of the mesh grabber replacement that handles that in 424 in 25 . . that wouldn't be giving away the plug in.
See
Added support for legacy file IO to the “Geometry Sculptor” tool
DAZ Studio : Incremented build number to 6.25.2025.26119
I don't know how far back Legacy stretches, however.
I have no idea how many items will fall apart in 2025. But these changes were like using mesh grabber to pull out a quad to fix a poke through etc.
Does that imply that you have to be a Premier member so you have access to the Geometry Sculptor tool? What if you are just a base or Daz+ member who owns and uses Mesh Grabber in DS 4? It sounds like that still means that non-Premier users still won't be able to render their DS 4 scenes that have Mesh Grabber deltas in DS 6. If that's the case, this isn't really very great news.
Non-Premier mebers have the extra step of converting to a morph in DS 4, though I am not clear if that requires an extra tool for some vesions of Mesh Grabber (I don't own any of the older versions). But yes, Geometry Sculptor is the only "Mesh Grabber" that will work in DS 2025.
The Support for legacy file IO to the “Geometry Sculptor” doesn't literally work as expected (not fully functional ....?). I could see the deltas that was made with Mesh Grabber in DS 4.24 after opened the scene file in 2025 Alpha, but in Tool Settings of Geometry Sculptor, zero deltas is marked in the modifier.
I changed the modifer of Mesh Grabber in DUF file to Geometry Sculptor, then the deltas could be correctly marked and shown ~
I just tried a mapped filder, a virtual folder, a product, and a category - all worked to open their targets in the Content Library pane. have you checked the end of the log file (Help>Troubleshooting>View Log File) for errors?
Scripts ->
Category : path to folder
Folder : Native : path to folder with drive letter
only Category custom action moves into right location, the other type takes nothing, no errors or messages into log file.
I tryed reinstall Studio, but nothing changes...
I just tried a mapped filder, a virtual folder, a product, and a category - all worked to open their targets in the Content Library pane. have you checked the end of the log file (Help>Troubleshooting>View Log File) for errors?
Scripts ->
Category : path to folder
Folder : Native : path to folder with drive letter
only Category custom action moves into right location, the other type takes nothing, no errors or messages into log file.
I tryed reinstall Studio, but nothing changes...
That is odd, given that it does work for me. What is the absolute path (including the drive identifier) of the folder(s) you are trying to go to?
I just tried a mapped filder, a virtual folder, a product, and a category - all worked to open their targets in the Content Library pane. have you checked the end of the log file (Help>Troubleshooting>View Log File) for errors?
Scripts ->
Category : path to folder
Folder : Native : path to folder with drive letter
only Category custom action moves into right location, the other type takes nothing, no errors or messages into log file.
I tryed reinstall Studio, but nothing changes...
That is odd, given that it does work for me. What is the absolute path (including the drive identifier) of the folder(s) you are trying to go to?
Another odd thing in addition ? ( referred in my case only to the objects inside Content Library ).
Sometimes when I run Studio and create a custom action inside Scripts menu, when I call that action I see the message:
"The file could not be found.Verify that the file is not been moved and that the base directory is mapped,then try again."
I saw that the script that creates the action takes the full path
let sRelativePath = "/DriveLetter:/fullpath/Light Presets/MYLights/lights.duf";
instead the relative one of the object:
let sRelativePath = "/Light Presets/MYLights/lights.duf";
If I set the relavite one, the custom action works (but this seems happens randomly for some objects not all times for all objects)
Never mind if it is only my issue Richard...
I dont know if there is something wrong on the disc or my pc needs an exorcism...
I deleted ...\AppData\Roaming\DAZ 3D\Studio6 Public Build\ and reinstalled Studio (same issues) but becasue all previous releses never takes me this issues, (I created the menu from 6.25.2025.19807 and managed in the following) I would try the correct steps for reset Studio and restart from scratch.
Which are the correct steps please ?
( I woul like thank you to all developers for your efforts, time and passion into build Studio ! )
Yes, Custom Actions use absolute rather than relative paths even if the target is in a mapped directory - I think it is the only place DS does this. So if the content directory moves, or the drive latter changes, the action will fail.
This is delibeate behaviour - if the Default category is the only top-level category then it is hidden, and you see the second tier categories like Lost and Found; if there are other top-level categories then they and Default are shown, and collapsed.
I didn't say otherwise. I did say that this (the hiding of completely empty tree nodes) isn't happening in the latest DS6 alphas.
I also said that it is a bug in Summer, not the behaviour of DS itself. Maybe a lack of QA... As I pointed out I've got very many products installed and only Summer has this behaviour.
Or perhaps this is a new feature; that there will be top level categories other than "Default"? Do you have a link?
The most important improvement I'd like to see for the 2025 model is the IK pins.
For example, when I want to fix the head and feet in place and move only the waist, I hope they'll be improved so they stay properly fixed.
The conflict between making objects immovable and forces irresistable has been acknowledged in the past. I have no idea where it sits in the priority queue for development but Daz is certainly aware that it is a limitation currently.
I'd mentioned that the latest version won't let me insert an audio file, something I've been doing a lot of since the Alpha was first released. Could at least one other Windows and Mac user take 20-30 seconds and see if they're able to insert an audio file using the Edit/Audio menu option so I'll know if it's an acutal bug or just something happening to me that I can try and sort out?
As mentioned, for me all of the files are greyed out.
It does appear to be the case, but could you please post a screenshot of what you get\see. Thanks.
I don't see anything about fixing the audio import in the change logs specifically; if you've installed the October 1st update could you take a minute to test it and let me know if it's been fixed? It's crucial to what I'm working on right now and if it's not fixed, I'd rather not update, then revert a minute later for nothing.
There is a serious problem with the Oct 2 update on a mac. After a few 3-4 minutes, the memory usage grows so large that the application memory of the computer is filled and the program has to be shut down (over 100GB). This happened a handful of times, each time with only one or two G9 characters in the scene -- no clothing and no environments. All I was doing was changing hair and skin textures to find the one I liked best.
There is a serious problem with the Oct 2 update on a mac. After a few 3-4 minutes, the memory usage grows so large that the application memory of the computer is filled and the program has to be shut down (over 100GB). This happened a handful of times, each time with only one or two G9 characters in the scene -- no clothing and no environments. All I was doing was changing hair and skin textures to find the one I liked best.
What type of Mac are you running? If you can let me know if you are able to import an audio, I'll update and check with my system to see if I get the same problem you're seeing (m4 Pro). If audio still can't be imported, I'll hold off until the next update.
There is a serious problem with the Oct 2 update on a mac. After a few 3-4 minutes, the memory usage grows so large that the application memory of the computer is filled and the program has to be shut down (over 100GB). This happened a handful of times, each time with only one or two G9 characters in the scene -- no clothing and no environments. All I was doing was changing hair and skin textures to find the one I liked best.
What type of Mac are you running? If you can let me know if you are able to import an audio, I'll update and check with my system to see if I get the same problem you're seeing (m4 Pro). If audio still can't be imported, I'll hold off until the next update.
I am on a 2020 Mac Mini (M1). I don't know how to mess with audio, but this issue is far greater than the audio issue. I would recommend skipping this update if you are on a Mac. You can't work more than 5 minutes at a time without Force Quitting the application. The last time I was testing it, I spent more time waiting for the scene to save than I did working in the scene (I was saving after every change that I wanted to keep).
There is a serious problem with the Oct 2 update on a mac. After a few 3-4 minutes, the memory usage grows so large that the application memory of the computer is filled and the program has to be shut down (over 100GB). This happened a handful of times, each time with only one or two G9 characters in the scene -- no clothing and no environments. All I was doing was changing hair and skin textures to find the one I liked best.
What type of Mac are you running? If you can let me know if you are able to import an audio, I'll update and check with my system to see if I get the same problem you're seeing (m4 Pro). If audio still can't be imported, I'll hold off until the next update.
I am on a 2020 Mac Mini (M1). I don't know how to mess with audio, but this issue is far greater than the audio issue. I would recommend skipping this update if you are on a Mac. You can't work more than 5 minutes at a time without Force Quitting the application. The last time I was testing it, I spent more time waiting for the scene to save than I did working in the scene (I was saving after every change that I wanted to keep).
Understood, thanks. I'm still willing to give it a shot, just to give DAZ extra feedback with a different processor and system but only if I can import audio. I don't mind fighting with it for a few hours to see what I can do or not do and then regressing, but without an audio import it's a no-go.
I just updated and mine crashed aswell, but I'm on windows 11.
I had a nude character and was also trying on hair and poses, things like that. Then went to adjust one of his feet when it suddenly crashed.
I didn't think to save the crash report, but I will next time.
the odd part...Texture shaded view is using up to 2x the sytem ram than iray preivew is.
With the scene I'm experimenting with right now task manager is showing 8GB-12GB when Texure Shaded is running and a steady 6.1GB when Iray Preiview is running.
Just a nude character with the same hair I was using during the first crash. I'm trying to reproduce the conditions that made it crash the first time.
I'm using an M4 Macbook Air. I wanted to test if I had the same runaway memory issue mentioned above, so I backed up the September 19 alpha and installed the October 2 alpha. I loaded 2 custom Genesis 9 characters with typical (at least for my renders) clothing and hair in a simple scene with a floor and a wall. I tested with Texture Shaded, Filament and Iray over a period of about 20 minutes (screenshot below is of Iray after the scene was open 20 minutes). The memory usage for Daz leveled out at about 14 GB when in Iray, maybe 12 GB for texture shaded. I saved that scene and tested it in the backed up September 19 alpha. Memory usage there was about a gigabyte lower (13 GB with Iray), but I suppose that's not a huge difference overall. Not sure if specific items, etc. in other people's scenes might trigger a memory leak that I'm not seeing, but at least for my M4 mac, I have not scene it yet.
I can confirm, the same thing happens to me. I load a simple character, move it a bit, and then, after a short while, I get a memory error and DAZ crashes.
My configuration: DAZ Studio 2025 ALPHA - version 6.25.2025.27507! (Updated October 2, 2025) on a Mac Mini M4
Okay, I took a shot and "updated" my DAZ Studio. They still haven't fixed the audio import, at least on the Mac side. I'm not sure what they were improving where the impact was removing the Mac ability to import audio but hopefully they'll return the capabiltiy sooner rather then later. I'll work with the new version to see if there's anything else that broke, then go back to the August 14 version, the last one that let me both import Audio *and* where the keyframes worked in the previously normal manner.
Yes, Custom Actions use absolute rather than relative paths even if the target is in a mapped directory - I think it is the only place DS does this. So if the content directory moves, or the drive latter changes, the action will fail.
With last update the issues on "Folder : Native : path" are gone.
Now Scripts/Favorites custom action links to folders into Content Menu works again.
Two little frustrating things stay from previous releases:
Tools bar messes up on the end of customization.When hit F3 (Window->Workspace->Customize) for Customize DAZ Studio and hit Accept, tool bar looses the order even I lock it with Lock Docking/Undocking (CTRL+U).
I have to save all time the Layout to save Scripts menu completly. If I reload custom saved Layout with Select Layout... the last custom action linked is not showing into the Script menu but keeps hided. I can see the presence of the action into Window->Workspace->Customize->Custom but not in the Menus->Main Manu Bar->&Scripts section on the relative tab of the same Customize DAZ Studio window so is missing on the Scripts menu.
Comments
I just tried a mapped filder, a virtual folder, a product, and a category - all worked to open their targets in the Content Library pane. have you checked the end of the log file (Help>Troubleshooting>View Log File) for errors?
May we please we get a Cancel option for dforce during the "Spring of Node" part?
I'm 45min in and it's at 12% so this one obviously isn't going to go well but I have no way to stop it.
Waiting for a couple hours or more for this to fail isn't much fun, and I didn't save my work before I tried this so I'll lose hours more work if I force close Studio.
I'd rather just be able to halt the dforce sim as close to instantly as possible and move on.
edit:
It finally ended the Spring of node part and immediately went unresponsive.
Then Studio kept resizing itself to smaller square in the top left of my screen then snapping back to full size.
It did this numerous times.
I ended up having to end it in the task manager.
This has come up on previous occasions - making the process an event loop, so DS is checking for button clicks etc., in what is a very short loop would emormously slow the process for the sake of what should be the few occasions that a finished item has a lot of short edges to report.
Does that imply that you have to be a Premier member so you have access to the Geometry Sculptor tool? What if you are just a base or Daz+ member who owns and uses Mesh Grabber in DS 4? It sounds like that still means that non-Premier users still won't be able to render their DS 4 scenes that have Mesh Grabber deltas in DS 6. If that's the case, this isn't really very great news.
I was trying to put soap foam bubbles on my motorcycle by dforce siming some of the older "foam bubble" props I have.
The mesh on the one small "test subject" didn't look that bad. Basically just an oblong glob with a soap bubble shader preset.
I knew it was in trouble when it started reporting Spring calculations the moment I clicked the to start the sim.
I wanted to stop it then because I knew it would fail but couldn't.
Maybe the time penalty would be worth it if we can stop dforce sims when it's obvious they are in trouble and won't be successful.
Or have dforce throw an error and stop if certain criteria are met. Like too many short edges or something like that.
I'd rather have it refuse to entertain my experiments than lock up and and lose the whole scene.
Sometimes older items dforce extremely well, sometimes they fail spectacularly.
Not just soap bubbles, but many of the old poser dynamic clothes work better than new items made specific for dforce.
The SVDL clothing is a great example of this.
So I'd like to keep the functionality to apply dforce to older items, but still want a way for the Spring of Node to be an early warning that things won't go well and give us an option to quit now or continue and accept our fate if we do.
The smart content is in the CMS database, perhaps that's the only thing in there. My CMS had not been damaged, rather the Smart Content itself was damaged and a bug in the DS6 Alpha exacerbated this. This was the cause of the problem:
https://www.daz3d.com/summer-for-genesis-81-female
I bought it immediately before the problem started and after I had installed it the problem was there. Eventually I figured out what was weird about the CMS and deinstalled it. End of problem.
The behavior is that Summer installs Smart Content with tags _at the top level_, Figures, Materials, Shapes or something like that. This is all I could see apart from "Default" which appeared in place of "Lost+Found"; I was mighty confused. No other Smart Content I have puts anything at the top level. I have over 10,000 DIM installed zips (some made by Content Wizard). For all of these the content is under "Default" and in both DS4 and DS6 that top level node is removed from the Tree View showing only its Children. This does not happen after installing Summer; the Tree View shows "Default" and the new top level nodes.
Boy did it take me forever to work that out; two days.
DS6 did not help because it no longer removes empty nodes from the Tree View. In my normal workflow this renders Smart Content frustrating non-productive. In DS4 I click on, say, a G9 and I see only the top level nodes containing G9 content (somewhere). With Summer installed that means (because Summer is 8.1F) suddenly I see the world it was in Spring. Same for G8... In DS6, nope. Summer even shows when she has nothing to display.
The Summer problem itself is a product issue. The DS6 bug may seem minor but it truely toasts Smart Content. I want to see what I can apply to a character, a sofa, a kilt, a sporran etc. I don't need and I don't want to see things, like shapes for a light or environment settings for a sporran, that simply aren't there. It worked fine, well, moderately well, in DS4 and I'm pretty sure it worked earlier in DS6.
I hope this isn't the case.
Mesh Grabber is one of the plugins I can't live without.
I've not tried to use scenes I've made in 4.24 with it in the ALPHA, just working with new scenes in the ALPHA so far and I'm not a premier sub so I don't have geometry sculptor.
It's a problem because the time to add the text to the TextView widget (or whatever it is) is large, this is a common problem in IO. The TextView widget (or whatever) is entirely in the event loop so the messages completely saturate the event loop. DAZ hangs, the widget displays all of the messages (well after they were originally emitted assuming dForcing is in the background) and then we can cancel!
Fix: QMutex. Check the mutex every time round the loop. Set the mutex from the event loop, check it in the "very short loop" (believe me it is a lot longer than checking a QMutex!)
Supplemental fix: just don't output, hum, 10,000, 100,000 lines to a window? Sure, I know you want them in the log file (though I only ever check the one with the word "shortest") and that takes a serious amount of time, even on Windows. But to a window? Who will ever look at that? It's not even paint drying, which is, in fact, incredibly interesting.
I guess I should post one of my log files?
Same for cancelling the mighty dForce (how many reports have I submitted to Microsoft?) QMutex. The answer to all your background processing issues.
Non-Premier mebers have the extra step of converting to a morph in DS 4, though I am not clear if that requires an extra tool for some vesions of Mesh Grabber (I don't own any of the older versions). But yes, Geometry Sculptor is the only "Mesh Grabber" that will work in DS 2025.
This is delibeate behaviour - if the Default category is the only top-level category then it is hidden, and you see the second tier categories like Lost and Found; if there are other top-level categories then they and Default are shown, and collapsed.
The Support for legacy file IO to the “Geometry Sculptor” doesn't literally work as expected (not fully functional ....?). I could see the deltas that was made with Mesh Grabber in DS 4.24 after opened the scene file in 2025 Alpha, but in Tool Settings of Geometry Sculptor, zero deltas is marked in the modifier.
I changed the modifer of Mesh Grabber in DUF file to Geometry Sculptor, then the deltas could be correctly marked and shown ~
Scripts ->
Category : path to folder
Folder : Native : path to folder with drive letter
only Category custom action moves into right location, the other type takes nothing, no errors or messages into log file.
I tryed reinstall Studio, but nothing changes...
How can I update to the latest alpha build? My Daz manager is not showing the update.
That is odd, given that it does work for me. What is the absolute path (including the drive identifier) of the folder(s) you are trying to go to?
Install Manager? Does it seem to show other updates OK? What version of DS 2025 do you ave at the moment?
Another odd thing in addition ? ( referred in my case only to the objects inside Content Library ).
Sometimes when I run Studio and create a custom action inside Scripts menu, when I call that action I see the message:
"The file could not be found.Verify that the file is not been moved and that the base directory is mapped,then try again."
I saw that the script that creates the action takes the full path
let sRelativePath = "/DriveLetter:/fullpath/Light Presets/MYLights/lights.duf";instead the relative one of the object:
let sRelativePath = "/Light Presets/MYLights/lights.duf";If I set the relavite one, the custom action works (but this seems happens randomly for some objects not all times for all objects)
Never mind if it is only my issue Richard...
I dont know if there is something wrong on the disc or my pc needs an exorcism...
I deleted ...\AppData\Roaming\DAZ 3D\Studio6 Public Build\ and reinstalled Studio (same issues) but becasue all previous releses never takes me this issues, (I created the menu from 6.25.2025.19807 and managed in the following) I would try the correct steps for reset Studio and restart from scratch.
Which are the correct steps please ?
( I woul like thank you to all developers for your efforts, time and passion into build Studio ! )
Yes, Custom Actions use absolute rather than relative paths even if the target is in a mapped directory - I think it is the only place DS does this. So if the content directory moves, or the drive latter changes, the action will fail.
I didn't say otherwise. I did say that this (the hiding of completely empty tree nodes) isn't happening in the latest DS6 alphas.
I also said that it is a bug in Summer, not the behaviour of DS itself. Maybe a lack of QA... As I pointed out I've got very many products installed and only Summer has this behaviour.
Or perhaps this is a new feature; that there will be top level categories other than "Default"? Do you have a link?
The most important improvement I'd like to see for the 2025 model is the IK pins.
For example, when I want to fix the head and feet in place and move only the waist, I hope they'll be improved so they stay properly fixed.
The conflict between making objects immovable and forces irresistable has been acknowledged in the past. I have no idea where it sits in the priority queue for development but Daz is certainly aware that it is a limitation currently.
I don't see anything about fixing the audio import in the change logs specifically; if you've installed the October 1st update could you take a minute to test it and let me know if it's been fixed? It's crucial to what I'm working on right now and if it's not fixed, I'd rather not update, then revert a minute later for nothing.
Thanks.
There is a serious problem with the Oct 2 update on a mac. After a few 3-4 minutes, the memory usage grows so large that the application memory of the computer is filled and the program has to be shut down (over 100GB). This happened a handful of times, each time with only one or two G9 characters in the scene -- no clothing and no environments. All I was doing was changing hair and skin textures to find the one I liked best.
What type of Mac are you running? If you can let me know if you are able to import an audio, I'll update and check with my system to see if I get the same problem you're seeing (m4 Pro). If audio still can't be imported, I'll hold off until the next update.
I am on a 2020 Mac Mini (M1). I don't know how to mess with audio, but this issue is far greater than the audio issue. I would recommend skipping this update if you are on a Mac. You can't work more than 5 minutes at a time without Force Quitting the application. The last time I was testing it, I spent more time waiting for the scene to save than I did working in the scene (I was saving after every change that I wanted to keep).
Understood, thanks. I'm still willing to give it a shot, just to give DAZ extra feedback with a different processor and system but only if I can import audio. I don't mind fighting with it for a few hours to see what I can do or not do and then regressing, but without an audio import it's a no-go.
hmm, thats odd.
I just updated and mine crashed aswell, but I'm on windows 11.
I had a nude character and was also trying on hair and poses, things like that. Then went to adjust one of his feet when it suddenly crashed.
I didn't think to save the crash report, but I will next time.
the odd part...Texture shaded view is using up to 2x the sytem ram than iray preivew is.
With the scene I'm experimenting with right now task manager is showing 8GB-12GB when Texure Shaded is running and a steady 6.1GB when Iray Preiview is running.
Just a nude character with the same hair I was using during the first crash. I'm trying to reproduce the conditions that made it crash the first time.
I'm using an M4 Macbook Air. I wanted to test if I had the same runaway memory issue mentioned above, so I backed up the September 19 alpha and installed the October 2 alpha. I loaded 2 custom Genesis 9 characters with typical (at least for my renders) clothing and hair in a simple scene with a floor and a wall. I tested with Texture Shaded, Filament and Iray over a period of about 20 minutes (screenshot below is of Iray after the scene was open 20 minutes). The memory usage for Daz leveled out at about 14 GB when in Iray, maybe 12 GB for texture shaded. I saved that scene and tested it in the backed up September 19 alpha. Memory usage there was about a gigabyte lower (13 GB with Iray), but I suppose that's not a huge difference overall. Not sure if specific items, etc. in other people's scenes might trigger a memory leak that I'm not seeing, but at least for my M4 mac, I have not scene it yet.
I can confirm, the same thing happens to me. I load a simple character, move it a bit, and then, after a short while, I get a memory error and DAZ crashes.
My configuration: DAZ Studio 2025 ALPHA - version 6.25.2025.27507! (Updated October 2, 2025) on a Mac Mini M4
Okay, I took a shot and "updated" my DAZ Studio. They still haven't fixed the audio import, at least on the Mac side. I'm not sure what they were improving where the impact was removing the Mac ability to import audio but hopefully they'll return the capabiltiy sooner rather then later. I'll work with the new version to see if there's anything else that broke, then go back to the August 14 version, the last one that let me both import Audio *and* where the keyframes worked in the previously normal manner.
With last update the issues on "Folder : Native : path" are gone.
Now Scripts/Favorites custom action links to folders into Content Menu works again.
Two little frustrating things stay from previous releases: