Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
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.