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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Although the progress bar itself has been reconfigured, see http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#4_22_1_107 , the logic of when it is shown is not different. Certainly I just tried General reelase adn Public Build and they both showed the progress bar as expected, though it was a diffrent shape in the Public Build. due to the adjustments mention in the change log.
I've seen no difference so far... What was the issue of "rotated" that you mentioned, like the one in the attached Ss?
Yes
No change on my side... still rotated when auto-fitting.
I know that behaviors of DzMessageBox was extended / updated since 4.22.1.118 but now a line of code : MessageBox.information("Would you like to save changes to the current scene before closing it?", "Save Changes","&Yes","&No","&Cancel"), in latest PB, turns into what is shown in the attached Ss1, i.e. Cancel button is set as the first one.
I had to change the order of buttons into: "&No","&Cancel","&Yes"...(in Ss2), as well as the value of options... but this logic seems not really correct, does it ?
The few hairs I tested load in rotated like that, but when I Accept the autofit dialog, the jump into place. I noticed that if I save the scene and reload it, the hair is out of place (not rotated), just too high usually. Here are a few screenshots I took, In the case of Speakeasy, I show before I click the Accept button and after. See how it jump into place?
This is/was a work in progress - these issues are fixed in a later build than we currently have. This is all part of laying the groundwork for Qt 6, as I understand it.
Yep, that was what I got, the very same results. So, most likely nothing has been improved in terms of this hair auto-fitting case... ?
Thanks Richard ! For the time being, I have to use two different scripts for GR and PB... ho~
Window->Workspace->Delete Layout(s) does not work for me. After I check several layout checkboxss and click Accept, they do not go away. They are still there to be selected or deleted again, even after closing DS and reopening it. I have the same problem in 4.21.0.5 General Release.
I just tried the function with DS PB and GR, it worked on my side. Layouts as well as the layout files in %appdata%\DAZ 3D\... folders were both deleted.
Thanks for the feedback. I don't know why it doesn't work for me. I don't see any error messages or clues in the log file.
You hadn't applied write protect to the folder for some reason?
No, and the only way I can get rid of those old workspace layouts is to go to that folder and manually delete them, along with their corresponding actions, menus, and toolbars. Some of them were very old, dating back to 2015. I manually deleted all dated before 2019, and after doing that, the DS interface correctly shows them gone from the layout selection and deletion dialogs, but still won't let be delete any remaining ones.
In fact, I had so many layouts that the deletion dialog originally wouldn't show them all. It wouldn't scroll, and wouldn't even show the Apply or Accept buttons. I had to manually delete some to even be able to see the whole list of remaining layouts, with finally enough blank space to show the buttons at the bottom.
Oh, I suddenly recalled that I'd ever experienced the similar issue long time ago ! How did you name the layout ? I used to name them as something like 2024.04.25, however, from a certain version, the layouts with this sort of name (with dot character in b/t numbers) could not be deleted ! Then only 2024-04-25 or 20240425 worked...
Pls check if you have the same case or not...
Oh, yes, many of my layout names have a dot character in them. Like, for example, this old one "2022-02-07 4.16.1.43 Beta".
I can still load those layouts, but can't delete them.
Yeah, that is the culprit ! They can be loaded but cannot be deleted. So, anyway, pls just manually delete them from those folders... if you don't need them.
Thank you for your insight! I would not have figured that out.
You're welcome !
Now in PB, when exporting objects to OBJ file, there're 6 digits after the decimal point in Scale field... What's the purpose of it ? and it cannot be change to 100% like the one in DS General Release...
Curious what this means for the new Filament DrawStyle:
Reduced Filament DrawStyle required feature level to 1
DAZ Studio : Incremented build number to 4.22.1.120
Does that mean Filament is no longer on the fasttrack to getting a revamp/fix/enhancements? It seems dev on it has dropped off somewhat in subsequent builds.
Has anyone used the new Filament shader (if it is useable yet)?
Filament is still under development.
The required level had been bumped up while they were working on stuff, they have now been able to optimise that work so that it no longer reqires such a high feature level. I suppose it is possible that it may go up and down again as they continue to work on the feature, for the same reason.
It isn't an intended change, but it is the consequence of an intended change - going from the original QLineEdit (with an adjacent QLabel that held the '%' symbol) to a QDoubleSpinBox. When the QDoubleSpinBox has limits, as it needs to for a percentage setting, it displays all decimal places.
I decided to attack this problem by using Bulk Rename Utility to change all the dots to underscores. Now I can delete layouts from the interface again
I hope this issue gets fixed in the DS code.Why would a developer intentionally use differect character filters for saving and deleting the same thing? I think it must be an error.
OK, thanks! I'll wait and see the right one's back...
Yep, I also think it's a bug...
As I undrstand it the change of cotrnol was a deliberate decision and this is a consequnce. It is not going to change in DS 4, I have no idea whether the later versions of Qt will alow it to be changed in the next major version.
Well, it doesn't impact any functionality but looks strange... as normally we don't need to input any decimal there when exporting to OBJ....