Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
That isn't a key, it is a top-level marker indicating that there are keys on some or all properties at that time. Yes, those are unselectable in this build but not in DS 4, Daz is aware of the issue.
This message is a general comment on the Daz software, whatever the version. But I'm taking advantage of the arrival of the new version to give some feedback on what could, in my humble opinion, make it run more smoothly:
The first point is that a new, empty scene is created as soon as the application is opened. And when we open an existing scene from a file, and open the application in the process, an empty scene is systematically created and we're asked if we want to save it...
The natural answer is "no", but before opening the existing scene, closing the empty scene takes an unnecessarily long time.
Would it be possible for the application not to create an empty scene on opening, with, why not, a launcher of recent scenes instead?
Another behavior that exasperates me is the fact that, in certain selection windows (for example, to select a constraint object), we have to select the element, then click on “OK”. It would be quicker to double-click on the element to select it, as you can only select one.
Actually, a new scene is only created when the application is opened with the Iray viewport active. That creates an Environment Options Node and a Tonemapper Options Node, which constitutes a new scene. I think when it Loads a File on Launch, it also constitutes a new scene.
Filament active will do that too. Adding a default camera would do the same, I think. But yes, I do not get the prompt for a truly empty scene.
I forgot about Filament.
Creating a Default Camera on New doesn't, not when I tried anyway.
Thank you for the explanation. I have noticed that the actual keyframes are selectable and only these markers are not. But that is still a debilitating issue as selecting multiple keyframes is a very convenient feature. Is there a work around to this issue that would quickly select multiple key frames like the markers do? Or is there a way to downgrade to a previous version of the alpha where the markers are working?
Thanks crosswind, I never used shaping tab until now and shaping tab may be very useful in some cases.
Characters has CTRL-*, FBM-* and FHM-* morphs with property cards but from now FHM morphs can't be switched into big size (vertical slider with big image) inside Shaping tab because it is a separate item outside the Actor section.
There are other morphs with his own property cards but only Actor can visualize the big thumbnails... all other items has only horizontal sliders with little icon like Parameters tab.
I don't know what we will see in new studio releases but for sure big icons sliders is the power of this Shaping tab, may all items in the tab will have his own ?
No, but Daz is aware of the issue so with luck (unless it is meant to be that way) it will be fixed fairly soon - though for now all I can suggest is watching the change log.
Sorry, but how could be that way? Otherwise, how I'm supposed to select, move and change the keyframes in my animations? It's unthinkable make us select every single subkey in the timeline...
Anyway, since you have the timeline under exam, please also fix the "double click grab" scrubbing in the timeline. I mean, in my 4.12 installation I can grab and scrub the cursor on the timeline with a single click ( like all other animation softwares I have ) but in the latest releases I have to click once to bring the scrubber on that spot and then click again to grab it and move it around. It's truly a workflow breaker.
It should be: Click once and scrub it around.
If someone asked for something like that (I can't imagine why, though) please make that behaviour switchable.
I was hedging my bets, since I don't know why it chnaged, not hinting that it was a deliberate choice.
There are no redraws so far as I can remember; DS just hangs. (Which I do consider a bug because I don't think, as a Qt programmer, that such things should happen in the UI loop but that is irrelevant to your point :-) I've not seen redraws but certainly increasing the View SubD number (which I do when dForcing) does make a single redisplay go mighty slow and increasing mesh smoothing iterations (reported as a famous PA thing previously) is strangely prone to delaying redraw time. I expect that; if I ask for something that takes a long time I'm not worried that it does. (I'm just annoyed that I had to ask for it in the first place!)
Hi guys, has anyone found a way to automate batch rendering in Daz 2025?
Currently the only option is the Premier exclusive tool, though a script might already be doable.
Are there any roadmaps that are public for the ALPHA build? What are the important features the devs are focusing on currently before the year ends? Do we have an ETA on the general release date? As I understand currently, premier seems to be the one of the top priority since those are the subscription features. I'm not experienced in scripting, but I assume this is one of the important features also being worked on because the scripting doesn't appear to be finalized yet.
I assume there will be a BETA version after the ALPHA finalizes the foundation for Daz Studio 2025. And after the BETA irons out most of the bugs, a stable release will come shortly?
Would any of the improvements be able to be updated to Daz Studio 4.24? Particularly, can the fast texture loading that is present in the ALPHA build be updated for Daz Studio 4.24? Or is it not possible due to the limitation of the old QT 4 tech? I read that loading for Daz Studio 4.24 depends entirely on single threaded CPU. Does the ALPHA build now have access to multi-threading CPU? That would explain why textures and custom shaders load far quicker in the ALPHA build compared to Daz Studio 4.24. It would be nice to have confirmation.
Besides these bigger questions I have, I wanted to focus on a particular issue for the ALPHA build. Users have mentioned that there is viewport lag when working on the ALPHA build. From my experience, the lag is workable. It isn't as responsive as 4.24 yet, but the ALPHA build has room for improvement. I did 1 testing with one large environmental scene with 10 figures:
My suggestion for a responsive viewport is to disable "Hardware Anti-Aliasing" for the ALPHA build. There isn't an option for this in the Preferences > Interface > Viewport setting. In Daz Studio 4.24, Hardware Anti-Aliasing was listed under OpenGL. I assume ALPHA is using a newer version of OpenGL?
I'm highly looking forward to the general release of Daz Studio 2025. The improvements to the program are very well needed. Daz Studios version 4 based on QT 4 is still capable, but seeing how fast Daz Studios 2025 based on QT 6 can be is very exciting. There were mentions of Vulkan in the Daz forums, but I am not too familiar with all that? Maybe Daz can implement that engine as well just like Blender implemented that in one of their recent builds. The viewport does look nice and clean if it is based on a newer version of OpenGL.
Forgive me if I'm a bit "jumpy" about this but it's not the first time I see animation tools getting heavily bugged.
Here are some of my experiences with ALPHA build version 6.25.2025.23807
1. Scene tab sorting is broken
In the Scene tab, the sorting does not work. Sorting by ascending or descending does not do anything as well.
2. Windowed panes "tabs" label not showing on first time as a windowed
One minor issue I experienced is when loading a new pane or dragging one from a grouped pane makes the tab lose its "tab". Closing it and reloading it from "Window > Panes (Tabs)" loads the windowed pane with its tab correctly. (Note: I have my tabs oriented on top.)
3a. Saving layout with windowed panes crashing.
Saving my layout crashes the ALPHA build. Previously, I thought this was due to me copying over the layout folders from Daz 4.24.0.3, but it crashed on the ALPHA build on a fresh installation of the program.
3b. Saving layout does not save a preview screenshot image.
This is a minor issue, but Daz usually saves a preview screenshot image when saving a layout. No image is saved in this current ALPHA build.
I'd like to ask, will props, clothing, environments, landscapes, hair, poses and animations already existing in the Shop be converted to versions that would work only in 6.25?
Also, will older Genesis figures no longer be included in future DAZ Studio versions?
One random bug I've had here and there:
Sometimes suddenly when trying to use autofit, Daz complains "Daz3d has to be registered for auto-fit to function". And autofitting stops working. Only restarting seems to fix it.
And if i look into "about installed plugins" all these built in "free" plugins have their registration fields visible and empty.
This usually happens when I've run daz for quite long time but have no idea what could trigger it.
No roadmap, feature list or ETA has been published so far, and based on Daz past behaviour I don't expect them to be published at all. We might get an announcement of some new features or of the coming version a few weeks in advance if we're lucky, or more likely we'll simply come to the store one day and see a big "new version released today" banner.
There will certainly be one or several public beta versions, and maybe a release candidate, before a general release is published.
I've seen posts mentioning that there was little chances any new features or improvements would be added to the 4.x line anymore. There will at least be one version published with 3DL removed (since the licensing agreement for 3DL is ending) but that's likely the last one.
That's very unlikely, there are way too many products sold here for them to want to update and retest them all (leaving alone the fact that PA items would need to be updated by the PA). They didn't update all products to duf format when they introduced it, and even for those they updated they usually kept a "legacy" install version with the old files.
So far there's been nothing announced that would suggest that they'd be removed.
Most of the content you can use in 4.x can be used in 6.x. The exception are some file formats, plugins, etc. More info in the evergreen thread. Plugins by 3rd party developers will need to be updated by the creators, as well as scripts where applicable as some do work as is.
Not deliberate, possibly an unintended consequence of using a proxy model to enable http://docs.daz3d.com/doku.php/public/software/dazstudio/6/change_log#6_25_2025_22707 (which is the filtering I asked about earlier).
The entirely single threaded claims are just that - claims. DS has long/always had multi-threaded eleemnts are mre are/will be added where desirable. However, the fact remains that not every process benefits from multi-threading (at all, or possibly because in most likely scenarios the overhead of managing multiple threads would more than outweight the benefits of dividing the task).
Yes it is (although I haven't tested this with the latest alpha). Here's a script which simulates a list of frames and renders each, one by one. It's slightly obscure because it uses the "Render Settings/General" "Render Image File name" and that must have "%1" in it somewhere; this gets replaced by the frame number (it's Qt syntax...) It shows some apparent bugs in the handle of renderer.getRenderOptions; it returns a pointer (or reference) to the current options, not a copy, so direct assignment does completely counter-intuitive things given a renderer with set/get methods; get/set should always be by value!
Anyway, despite the wackiness required to set the render options it shows a currently working (in the alpha version quoted) way of setting up a render on, messing with the render options and rendering it. It should be obviously how to extend this to loading a series of scenes as well. It's easy to read the name of the scenes and the frames (remember to include %1 in the name!
// DAZ Studio version 6.25.2025.19807 filetype DAZ Script
(function(){
var simulator = App.getSimulationMgr().getActiveSimulationEngine();
var timePerFrame = Scene.getTimeStep();
//var ticksPerFrame = timePerFrame.valueOf();
var renderer = App.getRenderMgr();
var opts = renderer.getRenderOptions();
var ofn = opts.renderImgFilename;
var savedOpts = DzRenderOptions();
savedOpts.copyFrom(opts);
opts.renderImgToId = opts.DirectToFile;
// simulate the given frame in the current scene then render it
function process(frame, width){
Scene.setTime(frame * timePerFrame);
simulator.simulate();
opts.renderImgFilename = ofn.arg(("0000"+frame).right(width));
print(opts.renderImgFilename);
renderer.doRender(opts);
}
var range = Scene.getPlayRange();
var first = range.start / timePerFrame;
var last = range.end / timePerFrame;
var width = (""+last).length;
if (false) {
for (var i=first; i<=last; ++i) {
process(i, width);
}
} else {
var frameList = [ 0, 3, 6, 12, 13, 21, 24, 31 ];
frameList = [ 2, 4, 10, 15, 17, 18, 19, 20, 23, 26, 30 ];
frameList = [ 1, 8, 11, 14, 16, 22, 25, 27, 28, 29 ];
frameList = [ 8, 14, 22 ];
for (var i of frameList) {
process(i, width);
}
}
// remove the simulation data:
simulator.clearSimulation();
// restore the original file name:
opts.copyFrom(savedOpts);
})();
My apologies for the formatting of the code in the previous comment. It displayed fine when I entered it but then not in the posted comment. I editted about a bazzilion times trying different HTML but no luck, so here it is as an attached file.
Yes, it's a DSA, but be very aware that it will overwrite whatever is in the render settings for the output file name; see my %1 comments above. Caveat Emptor, you have been warned and this script has no brakes.
I am having an issue and I am not 100% sure if it is due to Daz 2025 Alpha or my GPU/drivers but when I try to run a dForce simulation I keep getting the error.
2025-09-08 17:21:49.142 [WARNING] :: \src\pluginsource\DzDynamics\dzopenclkernelfactory.cpp(32): Open CL notify: Unknown error executing clFlush on NVIDIA GeForce RTX 5070 (Device 0).
Does anybody know if this has to do with the Alpha or my GPU?
What is the version of your GPU drivers?
And there are other bugs that are relevant; I didn't roll back to the prior drop so I ended up testing what **can** be done and, indeed, a single property can be selected if it is in the timeline. But not by marquee selection; that has gone too. I requires a click. Fortunately ctrl-click to add to the selection still works but the result of the change is still obviously and self evidently unintended.
For example copy'n'paste a complete pose to a different frame is no longer possible, so a pirouette is no longer possible on the time line because this requires pasting the same pose into multiple frames; think about it.
The eyeball bug is still there ("constrains/point at" to the camera), maybe slightly less but still there.
The selection (marquee and otherwise) on the last frame of the current timeline was fixed but now has been replaced by no ability to select anything.
The inability to manipulate items on the time line where they are invisible was partially fixed by the "Refresh" option in DS4 but still isn't happening automatically.
The selection of an entry on the timeline and the selection of the corresponding item in the scene are semi-independent; selection on the timeline switches the scene selection but not vice versa, IRC; it's just plain confusing.
<DEL> does not delete the selected key; try it and see (not on a scene you are working on, please.)
So far that hasn't happened; I swap back to DS4 to work round bugs in the alpha. The idea of doing what you suggest is not something that most software programmers understand; it's the idea of working with a file produced in a **newer** version of the app in an **older** version of the app (you undersand that, just stating it for the progs). S/W programmers understand "backward compatibility"; an old file works in the new version, but not what I term "forward compatibility". It is really difficult and some "new" stuff may get lost if editted in the older version. Nevertheless that's what Microsoft does, or did; traditionally older versions of Microsoft Office were able to load (for sure) and edit (to some extent) Microsoft Office documents produced in newer versions. I'm not aware of any other commercial software manufacturer that managed to do that.
You will never ever get an official answer to that question. Will you be where you live now in 100 years time? So far as I can determine (and I've tested only G8) all older figures load and save from the alpha. On the other hand I haven't tried loading files that are even a year old. This is backward compatibility. It seems to me that a lot of older **products** are being removed but Cookie is still there. As someone who has done this for a living I have to say I wouldn't do that. I'd leave the FOSS community to convert Cookie to an open format and laugh at the amount of money I made as a result.
Oops, cancelled.
Yeah. Don't believe anything you read on the innernet. Of course loading the file is a sequential operation; there is no point trying to multithread it. Other file formats maybe not, but Tati were fooled by XML and went for a file format that by definition cannot be multi-threaded. I'm not claiming to be better, just saying that is what the world wide water closet achieved.
I suspect @richard's marketing point:
Fails to point out that the whole premise is bogus: yep, the whole stupid file has to be loaded byte-by-byte. Thats's a PITA if it is big and on disk (e.g. if the scene file contains dForce simulation data) but the gradual fixes from and during DS4 seem to have delayed loading of the ancillary data beyond that required to render the scene.
So, yes, this is still a valid criticism, but you got it off the internet and I'm sure no one wants to hear me criticising the internet so I'll stick to you.