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
duplicate.
I am very happy for you onix! Events are developing rapidly in the 3D world now.
My issue may be resolved now with RTX video card (Onix has a GTX). Was never Nvidia driver related for my issue.
Issue was dropping to CPU during viewport render when changing textures with Illegal Memory Access indcated in log.
Complicated to explain.
On DS startup had a default scene load that included a default camera and an X-Ray HDRI Camera with an HDRI preloaded.
This was causing the issue.
The X-Ray HDRI camera works fine, so long as I load it AFTER adding something to an empty scene.
Was using the X-Ray HDRI camera steady in 4.12.0.86, so never thought of it as an issue. And had not updated my base Public install for a long time so it was still using "none" in edit>preferences for startup scene.
So adding the X-ray HDRI camera after never triggered the issue.
This saved default scene used to work. Something changed. Easy to fix anywhoo, now that know what this issue was.
Hopefully this fix did it. Would be nice.
PS. For those of you who don't know about and have bad thoughts about the name "X-Ray HDRI camera", it's actually not what you think. Let's you see your HDRI light "inside" of buildings without walls blocking the rays of light.
Dear Saxa--SD! You completely tortured old Dazy! Be lenient towards her while she gradually turns from a slow caterpillar into a beautiful fast butterfly!
But you really got me interested in the topic of X-Ray HDRI camera.
I like to experiment with HDRI in 3D graphics programs.
Let me get that clear, please ... you can use HDRI to light the inside of a room without hiding the walls?
By the way, I think we need to clarify that there appear to be two 4.12 issues with falling back to CPU - I suspect they are related though. One is the fall back when rendering an image series - pretty easy to reproduce as it happens for me with just a single base G8F animation, no props clothing or other objects - it just reverts to CPU when starting to render the second frame. The other issue is when, in the same scene, I experiment with lighting or shaders - i.e. changing them. After a few changes, (not adding extra) it falls back to CPU either in IRay preview or a test render. Fix by closing DAZ Studio and start again.
Just for the sake of completeness, as already reported I can't reproduce the issue. It seems everything works fine in my system for 4.12.0.86. Specs in the signature and discussion link below.
https://www.daz3d.com/forums/discussion/comment/5031676/#Comment_5031676
LOL. Nice for for humor & play after all that serious troubleshooting. Think I got more bruises than Dazy. But there have been some lovely butterfly moments.
That X-Ray HDRI camera (or more exactly the planes it includes) are the cat's meow. Have fun!
Yup yup. Really the big thing is the series of planes that are included with it as child nodes. I often use other more pro cameras with the planes. Like all things there is a downside. Mirror reflections are often showing the HDRI and not the wall behind. Need to play with that. Imporatnt Hint: Sometimes you need to Toggle the child planes so parts of scene can be visualized again. Honestly surprised this is not talked about considering some big advanatges with this.
Stress tortured my Dazy versions yesterday. 4.12.1.16 still has fall to CPU moments. Takes a while to trigger tho. Whereas with 4.12.0.86 it rarely if ever happens. Can go all day and it's fine. Though do have 64GB Ram and it makes all the diff (vs 32).
Came to a similar conclusion there are multiple issues. Maybe even more maybe? Like adding on top of that GTX users vs RTX with that Optix setting change.
What I mean by that is I just took 10 minutes and tested an animation render of image series @1440p with 4.12.1.16 on my RTX and I stopped it at 3 renders cos, they were all staying fine on GPU. So makes me guess it might me that Optix change that has come up several times. Is not affectuing me. Have other issue it seems with 4.12.1.6.
Oso Blendy Crashes Beta 4.12.1 - without fail. Every time there is something in the scene that has the Oso Blendy surface settings it will crash immediately if you try to render the scene or even if you try and use the Iray preview mode. I have two products I've developed that use the Oso Blendy shader, but since updating to the latest Beta I've not been able to finish working on the products because it crashes Daz Studio without fail every time there is something in the scene that has the Oso Blendy Shader and I try to either render the scene or if I try to switch to Iray Preview mode.
Two products of mine are nearly finished that rely heavily on the Oso Blendy shader, so I'm not able to finish them or submit them until this gets looked into. I hope this is an issue that can be fixed.
Did you report it as I can confirm this?
I submitted a ticket a couple weeks ago, and I'm still going through a back-and-forth. They said they couldn't reproduce the problem, so I had to send them one of my files. Thing is, I create a lot of my own content, and alter a lot of 3rd party content, so I'm waiting for the next response to come back blaming the content.
Thing is it might be the figures, or it might be files saved in either 0.85 or 0.86. I loaded a set saved prior to either release with no figures loaded and there was no problem with the timeline. Loading the same set saved with either .85 or .86 with figures added creates the problem.
Have you tried this with the non-Daz plug-ins disabled - you can use http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/plugins/plugins_load_config/start to switch them all off, restart DS, and test. If it works with all of the non-Daz plug-ins disabled try, one-by-one, turning them on in Help>About Installed plug-ins, restarting DS, and seeing if the issue has returned.
Not sure this is the right place for this, is so please correct me.
I recently (maybe a week ago?) updated the Daz Studio Public BETA release I was running from whatever beta release I had previously, that one would have been over a month ago maybe? I update my BETA copy pretty frequently, so if 4.12.1.16 is your semantic version number, then the previous build I had would have likely been 4.12.1.15.
Anyway, I noticed two issues pop up in 4.12.1.16 that had been resolved in the previous beta release:
I'd go back to using the previous general release, but I really love the fix that drastically shortened wait times when re-parenting or grouping complex hierarchies. Is there an easy way to downgrade to the previous public BETA release?
Happy to send along any log files if that helps.
I put in a support ticket about it but haven't gotten a response yet.
There is a long thread about the multiple instances ...
https://www.daz3d.com/forums/discussion/359146/4-12-1-16-no-longer-allows-multiple-instances-of-studio
They will be reinstated ... in a later version.
Downgrading to earlier versions - only if you saved the installers somewhere else than your DIM downloads folder.
IF you did that, you can uninstall the current version, copy those older zips into the DIM folder and install that version.
The previous beta was 4.12.0.85. The current released version is 4.12.0.86. If you were fine with the previous beta, you could go ahead and install the current release.
But before you install another version of either the beta or the release, it is a very good idea to back up the installer files, in case you want to go back. Daz does not provide previous release versions as a rule.
The issue also occurs with Oso Master Shader 1.
I've put in a support ticket regarding this.
I tried out .16 and it seems fine, but I can't manage without the multiple instances, so reverted to an earlier version.
@anyone
Yes, I backed up; i do lots and often. If 'you' don't, why not?
I have a directory devoted to this very thing, also, people should not also forget about backing up 1rst party plugins as well such as goz!
The problem isn't with the content. They couldn't get the file off Google Drive, so I had to create some smaller scenes that would fit on an email attachment. I used two preloaded sets from a couple of ironman13's products, advanced the timeline to frame #1 and moved a random chair. One scene was created in DS 4.12.0.85, and another in 0.86. Both were saved then opened in 4.12.1.16 and in both instances DS froze when trying to bring up the timeline. From what I can tell 1.16 has a problem with scenes saved on older versions that have keys set across multiple frames. The problem might be with the keys themselves, or it might be because I reduce the range to frame #1 (not frames 0-1). Whatever it is, I'm convinced the problem isn't with any specific content.
Hence the suggestion of disabling plug-ins and seeing if the issue remains. Of course this assumes you have one or more plug-ins other than the Daz ones.
FYIDaz Studio 4.12. Running nVidia 431.86 Studio Driver on GTX1080 was giving me fall back to CPU as others have reported. This was after only 3 or 4 itterations of changing texture & re-rendering, even when using less than 50% of GPU memory!
Just loaded NVIDIA Studio driver 441.12 and seems much better, tried several times with no fallback so far. Hopefully this has cured the problem since it really was annoying. Can't say for higher cards, but suggest its worth trying anyway. Good Luck.
I have a GTX1080, and was just wondering if anyone had tried the latest driver. Thanks for reporting. I may just have to update my driver, now.
Got an email today that they were finally able to recreate the problem. Hopefully they'll figure it out and fix the timeline in time for the next update.
Yeah that's screwed up as spectral rendering increases the realism making it much more accurate for realism, when disabled, it defeats the purpose of using iray as a solution for real-world lighting! I have spectral rendering enabled by default so I hope they fix this ASAP!
I'm curious as to what they tampered with to screw up spectral rendering to begin with? <=My guess is that NVidia did most of the tampering though, as I see no reason why Daz would even mess around with the rendering engine!
FWIW, I did update to the 441.12 today, and when I closed DS after several viewport renders, GPU-Z reported the memory dropped to about 138MB almost immediately, and Daz Studio was nowhere to be found in Task Manager. Previously, memory had been staying at about 2GB and in the Task Manager, Daz Studio moved from the Apps to Background processes on the Processes tab. At whatever point DS finally closed, the memory use reported by GPU-Z would then drop to the 100+ MB range.
I'm not doing animations, so I can't say if this driver makes any difference in rendering image sequences. I'm also using a GTX 1080, which may make a difference.
My initial impression is upgrading to the 441.12 drivers was a good move.
So, because I trust you completely, I also updated my Drivers this morning to 441.12 and you seem to be right again, they do seem better. First I tried a simple scene - one G8F animated through 5 frames. No CPU fall-back. Good - that would have gone to CPU on the second frame with previous drivers. Next a more complex scene. I watched what was happening in GPU-Z and saw something interesting. Frame one rendered fine - GPU-Z reported the VRAM usage at 5.3GB. On to frame 2 and suddenly the VRAM jumped to 6GB and then that figure was consistent for the remaining frames. So there is still a VRAM usage jump after the first frame but that scene was still small enough to fit within the 8GB on my 1070. However, previously, the second frame would have dropped to CPU no matter how much VRAM was still available. So it is an improvement although I don't like that jump after frame one.
Also, I have an idea that IRay is designed to use as much VRAM as possible. I say this because I've noticed that a scene reporting 6GB with two G8 figures only increased by a couple of hundred MB after adding a third. I would have expected a proportional increase after adding the third figure. Maybe it shares some of the common textures or geometry? I don't know but I've seen this on various occasions.
On a good card there are about 2gb for the working buffers alone (including optix), then there are the frame buffer and the denoiser buffer that grow with the rendering resolution. Then there are geometry and textures. On a small card iray will try to allocate smaller buffers to work.
On a side note in my tests it seems that cycles allocates about 1g vram less than iray. Since cycles is tile based probably needs smaller working buffers, and it uses less vram for the frame buffer and the denoiser. Not to mention out of core capabilities of course.