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
FWIW, Beta 4.12.1.16 opens files from 4.12 release version without issues on my PC. Also renders slightly faster with slightly fewer iterations than the 4.12 release version. No isses with scenes developed in 4.11 either.
980TI here. 32GB Ram, Windows 7, 64bit
Changing DAZ Studio to single instance does not fix any bugs -- it hides bugs, and it makes using DAZ Studio ten times harder to use for complex scenes.
Most apps I've ever seen do not handle errors properly, and DAZ Studio is no different. The main reason is that it is notoriously difficult. I wish it did handle errors better, but that is not what I am addressing. Multiple instance DAZ Studio can easily -- easily -- run out of memory, no matter how much memory a machine has. This has happened to me. Preventing multiple instances of DAZ Studio delays DAZ Studio running out of memory, but ultimately will not prevent it. Preventing multiple instances of DAZ Studio prevents the stupid mistake of running multiple instances unintentionally, but if that is actually the intention, then let it default to this primitive behavior, but allow multiple instances for users who need it.
For multiple instances, I know what is happening by watching the memory usage. With a small amount of care, I can prevent errors from happening, mainly because I only do renders (the biggest memory usage in DAZ Studio) in one instance (the scene I will ultimately render), not my other "working" instances. Even when I have two full scenes open, the resource usage is only high -- and stays high -- in the instance I have done a render in, despite the fact that I may no longer be doing any renders. That's OK -- sort of. But, by never doing renders in the second instance, resource usage is still under control, and is actually approximated by the single instance which did the render.
I've had 10 instances open and never ran out of memeory with 64 GB RAM in my system.Didn't get any errors there.
Not good enough.
I'll be voting with my wallet. I've also raised a ticket.
Shame, i like the sound of those improvements, but multiple instances is something I use quite often.
I have 6 different versions or copies of daz studio software. & i can run them all at the same time for various reasons as needed, and they never give me errors. I keep them mostly because of compatibility issues from a older instance of daz studio to a new version. which may have broke a plugin, add-on or script etc during the upgrade. The fact is It happens all the time, there is many times when a new release of daz studio will break compatibility of a older versions plugin or scripts and is the major reason for keeping multi instances of studio. having the ability to render and build scene at the same time is another reason.
I am no longer updating or upgrading daz studio beyond daz studio 4.12.0.33 or daz beta 4.12.0.34 at least until some of these issues has been fixed and if I am asked I will recommend to others they should hold off on upgrades as well, Specially if they want to use more than one copy of daz studio at a time. or keep a copy of daz that has working scripts Other wise you will be SOL if you try to go back to a older version studio because the upgrade broke something in the compatibility and you can no longer run a plugin, script.
I keep a copy of daz3 because i have plugins that no longer work in daz 4 & I paid for them and still use them. & I also have a copy of daz4.8 because the Age of Armour advance AOA light & atmosphere cameras sets I paid for & were broken with daz 4.9 versions of studio and I kept a copy of daz 4.9 for shader issues that were broke with daz 4.10 & so on and so on with each new version
That is all I can say about this on going issue in the forum. but there are many reason for having multi instances of daz running
So this load speed difference is the same number of morphs, just in one you've fixed the duplicate formulas?
Not being able to have more instances opened simultaneously is one of the worst "features" I've ever seen. In all honesty I am not seeing any reason to use the latest beta until this so called "feature" is removed.
Do you have a store link for the morph sets? I'd like to try it myself. Once installed, how do I try and see what I get compared to yours?
Is it possible to contact Angel-Wings and see if they can update?
Though that doesn't tackle the over arching issue with how Daz handles these errors. There has got to be a way to for Daz to work around these errors so it at least loads in a reasonable time even they are encountered. Just what is Studio doing when it encounters these errors to make it take forever? In my view, Studio should just pick one or the other instead of freaking out and running in circles. I think what Studio should do is have a priority on what gets loaded in these situations. Perhaps the user can define what is given priority with an option somewhere, and decide how Daz handles these errors.
So like I would do this: files ID'd as Daz Original get top priority. This helps keep the base models in the correct shape even if somebody accidentally duplicates them. The next parameter given priority is install date of the file. You can decide whether the older file gets priority, or the newer one. Since most of these errors are caused by a recently installed file, being able to default to the older file would make sense. The user can choose if this is done automatically without their input during the load. Then the next priority would be the date of the file itself (not the install date, but its original creation date). The key is getting Studio to default to one file over another, and skip the other files causing the error. If this can be done, not only would it load faster, but it could also preserve the base models even with duplicate morphs. Once the figure is loaded, then (and only then) is the error popup shown. Skipping the popups is a big part of making this less painful.
This data is available in the first few lines of any Daz file. So it would seem like asking it to read just the first few lines to get this info, and then load the one file that gets priority would streamline this process.
So like in Sylvie's case, Growing Up is not Daz Original, so it would look for the next priority being install date. Since Growing Up was probably installed first it will get loaded, and the Muffin Morphs would not.
Bonus points would be given if Studio could list a breakdown of the offending morphs causing duplicate errors, so the user can try to fix it. This would be a list of just those morphs, not a massive wall of text like the Help File generates.
I am aware that maybe this is not possible, but it would be great if it was.
Duplicate morphs is a real problem as Daz content grows ever larger. With thousands of products available and new ones releasing all the time from all sorts of places, this problem will only get worse with time. Moreover it is something that Daz cannot really test for, since how can they realistically do that? That is why Studio needs a system in place to tackle duplicate errors. It has to be done to help Daz move forward into the future. When Daz loads super slow and becomes a drag to use, people may stop using it. That's just how it is. So it doesn't matter who is at fault, Studio has to address this.
I can save, load and modify my files now. I still can't find the link to DAZ Faces Transition plugin. I'm on a Mac. I know that wasn't your primary concern.
Thanks for your hard work.
https://www.daz3d.com/forums/discussion/comment/4903221/#Comment_4903221
Face Transfer pane is Windows 64-bit only
Thanks. I have a Windows 64-bit laptop I can install DAZ Studio onto.
I am not using 2 instances at the same time often, but sometimes I do. Staying on 4.11 ...
Edited: Rob's post was edited to add an "(by default)" - yay!
Something that's been bugging me since 4.12.0.85, the element that receives automatic focus in a save modal popup has now changed to the "?" button (with tooltip: Click here to enter "What's this?" mode, for interactive help) instead of the previous "Accept" or "Save" etc. Sure, it takes but a second to click or tab to the right element before hitting enter, but this goes totally against the grain of muscle memory that has been instilled over several years of the previous workflow. **edit below!**
Regarding the single instance shenanigans, this was introduced in 4.12.1.16, so if you still have 4.12.0.85 you can keep your instances... I tend to have 2-3 open at any one time. Updating won't be an option till they provide a way to override this (but judging by Rob's post edit it may be that there is a toggle in preferences? If any one can confirm...??).
Regarding previous comments on dubious free VRAM reports in the log file on Studio boot up, I'm inclined to ignore it - GPU-z reports the precise figure (3mb on my desktop, as that card is not used to drive the display, and approx 80mb on my laptop with no other GPU accelerated software open, as that is also driving the display).
Edit: Seems the modal default focus issue has been addressed in 4.12.1.16 (Fixed an issue where some dialogs would not select the preferred default button (e.g. "Accept") when shown) - shame the instance issue prevents me from updating...
So how to turn it off?
As yet, you don't. This is still a work in progress.
I just sent in a ticket asking to get back the multiple instances of DS. The best way to get that feature back is for everyone to send a ticket in requesting it. I use multiple instances a lot for testing. Some characters I create I intend to use repeatedly, so I merge all the morphs into one, adjust the ERC rigging, and save it as a new morph (that will never be redistributed.) I need that second instance to make sure the combined morph/rigging is saved properly before wiping the scene and creating the next character. I don't want to use one version of DS for creating and another (the BETA) for checking the results. There's always a chance that the difference in version could hide an issue or create one. And if I forget which is the production version vs. BETA, I might save something in the BETA and create a version mismatch.
Before too many people swamp support, do bear in mind that Rob has stressed that this is still a work in progress. The chnage log often gets updated around the end of the week, though I'm not seeing anything post the Public Build yet, so it may be worth keeping an eye on that today and tomorrow.
and indeed it was updated, with several relevant looking ntries but I think the big one is:
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#4_12_1_19
Is the Beta still the same as the General Release? I had to go back to 4.11 because of the issue with IRay falling back to CPU on the second frame of an image series. Now I use 4.12 Beta quite a lot except for rendering image series. However, I've noticed that with 4.12 Beta, IRay falls back to CPU when I have a scene where I'm experimenting with different materials/shaders. I loaded some OOT hair and was playing with the hairblending options and rendering each to find the one I wanted. I noticed that after a few tries, the test renders were using CPU, not my 1070 GPU. So it seems that 4.12 does not handle VRAM very well at all.
Note that re-starting DAZ Studio and loading the scene again brings back GPU rendering - at least for a few tries.
No, the general release if 4.12.0.86, the Public Build is 4.12.1.16
The following occurs after updating to the latest beta (compared to the latest 4.12 release):
TL;DR; Renderer falls back to the CPU with no particular reason.
2019-10-19 08:00:45.466 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Rendering with 1 device(s):
2019-10-19 08:00:45.466 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : CUDA device 0 (TITAN V)
2019-10-19 08:00:45.466 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Rendering...
2019-10-19 08:00:45.504 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : Initializing OptiX Prime for CUDA device 0
2019-10-19 08:00:45.622 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : Importing lights for motion time 0
2019-10-19 08:00:45.626 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : Initializing light hierarchy.
2019-10-19 08:00:46.816 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : Light hierarchy initialization took 1.190s
2019-10-19 08:00:46.940 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : JIT-linking wavefront kernel in 0.069s
2019-10-19 08:00:46.978 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : JIT-linking mega kernel in 0.039s
2019-10-19 08:00:46.988 Iray [INFO] - IRAY:RENDER :: 1.2 IRAY rend info : CUDA device 0 (TITAN V): Scene processed in 1.521s
2019-10-19 08:00:46.992 Iray [INFO] - IRAY:RENDER :: 1.3 IRAY rend info : CUDA device 0 (TITAN V): Allocated 12.501 MiB for frame buffer
2019-10-19 08:00:46.992 Iray [INFO] - IRAY:RENDER :: 1.2 IRAY rend info : CUDA device 0 (TITAN V): Allocated 1.688 GiB of work space (2048k active samples in 0.000s)
2019-10-19 08:00:47.139 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.3 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while launching CUDA renderer)
2019-10-19 08:00:47.150 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.3 IRAY rend error: CUDA device 0 (TITAN V): Failed to launch renderer
2019-10-19 08:00:47.150 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): Device failed while rendering
2019-10-19 08:00:47.150 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [WARNING] - IRAY:RENDER :: 1.2 IRAY rend warn : All available GPUs failed.
2019-10-19 08:00:47.160 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [WARNING] - IRAY:RENDER :: 1.2 IRAY rend warn : No devices activated. Enabling CPU fallback.
2019-10-19 08:00:47.160 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [WARNING] - IRAY:RENDER :: 1.2 IRAY rend warn : Re-rendering iteration because of device failure
2019-10-19 08:00:47.160 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: All workers failed: aborting render
2019-10-19 08:00:47.168 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.168 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.168 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.178 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.178 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.178 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.186 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.186 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.186 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.2 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.196 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.0 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.196 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.0 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.196 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.0 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.204 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(304): Iray [ERROR] - IRAY:RENDER :: 1.0 IRAY rend error: CUDA device 0 (TITAN V): an illegal memory access was encountered (while de-allocating memory)
2019-10-19 08:00:47.204 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : CPU: using
I did some testing with animation in 4.12 and I believe the difference is that 4.11 allocated about 1gb as working buffer (without prime) while 4.12 allocates about 2gb, that's the same as 4.11 with prime. So, if a scene was rendering in 4.11 without prime, then it may not fit 4.12 because of the extra 1gb taken as working buffer for optix. I used gpu-z to check the vram.
Apart the extra 1gb working buffer, it seems it's working fine for me. As for the speed 4.12 seems about the same as 4.11 with prime on my 1060.
For my case, vram is mostly empty(~3gb/11gb). And I had no issues with 4.12 release. The latest beta is the first time I've ever noticed this. While navigating the scene with iray, it tends to fall back to the cpu if I move a few times in a row.
Yeah, unfortunately this discussion is happening in two threads at the same time. I posted a bunch of my own GPU-Z logs in the other thread which shows the influence of Optix Prime. This latest issue that I brought up here (a few posts back) has to do with CPU fallback after loading and unloading/replacing various materials and shaders. VRAM management seems to be amiss somehow because there seems to be a cumulative eating away at the available VRAM until it requires a restart of DAZ Studio to release some memory.
While the 1 instance thing is annoying, I'm getting issues trying to use the timeline. First time, the program froze when I clicked on the little arrows at the bottom to bring the pane up. After that, I get it to come up, but it now locks up every time I try to alter the "Range" - whenever I try to change the 0 to a 1. Writing a ticket now, but just wondering if anyone else has seen this with the latest update.
Editing to add that trying a different scene and I can't get into the timeline. Tried twice and it froze up both times.