Loading...
> >

Daz Studio 6 Beta - version 6.25.2026.14722! (Updated May 28, 2026)

1…5051535556…76

Comments

  • Richard HaseltineRichard Haseltine Posts: 110,210

    Scoremonger said:

    Richard Haseltine said:

    Scoremonger said:

    Some feedback about Daz Studio in general (not really 2025 Alpha-specific) - viewport navigation and object selection in Daz feels very compared to any modern 3D game engine like Unreal Engine, Unity or even Godot. I want to be able to easily fly the camera around my scene, select things, move things, duplicate things, etc. without having to manually toggle the look around mode back on.and such. Overall the UX in Daz is pretty painful and imo the things one does in Daz are more similar to the things you do editing levels in Unreal Editor than a dedicated 3D modeling app like Blender or Maya (but even those have friendlier navigation, selection and manipulation tools.) Of course, I'm biased because I'm a game designer and not a professional artist, but still... I've used a lot of 3D software over the years.

    Please describe what you thinkwould be better, there isn't much here that really explains what you want to see and why it would be better - which is what constructive criticism needs to offer.

    Anyway, thanks, it's meant as constructive feedback. I know there have been some efforts to create layouts in Daz that feel more like Unity, etc. but they were still pretty half-baked the last time I checked. Would be great to have at least one "industry standard" mode for basic viewport navigation, selection and object transform tools.

    Sure. My disclaimers will be: that I have not explored the massive array of Daz workspace customizations exhaustively, so for all I know it may be possible to reconfigure my workspace to give me what I want (but it definitely doesn't work that way by default.) I am also used to a number of other 3D tools, especially game editors and 3D modeling tools, that more or less have standardized controls for basic things and which I have used far, far longer than Daz Studio, so I know that what drives me insane might be more acceptable to someone who has been using Daz exclusively or for a long time.

    First, the simplest feedback - Daz has some of the most finnicky transform manipulator handle selection I've seen. You must be very precise when selecting a Daz manipulator handle. Like, down to the pixel. If you want to drag the object along the X axis, you must put your mouse pointer directly over the (fairly tiny) arrow on the manipulator. The manipulators in every other package out there, from Maya to Blender or any of the game engines I listed, have MUCH more forgiving manipulator selection. You can click somewhere in the general vicinity of the handle and drag, and the object will move, rotate or scale. In Daz it's unforgiving.

    In fact the gizmos have been fattened up in DS 2025, so this should have eased compared to DS 4. If that doesn't seem to be working for you then it may be worth a report.

    Regarding the camera, what I would like is a more easily accessible camera mode in which you can fly the camera around the scene, make object selections, and switch between manipulators easily with minimal keyboard or mouse inputs and zero clicking on buttons in the interface, exactly like the standard fly camera, selection and manipulation controls in all the freely-available major game engines. Fast camera mode switching, object selection and manipulation greatly improve workflow speed, paricularly when building out a scene (AKA level design.) The things that always jump out at me first when working on a Daz scene are "wow it's painful to navigate the scene" and "wow it's painful to move things around in the scene."

    ctrl will accelerate now (I think this came in in late DS 4). I think the other aspects may be more specific to games, where level navigation is part of the design process; I have various  other 3D tools and their navigation isn't like this (though it does vary from app to app). DS is close in feel to modo/Lightwave. The actual modifiers for viewport drag can be modified - I use ctrl alt drag for orbit/rotate, shift alt drag for dolly/pan, and ctrl shift alt for zoom and tilt.

    (I realize Daz does have the "Scene Navigator Tool" which is similar, but it's clunky to use by default and does things in a somewhat non-standard way. It also seems glitchy to me - I find the camera sometimes jerkily rotates along its forward vector while I'm using WASD, etc. - especially in DS 2025 where it seems to be an unfinished feature.)

    This is the *game industry-standard behavior for fly cam in level editors because of the workflow speed advantage for environmental layout:

    • Right click and hold to enter fly cam mode. WASD keys to move the camera around the scene. Manipulator hotkeys are disabled while flying around. It's similar to the Scene Navigator Tool, but incredibly easy to toggle. 
      • Note that at least in Unreal's case, they still support a right click context menu in the viewport while also supporting this fly cam feature - the context menu just requires a normal right mouse button click + release, but holding the button enables the fly cam.
    • Holding shift either accelerates or decelerates the camera's flight speed, depending on the engine - like a sprint modifier in a video game.
    • Mousewheel up and down either increases or decreases the camera's top speed, making it easy to fly around tiny areas of the world or massive ones.
    • When you're done moving the camera, releasing the right mouse button returns to the default camera and selection mode instantly.

    The viewport cameras in these engines have easy non-fly modes too - the standard orbit, panning, zooming stuff that Blender, Daz, Maya etc. do. For example, in Unreal it's very similar to Maya - you can hit F to focus selection on an object and then hold Alt+LMB and drag to orbit the object. In Godot it's the same except you hold MMB and drag to orbit. They all support similar panning, etc. This part is not quite as standard across engines. My main point here though is that the fly cam doesn't have to feel quite as modal as what Daz has implemented. The camera modes in these game engines are super fast to cycle between, and there's no setup or workspace reconfiguration required. And they haven't sacrificed any of the more traditional camera controls that Daz has.

    Finally, back to manipulator tools, it's very common to have the manipulator hotkeys be WER by default, thanks to Maya's influence. That's what all the game engines I listed do, not just because those are the standard Maya hotkeys, but because they are almost the same keys used for flying the camera. So as you switch between camera movement, object selection, and the manipulators, you're barely moving your left hand on the keyboard. It's a fast, easy and efficient combination of features that are used constantly when building out a space. That's also why I'm fixated on these kinds of features - they are used over and over again second by second. Small optimizations to features like these that are used so often can be super helpful.

    Anyway, I know that DS is a big piece of software with a bunch of users with a bunch of preferences and an absolute mountain of tech to maintain, and I assume the dev team isn't too big. So I know it's not as easy as snapping your fingers to make things just the way I prefer. But I wanted to call these particular low level workflow issues out because each time I come back to DS, these are the things that make me want to quit again.

  • ScoremongerScoremonger Posts: 18

    Richard Haseltine said:

    Scoremonger said:

    First, the simplest feedback - Daz has some of the most finnicky transform manipulator handle selection I've seen. You must be very precise when selecting a Daz manipulator handle. Like, down to the pixel. If you want to drag the object along the X axis, you must put your mouse pointer directly over the (fairly tiny) arrow on the manipulator. The manipulators in every other package out there, from Maya to Blender or any of the game engines I listed, have MUCH more forgiving manipulator selection. You can click somewhere in the general vicinity of the handle and drag, and the object will move, rotate or scale. In Daz it's unforgiving.

    In fact the gizmos have been fattened up in DS 2025, so this should have eased compared to DS 4. If that doesn't seem to be working for you then it may be worth a report.

    Regarding the camera, what I would like is a more easily accessible camera mode in which you can fly the camera around the scene, make object selections, and switch between manipulators easily with minimal keyboard or mouse inputs and zero clicking on buttons in the interface, exactly like the standard fly camera, selection and manipulation controls in all the freely-available major game engines. Fast camera mode switching, object selection and manipulation greatly improve workflow speed, paricularly when building out a scene (AKA level design.) The things that always jump out at me first when working on a Daz scene are "wow it's painful to navigate the scene" and "wow it's painful to move things around in the scene."

    ctrl will accelerate now (I think this came in in late DS 4). I think the other aspects may be more specific to games, where level navigation is part of the design process; I have various  other 3D tools and their navigation isn't like this (though it does vary from app to app). DS is close in feel to modo/Lightwave. The actual modifiers for viewport drag can be modified - I use ctrl alt drag for orbit/rotate, shift alt drag for dolly/pan, and ctrl shift alt for zoom and tilt.

     

    The gizmos in the latest version of 2025 are as difficult to select as ever, sadly, and they look to be about the same size as in DS 4. I'd report it, but it seems like what's called for is a new feature to add an invisible selection zone around the handles that increases their selection size without increasing their visual size. Is there a feature request channel to Daz other than the forums?

    As for the default camera movement stuff, yeah, those are not super-standardized across apps anyway, and Daz's implementation of those basic controls is fine, I guess. I have minor gripes but it's easy enough to get used to with a little tweaking.

    However the fly camera is useful for building environments in general, not just building them in games, and the Daz implementation of that feature is pretty clunky. Unreal can be used to build out scenes for film and animation extremely quickly and the fly camera and manipulator controls are a big part of the reason. Daz Studio arguably has more in common with level editors than with high end modeling and animation software since one of its main purposes is to construct scenes by placing models, lights and cameras into the world and moving them around. At a high level it's the same as building and lighting a game environment. I think there's a lot of crossover here.

    Anway, TLDR: I wish there was a fly cam that was easy to toggle and manipulator handles that were easy to select.

    I'll stop beating the horse, though. Just wanted to get those suggestions out there. Thanks for engaging with my feedback.
     

  • UncannyValetUncannyValet Posts: 267

    Scoremonger said:

     

    As for the default camera movement stuff, yeah, those are not super-standardized across apps anyway, and Daz's implementation of those basic controls is fine, I guess. I have minor gripes but it's easy enough to get used to with a little tweaking.

    It might not be standardised, but most 3D DCC software are using one of two methods.  They do not make you click three buttons (CTRL + ALT + something) to do a basic rotate or pan.  Usually it is simply ALT + Something or it is simply the middle mouse button for obrting etc.

    I would suggest daz take the opportunity to reassess defaults to be more in line with other software.  I doubt there is a significant userbase sentimentally attached to the current keybinds, as when I watch seasoned daz veterans on youtube using Daz, they still all seem to be using the Gizmos to orbit and pan, which is rather baffling.

  • Dr.NopeDr.Nope Posts: 3

    Since last update, most of the time I have to triple-click to bring up context menu in viewport.

    But thanks for fixing that undo-calamity.

  • TugpsxTugpsx Posts: 876
    edited November 2025

    I think one of the most coveted features in Daz animation is reverse playback and forward speed control. With the current features of Studio 6 and Scripting/SDK still under development. I have worked on a few quick fixes.
    I know we are using an Alpha and therefore things will change as we move along. As pointed out sometimes the UNDO stacks dont produce the desired results during script building.

    Here is a snipplet of a few things in the works for Alpha. I may need to grab a few beta testers from the Alpha users.

     

    Screenshot 2025-11-15 094406.png
    563 x 249 - 14K
    Screenshot 2025-11-13 223717.png
    606 x 624 - 48K
    Post edited by Tugpsx on
  • TugpsxTugpsx Posts: 876

    Here is a snipplet of a few things in the works for Alpha. I may need to grab a few beta testers from the Alpha users.

     

    Screenshot 2025-10-12 135438.png
    543 x 609 - 34K
  • Richard HaseltineRichard Haseltine Posts: 110,210

    UncannyValet said:

    Scoremonger said:

     

    As for the default camera movement stuff, yeah, those are not super-standardized across apps anyway, and Daz's implementation of those basic controls is fine, I guess. I have minor gripes but it's easy enough to get used to with a little tweaking.

    It might not be standardised, but most 3D DCC software are using one of two methods.  They do not make you click three buttons (CTRL + ALT + something) to do a basic rotate or pan.  Usually it is simply ALT + Something or it is simply the middle mouse button for obrting etc.

    You can use a single key modifier - but it will then usurp one of the tool click-modifiers, which is why I don't. Qt 4 did not, as I understand it, support using non-modifier keys (e.g. space for pan/dolly) but it is possible that Qt 6 does - which doesn't mean it will be added, of course.

    I would suggest daz take the opportunity to reassess defaults to be more in line with other software.  I doubt there is a significant userbase sentimentally attached to the current keybinds, as when I watch seasoned daz veterans on youtube using Daz, they still all seem to be using the Gizmos to orbit and pan, which is rather baffling.

  • Richard HaseltineRichard Haseltine Posts: 110,210

    UncannyValet said:

    In the Alpha SBH Editor, is there a way to remove the reflectivity on the haircaps while in Paint mode?

    They make it difficult to see what you have painted.

    It does not matter which Drawystyle you are using, the issue is on all Drawstyles

    Temporary solution: If you turn the Base Color of the haircap to Black, they go away.  I assume we shouldnt have to do this...  This was not an issue in the previous SBH Editor.

    The issue is probably "Z fighting" - two bits of geometry at the same spot, so the camera isn't consisten over which it draws first.

  • ScoremongerScoremonger Posts: 18

    UncannyValet said:

    Scoremonger said:

     

    As for the default camera movement stuff, yeah, those are not super-standardized across apps anyway, and Daz's implementation of those basic controls is fine, I guess. I have minor gripes but it's easy enough to get used to with a little tweaking.

    It might not be standardised, but most 3D DCC software are using one of two methods.  They do not make you click three buttons (CTRL + ALT + something) to do a basic rotate or pan.  Usually it is simply ALT + Something or it is simply the middle mouse button for obrting etc.

    I would suggest daz take the opportunity to reassess defaults to be more in line with other software.  I doubt there is a significant userbase sentimentally attached to the current keybinds, as when I watch seasoned daz veterans on youtube using Daz, they still all seem to be using the Gizmos to orbit and pan, which is rather baffling.

    Thank you, yeah, I didn't want to wear out my welcome, but you've identified my "minor gripes" with the default camera controls - they work, but they're more cumbersome than any of the modern 3D tools I use.

    I wish Daz would take a hard look at the UX for these fundamental interactions. Similar to how Blender finally bit the bullet years ago and abandoned their crazy "right mouse button to select" paradigm and other odd things they'd been hanging onto for years. Blender still has its share of quirks, but it's worlds more enjoyable to use after they did their UX overhaul (in 2.8, I want to say?) Granted this was a big development lift for them, but holy hell did it make their software better.

  • UncannyValetUncannyValet Posts: 267

    Richard Haseltine said:

    UncannyValet said:

    In the Alpha SBH Editor, is there a way to remove the reflectivity on the haircaps while in Paint mode?

    They make it difficult to see what you have painted.

    It does not matter which Drawystyle you are using, the issue is on all Drawstyles

    Temporary solution: If you turn the Base Color of the haircap to Black, they go away.  I assume we shouldnt have to do this...  This was not an issue in the previous SBH Editor.

    The issue is probably "Z fighting" - two bits of geometry at the same spot, so the camera isn't consisten over which it draws first.

    Perhaps, and I considered that, but it manifests very peculiarly because changing the color of the haircap makes it go away.

    And the Z-fighting/clipping issue does happen, but manifests differently and is zoom-dependent.

    There are two issues, that issue you describe as Z-fighting and separately what Im describing as "reflectivity". The "reflectivity" being much more annoying.

  • Richard HaseltineRichard Haseltine Posts: 110,210

    UncannyValet said:

    Richard Haseltine said:

    UncannyValet said:

    In the Alpha SBH Editor, is there a way to remove the reflectivity on the haircaps while in Paint mode?

    They make it difficult to see what you have painted.

    It does not matter which Drawystyle you are using, the issue is on all Drawstyles

    Temporary solution: If you turn the Base Color of the haircap to Black, they go away.  I assume we shouldnt have to do this...  This was not an issue in the previous SBH Editor.

    The issue is probably "Z fighting" - two bits of geometry at the same spot, so the camera isn't consisten over which it draws first.

    Perhaps, and I considered that, but it manifests very peculiarly because changing the color of the haircap makes it go away.

    And the Z-fighting/clipping issue does happen, but manifests differently and is zoom-dependent.

    There are two issues, that issue you describe as Z-fighting and separately what Im describing as "reflectivity". The "reflectivity" being much more annoying.

    Someone did test and Z fighting was strongly suggested by the fact that hiding, moving, or changing some of the geometry in the arena removed the effect from the hairs. This wasn't an issue in DS 4 because the hair wasn't drawn on top of existing mesh, it was drawn in a separate window using different application elements. Having the hair accessible in the Viewport, via a tool, was a much requested feature.

    Being able to override object drawstyles using the Universal Drawstyle is, at least in part, designed to help with issues like this.

  • MontecristoMontecristo Posts: 52

    manselrex said:

    Hi, I loaded both the Alpha and the current versions of Daz Studio; the difference on startup with an empty scene is dramatic.

    Howdy - there appears to be a memory leak in the Mac version of the alpha. Totte has done some really good diagnostic work on it, I think. It appears just a few posts before yours. 

  • DoctorJellybeanDoctorJellybean Posts: 9,921

    IceCrMn said:

    I'm seeing some strange things going on with Backyard Driveway.

    https://www.daz3d.com/collective3d-movie-sets-backyard-driveway

    Heres renders using all default settings in the ALPHA, the 4.24 Public Beta, and the General Release.

    All I've done is move the perspective view slightly to show the problem with the door and the garage door

    Is this a problem with the product or the ALPHA?

    It appears that the ALPHA is shuffling the uvmaps around. I didn't look any further into it so not sure.

    In the ALPHA you can see parts of the geometry have gone wonky that aren't in the PB or the GR.

    I'm pretty sure the 4.24 PB and 4.24 GR are the same at this point. Just posting them both for the sake of completion.

    I should note the problem in the ALPHA doesn't show in texture draw mode, but it does show in iray preview and in final render. The images I posted are final render with all default settings.

     There is a problem with the content itself:

    There are 2 illegal faces - facet 6 uses 2 vertices twice each, facet 7 reuses 1 vertex twice. There are numerous instances of a vertex being shared by multiple faces, but the faces do not share an edge. These scenarios are illegal for subdivision.

    Versions of Iray before adaptive subdivision support was added likely "worked" because it wasn't actually subdividing, but newer versions are.

    You could submit this as a content bug, or set SubD Displacement Level to 0.

  • IceCrMnIceCrMn Posts: 2,332

    @Doctorjellybean Thank you

    Setting that to zero does make it render correctly.

    I'll submit a content bug later today for it.

  • memcneil70memcneil70 Posts: 5,823

    Has DAZ programmers made an update behind the scenes to DS6 to improve performance without a new version being released? I am on 6.25.2025.30407. I know this is a stupid question but I had to ask considering the problem with memory pressure on MacOS. Or did the MacOS update fix our issue?

    On my MacMini Tahoe 26.1, I had to use DS6 to test Mikey 9 and loaded him, some Iray clothing (converted to Filament), FilaToon hair and accessory and a FilaToon set and some lights/cameras and moved stuff around until I was happy and didn't see any lag. Started the render and realized that my Memory Pressure was at 18.40 GB and the CPU was at 97 to 98 %. The render completed in 8m 49s. My memory pressure is back to 15.21 GB now.

  • TotteTotte Posts: 15,017

    Depends on how much you scrolled and in your case which screen the Viewport were at. Then Filament Viewport might leak less ( I need to test that)

  • memcneil70memcneil70 Posts: 5,823
    edited November 2025

    I have DS6 opening up with the Viewport Filament initially and one time in the Aux Viewport I turned it from Texture Shader to Iray to see if I had the character properly on the stage and that the lighting was okay. I then reverted it back to Texture Shader. 

    Right now after a reboot and with the screen empty, the memory pressure for WindowServer is shifting from 970MB to 1.08GB as I type this message. DazStudio is at 933.9 MB.

    Post edited by memcneil70 on
  • zenixphoenianzenixphoenian Posts: 0

    Dr.Nope said:

    Since last update, most of the time I have to triple-click to bring up context menu in viewport.

    But thanks for fixing that undo-calamity.

    I also have the triple-click problem with the context menu. Also the "Do not show this warning again" checkbox on the warning when overwriting existing files on rendering image series appears to do nothing (I check it and it asks the question over and over again for every file in the series). 

  • jbowlerjbowler Posts: 851

    I'm using the latest DS6 and experiencing a crash trying to set the environment dome.  I suspect it is a path name length issue; I don't see a crash in DS4 however DS4 fails to set the dome, it just resets it to "None".

    This is on Windows, the path name of the directory is:

    C:\Users\jbowl\AppData\Roaming\DAZ 3D\Library\Environments\Rendered HDRIs\Steampunk Workshop HDRI\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases

    The directory contains the following three files (without the double quotes):

    "C:\Users\jbowl\AppData\Roaming\DAZ 3D\Library\Environments\Rendered HDRIs\Steampunk Workshop HDRI\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1.jpg"
    "C:\Users\jbowl\AppData\Roaming\DAZ 3D\Library\Environments\Rendered HDRIs\Steampunk Workshop HDRI\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases\Steampunk Workshop HDRI 1K test.exr"
    "C:\Users\jbowl\AppData\Roaming\DAZ 3D\Library\Environments\Rendered HDRIs\Steampunk Workshop HDRI\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0-Full-Beauty.exr"

    The first two load fine when I use the "Browse..." option.  The third invariably causes a DS6 crash and, in DS4, causes the dome to be (apparently) reset to None.  The "test" .exr file is just a copy of the one that causes the crash.  Shortening the path name of the **directory** eliminates the crash.  There are 261 characters in the last path, suggesting maybe that something maybe erroneously uses a 260 character buffer without checking the path will fit (or maybe it gets the check wrong.)

    Note that File Explorer "Copy as path" on the problem .exr file prefixes it with \\?\ which gets round the Windows 260 character limit.

    I also noticed that sometimes (I'm not sure when) the dome setting dropdown does not offer the "Browse..." option with HDR files (only) but goes into the full texture map setting dialog (which in this case covers the whole screen), from which it is necessary to select Browse. Listing all the texture maps in the scene is not very useful...

    Here's the relevant fragment from the end of the DS6 log.txt:

    2025-11-20 10:47:13.314 [WARNING] :: QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it?
2025-11-20 10:47:13.442 [WARNING] :: Failed to load image: C:\Users\jbowl\AppData\Roaming\DAZ 3D\Library\Environments\Rendered HDRIs\Steampunk Workshop HDRI\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases\Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0-Full-Beauty.exr - Operation failed
2025-11-20 10:47:13.443 [WARNING] :: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
2025-11-20 10:47:13.450 [WARNING] :: Error occurred while attempting to load image. C:/Users/jbowl/AppData/Roaming/DAZ 3D/Library/Environments/Rendered HDRIs/Steampunk Workshop HDRI/Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases/Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0-Full-Beauty.exr
2025-11-20 10:47:13.450 [WARNING] :: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
2025-11-20 10:47:13.461 [WARNING] :: Error occurred while attempting to load image. C:/Users/jbowl/AppData/Roaming/DAZ 3D/Library/Environments/Rendered HDRIs/Steampunk Workshop HDRI/Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0.1_canvases/Steampunk Workshop HDRI [Iray lights, skydome] [dome+scene] 1K RQ 0-Full-Beauty.exr
2025-11-20 10:47:14.920 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : Received update to 04522.22 iterations after 6.815 s.
2025-11-20 10:47:15.590 Iray [INFO] - IRAY:RENDER ::   1.11  IRAY   rend info : Freeing temporary rendering resources
2025-11-20 10:47:15.592 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : Received update to 05000.00 iterations after 7.485 s.
2025-11-20 10:47:15.592 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend progr: Maximum number of samples reached.
2025-11-20 10:47:15.592 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : Device statistics at rendering done:
2025-11-20 10:47:15.592 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info :    CUDA device 0 (NVIDIA GeForce RTX 4090):    5000.0 spp,   21.638 ms init,     7.374 s render,  397.211 Msps

    There doesn't seem to be anything in the DS4 log; I assume it didn't try to through an exception from an event handler, or maybe Qt4 didn't notice.  It's a kinda weird restriction, one that I wasn't aware of, though I wouldn't do that anyway.

  • o8055246o8055246 Posts: 19

    Hello!

    Unfortunately, the memory bug is still present in version 6.25.2025.32308! (Updated November 20, 2025).

    Hardware used:

    • Basic MacMini M4 (MacOS Sequoia 15.7.2)
    • Monitor LG 4K set with 2560 x 1440 resolution

    By the way, the "Memory Bug" has existed since version "Daz Studio 2025 ALPHA – Version 6.25.2025.27507! (Updated October 2, 2025)".

  • DoctorJellybeanDoctorJellybean Posts: 9,921

    o8055246 said:

    Hello!

    Unfortunately, the memory bug is still present in version 6.25.2025.32308! (Updated November 20, 2025).

    Hardware used:

    • Basic MacMini M4 (MacOS Sequoia 15.7.2)
    • Monitor LG 4K set with 2560 x 1440 resolution

    By the way, the "Memory Bug" has existed since version "Daz Studio 2025 ALPHA – Version 6.25.2025.27507! (Updated October 2, 2025)".

    It is under investigation. 

  • IceCrMnIceCrMn Posts: 2,332

    The Symmetry Script, SHIFT+Y, is working properly after the update.

    Thank you for fixing it, I use this feature alot.

  • Richard HaseltineRichard Haseltine Posts: 110,210

    IceCrMn said:

    The Symmetry Script, SHIFT+Y, is working properly after the update.

    Thank you for fixing it, I use this feature alot.

    According to the change log it wasn't actually not working, it was taking the shift as meaning Run with preferred settings and not displaying the dialogue.

  • RenderNoviceRenderNovice Posts: 62

    There has been a lot of reports of view ports not providing an image preview using various draw styles. I didn't have this issue for the first three days of using Daz2025 and then . . . right in the middle of scene creation, the Viewport simply stopped giving me IRAY previews.  All other drawstyles still seem functional in the viewport.   Actual IRAY renders remain wonderfully fast. 

    Daz 4.24 -- also installed on the same PC -- immediately provides an IRAY preview in the viewport using the exact same .duf file DAZ 2025 no longer will.    I'm using the GEFORCE RTX 5090 FE, I9 Ultra Core with tons of RAM.  Yes, NVIDIA says my Studio driver for the 5090 is still up-to-date.

    Does anyone know if a clear culprit has emerged with viewports that suddenly stop working -- particularly in providing IRAY previews?  Are there any known fixes I can attempt to restore the IRAY viewport?

  • Richard HaseltineRichard Haseltine Posts: 110,210

    RenderNovice said:

    There has been a lot of reports of view ports not providing an image preview using various draw styles. I didn't have this issue for the first three days of using Daz2025 and then . . . right in the middle of scene creation, the Viewport simply stopped giving me IRAY previews.  All other drawstyles still seem functional in the viewport.   Actual IRAY renders remain wonderfully fast. 

    Daz 4.24 -- also installed on the same PC -- immediately provides an IRAY preview in the viewport using the exact same .duf file DAZ 2025 no longer will.    I'm using the GEFORCE RTX 5090 FE, I9 Ultra Core with tons of RAM.  Yes, NVIDIA says my Studio driver for the 5090 is still up-to-date.

    Daz Studio 4.24 will have been using the CPU, not the GPU, so this does suggest a driver issue.

    Does anyone know if a clear culprit has emerged with viewports that suddenly stop working -- particularly in providing IRAY previews?  Are there any known fixes I can attempt to restore the IRAY viewport?

  • RenderNoviceRenderNovice Posts: 62

    Thanks for the reply, Richard: yep, the 4.24 previews were via the I9 Ultra CPU -- and were quicker to render than I would have guessed.  It's a workaround, albeit a clumsy one.  But still nothing so quick as the viewport I had when the 5090 card was doing it in DAZ 2025!

    I suppose an incorrect drriver can work fine for a while, and then just suddenly stop working?  ('Cause that's what I observed today -- was working fine this morning)  NVIDIA seems to offer two drivers for their cards: a game-ready driver, and a studio driver.  I've always assumed the Studio driver was the correct one to use for Daz -- advertised for creating content, more testing and stability.  (Most current release in October, 581.57)  Just to test your theory, I tried installing their most-current game-ready driver -- 581.94, released in April 25, and it makes no difference: no Iray preview image in the viewport.  Sorta tough to assess scene lighting (and other things) without it!  There sure seem to be a lot of reports on this forum of View Port problems . . .   (I get it, ALPHA version, but the dropping of support for Windows 10 is forcing us to update our machines and move us to the 50-series!) 

    Anything else I can try?

  • windli3356windli3356 Posts: 293

    How do we update our Daz Aplha public build to the latest? Mine version stuck at 6.25.050427 for awhile now.  

  • DoctorJellybeanDoctorJellybean Posts: 9,921

    windli3356 said:

    How do we update our Daz Aplha public build to the latest? Mine version stuck at 6.25.050427 for awhile now.  

    It should appear as an update in DIM. 

  • Richard HaseltineRichard Haseltine Posts: 110,210

    RenderNovice said:

    Thanks for the reply, Richard: yep, the 4.24 previews were via the I9 Ultra CPU -- and were quicker to render than I would have guessed.  It's a workaround, albeit a clumsy one.  But still nothing so quick as the viewport I had when the 5090 card was doing it in DAZ 2025!

    I suppose an incorrect drriver can work fine for a while, and then just suddenly stop working?  ('Cause that's what I observed today -- was working fine this morning)  NVIDIA seems to offer two drivers for their cards: a game-ready driver, and a studio driver.  I've always assumed the Studio driver was the correct one to use for Daz -- advertised for creating content, more testing and stability.  (Most current release in October, 581.57)  Just to test your theory, I tried installing their most-current game-ready driver -- 581.94, released in April 25, and it makes no difference: no Iray preview image in the viewport.  Sorta tough to assess scene lighting (and other things) without it!  There sure seem to be a lot of reports on this forum of View Port problems . . .   (I get it, ALPHA version, but the dropping of support for Windows 10 is forcing us to update our machines and move us to the 50-series!) 

    Anything else I can try?

    Try a clean reinstall of the driver, or roll back to a slightly older driver and do a clean install of that. If all else fails try DDU to take the driver off and then reinstall from scratch. Windows can do weird things to GPU drivers - I lost the Sleep function after upgrading for the last Iray update (wghile using an older driver that Windows 11 had grabbed when it was installed) and then had a string of crashes, DDU may have helped a bit but I am still having issues with some driver somewhere).

  • johndoe_36eb90b0johndoe_36eb90b0 Posts: 263

    @Richard

    People using DDU and uninstalling drivers in general in Windows 10 and 11 are making a big mistake. I used to do that all the time back in Windows 7 and 8.1 but Windows 10 and 11 are different beasts.

    Namely, Windows 10 and 11 come with NVIDIA (Intel, AMD) display drivers and the OS updates them through Windows Update.

    If you want to install official driver from OEM (say NVIDIA) YOU DO NOT UNINSTALL WINDOWS DRIVER -- you just install it over existing one (and don't check Clean Install either).

    That way the OS knows not to touch the driver anymore.

    But if you uninstall or do clean install then Windows will fight you and try to install its own driver back (and in most cases succeed sooner or later leading to things being broken as you usually don't even realize the driver has been rolled back).

Sign In or Register to comment.