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
Just a further note on this crash. It DOES occur on 4.22.1.150 on MacOS 14.5 on Apple Silicon but does NOT occur on 4.22.1.150 in MacOS 10.15.7 on Intel. Might help in pinpointing the issue.
My processor on Windows 10 is Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
A USC2 render that I did in 4.22 full version and then opened in the new 4.22 Beta and saved now doesn't open in 4.22 full version or 4.21 full version. It throws up the following error.
DAZStudio.exe caused ACCESS_VIOLATION in module "D:\Program Files\DAZ 3D\DAZStudio4\dzcore.dll" at 0033:00000000F1E20509, DzBrickParam::clearTokens()+9 byte(s)
Other old renders work fine in all versions only this one shuts down with that error.
What ecology? What terrain preset or classic feature?
I don't think it is USC2 that is the problem I think it has something to do with the extra settings that have been added to the Environment tab on the new Beta.
Tried a USC1 scene that I made a while ago. Loaded into the new beta and made a couple of adjustments using the new items under Environment, saved it and loaded it into 4.22 full version and it crashed with the same error message so it is something to do with the new 4.22 beta.
When opening a scene that has a surface texture file with a % in its name, DS 4.22.1.150 cannot find the texture file. It appears to me that the problem is introduced when the scene is saved. This is what is in the saved scene file for the material:
I think the DS released version 4.22.0.16 has the same problem. I have used this texture file in scenes many times in the past without a problem. I don't have a DS version older than 4.22.0.16 to test. The texture file works fine in the scene when the scene is created. It is when that scene is reopened that the error message occurs. I suppose it is possible that in the past I just rendered the scenes using the texture, and never tried to open the scene again.
I would suspect those paths have been an issue for a long the the paths starting with // - though the % sign should be escaped (% is the code marker for characters that are not valid in URIs, e.g. %20 for a space).
I don't completely understand. Are you saying that the % in the texture file name should be handled by DS when saving a file, but it is not done correctly? Should it be saved as %25?
Edit: Yes, I edited the scene file and replaced the strange character sequence with %25 and fixed the png extension. Now the scene works correctly.
"url" : "/Runtime/Textures/barbult/UltraScatter%20Distribution%20Maps/Gray%2050%25.png",
There were two places in the scene file that I had to correct. The second place was in the Materials section.
I think the save should probably be escaping (using % folowed by the code, as in your edits) when it saves.
I won't say it is a bug, but it certainly looks as if it could be. I wasn't aware that % was an allowed character for filenames, but we know that non-standard but allowable characters if file and folder names can cause issues - which is why this area of the code has received some work.
% was probably not my best choice. But I do expect Daz Studio to be able to correctly save a scene with image files that it accepts when creating that scene. Right now, when it identifies the file as missing when reopening the scene, it won't even let me locate the "missing" file, because the name is corrupted. I still hope the developers choose to update the code to "escape" characters like % when saving a scene. It is already done for the space character. It's disturbing to save a scene and not be able to reopen it accurately later.
I tried to install the most recent beta and It acted like it installed, but I couldn't find it in program manager (Win11), so I checked DIM and it showed as downloaded but not installed. I tried to install it again (asked for the normal permissions) and it still wouldn't "install". So I thought maybe the download was corrupt and I deleted the installer (using dim), but now DIM doesn't show it in the list of available downloads??
I do have a folder for the Beta in the normal location (C:\Program Files\DAZ 3D\DAZStudio4 Public Build), but if I try to run the exe file, I get a window stating that "DAZ Studio has encountered a fatal error, and must close". Apparently the installation partially completed and failed, But the installer didn't clean up after itself. I thought renaming the installation folder might force DIM to see that the Beta wasn't installed, and give me the option to download it again. No luck, and all traces of the beta are gone in the download folder (DIM did one thing right, It deleted the install package, but it doesn't know that it need to re-download the beta installer).
Does anyone have any suggestions to force DIM to re-download the installer, or a way to download the beta manually?
There is no other way to download DS PB version but via DIM only. First of all, you have to make sure that the application of DS PB is fully closed (check it in Task Manager), then in DIM, delete the package in Ready to Install tab. Go to Ready to Download tab, make sure Public Build channel is checked in Download Filters, then Refresh... see if the installation package is pushed to you or not...
As for file names, be aware that zip doesn't support unicode, so for daz assets in general the PAs should only use ansii characters, being them distibuted via zip. There's also the case sensitive difference between windows and mac, so using always the lower case in file names is safer. Cerainly % is not a safe character in a filename and PAs doing that are looking for troubles.
The beta was definitely closed when I tried the install/upgrade. I hadn't opened studio in several days. I've tried closing and reopening DIM (many times), rebooting the computer (several times), removing the beta (Public Build) folder in programs, and even tried putting an old copy of the beta (and manifest) back into my DIM install folder. DIM still doesn't give me the option to download the new version, or recognize the existing (corrupt?) installed version. Of course Windows 11 add/remove programs utility doesn't show the beta as being installed (but it doesn't show the production version either). Oh, it definitely isn't a permissions issue either.
I guess it's time to contact support, but my guess is I'll have less luck with them than with the helpful folks here.
I frequently use % in file names particular for HDRIs rendered from DAZ - the file name includes the % convergence. So, e.g. "rendered scene 80%.exr" would be when I gave up rendering a 16k spherical camera view of the scene to use as the background :-)
Pretty much any character except "/" and NUL is valid. Windows has this misleading thing to say:
In fact everything on that list except "/" is valid on Unix, and therefore Apple, systems.
It isn't the OS that matters, it's the URI syntax
No: zip files are irrelevant here (the discussion was about an XML file) and here is a .zip which refutes your assertion:
So far as I am aware .zip files support "/" too and maybe NUL (though that might trigger bugs in the decoder). The problem is that .zip file interpretation is dependent on the OS so the first file in that .zip,
dir/\\:*?"<>does not show up if the file is opened by Windows Explorer even though it extracts just fine under Linux. The third file (a Chinese name) works just fine on both.You observed that %25 works just fine, but I wasn't responding to that; you said in the same post:
My point is that any character is valid. Qt uses UTF-8 consistently for byte encoding these days. URI encoding allows any byte value so far as I know; consider %2F (used in URIs to disambiguate from the syntactic use of "/"). Both allow any Unicode sequence and that's necessary in this context because we don't all speak ASCII. English has characters outside ASCII and, somewhat ironically given what ASCII stands for, so does American.
Yep, the handling of file names outside the content library (and maybe inside) is broken on Windows; I mount network partitions in my file space and Daz is currently expanding a path that traverses the mount point to include the full UNC of the mount. This isn't just wrong (it includes the prefix too) it's plain broken - I used a mount point (reparse point) deliberately so I can move things around, Daz breaks that and, after it has done it, it can't even find the file itself!
zip has supported unicode filenames for nearly twenty years now, however DS and DIM use the minizip library for zip file support and that library does NOT support unicode filenames. The files are extracted (or inserted when using DzScript) as a bytestream using the current system codepage on Windows. There are several DIM packages distributed by DAZ using the non ascii portion of the Windows-1252 codepage to get characters such as "é". I suspect these packages may not extract correctly on OS X or on Windows if your OS language is set to something other than English.
Four months ago I submitted a feature request to switch libraries to something that supports unicode, so maybe it will show up in the changelogs some day.
May be unix but not windows. Both the windows zip and 7zip don't support unicode names. In 7zip there's an option to force a specific locale for the command line, that's quite awkward to use in power shell anyway. Try any japanese zipped file in a english locale it won't work, you either need to change the locale or force by command line. This is a known issue never fixed by windows nor 7zip.
https://superuser.com/questions/554108/extracting-a-zip-file-with-japanese-characters-in-the-archive-s-filenames
p.s. As better explained below, this is a issue specific to windows, because it doesn't save as unicode if we only use the locale character set. At least up to windows 10, can't test 11 but I doubt they fixed it.
If you save as chinese from a english locale, it will save as unicode and will be readable as you say. But if you save as chinese from a chinese locale it will save as non-unicode and will not work.
Great to hear that you are improving the search feature!
One issue have found when it comes to transparencies such as eye moisture and cornea and tears while using the toon option is they just come up as white. So far the only way to fix it is to set the cutout opacity to 0. Hopefully when the next version goes live they have something sorted. Also found that using HDRI's even with Parris's IBL product does not work either just get a white background. So won't know how to do backgorunds with skylines in it.
I cannot get this new update installed, opened or running. It removed what I had before, and now, I don't have anything - I don't know what to do. I've tried reinstalling it, twice. Now, I don't have anything on my desk. And can't get the install to open from the DIM that shows that little boxed arrow that is to open the program. Nothing is happening.
Any warnings or errors? Have you checked the DIMHelper log? What are your system details?
I have had this happen intermittently, including with the release version. I believe something glitches during the install after it removes the previous version, but DIM thinks it has been sucessfully installed..
In DIM, Search on your installed content for 'beta', and uninstall anything related to the DS beta, noting what you uninstalled. Then reinstall the DS beta and those packages and it should be there.
If it isn't there, after uninstalling, remove or rename the install directory under c:/Program Files (presuming you are using Windows). I believe you need to do this as an Adminstrator.
If I have a character with a geoshells in my scene and I Edit>Duplicate>Duplicate Node Hierarchies, the character and geoshells are duplicated, but the geoshell surface materials are not applied to the duplicate geoshells. For example, some LowPi clothing is created with geoshells instead of unique geometry. When I apply that geoshell clothing to LowPi and duplicate node hierarchies, all of the duplicate's clothing is a blank shell. If I put "real" geometry clothing on LowPi and duplicate node hierarchies, the duplicate clothing surfaces are properly textured. Why are duplicated geoshells not properly textured? I understand that the geoshell is not unique geometry, but the shell is duplicated and named appropriately and has the right shader. So why aren't the shell's surface materials also copied?