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
Did you update your graphics card driver? The new 4.14 update will not work without a very recent driver. And it must be installed from the NVidia website — if you let Windows do it, what you get is a generic driver that can't handle Iray rendering.
As stated, check your driver version.
The update to 4.14.0.8 was not forced - it appeared as ana vaialble update which you presumably selected to install.
it takes [blooming] forever to save and overwrite an existing scene now.
before it took 2 seconds now around 1 minute
whats the problem?
I have not seen any significant change in "save" time, either to a new file (save as...) or to the current file (save) in the absence of dForce simulation data. The time to save a file with dForce simulation frames has always been much longer and the file much bigger. A trivial scene (one character in an HDRI environment) that saved as a scene file of 231KByte before simulation occupies 76MByte after I had run a dForce simulation on it; if I understand the approach there are "FPS multiplier" frames saved per animaton frame, so in this case the 76MByte is 60 frames, about 1.3MByte/frame. Those are frames for the Keicy short hair and a dress.
It may be the case that 4.14 is producing more dForce data per object/frame because of the new dForce kernels, so if your are considering the save of a simulated file see if you have a copy of a similar scene saved with 4.12 after simulation and compare the file sizes. I had a brief look but I can't find an obvious example in my scenes; I can generate one from an old scene but don't have one to hand.
I do strongly suspect that the new dForce kernels are a lot more robust in the presence of collisions. I've observed that the dForce "desert hair" seems to suffer something that might be termed an "afro explosion"; the hair just spreads out from the head like an inflating baloon. My hypothesis is that this is caused by a high hair density resulting in lots of collisions which, in previous dForce kernels, would simply cause the kernel to give up but now causes every hair to move apart. Successful simulations (or at least ones that take longer to give up) are likely to generate a lot more data.
I guess you did not make a render yet. The loading time is not the only hiccup. I imagine there will be soon another update, to get the shading back to where it was?! If not and this will be the way, i think a lot of vendors have to update their products. But my guess is, that there went something wrong. Also the light is again stronger in Filament and the shadows behave in another, really interesting way.
Something like that has been annoying me too, but I can't reproduce it. Here are a pair of renders originating in a bug report I submitted in March 2019; the first is from 2019 so, IRC, 4.12. The second I just made with 4.14.1.22. To double check I diffed the two images with PS 2021; that's the third PNG.
It's really annoying; there's not change there but I don't know if I'm seeing a bug in other cases or just changing something consequential in the lighting and getting a bad render.
It would be really good if you could submit a bug with the scene file with the original, pre-4.14.1.22, render and the current beta render. Iray renders should not change in the way you demonstrate.
Can you not do that? I'm pretty sure I've done exactly that in a bug report before.
I just spent an hour trying to do so. I don't have a base reproducible example.
Just installed a 3090 today..working with Daz 4.12 (dont want to go to filament yet) and I can confirm that even with the latest Nvidia studio drivers (or game ready) 456.71 daz will render NOTHING in Iray preview or Render mode..I have tested my gpu ad nauseum today for hours, the card is working fine and all systems check out well, its definitely Daz..two days ago I could render splendidly with my 1080TI, quite quickly even but wanted the new card for gaming and especially to use the higher Vram to render more complex scenes in daz..as even the 11 vram is a limiting cap with the 1080ti, so..nothing to do but wait until Daz figures this out, anyone else had ANY Luck with the 3080/3090 series cards? Im not trying to whine, Im grateful to have the card as I built a new system in November and just today got my hands on the new card.
Please try to render something simple e.g. a figure and attach the log.
Some conforming stuff gets totally deformed if any part of the model's body isn't at 100%. An example is Timeless Hair for Genesis, as soon as I slightly change the chest or abdomen sizes, the hair are totally misplaced. This doesn't happen in 4.12.0.86.
Try using a clean install of the driver version that is listed as the minimum in the Highlights/Iray threads. Note that Ampere support requires or 4.12.2.31 later http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_14_0_10#4_12_2_31
I submitted a ticked, but wanted to ask here as well in the event that I might get a quicker response.
I recently updated DS from 4.11 to 4.15 (I do keep all older versions of Daz) and have noticed that I can no longer run more than one 'instance' of DS. I often have more than one instance of DS running. Rendering in once instance, while setting up a new project, or beta testing in another instance. I have read through many of the comments here, but haven't found if there is a way to re-enable this much required functionality.
Any info would be appreciated!
Thanks!!
~Wolfie~
I have a second shortcut with the following in the target field. It allows me to run two instances simultaneously.
Run DAZStudio from the command line with the (two) options "-instanceName #" (i.e. without the quotes - the characters in bold). It's possible to add these to a windows shortcut or, I assume, do something similar on the Mac (I don't know details of the Mac window system) or to run a script with those arguments or you can search the fora for instanceName (no leading -; that stops the search working). Look in the 4.12 highlights thread for more information; check the entry for:
4.12.1.40 (November 25, 2019)
Brief summary: DAZStudio checks for another instance of itself when it starts, if it finds one it exits. The -instanceName argument sets the name of the instance it looks for so that it only exits if there already is an instance with that name. # gets replaced by a unique number such that DAZStudio never finds a matching instance. You can run as many as you like (until, of course, you run out of memory). The main limitation is that multiple dForce/Iray renders can cause your GPU to run out of memory then you may have to shut down a failed instance and restart it to get working Iray (at least in 4.15).
The "highlights" entry above also holds a DAZStudio script, which some may find useful. You can save the script, which is called "Launch Instance.dse", somewhere in your Library directory and then create a "Custom Action" for it to put it in the "Scripts" menu (right click on the file in the content library pane and select "Create Custom Action"). It allows you to create a new instance of DAZStudio from an existing instance, but set the "Start Process" check box at the bottom left or it does nothing. It allows you to pick up settings from old instances or, indeed, from the current running instance; that's the default when you click "Copy App Settings" and "Copy Session UI".
If you read the post again. It states...
'If the "Launch Process" option in the script's dialog is NOT checked, a message is displayed that contains an OS specific generated string that can be used to launch an instance of the application from command line, a shortcut or an alias.
This message contains a "Copy" button that will copy the generated string to the system clipboard, to ease its use for purposes where this is desired.
This generated string is also written to the log (Help > Troubleshooting > View Log File...).'
... followed by...
'If the "Launch Process" option IS checked, a new instance of the application is launched, configured according to the active options and their respective values.'
It does not have to "re-render" for some settings, because they are "post-editing settings". Pixel-blur is just full-screen aliasing of each pixel. Gamma is just a photo-edit gamma adjustment. Contrast, brightness, "the illusion of "exposure"... are all simple things that are not actually part of "rendering", it is just manipulating the "rendered image data".
Literally, the same things you can do in photoshop, just built into the rendering panel.
You can extend these settings using canvases, to get the full floating-point range of the data-sets. (Well, it's not actually a full set, as the data is confined to a specific upper and lower bound of the floating-point values. You have to adjust the upper and lower thresholds to work within the ranges that are actually used.)
Some things demand a re-render, obviously. Simply because they alter values which need to be rendered, to display the output. As opposed to stopping the render, guessing a value, and re-rendering it again. (For those not using iray preview mode, or for those who want to see a more true "render representation", which preview mode does not have the ability to offer. Since it is just a fast-preview, and not a true "render".)
Correct, but it does have to re-render for a change in sampling radius, so DazStudio should not allow it to be changed in the rendered-image window, only in the main UI. I think that was the original point.
Anyway, the latest DAZStudio beta forces a re-render even if the only change is to the convergence percentage; self evidently something that can be changed...
I'm wondering if you ever found a solution to this, as I'm now having the exact same issue with the current Beta.
@Leonides02 Can you purge Daz's memory (Scripts-->Utilities-->Purge Memory script) before loading your scene to render to see if that eliminates the error?
If that doesn't help, then check to make sure you have Virutal Memory (i.e. Paging File) turned-on...
Control Panel-->System and Security-->System-->Advanced System Settings (or via Settings-->System)
Then, in the "System Properties" pop-up:
Go to the "Advanced" tab and below lookd for "Performance" and click "Settings"
Then in the "Performance Options" pop-up:
Go to the "Advanced" tab and below look for "Virtual Memory" and click "Change"
Then in the "Virtual Memory" pop-up:
At the top, you can put a checkmark next to: "Automatically manage paging file size for all drives" (or set Custom levels) - Restart after making any changes
NOTE: I use Auto and my "Currently allocated" is set to 12800 MB (i.e. 12.5 GB)
NOTE: The Paging File allows part of your hard drive to be used as RAM.
Thanks for your help, Robert. Unfortunately, this didn't solve my problem. What's strange is it's only isolated to one scene file. Another scene with the same character and props has no problem rendering.
I will do some more experimenting.
@Leonides02 I hope you can figure out what is causing the issue with the one scene, but not the other. It may be some setting with the character (or outfit) that got changed accidentally, such as the SubD level getting bumped-up too high, so I would check that first. Perhaps it's a problem with the hair or the oufit/scene textures (high polygon count or large texture maps). Try rendering the scene without any hair on the character and without the outfit, to help you narrow-down the problem area. It could also be a render setting throwing it off... compare the proressive render tab settings between the 2 scenes. Also, try a render with the Draw Ground set to OFF in the Environment tab.