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
It also fixes the curious problem of Death's Missing Clothes; I only, yesterday, tried Death in a Scene and he/she/it did not have any Smart Content. Along with 4.22.0.9 we also got an Upgrade To Death. One or other of the Upgrades have, in fact, restored the Smart Content; not just Panties but even Skin! Curiously I observed the same problem with G9 Base + Death's skin (alone, applied from the Content Library).
Despite the amusement value it might, in fact, have been a mis-feature of G9 Base; it might be that something broke the smart content of G9 Base itself rather than Death.
After updating the new beta (from 2 betas before), I'm noticing a drastic increase in TCB bug, erratically calculating NaN limb values, causing me to wait HOURS on a high-end machine to sort itself out to show character on the viewport again. I've already opened a request years ago, recently even sent a broken duf to reproduce it. Now it is even more alarming for animations, I have to save even more, since some workspaces requires dforce animations to remain saved which can take up to minutes. I really wish animators were given some love. And let's not jump to the "this is a posing application" bandwagon. I am positive that daz studio is way past that waypoint long ago.
Another problem:
I don't know when or why this happened, some of my feet morphs (fan down, individual fingers up/down, toes spread sliders) suddenly inverted. I.E: moving towards positive spread now compresses fingers intead of spreading them. I looked for what I might broke myself, but I am also not sure if it is after updating latest beta. Anyone else noticed or have this? Or a solution?
Luckily, it happens only when you copy-paste the keyframes into the inner timeline, if you copy-paste them in KeyMate the keyframes will be fully working.
Yes, this was the original bug. But as of now, I noticed changing character limbs caused previous limb tcb keys to go NaN, unfortunately. Happened twice in two days.
So it's even worse than before. I didn't notice this because I'm still on version 4.12.0.86
Send a report and hope for a quick fix.
Exactly, what triggers the bug? Perhaps there's a workaround for that. Have you tried the "old trick" of selecting the keyframes, setting a different tweener and setting back the original one?
I'm working on my toes with the latest studio. However, you made me remember to use keymate again. I gave it up long ago for a certain reason, which I don't remember anymore.I think it made studio crash if you filter something and then delete it from the scene while the filter was active. I could never be careful enough, so it always made me loose work.Gonna give it a shot again.
Yes, it actually happened with a linear keyframe T. I had a change at T+2 (only affected limb values are tcb) and another tcb keyframe at T+4. At T+14, I was making an adjustment with pose master, finished it. Then, I wanted to look how it translated in the timeline. I mistakenly clicked at T+3 instead of T+4. Character suddenly disappeared from the view, went for a drink, come back after ~30min. Character was back. Changed all to linear and back to tcb again. Sigh...
The scary story here is that now the bug was actually triggered while posing, without any copy-paste keyframe mumbo-jumbo.
The only chnage to the TCB fields in this build is the relabelling, as far as the numeric fields go theya re unchanged. Any difference between release and public builds is presumably down to settings.
There is a bug with the TCB fields - they do not update when a key is selected in the graph, only when it is selected in the dope sheet. That is not the intent and will be addressed.
I ran across an oddity while testing a scene I had originally created in 4.21. It appears that something has changed about ground fog between 4.21.0.5 and 4.22.0.7. The scene I had created in 4.21 used a sun-sky Render Setting based on one from the UltrasceneryXT-Materials and Skies set, and it works fine in 4.21. When I tried to use the same scene in 4.22, it was almost completely dark. After some testing, I found that the problem appears to be the field Ground Fog Decay Height. These settings have a default of 75000, which works in 4.21. But in 4.22, it appears that this value is handled differently and needs to be a lot lower. Just an FYI ...
transitioning into Iray in preview or pbr is more latent than I think I've ever seen it. Transitioning out of Iray into texture or wireframe makes the app unresponsive.
An example?
I'm still getting the filtering bug, when I filter something in the graph pane I see a totally different parameter instead of the one I selected.
I am getting a crash on this scene here:
As I am now the proud, or should I say poorer, owner of a PNY GeForce RTX 4070 and want to test some old DAZ Studio scenes I had CPU rendered in the past but am instead getting DAZ Studio crash dumps on thids scene, and more, but not all of my old DAZ Studio scenes (3 scene crashers so far)!
I have not tested opening those DAZ Studio crashing scenes with DAZ Studio 4.22.0.1 RELEASE but I think they probably would crash DAZ Studio as well.
I am disappointed as I wanted to test the speed of my video card on old scenes I had done that are somewhat complex.
And why is the DAZ Gallery so extremely slow? Is it under constant DDoS attack always or something? Why not contract a service to stop those attacks? e.g., I sometimes get a connection intercepted by "cloudflare" asking me to check a box while it procedes to "check that the connection is secure" before it sends the requested URL to me. That only happens while I am using a VPN service offered commercially of course. hmmmm....
Out Of Touch hair? makes sure there are no maps assigned to Transmitted Colour in any of the materials
Apologies if this has been addressed; I went through numerous previous pages of this thread and didn't see any references to it, and also searched the forums in general. I would think it should have been an immediate question ... or it's a config thing I haven't run into before.
When I have a scene open and click "Save," instead of ... saving the current scene, something drilled into you when you work with computers ("save your work often!") ... it pops a window showing the files in the current folder and apparently expects me to create a new file every time I click "Save." This is bizarre behavior. In fact, I'm just saving my work on the current scene, which I do umpteen times while working on a given scene. The prospect of having to reselect the curent scene and click through the warning ("The target file already exists. Would you like to replace it?") every time I simply want to save the scene I'm currently working on is terrifying. It's 100% guaranteed that I will eventually overwrite something I didn't mean to select.
I'm hoping that this is just a weird config setting I need to change in this recently installed beta instance (4.22.0.7, installed a few days ago).
Are you perhaps clicking "Save As" instead of "Save"? Or perhaps you have loaded a scene subset?
Have you set an Author name in Edit>Preferences (Daz Studio>Preferences for a Mac)? Save works only if the scene's author matches the current author, otherwise it functions as save as - to avoid overwriting asset filesby accident
I always forget about that possibility.
The spectral conversion color space is still broken in 42.0.9; REC 709 produces reasonable colors, all the other choices (including XYZ!) give, well, 50 shades of black. Not that I'm criticising of course, it's a good black because:
The weird thing here is that if I take a scene with real-world lighting (it's actually Crypta Sepultus with the luminosity of the candles corrected and exposed with an EV (100ASA) of -1) I can, in fact, get a variety of, well, "interesting" renders, with colors (other than black), but only if I set the tonemapping EV to 13 (nonsense in a scene lit by 13 candles).
It looks like the spectral rendering is doing half the job; transforming colors into a spectral space but then somehow failing to transform them back, or vice versa.
Forget that, it's a really dumb option to put into a UI. The converstion space MUST BE RECT 709/sRGB because all the data (the colors, the bitmaps, everything) has to be encoded in that space.
I still don't understand that. I do understand that all the DAZ data is sRGB, so "REC 709" (which, from the Iray documentation, is sRGB) is a requirement. What I don't understand is why simply turning on "Spectral Rendering" without changing anything from the defaults whacks the tonemapping EV from -2 to 15 (in my scene); about 1E5x!
There is only one OOT hair, the Ryan hair. The other is AprillYSH. All the church stuff from Merlin's church bundle has a lot of stained glass windows and was converted via DAZ Studio's preset to convert 3DL to iRay materials but that was done way back on the original render.
I guess I will edit DAZ Studio Preference settings to use CPU only so I can open the scene and check the maps for the Transmitted Colour maps for assigned materials At least I hope I can reopen the scene but doing that. Maybe I have to rebuild the scene all together from scratch.
Yikes - you are right. Something has drastically changed. The UltraScenery XT ground shader doesn't even seem to work the same way, even with all fog OFF. Do you see this same difference in ground shaders? Edit: USC ground shader is fine in 4.22.0.9. I had the wrong version of some products installed. My Bad! Ground Fog is still wrong, though.
Here is a comparison between the same saved scene file with Ground Fog Off and Matte Fog Off, rendered in 4.21.0.5 General Release and 4.22.0.9 Public Build.
4.21.0.5
4.22.0.9
Here is a comparison between the same saved scene file with Ground Fog On and Matte Fog Off, rendered in 4.21.0.5 General Release and 4.22.0.9 Public Build.
4.21.0.5
4.22.0.9
Settings for the scene:
Yep, spectral rendering is broken in 4.22.09 I like to render in acescg and convert all textures to acescg colour spectrum. In previous versions of studio worked just fine. Now i 4.22.09 the textures in every scene look like dirty dishwater. I also agree that the lighting is all off as well
It should (should as in "probably doesn't") work to embed ICC color profiles in the maps which are out of the sRGB gamut. There's not a lot of point converting sRGB data to a wider gamut; the XYZ values in the result are still within the original gamut and all the values will remain in that gamut unless there is an out-of-gamut light source; i.e. a light with a profile which produces spectral data which can generate out-of-sRGB-gamut values. My test case had none of this; everything was inside the sRGB gamut and the "convertion intent" (natural; faithful is a dubious choice at any time) and the observer (1964; a somewhat broader population sample) should not make any easily observable difference to the output.
I think it may be down to some Iray change in the interpretation of the input data; it isn't immediately obvious how the DS engineers could have changed the interpretation of EV in that way. There's history here; back in the days "tonemapping" had to be turned off to render to a canvas. If it was on the canvas got the tonemapped result. This was fixed and, with the fix, the tonemap EV value started to control the render convergence even on the canvas (so you have to set EV correctly if rendering to a canvas even if you turn tonemapping off.) It's the same kind of confusion; DS splits single concepts into two and makes them independent at which point AHBL.
There's a new Public Build that I think has a new Iray version, but I don't see a highlights description of it yet, so I'm just trying to interpret the change log.
Edit: No, no new Iray version in 4.22.0.10, in spite of the change log implying that it was merged to 4.22.0.10. Only some (not Iray) changes were merged, based on later information.
a new Iray ver. in 4.22.10 ?
This is what I saw in the change log:
But the change log description now posted for 4.22.0.10 doesn't say anything about an Iray change, so maybe that means that only part of 4.22.1.29 (excluding Iray) was merged to 4.22.0.10.The documentation appears to be inconsistent, to me.
Not sure... if it's said to have been merged, it might've been merged...