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
3Delight had been rock solid for me, until the day that it wasn't. I've barely been able to finish one render job since. I still don't know why.
To be fair I don't have that good an eye for renderer quality I think. And your info overwhelmed me a bit. I looked at one or two pictures...
I'm really struggling to follow some of the time. Like listening to scientists discussing string theory problems as a bystander, lol. I'm very happy I can use my Daz Studio again after a hiatus of months. I'm slowly getting to know iray now, step by step.
Is it crashing with no message or is there any output on the terminal?
It might be that your 3Delight needs a fresh re-install.
I going to ask some of the 3DL users here if they know what's going on with 3delight.com being down.
I hear ya.
I've been hanging on on the Awe Test track forum where the real Daz 3Delight experts hang out. Trying to learn more about Wowies Awe Shaders (which are still a work in progress).
I can hardly follow most of it.
But They're all very approachable and helpful there.
I ocasionally post the same scene in Iray, 3Delight and Awe (and ocassionally Lux) - A fair number of people point at Iray as being the best (although that was never the reason for the comparison) due to the light. I prefer 3DL for D&D style fantasy scenes - mainly cause they bring back memories of going into book shops for reading material and seeing all the cover art.
Hi
My computer just almost ran out of memory. It was swapping so hard that the mouse pointer froze or could barely be moved. I avoided a kill of Daz Studio (which was rendering) by killing some other apps quickly. (I took a quick screenshot of top, which is attached (sorted by memory use)) But my system is quite new, an AMD Ryzen 7 2700 with 32GB. I took one glance at top and knew that Daz Studio was the cause. Do other people see similar huge memory use of Daz Studio? Okay I usually make big scenes, the one I'm working on has several large rooms and a dozen or so characters. But in renders, never more than a handful are visible. I could get more ram -the board supports it- but... really?? Do I have to?
More swap doesn't seem very helpful, only thing it'll give me is more time to manually kill apps, but it doesn't make working with the system any more pleasant. (The storage is SSD, obviously)
@antadev66
According to your screenshot, DAZ has eaten about 23GB of RAM, 49GB is reservation, that may never be committed.
Also you had have some web browser running. It can consume titanic amount of RAM, spreaded by several processes, so no one can see it as it is.
you can notice, that DAZ alone well-fit in your system memory, due to it's memory consumption. But all apps in total had claimed about 46GB of memory — twice as DAZ3D did. Best way to acheve that without being listed in `top` — open a lot of graphical sites (DAZ shop, DA, patreon, pinterest, maybe streaming video) in several browsers.
In your case I can suggest try to use zswap, like described here.
In ubuntu 18.04 I set up kernel parameters as follows: `zswap.enabled=1 zswap.zpool=z3fold zswap.max_pool_percent=25`
It will create compessed write-back swap cache, that never invalidate util exhausted, with up to 3 pages (4096 b for x86/x64 arch), so, in good-compression case it can save to you about half of your ram as ( 3 [compress ratio] - 1 [space to store compressed data]) * 25 [max allowed percent of allocation].
you can play around with `zswap.max_pool_percent` value or try to cut out `zswap.zpool=z3fold` from string (to force zswap to fall back to zbud allocator, that can save only 2 compressed pages, but they may be larger [poorly compressed]).
Also you can change parameters via `/sys/module/zswap/parameters/*` in runtime and grab stats as `grep -R . /sys/kernel/debug/zswap/`
I ocassionally see the system become unresponsive when I've either overloaded the scene or otherwise the system has run low on memory (keeping Daz open for too long, a lot of adding and removing assets to the scene - I'm not sure it's that efficient at freeing memory again). The end result on my system if the mouse becomes unresponsive is after a moment, Daz gets killed.
It's nearly always when you hit render.
Probably not a good idea to load too many rooms that won't be visible in frame - but that can be hard to do, especially in some related sets (Dream Home is a definite offender there, especially with Iray, which of course it predates.
The Scene OPtimizer product from Daz Store can help reducing memory load by reducing texture sizes, you can do this manually with Gimp by scaling each texture map (diffuse, bump, spec etc.) to half size, but even just dropping all texture maps (except diffuse) from background figures can help.
It's correct that you can not, at a glance, see the memory footprint of firefox since it is split up in many threads: All "Web Content" entries belong to it. And yes I have many browser windows open, each with many tabs. That notwithstanding, DazStudio has, on its own, claimed 67% of physical RAM. And the top screenshot was taken a couple of seconds after killing geeqie picture viewer with a dozen windows, which avoided Daz being killed. Killing geeqie freed up about 5G: I saw that free physical memory and free swap memory was almost zero before killing it. For obvious reasons I had no time to make a screenshot at that time ;) You can still see the remnants of the resource panic from the avg system load dropping from 9.26 back down to 3.31. And sure, I'm not disputing that firefox also consumes between 10G and 15G RAM, but with well over 200 tabs open that is reasonable. My beef is not with firefox.
Heh, that's also a way to look at it, but it's turning the issue upside down. The other half of available RAM, the part not used by DAZ, was used by many other apps and daemons including Thunderbird, Kde Plasma, xorg, etc. Neither Thunderbird nor Plasma are known for their small resource use. So the elephant in the room is still DAZ Studio... not Firefox. It would surprise me if Firefox consumed more than 20%-25% of total RAM. DAZ Studio took 50%.
Hm zswap. So memory compression if I understood correctly. That's interesting to try, now that I have the Ryzen CPU, thanks! I'll look into compiling that into my kernel at the next opportunity.
Exactly. I've been there before, too, so as soon as I noticed the trouble I switched to a vt and killed some other, less important, apps.
Yes but that is puzzling. My nvidia has 6GB, and I've heard over and over that whenever all textures needed etc. do not fit in the cards memory, Iray is unable to render using the card. So if the entire scene must fit in 6GB video memory, then what occupies normal ram in fourfold. That's bizarre, no?
Hm. Okay. At least I should split up my scene and have separate files, each with their own rooms, that should help. I may have pushed the envelope myself a bit and made it worse: instead of closing my scene to load an older scene I needed a figure from, and then export a scene subset with the figure, I loaded the entire older scene into the current one using merge, and then proceeded to delete everything except the figure I needed. That surely hasn't helped keeping memory use down, he he.
I'll have to try and become more efficient at planning ahead which scene subsets I'm gonna need... 
Lucky you, I either never catch it in time or it gets bad quick on my system - by the time I notice there's a problem the entire ui resposiveness is close to zero.
Thankfully, it really only happens once in a blue moon, I keep to a minimum things running on my system, Firefox with only a handful or tabs, plus I use a Window Manager, not a full desktop.
I'm not certain of the backend pre-processes during rendering, in some situations it's more efficient to bake textures together (basically merging to images).
But then, the vast majority of 3D users usually just do pin-up type images - multi-figure renders, which are more likely to blow the GPU memory aren't that common.
There are a couple of tactics - render in layers, i.e. groups of background chars with the same light but no background and merge the images together in post-work. Another is to save posed and clothed figures as objects and reload later, objects aren't and therefore take up much less memory (you can no longer repose though).
I've found older figures to be more memory saving, which according to many shouldn't be as G8 actually have fewer polys in the geometry than old figures, although they do have more and much larger txture maps. G8 can be quite stable on Wine, G3 and G2 a little less so, G1 almost as stable as Generation 4s.
antadev66
Sorry for this, it was just guessing. You are absolutely right about FF and other stuff.
I will be glad if it helps, really )
But keep in mind, that memory compression (zswap or zram — another way to have compressed data in-memory, with own caveeats and tradeoffs) just may render your system more responsible, but they are still kinda krunch, not remedy. However, both of them can prolong system's operational state and improve responsibility.
I remember reading about such solutions a long while ago. I then dismissed them for deployment because at the time my system bottleneck was cpu-bound. That's now changed.
Adding more swap might help: If you think about it, the time you have to remedy the situation is from the point you notice the slowdowns (ie. heavy swapping) until your swap is completely used up. But if extra ram use is only very gradual it may make no difference, just a noticeable delay between taskswitching. In my case it is often a runaway process, a tab crashing or me not thinking while opening a handful of tabs with 72 megapixel photos...
Ah? Wasn't aware of this trick, that could be useful. In some cases...
I'm lagging a bit, I think I use almost exclusively G3 at this time.
@antadev66
Oh!
In fact, any disk interaction is about losing some CPU cycles as IO-wait. Time, that can be spent to (de-)compress data, as fast as some GiB/s, opposing to several tens MiB/s provided to random access by ssd or thousands times slower by hdd.
Thus, if you have to swapping, you mostly always have enough CPU time to compress too.
I've left my setup at 2GB, it's a hangover from my last much lower spec build (I just swapped the HDD and SDD into the new build and mostly carried on) Swappiness is Arch default at 60, but neither system has has ever used anywhere close to the full allotment (as far as I know - I don't keep a monitor on it).
I've gotten 15-18 Genesis 2 in a scene at once (as long as most of them are using the same textures), other times it seems to baulk at three...
Genesis 8 are very similar to G3, the main improvement has been in expression ability - a lot of Daz buyers skip a generation now and then, some are still using Aiko 3 (the oldest Daz figure you can still buy in the Daz shop). There have been a number of really nice G8, but also a lot of figures with limited genetic variance from previous figures - the males especially.
Oh I completely concur. But on my old system I had 16GB and still never ran out of memory. This is new to me, and it's pretty strange. I think the iray rendering has a lot to do with it. But I started making larger scenes too...
trying to find out something. I have 2 computers and 1 will be totally Linux. is there a method for me to send Render tasks to the 2nd computer while I'm still using Daz Studio?
Umm... In my experience: Yes and no. That method is exactly what I used for several years, and I was happy with it. But there were limitations: you had to use the 3Delight renderer. I did not have success with other engines, definitely not iray and also not with Luxrender. So the answer was: yes...
However, that setup started bugging out for me at some point. I never figured out if my library got corrupted with bad files, or that Daz Studio made an incompatible change, but my remote renderer started crashing. Randomly but so often that almost none of my renders finished to completion. It is possible that the update from 4.9.3 to 4.10.0 caused it, but I do not rule out anything else. To add insult to injury, when trying to find an update to my standalone linux renderer I found that that product seems(?) no longer available. In any case, I found nothing that worked. So that avenue became a dead-end for me.
Maybe someone else knows a different trick. I'd be interested myself. But I know of no method. Well except of course, to install a complete Daz studio on the linux computer too (using wine) and render using that copy.
Easily enough with 3Delight Engine by setting the render to Rib and checking Collect and localise (under Render Settings - Advanced). Then copy over the render file and the folder with the render textures (only provided by Collect and localise with 3DL - but you can also run ribdepends, which is found under the Daz Studio folder in Program Files (in /bin).
Lux can do the same by rendering to an Lsi file - it should also write out a folder of textures.
But yep, the standalone 3Delight download page has disappeared lately (although you can still pick the package off of the Wayback Machine - a fairly easy linux install).
Iray is a little more problematic, there's no standalone, the only option is Iray Server, $295 (there's a free trial month) - A little out of the usual hobbyists pocket (IMO).
@GafftheHorse, thanks for your "how to" tutorial. After a week of tinkering and fine tuning I finally have Daz Studio 4.12 up and running in Linux. I'm using Ubuntu 18.04 because it was the most stable for me. From there I can export through diffeomorphic and render in Blender Cycles.
Do you know of any tutorials for getting DForce working?
Glad the tutorial worked for you.
RE: dForce. Do you mean getting it working (on Wine). Or using dForce?
I'm going to assume the former, the Daz forums are awash with good dForce tutorials.
Go to the Simulation Settings > Advanced tab
If there is a message reporting it's unavailable, there's a problem with OpenCL (thankfully, Daz dForce uses OpenCL and not Cuda).
Wine needs the OpenCL libs included with the build, It's possible (probably likely) that they aren't.
I use wine-staging, which includes a tonne of extra libraries and patches, (mostly for windows games, but they also include OpenCL libs). This should be mentioned in the 'how to'. Daz works in (stable) wine, might even be more stable than staging, but without the needed OpenCL libs, no dForce.
As an Ubuntu user, You will need to find and add an apropriate PPA in order to get a more complete (and hopefull up to date - the Ubuntu Bionic version is 3, current is 5.11) Wine package.
Luckily, your next question 'How' if you run into problems with this, try this Linux Uprising article. Ubuntu 18.04 is supported for 5 years, but you'll find it to your benefit to mostly keep to the most recent Ubuntu release as much as possible (a good tip is to wait six months after a new release then upgrade) you should see a much better working Daz on more recent Wine versions.
If you are still having problems with reported unavailable dForce, install clinfo on linux, and download the Windows version(link at bottom of page) - un'zip' and put in your wine windows folder.
Run both and compare the output (I often get Daz reporting unavailable dForce, until I run clinfo on one/other platform quit and reload Daz - seems to wake it up).
Hope this helps.
I tried this with Reality but it's just not feasible. The paths in the file stay absolute, IIRC, and in windows notation in any case. So on a linux system you'll need to somehow fake C:\ paths then, or rewrite all the paths inside the file.
Ah? that could be interesting to look at, if they at least thought of a sane way to collect/access the files.
How did you people (people using linux) solve/avoid the issue of getting duplicate directories in your content library with Capitals and without capitals? You know, like "My\ Library/Runtime" and "My\ Library/runtime" and such shenanigans deeper in the tree, causing Daz Studio to complain about missing files or worse?
If it's the LSI file you are talking about, you can use a good editor to search/ replace the c:\ file paths to a valid *nix path - it is, after all, just a text file. It's a little annoying if you are having to do it alot - but it is feasible.
Easiest option is to sort out the command using sed and pull it out of bash history and run it after generating the Lsi everytime.
I have to do the same when I was using MCasuals MCJTeleblender to transfer scenes to Blender from Daz - it really only needed one string replace action.
Reality is a little too automated and helpful in my view, wanting to kick off the lux engine itself (and of course launching the windows version) - I prefer Luxus, but Luxus has not been updated to use the newer Luxcorerender and only runs on the old luxrender, and apparently, there's no liklihood of an update.
3Delight rib files don't need it, of course, if you run from within the collection folder
Wayback machine most recent 3Delight engine package for linux
I've never even bothered looking into the Iray server free month - the price is a little too steep, so even were it workable.
A cheaper option is renting server time - Daz PA (and PC+ Club Admin) Jack Tomalin has an Iray cloud render service which is quite reasonably priced.
If you install with the Daz Install Manager (not sure about the new Content Manager) - it sorts all case issues out for you - I've never has problems with my Primary Daz runtime - Daz QA and lack of enforcement of folder location rules on the other hand....the old Poser runtime side is bad enough, but there are loads of examples of related products in entirely different paths in content and abundance of folder naming mistakes. I used to report them, but fixes took so long or never seemed to come.
Freebies and items bought elsewhere I install manually and fix issues as I copy over manually
Yes I meant getting it working in Wine, but it's not a big deal for now. I barely have any Dforce outfits, so I rarely use it. Sometimes I use it for blankets or bedsheets, but Blender can handle that.
I'm using Wine-staging v5.11. Luckily everything worked as I installed it. I don't really know how to make separate bottles or anything like that. I'm at that dangerous stage where I know just enough to get myself into trouble.
I used Ubuntu 18.04 because I read that that was the most recent version Nvidia's drivers supported. So, if I upgrade my version now, is it likely to break anything? Right now, the only thing installed is DS, Blender and Steam with a few games. But if I can get everything working, this is going to become my main PC. My Win7 machine is on its last legs.
Official driver support is good - but most big distros carry the drivers even if 'official' support is not stated. So you don't need to be trapped in Ubuntu.
Nvidia's proprietary drivers are required for Cuda and therefore Iray as the technology is proprietary, but OpenCL is Open technology. I would love to dump the proprietary driver for the open Nouveau drivers, even if that meant no more GPU renders, the Nvidia driver is the windows one in a wrapper.
RE: dForce and OPenCL - aside from ensuring you have wine-staging, you also need the linux
Wine can seem complex, but the bottles/prefixes are just basically folders containing the stump of a windows file sytem with softlinks to your Documents dir (this bugs me as Documents used to be just documents, now I have loads of stuff in there Windows 'My Documents' equates to the /home/username folder I really want to sort this out)
Creating a prefix is as simple as
#> WINEARCH=win64 WINEPREFIX=/home/username/wine/Daz64 winecfg
win32 would create a 32bit prefix - I still keep one for the 32bit Daz, just in case - I think it defaults to win64 by default, but it used to default to win32 so I keep that bit, but it might not be important - the important bit is the prefix path, this tells it where to create the new wine prefix/bottle (in this case in a 'wine' folder, create a new prefix called 'Daz64' winecfg is the little control ui (you could used 'wineboot -u' (instead of winecfg) if you wanted to create without running a program after - I like to change the windows theme with winecfg.
Then you just have to specify the same WINEPREFIX value when you want to run a program on that prefix (most linux distros default to a setting a prefix in .wine if one doesn't exist otherwise.
I've quite a few Daz Wine prefixes, as I keep some old Studio versions around
daz64 - the primary, also has the DIM, Daz Beta and Hexagon
daz32 - 32bit Studio and 32bit DIM
plus a number or older versions.
daz64_4.10, daz64_4,11 and daz64_4.12
also prefixes for Bryce and Carrara - I picked both up for couple of dollars in a bargain sale - but neither runs at all usably on wine.
I use Archlinux - it's not a Debian base like ubuntu (package structure would be a little different, also some library paths in /, and it uses pacman not apt as package manager) - but it does have an excellent wiki. Relevent pages in this case wine gpgpu
18.04 Bionic is not the current LTS. 20.04 Focal Fossa is. It's been out since April so any initial problems will have been ironed out. When I used Ubuntu (2009-2014) I used to upgrade at every release, but I generally recommend users who just want a reliable system to upgrade within a couple of months of each new LTS (that's every two years). Nvidia drivers are available for 20.04, and what reviews I've read report small but significant improvements all round.
Thanks for the info. I'm going to get a fresh start working on this tomorrow. I'll keep you updated.
UPDATE: I upgraded to 20.04 and things went pretty well. I've got some network drive issues to work out, but other than that everything's ok.
UPDATE: I got the drive issue straightened out. Turns out during the upgrade, cifs-utilities got deleted. I swear it's little stuff like that that always makes me give up on Linux and go back to Windows. On the plus side Dforce is working now for some reason. ¯\_(ツ)_/¯
Wine itself effectively manages it, setting this property just let you dont mind about linux software too.
There's always a few small packaging anomalies going from one release to another - but best not to stay on an old LTS when there's a new one out. I've heard of problems people have run into when they found themselves on a no longer supported grandfather LTS when trying to upgrade.
Don't sweat on the little stuff - if you ever feel you might be better going back to windows entering "recent windows update problems" in a search engine should cure you. You shouldn't have to do a major upgrade again until 22.04 (the next LTS - then I'd wait til 22.06 to allow it to settle) - Of course, you might decide to switch distros in the meantime - Pop Os is really showing promise, and Canonical, the company behind Ubuntu hasn't been as desktop/user focused since they dropped mobile plans.
I don't think there's much chance of me going back to Windows at this point. Nvidia's updates have pretty much made my GTX 770 unusable for rendering, and my 1080ti is getting more and more unstable. I guess all that would improve if I upgraded to Windows 10, but that's not happening.
So for today's adventure, I was messing around with fire/smoke simulations in Blender. During a render, the GUI locked up, hard. After rebooting, X wouldn't start, just a bunch of horizontal lines. I could Alt+F2 and get to a command prompt, but from there I had no idea what to do. Eventually I decided to try enabling the onboard video (AMD Ryzen). Ubuntu booted fine, so I switched back to the graphics card (GTX 770) and Ubuntu starts fine, as if nothing ever happened. I swear computers hate me.
I'll probably look for another distro once I get a little more comfortable. I'm still in the training wheels phase.
@Kitsumo
More looks like sort of hardware trouble, maybe with 770. Possibly memory (VRAM) issue, or chip (GPU), but may also be a power (VRM).
Most users unable to understand that something goes terribly wrong with hw, until smth ckacks down completely — and it may count couple of years.
It sounds like a hardware fault - and since everything sounds fine with your other graphic card and the onboard is ok, it's not the mobo, it would logically seem to indicate your 1080ti.
I've a 1080 (not a ti though), and far as I know, the linux driver is the same as the windows one, 'cept with a wrapper round it. My onboard AMD GPU id deactivated, a consequence of a Ryzen 7 plugged into my particular mobo (wish I'd know that issue before I bought).
Ubuntu is still fine for a user-friendly starter distro - Canonical are more focused on IOT and containers and not as much on human users.
The main differences you will encounter between distros
Package management (ubuntu, mint, and a lot of others use debian apt, others might use red hat base, or their own)
some file location differences
different default desktop
The certifiable check would be to try out the potentially problematic card on another system.