Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Report possible bugs to Daz, they will check them, aggregate them, and report to nVidia if/when required.
Iray is sent only the final mesh, not the rigging or shaping data on top of the base mesh (it wouldn't knoww hat to do with that anyway). Remember that, unless you have lowered the SubD level, Genesis # has a higher final mesh resolution than Victoria 4 (Victoria 4 is roughtly the same as Render division level 1), and of course the newer materials tend to have more, possibly higher-rsolution, maps and more complex materials.
On the issue with the 960 and the 2070, what driver version are you using? "REQUIRES NVIDIA Driver 441.22 (or newer) on Windows for pre-Turing GPUs, 442.19 (or newer) on Windows for Turing GPUs;" - that is, the 2070 (Turing) cared needs a newer driver than the 960s (pre-Turing).
SUCCESS!
I finally figured it out -- With Mac's Catalina, there is something called SIP - System Integrity Protection. You can disable it by booting up into Recovery Mode, opening Terminal and entering: csrutil disable then restarting. I was then able to install the public build and open my old .duf files. To enable SIP again - boot into Recovery and in Terminal type: csrutil enable... etc.
From my experience there are two kinds of CPU fallback. One (you could call it a "soft fallback") is when the GPU doesn't have enough VRAM to hold all the data necessary to render on the GPU, so it gives up the ghost and forces iray to send everything back to the CPU. The other fallback (a "hard fallback") is when the GPU has enough VRAM, starts rendering without issue, and then iray suffers some kind of illegal access error and can't continue rendering on the GPU and sends everything back to the CPU. One of them is fixable by the user by reducing subdivisions, texture resolution, etcetera, while the other is not, as it is a bug in the rendering code. (Adding to the frustration, I've found that it's tough to force a hard fallback in a way that's repeatable, and intermittent bugs are just... ugh.)
Now, I haven't really used iray in hosts other than Daz Studio (I'm a VRay chick) so I don't know if there's a similar fault present in other implementations, but it seems like this would be much bigger if the issue was common to many different platforms. That tells me that the hard fallback issue has something to do with the interaction between Daz's code and NVidia's code, in which case the responsibility for fixing it lies with both Daz and NVidia, starting with Daz pestering the heck out of NVidia to acknowledge the bug and begin working on a solution. That may have already happened, but it's hard to tell without some kind of concrete statement from either on the matter.
I have no idea if it's been answered further upthread and I've come across roadblocks finding an answer: is Face Transfer going to be made available to Mac users soon?
Is there a rough estimate, say in months, of when the Filament renderer is going to be released in a public beta version of DAZ Studio?
I am afraid these are both answered with we don't know as Daz hasn't said.
I'm the only having issues with the timeline in the latest beta? I can create keyframes but I can't move them.
Which mode is the Timeline in (from the option menu)?
Advanced, the one with all the options activated.
I do animations so I always have that selected.
This "hard fallback" you are describing is almost certainly a hardware fault (not a software issue) stemming from one or more of the VRAM memory chips on the GPU in question's mainboard overheating and failing to communicate back to the GPU die when needed. For some reason (that I have never been able to fathom) Nvidia isn't generally in the business of tracking VRAM temps on their GPUs (to this day, Nvidia Founders Edition GPUs have no user-accessible memory chip temperature monitoring capabilities despite many 2nd party manufacturerers like Asus routinely adding them in.) Meaning that many consumer-level Nvidia cards have a total blindspot when it comes to operating temperature issues and video memory.
I guess the best excuse for this is that the vast majority of common use cases for consumer-oriented GPUs are not particularly memory intensive (in-game graphics rendering - despite what you may think - is generally not a very memory intensive task from a hardware level.) However doing the sort of unbiased rendering that Iray does is an extremely memory intensive task, and it will expose any temperature related faults a GPU has with time (the reason why these illegal access errors only come once a significant amount of time successfully rendering has transpired is because it takes time for hardware to reach an overheated state.)
The easiest way to combat this is to underclock your GPU memory (one of the most common differences between eg. Nvidia consumer GPUs and their pro Qadro branded functionally identical counterparts is generally lower clock speeds for exactly this reason) since that will bring greater stability. You could also try aftermarket cooling that focuses on VRAM chip cooling in addition to GPU die cooling (my main rendering machine is built around a Titan RTX cooled using a full waterblock/custom water loop for exactly this reason) although there is no guarantee that the GPU in question doesn't just have one VRAM chip with fundamentally bad temperature tolerances. In which case, an RMA should be in order.
No, you are not alone. This has been going on since the previous beta. As far as I know, you have to drill all the way down until you find the node(s) with the lowest level transformation key and then you can move that. I don't understand whether this is by design or a bug, but it makes using the timeline very difficult to move keyframes. I submitted a help request about it, but I haven't received any help yet.
I seem to be hit with the Balck Screen bug that people mentioned before (when they hit "Render"). This is in the latest beta (happened less in 4.12.1.76, but it still happened). What was the fix again? It worked for one render, but now renders blank (black there after — even after a restat).
Oh, and I'm running the 445.75 Driver, so that's not the issue.
I tried to install the public build update through DIM. I'd been using the previous version of the public build. I get the popup asking me if I want to allow changes like usual, and something happens, but Daz doesn't get installed, and my previous installation won't work.
Under installed in DIM I see this:
So what did I do wrong?
Did you have an instance of DAZ Studio running when you tried to install the update? Try uninstalling and reinstalling.
Have you tried uninstalling and reinstalling?
Maybe try a slightly older driver.
Went back to 4.12.1.76 and it's doing it there now too. Don't get this at all. Rendered previous days just fine.
4.10 Renders it just fine, so it is specific to the 4.12 Beta
Edit: False alarm. I was actually running out of memory (4.10 crashed to CPU as a test) and forgot that CPU fallback is turned off. My apologes.
Hope it's not by design because it's atrocious. Unthinkable work on the timeline like that...
I have experienced this too (starting in 4.12.1.76 I think), when I am trying to select keys (to delete) and I was hoping it might be fixed in this build (4.12.1.109). It is very frustrating. I have noticed that there are occasions when I don't have to drill all the way down. Sometimes, it lets me select the key when I am still a level or two above the place where the key is actually located. When I select "above" the level where the key actually exists, I always want to select all keys at and below the level I'm looking at.
Yes, I had tried that two or three times before posting. Restarted DIM too. What I had not done is restart my computer. Then when I restarted DIM, I saw that in Installed, there was a greyed out "Daz Studio 12" without the Public Build tag, which hadn't been visible before. I'd never installed the 4.12 release build. My release build is 4.11. I then uninstalled that Daz, and got the installation to complete, and Daz is now updated.
PS: Is the thing with Daz not terminating its processes now fixed? Unless Daz crashes, I often have to End Process in Task Manager if I want to restart Daz manually.
PPS: Now my old 4.11 install is no longer functional.
I have a dum-dum question ("dum-dum" bc it's probably been already asked somewhere, but I can't seem to Google it), so please excuse me if it's been asked/answered already...
I have the Beta, but how can I install any plug-ins to see if they work with the Beta?
I'm trying to use pwToon (on my Mac) to see if the new Beta fixes an issue I have where I can't select files from "Open..." menu choice. This makes it very awkward when I try to change texture or shader settings. Most of my files use the pwToon plug-in, so I can't open them in the Beta.
Any assistance would be greatly appreciated.
If pwToon is already installed, uninstall and reinstall it.
Does this mean that pwToon would then work for both the BETA and DS 4.12, or only for the BETA? Also, would I have to do this with any other plug-ins I have working with 4.12?
It should work for both. As for other plug-ins, it depends on the plug-in. For DAZ plug-ins I would uninstall and reinstall and see if it shows up in the beta. Which plug-ins are you thinking about?
pwToon is my main concern. I wanted to make sure ahead of time so I'm not making a pain of myself over and over again.
Thank you for your help, Doctor Jellybean!
pwToon is considered 'DAZ Studio' content so it will show up in both the public beta and release version of DAZ Studio if you have configured both versions of DAZ Studio to use the same CMS database and content library path names. Most people have them configured to be identical but check your DIM & the DAZ Studio preferences for both versions if you aren't confident that you've done that.
The plugins will work for both the public beta and release as their serials are shared in a comon serial database. You have to only enter the serial once but the plugins need to be upgraded for both anytime an upgrade is available in DIM.
All plugins except the CMS postgreSQL plugin. You can only install that one once so you should install the release version of that plugin and hide in DIM the public beta version of that plugin in DIM.
Has anyone explained what the new SSIM options mean under "Progressive Rendering?"
Here's what the official Iray documentation has to say about it (there's info there about the new Matte Fog features as well.) It's actually been a documented feature there for something like 2-3 months. Been Keen to see how it performs under DS, but haven't gotten around to playing with it yet. One thing to keep in mind is that it is inherently incompatible with the ai denoiser. You can use one or the other, but not both at once.
Hm... So it's a new denoiser option...?