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
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
The Evergreen thread gives the current state (and gets updates to older posts, not just additions) while the change logs tell you what has changed (though I at least do find the new version numbering harder to track, which can make it tricky to spot the joins between releases).
Here's the crash report fom my latest crash
I thought that was the case, but it seemed possible that the mention of shortcuts applied rather than being "I had a similar issue with shortcuts" so I wnated to be clear.
BlenderのIKはうまくできてますんでそこを学習してみては。
Blender's IK is well-designed, so why not try learning that?
これPoserでできてるのになぜDazでできないんですか？
Why can't I do this in Daz when it works in Poser?
ぶっちゃけ言ってIKシステムの中身見て何が違うか勉強しなおしたほうがいいかと。
Honestly, I think you should take a look inside the IK system and study up on what makes it different.
I was thinking about why the last few versions of DAZ Studio (D|S) no longer sees the audio files for import. From my limited programming experience, I figured that when the program calls for an "open file" dialog box it needs to be passed a list of parameters of the types of files it's looking for. It would follow that – for whaterver possilbe reason – the developers have kept the "open file" dialog box but neglected to keep the parameter list for file types to accept.
To test it, I re-installed the latest version to confirm. Here's what the Audio…/… load dialog box looks like in the latest couple of versions of D|S:
No options of file types to import.
And here's what it looks like in the old versions of D|S that still work:
So, it looks to me like they might just need to add the parameters? Any comments, or am I totally off the mark?
Crash if load "wearable" without load on character on last build.
(Screenshot failed to upload)
Just a bit.
Daz Studio 6.x uses FFmpeg for the multimedia backend. Nothing in regard to FFmpeg or the audio importer has changed since 6.25.2025.18515
Populating the supported formats in the import dialog comes from querying FFmpeg for a list of the formats it supports on the machine it is installed on. FFmpeg's support for standard uncompressed WAV format does not require any external dependencies - the necessary libraries for handling uncompressed PCM audio, the most common type found in WAV files, are part of the FFmpeg core and are included in any standard build.
What has changed recently are a number of dependent libraries (25.2025.25407, 6.25.2025.26707), and distribution footprints (which files are included), but that should have had no impact on FFmpeg's response when queried for the list of supported formats omitting WAV.
I don't want to throw a hand grenade, but I was wondering if there was a roadmap to when we could expect the Alpha to be progressed to Beta or even release? I've got a very script heavy workflow, and I know I can use Daz 4 for that, and then just render in Alpha, but it would be nice to be able to upgrade my GPU and do it all in one place.
There's no roadmap that we know of. Daz rarely gives ETA on new versions and features.
Thanks for the info; I know it worked in 6.25.2025.22607 (August 14, 2025) and stopped working in 6.25.2025.23807 (August 26, 2025), hopefully they'll be able to see what change was made between versions that broke audio import and fix it in the near future.
I need a sort of confimartion: Someone tried exporting and reimporting an animation in BVH format for the DAZ Dog 8? When I try the BHV file seems to work fine on the BVH Viewer but when I import it to the model the animation is broken.
anyone else noticing higher CPU temps when doing preview renders?
The scene I'm playing with now in 4.24 peaks my CPU at 53C and only for a few seconds before settling in around 48C-50C
My CPU idle temps are between 26C-34C
In the ALPHA it peaks around 76C and settles down to around 71C-73C.
tjMAX on this CPU is 95C so my CPU cooler is handling it fine
I think a 20C increase is alot.
Might not be, but looks like alot to me.
That's a shame, but not a surprise, sadly.
My CPU is a Threadripper 3990x.
On my side, when loading a scene in Alpha, CPU temperature jumps from 45 to 72C (at this peak for 1~2 seconds...), but when previewing, just jumps to 61C ~ 62C.
When doing so in 4.24, almost the same ~
If this is new it is possibly rlated to the new Iray version, so it might be worth checking reports on that http://docs.daz3d.com/doku.php/public/software/dazstudio/6/change_log#6_25_2025_27306
I still have a problem with turning off the 'Display in Viewport' in Daz 2025.
When I do that the light does not emit light in my scene (it used to emit in 4.x)
I like a lot of lights to light up small little areas in my scene. But without the ability to 'Display in Viewport'->Off, they clutter up my scene and I can't see to manipulate objects well.
Is there anyway to change the display of the 'white lines' to be invisible ?
Like add a material to the light and then set transparency to zero ?
Yes, I have the same issue. I am interested to hear that I am not the only one unhappy with the change. I believe the developers are aware of it. I don't think it has been determined whether it is a bug in DS6, or a correction to an error in DS4, or something else. We'll have to wait for the developers to investigate it.
@TromNek and @barbult
I tried testing the toggle option for "Visible in Viewport" and it appears to be working on my end as intended. It being invisible in the viewport while still emitting the spotlight.
oooh, I see what you two are saying now. Yeah, I experience the same bug where the scene is also dark if the "Preview Lights" are on. I normally work with the "Preview Lights" off so this isn't something I noticed. I can confirm with TromNek that it does work normally in Daz Studios 4.24 (and I assume older versions.)
If it helps, I also think that the spotlights can be visually distracting with the ray lines. What I ended up doing is changing the display to work similarly to how Blender displays their spotlights.
You can adjust the values in the [Display] > [Scene View] tabs of a selected spotlight
Ray Length: 2.50
Opacity Scale: 100%
Ray Opacity: 0.0%
Show Base: Off
Base Opacity: 15%
Show Edge: On
Edge Opacity: 5.0%
I would like to report some of my experience so far with 6.25.2025.27507.
Scene Tab Fixed
As the changelog states:
"Fixed a regression in sorting options on the “Scene” pane"
Thank you devs for fixing this.
Spotlight View is Dark
The viewport is dark when in spotlight view while having the "Preview Lights" option toggled off.
I must note that "Perspective View" and any camera view makes it work as intended by showing the scene in it's "light" view if the "Preview Lights" are off. My suggestion is to apply any of the coding that was done for the Perspective and camera view and apply those to the spotlight view.
Spotlight View Does Not Show Wireframe Drawstyles
Another minor bug I noticed with the spotlights view is how it reacts when in different viewport drawstyles. I mainly noticed it does not display any objects when it is in any of the 3 wireframe drawstyles. (Wireframe, Lit Wireframe, and Hidden Line). It does show up in the drawstyle, Wire Shaded, which I think it works because it works similarly to the drawstyle “Texture Shaded”.
Viewport Multiple Views = Lag
This issue has been present since the early ALPHA builds.
I think the main issue fallbacks to on what I previously mentioned, that there is currently no option to disable Anti-Aliasing in the preferences settings. I think this would dramatically improve viewport responsiveness if the devs are able to implement this in the ALPHA build.
Last thing, I did notice a bug with the Joint Editor Tool in the Tool Settings tab not showing surfaces in the previous builds. I will do some more thorough testings with this build to see if the bug I experienced is still present in this current build.
It is not a bug in 6.x, it is a correction to a bug (unintentional) in 4.x
What 4.x did would be a feature request (making it intentional) for a "Display Avatar" property that could be used to toggle display of a node's avatar - to align it with the Drawing > Draw Avatars property in the Draw Settings pane for the Filament DrawStyle, and the Drawing > Draw Node Avatars property in the Draw Settings pane for the NVIDIA Iray DrawStyles). So explaining that reveals an inconsistency in the labeling of the Draw Avatars vs Draw Node Avatars properties - the Filament DrawStyle property needs to be relabeled to Draw Node Avatars to be consistent.
Hey, I don't know if any of you have the same issue, or know how to fix it.
Most of the stuff works fine for me in the Alpha, however one particular error I have is:
If using the translate tool in any direction - and the characters moves out of the viewport, the gizmo/translate tool disapears. If I click on the Character again, it comes back - however, if I use it, the viewport cam jumps around, multiple objects in the outliner are selected randomly and it just "undoes" a few steps, sometimes the entire scene is broken after that. I cannot CTRL-Z this. This is a repeateable error and sometimes causes a lot of trouble.
The avatar is the little camera or light mesh that appears in the scene view. You are wanting to be able to hide that, but keep the effect (in this case the light coming from the camera), which is also part of the node drawing, visible.
Here's another crash report
I had 3 characters in a fresh scene and had just loaded an atv vehicle and was attempting to move it when Studio crashed
Seems my crashes are happening when I try to move things.
Doesn't seem to be isolated to the gizmo or the translation sliders.
I've had it crash using either
The optimisation in http://docs.daz3d.com/doku.php/public/software/dazstudio/6/change_log#6_25_2025_18307 is to interaction with a tool in the active Viewport, using a property slider or looking at an inactive view is not optimised. I can see that it would be desirable for these areas to benefit, but it does depend on how the current round of optimisations is implemented - I would suspect that an attempt at a general speed-up in Viewport updates, that would work on any number of visible viewports, might have a negative impact on the actual active viewport as a lot of other stuff has potentially to be accounted for, so speeding up the active viewport/tool combo may well be the most (or even only) effective use of resources.
Thanks, that's helpfull. I may start doing that.
I have had some success by changing the 'Scale' of the light down to 1%.
But, I like to group lights in a hierachy (sometimes many levels) so I can move/rotate them together. And the scaling of things higher up in the hierachy affects the position of ones below it.
Maybe I'll stop using groups in a hierachy so I can scale lights down and they don't clutter up my view.
Dr. Jellybean's reply to me talks about Filament and Iray Preview, neither of which I am using. I am using Texture Shaded. His reply talks about Draw Settings pane labeling discrepancies. I don't understand how any of that applies to the problem of the Texture Shaded viewport going black when the selected camera's visibility is off.
Richard, thank you, now I understand that a "node avatar" refers to the little line drawing representation of that node in the viewport. For example, a camera's location in the viewport is represented by a little drawing of a camera. You can see that camera's node avatar in the viewport when you are viewing the scene from a different camera.
But Richard, I am not wanting to keep light coming from a camera. The headlamp is the only light I know that comes from a camera. Even if headlamp is on, it doesn't illuminate the scene when the camera visibility is off. I am wanting a camera whose visibility is OFF to be able to see the scene. I am using Texture Shaded draw style in the viewport. I want the viewport to have the same appearance when viewed through the camera, regardless of whether that camera has its visibility On or Off. I cannot work in a viewport that is all black. I can't imagine a scenario where that is an advantageous implementation of camera visibility. I'm not trying to be argumentative. I'm trying to clarify what I see as a DS6 problem and understand how that could be the intended implementation. There must be something I don't understand yet, maybe related to the statement about "light coming from a camera".
The reason I noticed this problem in DS6, is that BJ Camera Manager plugin (which I use in DS4) sets camera visibility fo OFF by default for any new camera it creates. The explanation for this is that it reduces viewport clutter. If you have a scene with 10 cameras, when you view your scene through one camera, or perspective view, having 9 or 10 camera node avatars cluttering the viewport makes it more difficult to see the elements you are trying to work with. This works fine in DS4. When the camera visibility is Off, the Texture Shaded view is still visible and toggling Preview Lights works as expected. Now, when I open that saved scene in DS6, the viewport is suddenly black and I can't see my characters, or environment, or props, or anything. Toggling Preview Lights does nothing. It took a long time to figure out that this had to do with CAMERA visibility.
Although I understand what a node avatar is now, I still don't understand what that has to do with the selected camera not being able to see what is in the scene. Why would camera's node avatar visibility affect what that same camera can see? I never expect to see the selected camera's node avatar in the viewport, because I am viewing the scene through that camera (My "eye" is behind that camera, looking through its viewfinder.)
Sorry, soemone was talking about the issue with invisible lights not casting light earlier and I go them confused. But it is the same thing, you want to hide the avatar (so you don't see the camera mesh) but keep the node active (so you can see through the camera). It is logically consistent for hiding the node to stop both behaviours but this isn't what DS 4 did, hence the apparent bug in its not behaving as expected now.
Doctor Jellybean is saying you can hide the avatar but not the node in those DrawStyles, though the Filament label needs to be changed to make it clear what it is doing (to avoid this kind of confusion), and what you are doing is making a feature request to have the same option for the OpenGL preview in some way.