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
Save the render? That's possibly simply by stopping it then restarting it. This results in a file "r.png" in the temporary files directory which was the state of the render when it was stopped; copy the file out and rename it to something sensible. Check the log file; help/troubleshooting/log file for the full path of the saved file. IRC it's also possible to save the Daz scene file while the rendering is paused.
It just got pushed to DIM, the package date is November 5.
First thing I'll test is that it exits... 4.12.60 on W10 did not exit for me even if I just opened it and immediately closed it; really annoying having to go into the task manager to kill it before a new one would start.
File menu>Save Last Render. A lot of people never seem to have noticed that. No need to hunt down the temp folder, copy and rename.
just downloading installing daz studio 4.14, what happened to 4.13? Or did I not notice thought last version was still 4.12
I doubt it was "fixed", as it was a feature, intended to prevent one copy of it opening while another copy was shutting down. However, it shouldn't be taking a long time to close. If anything, that's what they would try to fix, imo.
Unfortunately, v4.14 still presents the same problem :-/
https://www.daz3d.com/forums/discussion/comment/6190691/#Comment_6190691
This is a bit frustrating, to use the 3090 without Iray planes I prefer to continue with my 2x1080Ti and be able to use Iray planes in the stable version.
No news on possible solution?
Thanks!
Reagarding drivers: the recommended one for DS 4.14 is officially the latest Studio Driver. I notice that the number for that one is one step behind the latest gaming driver. Despite this, does the gaming version lack the necessary optimizations?
thanks, guys! i'll try those things out. but, often my issue is that daz crashes entirely, not even a fatal bug error, so I'll have to see if it persists through that.
Can you provide a scene file or set of steps to reproduce it, so Daz3d can report it to NVidia?
4.12, I've changed to 4.14, btw,
sorry for the late reply
Sure, it's really easy:
- Open Daz
- Load G8, G3 or G1 (G1 with some skin texture) (INTERESTING NOTE: The G2 characters, specifically Genesis 2 Base Female, DO NOT present that problem!)
- Create a Iray Section Plane node (Move it a little bit the Y axis up to see part of the character)
- Activate the Iray preview and wait for it to finish (use GPU-Z or Windows resource monitor to monitor GPU usage)
- When the preview is complete and the GPU doesn't make use of the CUDA cores, simply move the perspective or camera, at this point the Iray preview will no longer work, the GPU will not be detected by the program and will require a restart; or if you try to uncheck and re-check the GPU in the advanced Iray settings, and activate the Iray preview again, Daz will give an error and shut down. (NOTE: Curiously, you can move the perspective or camera while the Iray preview isn't completely finished and it works that way; so the problem is when the preview is completely finished).
Tested on versions 4.12.2.60 and 4.14.x, with a 3090 or a 1080Ti (so it's not an exclusive problem of the new GPUs), with several drivers (Game or Studio), with W7, W10, and with a new installation of W10.
BTW, the example is using the Iray preview, but if the scene or animation is rendered the same problem happens.
Thanks!
UPDATE:
New tests carried out indicate that the problem is related to the skin material. I had previously mentioned that, curiously, G2 Base Female didn't suffer from this problem, and that's right, BUT if you apply a G1 skin material, BOOM! The problem appears.
On the other hand, I've tested properly G2 Base Female, doing 4 complete Iray previews, no trace of the problem... so, what's different about the material used in G2 referring to G1, G3 or G8 in order that this problem doesn't occur?
Unless I am entirely mistaken @amandainjapan is talking about being able to access Daz Studio's file saving UI functions while a full Iray render is ongoing (currently all DS UI interaction is disabled any time an Iray final render window is active - an artificial restriction imposed by DS's developers in order to maintain UI consistency between Iray and 3Delight.) Iray itself has been designed from the very start to enable non-main-UI-blocking rendering activity and even multiple simultaneous independent rendering tasks. Both features all versions of DS so far have yet to take advantage of.
The UI is not disabled if the render is cancelled. So long as the render is to a window and the window is kept open it can be resumed. If significant changes were made to the parameters of the render - anything not in the render window dialog - the render will restart from 0 but if no changes are made it resumes from where it left off. Indeed it seems to be possible to start a new render, cancel it and then resume either render although I guess that will require double the Iray resources. Only one render can run at once (in a single instance of Daz). There are glitches with HDRI renders, i.e. if the render includes a canvas; I've see a paused render restart from scratch even though I changed nothing, or rather nothing I was aware of. The range of parameters that can be changed also changes with canvases; changing the EV of a tone-mapped render works fine mid-render unless a canvas is present in which case it seems to restart. I also suspect the scene can be changed in at least some ways and the render resumed but I haven't tested this.
Daz needs relaible steps to reproduce the issue in order to make a rport to nVidia so that they can investigate and fix it - despite testing, and reports, they have not been able to find such a set of steps (or a saved scene that shows the effect). There were changes to this aspect of the renderer in 4.14.0.x as the API that was being used is deprecated, so Daz can be confident that the issue is not down to that old code path if it iss till persisting.
Thank you for your answer.
I can create a scene quickly if needed but I don't think it's necessary, the steps can be easily reproduced:
https://www.daz3d.com/forums/discussion/comment/6205951/#Comment_6205951
And it seems that this problem is suffered by many people:
https://www.daz3d.com/forums/discussion/comment/6206536/#Comment_6206536
Thanks!
PS: I have the 3090 in a drawer as I can't use Iray planes, lol, $1500 in a drawer! :-p
Yes. The point being made here is that Daz's UI doesn't need to be made inaccessible in the first place because Iray internally supports non-blocking asynchonous rendering. And there is also support for multiple simultaneous active render contexts (see the official documentation here.) Meaning that having more than one Daz Studio instance open to do multiple simultaneous renders is also technically unnecessary.
Can you submit a bug report with this information?
DS used a render window (long) before Iray was added, using the same UI. You are jumping to conclusions about what was done, why, or when.
I'm not convinced that being able to save an ongoing render would entirely make sense, since it would either have to pause (the current behaviour, and not supported (as far as I know) by 3Delight) or grab data on the fly, potentially giving a mist-match. It certainly wouldn't be a good ddiea to have the UI generally unfrozen - it wouldn't be possible to send any scene updates to any render engine, I would think, without triggering a restart and having functions available but not live would just be confusing. If you think you can present a wel argued case for such a feature, though, you should open a support ticket for Daz to review.
Carrara can manage it with the Octane plugin
just saying
well so can DAZ studio but only still images not animation
Those are slightly different steps from any I've seen before, but trying it just now I didn't get any issues and the GPU remains avaialble for rendering. Until Daz can figure out a combination of factors that reliably triggers the issue (and they have been trying) it isn't going to be possible to report the issue to nVidia.
"Checkpoint" I believe; the current (and very annoying) render window dialog has a "cancel" button which immediately pops up a dialog (this is the very annoying part; doing cancel in the log window doesn't poop that dialog). The UI is basically wrong; it really isn't cancel, it's "Pause". That said:
The only data in question is the internal canvas. Doing "cancel" invariably produces an image of the state. In some cases that I have observed with [non-internal] canvases enabled a "resume" might not be possible yet it still isn't data-on-the-fly; it appears to be the state of the canvas after a specific iteration, I suspect the one after "cancel" was pressed, but I can't tell.
It's there already, it's just mislabelled. Cancel in the render window is Pause; at least 95%, maybe 100%, of the time when I have done it I can Resume so long as I don't change anything (the %s change if I do.)
Exactly.
DS's current UI behavior while rendering using Iray was copied directly from DS's existing UI behavior while rendering using 3Delight - which does necessitate UI blocking since 3Delight has no in-built support for asynchronous operation. It's just that Iray does have that fucntionality. Meaning that the UI blocking when using it is wholly unecessary.
It doesn't make sense. It also isn't what was being lamented about DS's current implementation of Iray. That was the fact that DS doesn't allow the user to access the UI in order to eg. save ongoing changes made to the currently loaded scene while an Iray render relegated to an external window is actively being rendered, despite the fact that each Iray render task launched by DS to an external window gets its own separate Iray Render Context. Meaning that it is programmatically immune from changes made to the currently loaded DS scene or the DS UI in general (apart from closing the program entirely) since each Iray Render Context is given its own working copy of all relevant 3d assets and render settings at initialization time and then refers only to those for the completion of its task.
I obviously am senseless then, I save ongoing Octane renders all the time
Thank you for trying it, I didn't think it would be so difficult to replicate the problem since so many seem to suffer from it.
I have tried again, clean installation of W10, I haven't installed anything else (apart from Chrome and Winrar), I haven't even installed drivers or Windows updates.
While I was downloading Daz Central and Daz Studio v4.14.0.8, Windows installed the Nvidia driver, v456.38, and I thought that before installing a more recent one from the nvidia website I could try this one, and it failed.
Then I closed Daz, installed the latest Nvidia Studio driver (v456.71), restarted, opened Daz to clean the error log, restarted it and tried again, same error.
Attached the LOGs of both occasions.
Steps that I have followed.
- Open Daz
- Load G8 Female Base
- Create an Iray section plane (raise it a little bit to see the legs of the character rendered)
- Activate the Iray preview and, IMPORTANT, wait until it's completed, that is, the GPU is not being used yet to finish the rendering (in the windows resource monitor, wait for the CUDA cores to drop the percentage and not be in use)
- Move the perspective (I haven't even created a camera), and from there on it renders through CPU.
Hope that helps.
Saving a Timeline movie on a Mac fails with a circular file save error. This used to happen elsewhere but was fixed, seems they missed one. I put in a ticket, but they didn't feel like fixing it.
Correct me if I'm wrong, but is this the first time you've mentioned you're using Daz Central as your installation manager? I don't know why it would matter in this case, but there have been many reports of buggy behavior with Daz Central (it's a very new program) and Daz installations to the point where it seems most experienced users (even ones who don't need the much more advanced options DIM offers) have shied away from adopting it. Could be that the difference between people seeing this and not is actually which install manager they're using (could also be proven wrong about this very quickly.)
Yep, this is the first time I mention it because it's the first time I do it through it; previously I had downloaded it through DIM but installed it manually, with the same result and the same error, and finally I also tried updating directly through DIM, and it also failed.
So I tried the 3 methods, manual/DIM/Daz Central, and there's no difference in the result :-/
Thanks anyway.
My driver is older, 452.06 - I'll try later with a more recent version but I certainly can't reproduce this right now. Actually, the GPU did fail tonight. Tried a couple of times and still getting the same result, also tried beta and General Release in case they were giving different results. Of course that doesn't mean Daz will see the same.
I agree that the UI as designed is far from ideal and I certainly agree that changing the scene while a render is in progress is highly desireable; at present I start a second instance/run the beta to make such changes. I.e. I start a render then load exactly the same scene in another instance so that I can keep working on it. However this statement is perhaps misleading:
Ok, yes, everything I've seen indicates that the Iray render, and possibly others like a filament (viewport) render could be made immune from scene changes and this would be a very good thing. However if you change any of the tone mapping settings using the tab in the render window they are immediately reflected back in the scene. These changes can be made without pausing/cancelling the Iray render, so long as there is no canvas the render just continues (well, it jumps back to updating per iteration, but it doesn't restart unless there is a canvas.) Now I admit that is a UI feature and I would like it a whole lot more if I could not only tweek the tone mapping, particularly the EV, during the render but also not have those changes made to the scene, well, unless I chose to push them back. Of course I'd also like to be able to enter the file name during the render and not have the render window disappear when I click "save"; as it is I frequently have several render windows open so I can do direct on-screen comparisons of different settings, normally the image convergence settings.
On that matter, why does the UI allow me to change the pixel filter gaussian radius on the fly? That always requires a restart doesn't it; changing the sampling width, or the sampled width requires recomputation of every sample. (I'm not sure whether it changes the guaussian radius or the amount of space that is sampled for a gaussian with the correct radius, I hope the latter ;-)
So, it has failed when you update the driver?
If not, maybe it hasn't failed before because you haven't waited long enough for the Iray preview to finish completely.