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
Scene load time seems to be the sum of the time to load each thing in the scene. For me this is dominated by character load time and the time to load the scene is pretty much equal to the time to load a character times the number of characters. This is why I'm still tempted by the per-scene CMS set; it's a PITA setting it up but once it is set up time to re-load the same scene should be substantially improved, better than the factor of 5 I get at present with my fixed subset. This also helps a lot with creating keyframes in animations and that is something I do a lot so that is a real plus for me.
The time to close DAZStudio also seems to be a function of the number of characters in the scene when DAZ is closed, but it's often not a simple multiple - I have scenes with 5 or so characters that cause DAZStudio to take a lot more than 5 times the close time of a scene with a single character. The work round for this is to delete everything in the scene (which is typically pretty fast) before closing DAZStudio.
jbowler,
Thanks for doing this and for sharing it and again for the information on the other thread. I would share that you are far ahead of me. Your analysis indicates that you have already implemented a sophisticated directory management strategy such that you have isolated G8F. I still have DAZ/Poser, V4, G, G2, G3FM, G8FM and G8.1FM content somewhat blended. I do have some level of segregation. Very roughly: Evironments and Props are separated (164GB), all characters (the entire people sub-folder) as a group (580GB) are separated from G8F characters, G8F characters {125 characters} (plus characters I have retained only for their MATs {27 characters}) (167GB), G8F Retired {28 characters} (8GB), G8F AFE (2GB), G8F Extra Grafts (Kitten+) (0.3GB), G8F Extra Morphs (0.3GB), G8F Pose Set Expressions (0.1GB), G8.1F (0.4), G8.1M (0.0). My entire strategy was focused on identifying (G8F) products with large numbers of morphs, deciding if I used them a lot, a little, if they were duplicative etc etc, and categorising. Somewhere I have data on roughly the number of morphs in each prodiuct etc - about 40 pages of drivel. The objective was to improve G8F load times. While the other stuff above might reflect a poor overall data management approach, I do not believe (other than perhaps app start time which really is not bad) it was impacting the long G8F load times. After what was weeks of effort, I cut my G8F load times by about one half. Not a good ROI. Like you though, I identified the largest area for potential improvement is in characters and that I could still significantly improve my load time and overall DAZ Studio experience by more aggresively reviewing what characters to retain and what to retire. (My retained to retired is roughly the opposite to yours so clearly you have been more ruthless... and more successful.)
The information you shared in the other thread has caused me to realize I was not taking advantage of the functionality of either the Content Directory Manager or the DIM. My challenge now is to implement an approach some what retroactively (ie without breaking anything). I think I have my eyes open enough to better organize content going forward but it is my existing/older? content that might be an issue. (?? For what ever reason I spend a lot of time converting V4 clothing for use on G8/8.1F as an example so I would not be a fan of 'starting over'.??)
Thanks again.
Been following (and advocating for others to follow as well) the practice of limiting currently installed content to just core Daz Studio components, universally useful things like plugins, and stuff used in scenes/projects actively being worked upon for at least 5 years for the exact reasons your tests indicate.
Fun fact - Daz Install Manager has functionality built into it to enable just this sort of operation (and has had it for at least all the years I've been paying attention to such things) If you go to the DIM Install tab, hit the checkboxes next to some of the items listed and then right click anywhere, you will see that the last option available is called "Export Selected as CSV..." This allows you to preserve a list (in CSV format) of all the content packages needed to eg. load your most recently completed scene/project. Thereby freeing you to uninstall those items in DIM (to enable speedy development of the next scene/project on your docket) without having to resort to time-consuming detective work to determine which no-longer-installed packages are needed to get that scene open once again at some later date. Just make sure to keep all your not-currently-installed DIM install zip files in your DIM downloads folder. Then right click in the "ready to Install" DIM tab, select "Select Package(s) > From CSV File..." and point it towards your saved CSV ffile. You will get a recreation of those item selections (minus anything already currentlyinstalled) ready for one-click reinstallation.
A coule of questions to confirm. Please confirm this will work offline, I am assuming, because the not installed content is in your downloads folder, this is the case; but, I would like to confirm because my DAZ Studio system is not usually connected. (I think I am also assuming that DIM's Ready to Install tab reflects content in your Downloads folder not already installed. I've not noticed but when I uninstall content, that it is still in Downloads, does it repopulate as Ready to Install.) I also think you are saying that after you make a scene, you go to your installed content, identify everything in the scene from the installed content list (checking them off) and then export as a .csv. I assume you are naming the .csv similarly to the scene and saving it with the scene or some other regularized location. Then, prior to opening a scene, you go to DIM, select the Ready to Install tab, rmb click anywhere, ... select your .csv that is associated with your scene and DIM will identify anything not already installed that is used in the scene.
I have a lot of non-DAZ content (and have manually installed almost everything I could over the years) so anticipate that as limitation one for me. And, I have had a number of hardware and operator meltdowns (including regular deleting the contents of the Download folder as a Disc Mgmt Strat) over the years. I don't think my UI, with the DIM, in any way reflects what I own or where it might be; so, I anticipate this as limitation two for me.
Let me know if I have followed your approach correctly and if these are accurate limitations as I might attempt to implement it, Thanks.
Yes, absolutely no internet connectivity required (just check work offline when you first start DIM.
Yes.
Yes, that's exactly how it works.
Yes. I'm a digital media professional, and every project I work on eventually ends up filed away in a separate folders on a large NAS/remote site backup service(s) I have setup for just that purpose. It's the smart way to operate especially if what you make makes you money.
Yeah, that's it exactly.
To many a person's shock and surprise (certainly mine when I first realized this), Daz designed DIM to be completely compatible with content originating from other stores/homegrown assets. And even went through the trouble of thoroughly documenting the steps required to make a non-Daz-store native collection of content DIM friendly.
The short explanation is that your content needs to be saved in a normal .zip file with specific naming/directory tree layout convention in play (again, all explained in the documentation) and a relatively simple to generate metadata file or two in the root folder. For quite some time there has been a pigeon industry of no-frills paid/freeware apps that automate almost all of this process for you (eg. this one on the Daz store itself) maknig it virtually a breeze to make any (and I really do mean any) non-DIM native content fully compatible.
Speaking for myself, the very first thing I do after I acquire/make/etc a new set of file assets for use in Daz Studio is to generate a DIM formatted install file and keep that permanently archived in a folder along with all the other orginal attribution/documentation/content payload files belonging to the collection. Disk space is cheap. And being able to instantly call re-call up content without too much technical monkeying about is essential to having a productive creative process going.
Thanks so much for the reply. I read up on the Content Package Assist and watched a good video (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjiwuLuwZ_vAhXiGFkFHaYCA5UQwqsBMAJ6BAghEAM&url=https://www.youtube.com/watch?v=9FhT-4ewaHs&usg=AOvVaw1pvjOlV0jf0e0nzV_HHlBY) (Cklearly I have no idea how to paste a link in here. . . . . )
I also played with some zipped content and .dsx files to confirm (maybe) how the DIMs Ready to Install and Installed folders use them (at a macro level) and to establish a way to deal with content already installed. I would absolutely need something like Content Package Assist if I did not have zips and manifest files in order to create them or if I already have them I could avoid that step and trick DIM by adding the folders to the Downloads and Manifest folders of DIM. That does not guarantee your approach would work because in my case the content may not be installed where the folder indicates - I might have put the Sveva textures with the LilFlame clothes and not the Materials folder . . . . . or the Clothing folder under Sveva, Sveva-LilFlame . . ., I might have put all dForce clothing in its own folder. . . .
I think, for me to confidently implement your approach: I would need to install everything as per the creator's design and I would need to reinstall all of my content. And as best as I can tell, DIM ccan be told where to put stuff, but it doesn't know where it is once it has put it there. In other words, what I am thinking is, I could use DIM to know what is in Downloads or Installed, and I could use its paths to place the content in various directories. I could use Content Directory Manager to control what directories DAZ Studio might use in any given instant, but what DIM knows as installed and what Content Directory Manager allows DAZ Studio to see could be different.
While your and jbowler's appproaches are not mutually exclusive, I see your approach managing content at the item level while jbowler's approach manages content at the direcory level. Assuming I get good at it - uninstalling an item, creating the CA package, loading it into DIM and reinstalling - say five minutes? (no idea really). 3000 G8F clothing items x 5 minutes each = 15,000 minutes or 25o hours or full time effort for 2 months. I am likely to give up before I get that done let alone all my other content. And maybe there's a logic to the coding but I cannot imagine sifting through thouands of entries in the Ready to Install folder to find the things I want to load up at an indivual level. I can certainly see benefits, (attribution, licencing etc) but I am a hobbyist and for me there are two very different problems:
1) how do I manage the content I have so that I get the best enjoyment from DAZ Studio. This I think mostly involves optimizing DAZ Studio performance by restricting hardware load through content limiting. and
2) how do I manage content I acquire in the future to better enjoy DAZ Studio in the future. ie how do I not make the problem worse.
I don't think there is an easy answer, and it's like painting the wheels on a moving train. . . Lots here to think about and I thank you both.
Yeah, trying to retroactively bring installation scalability to a runtime library that's been custom modified by you to make more sense. Aa very tempting prospect I know - actually originally operated this way myself back in the mid 2000s when I first picked up Poser/Daz. Only didn't end up today with huge unmanageable runtime libraries due to work/school having caused me yo take an extended hiatus from 3D art production almost entirely through most of the 2010s. At which point, DIM was already a fully feasible solution.
Pretty much. It is a huge undertaking I know if content collecting is something that you've been doing for a while. But it is really the ideal solution if keeping content usable and accessible is important (it is only a matter of time before some texture/geometry file buried somewhere deep in that one monolithic runtime develops a legitimate file error that only a runtime file structure reformat can fix. In which case you are pretty much screwed unless you can separately reinstall the different items present in your library.) And the unfortunate fact is that the longer you wait to start doing it this way, the more time/effort it will take to make that switch.
The primary organiziational purpose of the Manifest files in the DIM system is to track file locations for both installation and removal of content packages by DIM (Daz Install Manager.). This of course is predicated on the user not messing with file/folder structures in the install locations. Using DIM to manage your runtimes shoudl be an all-or-nothing affair imo. That doesn't mean you can't customize where things go, however. You just have to do that customization to the content itself before it gets packaged into DIM format (for eg. native DIM content just extract the zip itself to a temp folder, change things how you want, and then re-package it with eg. "Custom" added to the end of the DIM file itself - fwiwi here's a free DIM maker tool to complement the previously mentioned paid one.)
Most definitely. Using Daz/DIM to manage your content is actually an extremely open-ended solution. The most important part is that you pick a particular way to go about things and then stick to that at all times.
My general advice to anyone facing this sort of conundrum (years of content collectively installed to a handful of monolithic Runtime Library folder trees which are progressively leading to DS overloading and nightmarish corrupted/missing file scenarios) is to do the following:
Doing this really won't end up taking up as much time as it may seem (myself I've actually foudn the process of going through my 10+ year old back catalog of 3D content to make it all DIM friendly to be an excellent exercise in reminding myself off what I have.) And you will really appreciate the time savings you will end up with down the road in terms of content management if you stick to it.
Why do faces look lighter in 4.15? I'm using the 4.15 beta alongisde 4.12.0.86 and the first thing I noticed is that as soon as I bring a scene in from 4.12 to 4.15 it looks like the faces are lightly powdered in white? Whats going on? If I reopen the scene in 4.12 everything is normal, but if I try to render in 4.15 the face is noticeably whiter/lighter than the rest of the body. Also what the heck are these tonemapper and environment nodes? Can I safely delete these?
Is it just me or when you deleted figures or objects from the scene they still hang in memory because no matter how much I clean the scene even to void, the ram usage remains the same.
Thanks again for this.
Do I understand from what you are saying that through the manifest file that the DIM knows what specific directory into which specific content has been installed.
With respect to your suggested way forward, have you, or anyone else perhaps, tried what you have suggested but run a 'newest' verion of DAZ Studio associated with 'cleaned DIM content/runtime' along with an older DAZ Studio poniting to older runtimes. I am suggesting this as a temporary situation and as a modification to your step 4 above.
They go onto the undo stack, as they did in 4.12 - the only difference I can see is that a load could not be undone in 4.12; it was necessary to delete the item which effectively made the undo stack useless... If you sit on the timeline and do first frame/last frame repeatedly it will eventually eliminate everything else from the undo stack, that might free up memory. (Until DAZ Productions fix the bug that simply moving about the timeline adds to the undo stack...)
If you delete everything in the scene you can close DAZStudio and it will actually close very fast (compared to the time it takes to close if you don't delete everything first), then you can restart with lower RAM usage. If you keep working DAZStudio will eventually delete the undo stack (it is very small for a modern program) and then the RAM will be available for re-use. Unless DAZStudio has implemented its own memory management pools (which is not too hard with Qt) it is unlikely that the RAM usage will drop significantly until everything has been deleted. I do see that the RAM usage does, eventually, drop if I have a "huge" scene (at least 5 characters) and I delete/open a small scene, however these days I just use instances so that I don't have to wait for DAZStudio to exit before working on a new scene.
Yes. Each time you install something through DIM it automatically copies the "Manifest.dsx" found at the archive's root (containing descriptions of each and every file/folder contained therein) to the Maifest Archive location (found in DIM settings.) This is how DIM populates the list in the Installed tab - it jsut scans that directory for .dsx files at first run and lsits what it finds there. Uninstallation is then just a matter of DIM go through the product's Manifest file, deleting all the files/now empty folders listed there, and then deleting the Manifest file from the archive. Hence why you can still uninstall packages even if you've removed the original installer from visibility in DIM's Downloads tab.
Good point. Thinking back, I'm pretty sure that when I first started doing this iI ended up using independence of the beta vs final DS releases to facilitate just that. Another way you could do it is (if you have more than one DS capable computer) to start over from scratch with DS on a different machine (with the bulk of your uninstalled content stored on a shareable network or USB drive somewhere) and build up a separate DIM-standardized install base that way.
The "Tonemapper" and "Environment" [Options] nodes contain the settings from the corresponding panes in the render tab. The "Filament Draw" Options node contains the settings from the Filament "Draw Settings" pane. Deleting them in 4.14+ does the same as pressing the "Default" button on the relevant pane did in 4.12.
Check your "Render Settings" tab in both 4.12 and 4.15. Look at the "Advanced" pane; it should be "NVidia Iray" because that is the default. If it is you need to check all the sub-panes, "Hardware", "Canvases" and "Bridge" in both; they can be changed independently and aren't completely properties of the scene. Make sure they are the same. I think the "Defaults" button still works on the Advanced tab but I haven't checked that and I found the 4.12 behavior weird; when I loaded a scene it sometimes seemed to retain some of the settings of the previous scene.
Then check the "Render Settings" "Editor" pane and look for anything which is not the default. (Assuming you aren't in the habit of changing the defaults, as I am; if you do it is necessary to be much more careful...)
It this is all fine or the face/torso distinction still happens after making both versions have the same settings, I suggest posting renders of the neck from the two versions; someone here may be able to guess at what is going on, along with the exact Beta subversion number (since I think a couple of things might have changed in recent betas).
The beta and the general release have entirely separate content directory settings. They are not stored in any obvious place on disk; I think they are in the Windows registry (YMMV on the Mac).
Both versions store a list of other "Content Sets" in the file %AppData%/DAZ 3D/(Studio 4|Studio4 Public Build)/ContentDirectoryManager.dsx
You may have as many Content Sets as you like and, because they are stored in a file, it is possible to generate them from the DIM "Content Path Shortcuts" list to be found in %AppData%/DAZ 3D/InstallManager/UserAccounts/Account.ini
As a result it is possible to swap between different instantiations of your DAZ installation even with a single instance. If you run instances with -instanceName your Content Directory Manager set is not stored. So you can use -instanceName to run a new instance of DAZStudio (i.e. a new instance of exactly the same version) with a different CMS configuration (including, I believe, totally different) just by selecting a different "Content Set" in the content directory manager when you start. (BTW I have not test this in detail, but I just ran a second instance of the beta, swapped to my "Everything" content set and all the smart-content icons showed pictures rather than my standard warning triangle expection).
The big annoyance here is the CMS itself only knows one world; so when I de-configure my content the CMS still knows about the now missing stuff and Smart Content displays warning triangles. @RayDAnt's suggestion of using multiple machines would avoid this, but it can be helpful (I can see instantly what isn't installed...) I don't know what happens if you have the same content installed in two places.
You folks are very generous with your information and time. Thank you. I would have to admit that while I have been playing at this for some time, I have not been under the hood to the extent you have.
I am trying to recall, and might be mixing up Poser time with DAZ Studio time, but I specifically recall persuing the instances thing as a way to improve concurrent activity. I even tried different render engines until I couldn't afford it/justify the cost as a way to get 'round the 'blocking' thing. Maybe at the time it was a hardware tlimitation or maybe an operator limitation. . . .Anyways, I was surpriised a couple of days ago when jbowler mentioned instances. . . . Since then I have implemented the desktop icon suggestion and the script option found in a release thread for 4.12 (I believe) here. After very limited testing, and I think you are saying this in more technical terms, I can confirm if you use the desktop shortcut option (created as suggested) your new instance will 'copy' all of the 'preferences' of your open instance. But if you use the script and name your instance, when you use the script again you can open your named instance with the 'preferences' as per how they existed when you saved it. Lesson One!
I think I can likely find threads here and/or elsewhere, and honestly it could be old news, but they specifically said not to install content directly to your runtimes. So, for years, I have been dutifully unzipping content elsewhere or installing content from DIM to 'ghost' directories and then moving it into my operational directories. There might be strong advocates on both sides here. I can certainly confirm, after a day of looking at (specific content names and item counts) the various tabs of DIM, the DIM Downloads folder and the ManifestFiles folder that my approach has made the functionality of the DIM almost useless to me. I have learned how the various tabs of the DIM are populated and what a Manifest file contains (how it records the installation path of content), etc etc. Lots more here to understand. Lesson Two!
I think I have three activities:
1) Sort DIM before installing anything new or reinstalling existing
2) Install anything new using the DIM (much of this will likely be offline. . .)
3) (re) Install old/existing using the DIM creating packages if needed using something like Content Package Assist. (again offline. . .)
2 and 3 can be concurrent and ongoing but likely should not start until activity 1 is completed. There are likely a number of steps to activity 1. I have established, at the name and count level anyways, a relationship/coincidence between the DIM Downloads folder, ManifestFiles folder and the DIM tabs. (There were outdated application versions, name changes to content etc to resolve.) Next, I want to confirm that what is installed via the DIM is where the DIM thinks it is. I suspect this might take another day or two and may conclude activity 1. Activities 2 and 3 will be a little more daunting and I have not quite decided on the directory structure I will use for it. Thanks again for all your comments and suggestions.
I suspect all the load time is going building the UI; the "Parameters" tab for a typical character on my system has about 7500 slider widgets on it. That is a fantastically large amount of Qt UI for a single pane. We already know from the previously posted VTune analysis of DAZStudio shut-down time that the time is spenting unlinking QObjects before DAZStudio closes; the VTune analysis shows the Qt (not DAZ) code for unlinking signals at the top of the instruction prefetch fault list. Each widget has multiple sub-widgets; a QSlider, an input box, an icon, four buttons which evoke drop-downs. At a guess that could easily be 20 QObjects per dial and each QObject has quite a lot of signals.
As has been suggested delaying the instantiation of the dials is the only obvious way round this without changing the UI completely but such delayed instantiation is itself a lot of work. It has also been pointed out that Qt4.8 was known to have performance issues with QObject deletion because of the way the signals are unlinked and this is supposedly improved in Qt5 (this is from the Qt discussion lists, not the DAZ ones.) Certainly this is consistent with my work-round for the shutdown time.
A single character seems to produce a minimum of three dials, e.g. Rana, Rana Head, Rana Body. Some characters produce more, for example Zelara 8 gives me Zelara 8 Spine Interaction HD, Zelara 8 Body, Zelara 8 Body HD Details, Zelara 8 Head, Zelara 8 Head HD Details, Zelara 8 Alien HD Details, Zelara 8, Zelara 8 HD Details. That basically 3 for Zelara 8 but 5 for the Zelara 8 HD add-on.
It isn't quite a a simple as load time being proportional to the number of dials; expression packs add a lot of dials, accounting for 1144 dials total for Pose Controls/Head/Expressions in my system, but poses+expressions only seems to add about 2.5s to my load time. It is, however, very likely that the QObject creation time is not linear in the number of QObjects created; indeed that was part of the problem identified in deletion. Consequently it is conceivable that load times with lots of characters may magically improve with Qt5 or, indeed, Qt6.
There is a lot of time taken building all the (internal, not UI) links between properties - the increase in load time with incerased properties and relationships bears witness to that.
A slight correction -- DIM doesn't just copy the manifest.dsx, it takes the info from that file, and from the [productname].dsx in the downloads folder, and adds the info about where that package was installed. The .dsx file it puts in the Manifestfiles folder contains all three sets of information.
I don't know much at all about these things, but I'm wondering if it's possible to load just some of the characters. For example, if under Characters in the My Library folder I have Genesis, Genesis 2, Genesis 3 and Genesis 8, is there a way I could make a set just for Genesis 8 (or Genesis 3)? Then, if I loaded just one version of Genesis, would that cut down on load times?
This doesn't help; see the last two rows in my table for the load of a G8F. The first but one row is with all my G8 content, basically 90 seconds. None of my other content was visible to DAZStudio. The last row is with all my content, basically it took 90 seconds (there is less than half a second difference in time between the two loads, and this is within the error limits of my timings).
Only G8 related content has a significant time on load of a G8 character after the first load. Indeed only G8F stuff affects G8F and only G8M stuff affects G8M load times. The really annoying thiing is that a lot, perhaps most, of the time is down to the number of G8 characters; each new character causes a slow down on all the characters. This is because DAZStudio treats characters as morphs; you can morph any combination of characters you like. I know PAs do this a lot to show how their new characters will happy-morph with the DAZ base characters, but I never do it; if I want to change the shape of a character I use one of the morph packs. I'd like to be able to tell DAZStudio to ask for morphs to be enabled if I start to use them, not have everything enabled automatically.
It is possible to build a scene starting with pretty much nothing available to DAZStudio and just adding things as required, but in practice that means separating things like characters into groups and even moving them around using DIM while developing a scene.
Daz3d has got to be the worst program ever made, the mouse keeps disappearing, i cant find content i bought last year, and the [dratted] panes keep uncocking and disapearing [what on earth] is going on i am about to uninstall it forever
This is an issue that affects quite a few people - it often seems to be associated with clicking both left and right mouse buttons together. As I recall a way to fix it is to use the UI feedback to get the invisible pointer over one of the Viewport navigation buttons and drag on that.
installed how? Where are you looking? The Content Library pane under Daz Studio Formats/Poser Formats shows how content isa rranged on disc and doesn't depend on metadata.
Perhaps your interface files are becoming corrupt - do you force quit Daz Studio through the Task Manager? Once you have the panes as you want them, Window>Workspace>Save layout will let you store a snapshot of the state; do that, ideally under a new name, any time you put work into the configuration.
Does it really not affect you @richard? I.e:
Left press-and-hold on the viewport "View Pan" button; observe that there is no cursor and if you move the mouse toward the center of the viewport it pans. Now, without releasing the left mouse button, right click (press and immediately release) the right mouse button. Now release the left mouse button. Does the viewport cursor re-appear for you?
Yes, but I've never had it happen by accident.
It has to be the "View Frame" button and it has to be a right-drag; a left drag or right click doesn't bring it back.
Easier is to navigate over one of the view controls with a drop down menu (any of the three at the top) and left click. There is no fix with a conventional mouse; it won't happen if your mouse doesn't have a right button ;-) Nothing else in the DAZStudio window works.
The Easiest Recovery Of All is to shut down and restart DAZStudio, because this can be done from the keyboard.
Hi All. Hope everyone is healthy!
I want to say thanks and great work to DAZ on this latest v4.15.0.2 General Release. I really like DS (and DAZ) but just cannot handle 'experiment-ware'. To have a stable version with the latest generation rendering power is very well received. Cheers, Don
Been on v4.10.0.123 forever now since it has been extremely robust. For ArchVis work in UE4 I purchased a new computer and DAZ gets to tag along for the ride. =) I am posting with some info in regards to DS Pro v15.0.2 (General Release). Hope this helps others as well.
Firstly: v4.12.0.86 (and a couple v4.11.#) worked but they had strange bugs with the fitting tools. I mainly use DS for the nifty fitting tools to help save time in Blender. v4.10.0.123 was amazing in both the mesh tools as well as putting out solid renders via IRAY. I am not using any DS version for animation so I cannot really comment.
TLDR: DS v4.15.0.2 is very stable and I have had zero crashes and have opened up my v4.10 dufs with no issues. As far as I can tell I am on board with this.
Computer (the new one)
Installation that worked perfectly:
Back Up your DAZ directories. (I use and highly recommend GoodSync for this)
Download and Install DS v4.X:
- Don't use DIM or DAZ Connect
DS v4.15.0.2 Details for folks who want to know what I tested:
Hope that is good information and helps others that want to know if this latest version is stable with the latest gen CPUs and RTX 3000 series GPUs. I understand there are many variables but I certainly had many strange issues with 4.11/12/14 versions. In my opinion this latest release is a winner!
So far I haven't been able to do much in 4.15, since it crashes just while manipulating a character, ones that I had no problem with in 4.12.
Fortunately I still have 4.12 installed on my other machine, so I can still render. Hopefully they can stabilize 4.15 soon.
Hello!
Is there some way to roll back to Daz 4.12? There are just too many bugs in 4.15 for me to fix for a new 2TB desktop computer w/NVIDIA/AMD. If you go to the Welcome to Daz Studio page it even references Daz Studio 4.12. I am finding that Daz Central does not download my items as it should and I have tested a few to see that if an item is as old as 2018 it is not pulling in the Metadata with Daz Central or it directs me to the item log. But from my test I opened an item I purchased in 5.6.2016 and it opened just fine. I am highly confused.
This is the message I get when I go to the log file.
Penthouse Living Room
This is a placeholder for the product Read Me - this product has not yet been publicly released. Keep an eye on the New Releases section of the DAZ 3D Store for the product to become available, then check back here for more information.
Hence, I bought this product on 5.13.2018. And have used it considerably since with 4.12 version and as recent as 8.2020. And yes, I have selected update metadata also.
I have 4.12 on my laptop and I am constantly goin back to my laptop. What is missing in version 4.15?
The Penthouse Living Room message is obtained from the Documentation section in the server, and this is the ReadMe page for that set
http://docs.daz3d.com/doku.php/public/read_me/index/50283/start
Re the missing products, you may want to try DIM.
Are you sure that's the log, Help>Troubleshooting>View Log File, not right-clicking on the product icon and selectiogn More Information (or just clicking the icon at top-left when you are inside the product in Smart Content)?
I'm not clear on the issue - are the products showing as not isntalled at all in DS, even though they are installed through Daz Central/Daz Install Manager, so that double-clicking one causes DS to try to download it? That would indicate a problem with the communication between Daz Studio and/or the installer and the PostgreSQL database used by the Content Management System.
Also, what products are they and what files are you trying to load, if it isn't a ttoal installation failure? An error message telling you to check the log file can happen if you try to load a preset (for pose, shape, or materials) without having the base model loaded and selected.