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
well this is a new one
I cancelled an image series and it's still going ...
I can change my parameters etc in DAZ studio but it's rendering
it takes 10 minutes after I close a DAZ Studio 4.15 file before I can open a new one. I found out DAZ still keeps running in the background. Close it via task manager and instantly you can open DAZ Studio again.
You also risk data corruption. Instead start a new isntance with a differnt name, you can use the script heer to do it before closing the original DS or you can use it to create one or more shortcuts for starting new instances Daz Studio Pro 4.12 - instances
It might be a good idea to lock a comment thread somewhere about the two issues (creating separate instances, dealing with the time to close a single instance.) It took me a while to work out how to use the script at the end of the "instances" highlight thread entry and, anyway, it's in the 4.12 highlights and we are on 4.15. I find it a little counter-intuitive to have to start a new instance from an existing running instance, though it does handle the issue of whether to run the General or Public release quite well. Also the script has that "Start Process" checkbox and I can't see what on earth it is doing if that is not checked...
As for killing the beast, I checked carefully after you said that last time but didn't get round to posting my results. So far as I was able to discover nothing is written to disk during the (background) closedown. Maybe the CMS connections are closed but PostgresSQL is (has to be) robust in the presence of application level disconnects, indeed it is robust in the presence of system crashes, disk crashes, etc, but see my comments at the end of this post. What happens when the close starts (when the close button on the window is clicked or when the "should I save" dialog is completed) is that the system settings are immediately written to the AppData folder. In the case of a DAZStudio running with -instanceName the only file written to the root is customactions.dsx; the other .dsx files are written to the instance directory and, under normal circumstances (i.e. the absence of extra command line arguments) are never used. Nevertheless they are all written before the true close starts; this shows in the log file but I verified it using the file modification times on disk.
This is actually very important because background processes get killed arbitrarily on system restart (shutdown on UNIX) and on log out. Windows will wait for foreground processes to exit and give the opportunity to abort the log out or restart if they don't exit but background processes don't get that privelege. This is why restarting a Windows sytem fixes the failure of DAZStudio to start without indicating that the problem was a background process.
Anyway, I triple checked and DAZStudio seems to behave the way I expect. I can't tell for sure but it certainly looks like all the files are written while DAZStudio is still in the foreground, if not it is pretty much the first thing done in the background. The sequence is consistent with the log messages:
2021-01-31 14:45:51.205 Saving session layout...
2021-01-31 14:45:51.222 Saving custom actions...
2021-01-31 14:45:51.234 Saving session actions...
2021-01-31 14:45:51.251 Saving session menus...
2021-01-31 14:45:51.276 Saving session toolbars...
2021-01-31 14:45:51.288 WARNING: Object::disconnect: Unexpected null parameter
2021-01-31 14:45:51.288 WARNING: QCoreApplication::postEvent: Unexpected null receiver
2021-01-31 14:45:53.598 Begin Application cleanup...
I do know of one potential issue with a forced close-down. The first of DAZStudio, DIM and (maybe) DAZCentral which is started hosts the PostgresSQL server. If that process is closed it sends the server threads into the background. This is fine but when DAZStudio has launched the database it leaves what is apparently a background DAZStudio process; killing that will hose all running DAZStudio applications at least to the extent that they lose their database connections. I never see this issue because I always start DIM first and I never close it; so it always holds the SQL threads.
The script can be used to generate the code for a shortcut/alias, in which case you might not want to run the new instance from DS.
Whatever Daz Studio is doing after shutting the GUI down, it's not being done efficiently.
If we risk data corruption, Studio should give a warning about that, and offer the creation of a new instance:
"You clicked the Exit button. Daz Studio will work in the background for a while. Please do not kill the process with Task Manager.
Would you like to launch a new instance of Daz Studio immediately?"
Or even better, have a Daz Studio Manager/Monitor icon in the System Tray, where you can launch new and manage running instances?
Many users will not be aware of the background process and shutdown their computers after they are done with Studio: are they at risk of data corruption?
Then add a "Close Daz Studio and shutdown my PC when ready" option to the aforementioned dialog.
I'm not trying to bash the dev team, just suggesting stuff. Adding a dialog like that would probably be a breeze for the devs who built Studio.
Probably wouldn't have a major effect, but an option not-to save those every time when closing DS would be nice
I don't think .07 seconds will make a noticeable difference.
IMHO, the time stamps in the log don't tell you the truth, at least with the warnings they don't.
You can't, you need to open up a ticket and hope they give you one...
In the very first post in the general release thread, I posted that people should back up their previous versions before upgrading, as the majority of users never do and then end up wanting to roll back to the previous version, which they can't.
In this case the process seems to be single-threaded, implying it is in the foreground thread. That means the messages to the log file are synchronous. So far as I have been able to tell these timestamps are accurate. The time stamps do always seem to increase monotonically which is suspicious; I can believe that warnings from Iray report the time of the write of the message, not the time of origination.
I closed the background thread at least 50 times without any drawbacks or damages. By the way I do use the scrit to open several instances. This script also only works when the background thread has been closed.
Use the script to create one or more additional DS instance shortcuts, so they are ready for use.
Any word on when the Private beta progress will be moved over to Public? The update to iRay and functioning pose tool changes sure do look mighty fine.......
Or launch DAZStudio and never use it; instead just run the script (attach it to the menus via a custom action) each time a new DAZStudio is required. This has the additional advantage that UI settings can be changed in the "launcher" DAZStudio and will stick (after a relaunch of that DAZStudio). Startup of the instances may be faster too, it certainly shouldn't be any slower.
I'm kind of confused, have been trying to downgrade from the 4.15 beta to the 4.14 one, but it doesn't seem to work somehow. DIM tells me I have the 4.14 beta installed, but when I start the program, it's 4.15, on the splash screen as well as in "About DS". Is there a trick to this somehow? Help would be much appreciated!
EDIT: Okay, I managed it somehow, I think the reboot in between uninstalling 4.15 and reinstalling 4.14 did the trick.
I submitted a ticket for the opacity/volumetrics issue. They replied quickly and apologetically: 1) there is no other version of DS they could give me, and 2) if it only happens when rendering then it would be an issue with the update to the NVIDIA Iray Render Engine that was given to them by NVIDIA. They also requested screenshots to pass on to the developers.
Since it also occurs in Iray Preview and not just when rendering, I did a very quick test last night with Render Studio 2.0 and one of RSA's billboards, similar to Sevrin's test. I submitted them and an HDRI render to show that the billboard displays correctly (no border around it).
What is the point of launching another instance of DAZ Studio when the previous instance is still using both VRAM and system RAM until it exits?
Next instance is going to have less resources to work with, it's a workaround, not a fix for the problem with slow GUI element list traversal and destruction which I documented in the thread already with VTune Profiler.
DAZ Studio developers should really sit down, do some code profiling on their own, and don't do any other changes on the code until they fix this -- it is embarrasing to have such an issue for so many versions already.
It isn't a fix for a problem, it's a way to allow users who want to run multiple instances.
Yeah, this sort of functionality exists primarily to serve the needs of prosumer/professional users with high VRAM capacity/multiple GPUs for whom parallel processing (eg. prepping scene 2 while scene 1 is rendering in a separate window) workflows are a must.
I run multiple instances at once. No problem so long as I don't do dForce or Iray rendering in more than one at once. I avoid leaving the viewport in Iray mode and before I do this while another instance Iray rendering I check that the GPU has enough memory (VRAM) spare. Some of my scenes run to 15GByte of DRAM and I quite deliberately don't have a swap partition but I consider those big scenes; no more than two at once. With those scenes I will sometimes end-process DAZStudio because simply deleting everything in the scene (the fast way to exit) takes several minutes.
Filament helps a lot. Now that I've worked out how to tweak the "Filament Draw Options" settings to match the Iray preview I can use Filament to do expressions and, now the scaling bug has been fixed, set up HDRI backgrounds; both impossible in the Texture viewport mode.
My typical DRAM usage for a simple scene maxes out at 8GByte, roughtly 2GByte per character plus whatever the scene requires. Strand based hair in close-up maxes out my GPU (12GByte) so that is an unfortunate limit; I would be better off from every point of view with two 3070's rather than one TitanXP (which is what I have), but I'm not going to do that until the 3070's start getting sold for the NVidia list price!
So far as process exit is concerned normally I do delete everything in the scene before closing DAZStudio. I don't re-use DAZStudio instances for different scenes, it's a waste of time; I delete everything in the scene, close DAZStudio and open a new instance. Scene load time is so long that by the time I've loaded a new scene the old instance has exited. An exiting DAZStudio holds 2GByte of VRAM for a while (if Iray has been used in the instance) but it is released early in the close-down. DRAM usage decreases linearly with time and so long as the scene was empty it is quite fast, faster than loading an existing scene. (Often I open a new scene before closing others because of this...)
I've become very careful about leaving "Render To Window" windows open; the GPU memory is not released until the window is closed or saved. Sometimes I'm rendering iteratively while trying to work out a good Render Quality setting (I often start off at 0.1 - that was my default for a while), but I save the renders by copying r.png and, if required, the canvases from the temporary directory then resuming the render at a modified Render Quality and just work with one window at once.
We know a lot more about the load (scene and character) issues, see:
https://www.daz3d.com/forums/discussion/466376/what-can-we-do-to-improve-the-long-load-times-of-characters#latest
In fact the CMS work rounds in there do also benefit the DAZStudio close time, but I haven't measured by how much. My test scene towards the end of that comment series is a 15GByte scene. I've yet to time a "raw" close, where I do not delete the entire scene first, but I know that even deleting everything in that scene takes a long time, unacceptably long for me.
Some efforts have clearly been made; there are extra time logging messages in 4.14/4.15. Unfortunately it is a memory-thrasher as you established; close down time is critically dependent on the order in which items are freed, as clearly demonstrated by the delete-the-scene workround. I've had Intel engineers staring over my shoulder trying to work out why on earth a program faulted at a particular place, those guys drove back down to San Jose with VTune profiles akimbo but they still couldn't help; these problems are really hard. This is why I keep suggesting the Doctor's Solution; rather than trying to fix something avoid doing the thing that causes it ;-)
G8F with Underwear GeoShell at 6000 Xtrans
@DoctorJellybean Hmm... what is the Geometry mesh offset?
I presume it must be considerably larger than 0.010-0.020 since it is supposed to appear over instead of on skin.
Do you happen to have any others that sit closer to the figure (perhaps wet skin or dirt geoshell)?
Also, can you please test with negative Xtrans?
Somewhere, maybe in the 4.14 threads, an issue was reported whereby geoshells at sufficient distance show this effect. Some work may have been done to fix it but it is easy to produce an example of the same effect
That's G8 basic female at -8000 from a camera at (0,120,120) Y rotated 89.15 degrees. The G8F has an Iray "flat paint" shader in red and the geoshell the same in green. The mesh offset is .01. It's a Filament render, the effect does not show up in an Iray render with those settings. Minor movements shift the polygons massively, changes in the drawing algorithm do to; this is texture shaded:
My impression was that the original report would repro even if the camera was close to the figure, just so long as they were at a large scene offset. The effect disappears if the camera is axis aligned, it also disappears for me at a focal length of around 250mm; i.e. if I viewport-zoom the camera in and decrease the focal length appropriately (it starts out as 10000mm) the effect in texture-shaded disappears then. It disappears earlier in Filament and I can't repro it with Iray. The math accuracy requirement in the first shot is .01/10000, i.e. 1E-6, the math accuracy of IEEE FP16 is about 6E-7. It isn't dependent on positive or negative X but may depend on a camera/viewport transform that has to do math on (x,y,z). It's difficult to fix this kind of thing, the work round is to either remove the geoshell or increase the mesh offset.
UPDATE: I can get it to happen in the Iray viewport with a geoshell offset of 0.001 and in an actual render with an offset of 0.0001, but it may actually be some subsurface details of the shader I used:
The offset in the original example was 0.10
I repeated it with a wet skin GeoShell, same XTrans. The offset on the left is 0.030, and on the right 0.040. It is down to floating point precision, which is very tricky especially off world center.
Floating point numbers have a specific size, a specific number of digits on either side of the decimal point, that can be used to represent a value. When the value is so small or large that it exceeds the boundaries of the value it can represent, the number is rounded/truncated to fit within the digits available. This causes numbers beyond a certain value to be represented as the same number... that is, a loss of precision.
The center of the world is 0.0, the further away from the center of the world you go in any given direction reduces the amount of available space (of the number) for a given value based on that position to fit within.
@DoctorJellybean I am well aware of floating point number system limitations, however I think that this may still be a bug because I don't remember this being the case in older DAZ Studio versions.
Also, even if you use 32-bit floating point values, adding large and small numbers (i.e. 5000.0 + 0.02) still introduces much smaller error than it is apparent from the scene (error is introduced at 5th digit past the decimal point).
In other words, this shouldn't happen, and it breaks DAZ3D products such as city environments where you can't position your figure with a geoshell where you want because of this and increasing the mesh offset introduces unwanted shadows for partial geoshells that don't cover whole skin surface.
Here's a link to my most recent explanation post on Shadow Acne (what the root phenomenon behind these kinds of anomalies is called) in Iray/Daz Studio, both on what it is and how to manage it. Imo it's quite probable that recent minute tweaks in Iray's inner worknigs would result in it manifesting more or less under certain conditions. However the methods for dealing with it should remain the same.
In short, move your figures/camera to their desired locations and then play with the Iray Instancing Optimization control (set it to something else, then set it back) to brute force Iray's internal coordinate plane to reset for that new camera location. Apart from Daz's developers adding a button somewhere to trigger the Iray API "set_dirty" API method (mentioned in the linked post) palying with the Instancing Optimization control seems to be the only way to manually effect it.
What was the camera x,y,z for the image you posted? I couldn't get a repro in Iray without a large camera offset; I suspect Iray may be re-centering on the camera before rendering which is a reasonable approach to handling spurious floating point errors.
I just selected the figure and left clicked View:Frame.
That moves the camera in x,y,z, though sometimes I am at a loss to understand how; I've done "frame scene" on a characters foot and ended up on the moon.
Nevertheless I agree with @johndoe_36eb90b0; after doing a "frame scene" with the result you posted, assuming the camera focal length is reasonable, a render should not show FP errors regardless of the actual offset of the character and the (co-located) camera.
I tried my "group" trick on my test scene but it didn't work. It looks like the camera and the figure are moving apart as the group containing both are translated (at least in the viewport). This is really weird.