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
anyone else noticing that after changing any parameters while Iray preview is enabled the Iray preview stops rendering until you go back to a different preview method and go back to Iray again?
No, I haven't experienced that.
Yes; I think this may be new but I can't be sure. It seems that changing anything which is not visible (directly) in the viewport does not result in a re-render (i.e. flipping back to 'smooth shaded' then drawing with Iray). I was messing around eliminating objects not directly visible in the viewport today and I noticed that when I made something "not visible" (i.e. the global "not visible" which disables everything) the viewport did not re-render. I'm not sure it's a helpful optimization.
In fact I did eliminate an object which was obscuring a light source and I *believe* I didn't get a re-render but I might be wrong; for sure the annoying shadow disappeared in the real Iray render.
I simply get downgraded to shaded view each time I change a parameter. have to switch to shaded, back to iray and it renders fine. Latest Nvidia drivers, latest public build. For me it's definitely new, never had this issue on previous beta builds.
That's the expected behaviour. It's not "downgraded"; if you look in the viewport view-type dropdown it will still be set to Iray. That's the initial state before the first iteration has been obtained from Iray but after the geometry has been set up. Sometimes it can take a long time to get the first iteration sometimes it might never happen if the video card runs out of oomph. I won't speculate on precisely when the state in the video card is reset and precisely how much, doing so is against the forum rules, however it is worth your while lookinig for errors in the log file and running a separate GPU monitor program. You may find that some other app has sucked up all the video resources.
The bug I detected is worse than I thought. Last night I decluttered the same scene some more by removing more "out-of-view" furnishings; the Iray preview did not change but some of the furnishings I removed were visible! When I rendered the newly !visible furnishings were missing. When I swapped between outline-box and Iray modes the ghost stuff did disappear. I rarely use Iray preview for decluttering; it's normally easier in CPU (texture) mode as I can set the ceiling to not show for interior scenes (this doesn't work in an Iray preview). Consequently this may be old behaviour that I've only just encountered.
DS 4.22.1.123, NV GRTX4090 with Studio 552.22 of 4/16/2024 (the latest Studio)
You didn't get what I meant. It renders. You change a morph parameter during Iray preview, it no longer updates renders. EVER. You can wait 1 hour, it won't update. If you switch back to shaded/texture and back to Iray, it renders back in under 1 second. I also have a 4090, if that makes you feel any better.
Edit: Instead of updating renders, you simply revert to shaded preview, and if you move the camera around it updates Iray for a few miliseconds then reverts back to shaded. Only way out is to manually move to texture/shaded and back to iray
I tried opening a ticket about this in January 2023, but it has never received any response or reply, despite my following up on it every few months.
After being loaded into a scene and rendered in Iray, some shaders reproducably experience noticably different results based on which frame of the timeline Daz Studio is rendering. These shaders only appear to work correctly if loaded as part of the initial scene load. Put differently, load a scene with Jada 8.1 in it, and it's fine. But add Jada 8.1 into a scene, and this bug occurs until the scene is saved and reloaded.
This is an extremely tedious problem, as my standard practice is to build my scenes on Frame 30 (as this gives me space on the timeline if I need to later set up a dForce timeline, without any hassle with moving around frames), and the workaround can take several minutes to save and reload a scene before I can correctly render or preview it.
So far, the shaders I have noticed this most prominently with are PBRSkin (most obvious on dark skins) and UltraScenery's custom shader, but they're affected so differently that I do wonder whether it's a universal problem that instead affects less commonly used or less noticeable parameters on other shaders.
On PBRSkin, Jada 8.1's skin for example gets - for lack of a better word - "Flatter" as the timeline progresses:
Frame 0:
Frame 15:
Frame 30:
UltraScenery's custom "UltraScenery Terrain (MDL)" shader instead experiences problems with its tiling:
My ticket for this was originally on DS 4.21.0.5 (although I'm certain I noticed it earlier), but I can report that it is still completely replicable for me in the latest Beta, and I've since confirmed that other people are witnessing the exact same on their systems (note that if you're checking it in Iray Preview, you may need to come out of Iray Preview and back in to see the change happen), so I'm posting it here in the hope that someone finally spots the report and moves it up the stack for fixing.
I've not been able to reproduce my issue on a basic project, however I can't seem to figure out what the issue could be. Could it be related to Squishy Humans product? My scene is empty besides one character with Squishy armatures.
The UltraScenery tiling problem on frames other than 0 is something I have seen, too. I posted about it a long time ago, but I can't find that message now. I think HowieFarkes said he didn't know what caused that to happen. He uses custom terrain shaders, so I don't know if that has any impact or not.
Customer support for technical problems is no longer very useful. I've experienced delays of many months with absolutely no response at all, just like you have. Richard Haseltine has posted that adding comments to the help request can further delay it my pushing it back to the end of the queue. So, you might be better off just leaving the help request as it is. I've also had the repeated issue of some of my help requests being closed and marked "Solved", without any resolution to the problem at all, just because they get old. It infuriates me that Daz can calls this customer support.
Some observations about the UltraScenery tiling problem:
I have also opened a ticket regarding the timeline texture issue when i had it happen to me, i haven't had a response.
@Matt_Castle I can reproduce your problem with the PBRSkin shader in the timeline on frames other than frame 0. These attached renders are what I see: I think the reason we see the shader rendered correctly after saving and reopening the scene, is that the character added in a later frame, now appears to have been moved to frame 0. See the screenshots I attached. It would be nice the get an explanation of what is going on and whether this is considered a bug by the Daz developer team.
Jada 8.1 added in frame 0 and rendered (looks correct)
Jada 8.1 added 9 in frame 2 and rendered ( looks wrong, no specularity/gloss)
Timeline when Jada 8.1 was added in frame 2. Her keyframe appears in frame 2.
When the scene is saved and reloaded, Jada 8.1's keyframe appears in frame 0.
Do you have any tools that can animate materials via nodes active, e.g. https://www.daz3d.com/pbr-skin-plus or https://www.daz3d.com/1-click-pbrskin ? In order for surface/material properties to animate they needto be linked to a node property
Butting in here, I have https://www.daz3d.com/1-click-pbrskin installed. I don't understand whether you (Richard) are saying that having something like that installed is a necessary thing or a problematic thing.
Okay, that's interesting.
Testing it, if I load Jada while the playhead is on Frame 0, the bug does not occur. If I load her while on Frame 30, the bug does occur. So I can actually end up with a bugged and a non-bugged version simultaneously in the same scene depending on what frame I was on when I loaded the figure. However, further experimentation with dragging either figure's keyframes around has no effect to either fix or cause the issue.
That's at least a slightly less ugly workaround (go to frame zero to load the models), but I still want to be able to effectively work on Frame 30 (and have that set in my default scene) so that I have the space available to do dForce timeline simulations. (DS is extremely sluggish about moving around keyframes - the tests I did above with moving the keyframes took a few minutes of the program locking out each time).
Not as far as I am aware.
Certainly, neither of those products was available at the time I rendered these examples. (I have reused renders from my original bug report in Jan 2023, but I have confirmed I am still experiencing the bug in both the main release and public beta releases).
1) I don't understand how the subdivision is supposed to work when it is selected in the Create New Primitive dialog. If I create a 1 M cube with 1 division and select Catmark subdivision, the cube is created with subdivision, but behaves completely different than if I create the cube without subdivision and apply subdivision later. When cubes' mesh resolution parameters are set to identical values in the Parameters pane, the shape of the cubes are entirely different.
2) Why are the subdivision choices in the Create New Primitive dialog different than the choices in the Parameters pane? In the dialog, Catmull-Clark (Legacy) is missing.
When creating a primitive that has an edge (i.e., Cube, Cylinder, Cone, Plane), choosing a “Subdivision” value other than “None” now also results in subdivision edge weights and interpolation/smoothing settings being set
The edge weighting is intended to keep the edges somewhat sharp, you can use the Geometry Editor to select edges on the cube created without SubD and increase the Subdivision Weight to get the same result (or remove weight from the cube created with SubD to get the soft edges).
Thank you. Richard. That is something I knew nothing about (subdivision edge weight). Your explanation was perfect. I can now understand what the change log was saying, and why the two cubes look different with no difference in the Parameters pane settings for Mesh Resolution.
So, I made this strange thing from the new primitive cube with subD and modified edge weights and per side surfaces.
I couldn't install the latest beta via DIM. It uninstalled the previous version, but it shows as -1 Bytes in the installed file list in DIM, and on restarting DIM it shows as not installed. Repeating the installation, and redownloading the file gave the same result. I ended up renaming the 'c:/program files/DAZStudio4 Public Build' directory and it did install.
I have seen others with similar issues. The inability to install without manually deleting the folder does suggest permission issues, or security software being hyper-sensitive.
I hadn't ever changed anything in that folder, and I'm not using any third-party security software on that machine; just Windows Defender.
I had also updated the release version of Studio, and DIM uninstalled it but did not reinstall. I "uninstalled" it and reinstalled it via DIM and it did sucessfully install...
.136 does fix the failure to render in Iray preview when objects are removed from the scene (by setting the 'visibility' parameter). Unfortunately this is fairly obvious because now when an object (in view or out-of-view) is removed the preview redraws three or four times.
The other reported problem, failure of the Iray part of the render so that the preview is left with just the smooth shaded portion, probably isn't changed; in my case it is certainly associated with a SEGV on OOM inside NVidia's code and is permanent until the Studio instance in which it occurs is shut down in a controlled fashion. The most obvious symptom I see beyond the log and the failure to do the Iray part of the render is that a large amount of memory remains allocated in the GPU. This memory is only released right at the end of the DS shutdown, but it is released (just) before the process actually exits.
I'm having a weird billboard issue in the beta. For some reason the billboard looks lower quality and there is a strange redness in her mouth when compared with the stable verison. I used the exact same settings and had no issues although I was using older versions of both installations. So I went ahead and updated both my stable and beta daz installs and my video drivers but it's still happening.
You're right. That's because of a new rendering param. in Render Setting of Public Build. I found it from another case but I just tesed with billboard props, I got the same problematic result as you had.
You just go to Render Settings pane, Optimization, set Off or Medium in Texture Compression property.
With higher texture compression in PB version, that famous "redish" issue will come, so that's why your saw red teeth.
Thank you! That was driving me insane.
*
Some custom shaders used in products purchased in the Daz Store are causing DS 4.22.1.150 to crash. The crash does not occur in the released DS 4.22.0.16. The situation is strange, because props with the shaders load OK and render OK, but when the scene is cleared up, Daz Studio crashes.
Two examples of shaders that trigger this crash problem are in the Tropical Botanica - Understorey product. The shaders are "PB Mossy River Rock shader (MDL)" and "PB Mossy River Log shader (MDL)". Sample props in the product that use those shaders are USCT Stone 01 and USCT Fallen Wood 01.
To reproduce this problem, just load either of those two props into a new scene and then close Daz Studio. CRASH. I have attached a crash log. I am running DS 4.22.1.150 on Windows 10. This problem is 100% repeatable.