Daz Studio and Linux

1323335373854

Comments

  • antadev66antadev66 Posts: 37
    maelstrom said:

    @antadev66

    Sorry, I'm not able to check it out. For now, I am running with only one monitor.
    Also, It may be wine or wm/decorator/compositor/de/X issue.

    Sure, it was more an FYI than a request for confirmation. I'm happy my DAZ Studio works again. What a stupid bug. I feel so dumb, it wasted months.

    I even managed to do my first render with iray using my nvidia card, that's a very welcome feat. Thanks to this forums invalueable help! :)

    I did notice an issue. I wonder if others observe this too? I loaded an existing scene while Cuda wasn't yet installed/working.

    It took a couple minutes only, which is atypical, loading complex scenes on my computer always took -literally- hours. I assumed this was thanks to new Wine version.   

    Later, after my first succesful iray render, I tried loading that same scene again, but this time it took forever, using all CPU cores at 100%. It hadn't finished loading the next morning, so I killed DAZ.

    To verify my suspicion that it could be related to the renderer selected, I now switched to renderer Basic OpenGL and then tried to load the scene. It loaded in a minute. I'm currently rendering it with iray.

    Is this a know issue? Should I / do people switch back to a simple renderer in order to open scenes??

  • antadev66antadev66 Posts: 37

    I used to use Daz on 2 monitors. I don't any more - not for any real issues (although the viewport sometimes moved on it's own - I put that down to either a windows/wine problem or an incompatibility with running on a Tiling Window Manager - worked ok on i3wm though).

    Maybe your left/right problem is to do with whichever is the Primary monitor, maybe it's an issue with whatever/whichever Desktop/Window Manager you are using.

    Yeah, could be. I'll investigate later. It's KDE. For now I'm happy with the workaround.

  • GafftheHorseGafftheHorse Posts: 567
    maelstrom said:

    since a postgresql update broke it

    Arch updates does not perform PostgreSQL migration, as Ubuntu does. Cant say anything about Void.
    But upgrading data manually not so big trick. Just make a backup and run `pg_upgradecluster <old_version> <cluster name>`
    To list clusters (database installations, in terms of postgres) just run `pg_lsclusters`.

    Yeah, there's an entry in the Archwiki with the procedure documented. I've just not bothered as I never use Smart Content as well as I'm still mulling switching to Void (for entirely other reasons nothing to do with Wine, Daz or Postgresql.

    maelstrom said:

    Canonicals main focus isn't the desktop

    Linux has no desktop/server artificial division, as windows does. Canonical has made and maintaining extended driver support, graphical zfs installer, automated system snapshots on upgrade, grub-embeded zfs rollback support (not sure about this). On a servers we had these features for years, in some kind of script or console.

    Anyway, I finally made myself familiar with Plasma and wanna move towards it in my next installation.

    No, but every distro has it's focus, some purposeful, some as result of side-effects. This often dictates how suitable it is for certain uses. I used to be a Ubuntu user - still had it on my laptop until last year. Canonicals focus is not as User focused as it used to be.

    I used to be a KDE fan - I switched about between KDE and Gnome during versions 1 and 2 of those desktops, was a solid KDE 3 and 4 user.

    Up until recently I nearly always had Plasma installed, even if I more often used a tiler or Openbox, to login into once in a while - I still have bits of the KDE stack installed though, but the Nvidia drivers result in poor performance for Plasma desktop so I don't have it installed to lighten the update load a little.

  • antadev66antadev66 Posts: 37

    Hm. More on my loading scene woes:  It doesn't seem related to renderer selected. Running DazStudio.exe from terminal shows this error, which obviously repeats every minute from that point... :(

    002b:err:ntdll:RtlpWaitForCriticalSection section 0x7f988cdb37e0 "wine-staging-5.5-r1/work/wine-5.5/dlls/winex11.drv/window.c: win_data_section" wait timed out in thread 002b, blocked by 0064, retrying (60 sec)

    Appears to happen randomly. I'd say until yesterday about 30-50% of times. However today I hit this 6 times in a row. Could be coincidence. No signs of distress otherwise, dmesg is clean...

    Any ideas?

     

  • GafftheHorseGafftheHorse Posts: 567
    edited June 2020
    antadev66 said:

    Hm. More on my loading scene woes:  It doesn't seem related to renderer selected. Running DazStudio.exe from terminal shows this error, which obviously repeats every minute from that point... :(

    002b:err:ntdll:RtlpWaitForCriticalSection section 0x7f988cdb37e0 "wine-staging-5.5-r1/work/wine-5.5/dlls/winex11.drv/window.c: win_data_section" wait timed out in thread 002b, blocked by 0064, retrying (60 sec)

    Appears to happen randomly. I'd say until yesterday about 30-50% of times. However today I hit this 6 times in a row. Could be coincidence. No signs of distress otherwise, dmesg is clean...

    Any ideas?

     

    I get that a fair bit. It's Wine struggling with Windows multi-threading.

    Couple of [Wine] releases ago (maybe Wine version 4), when that message repeated, I might as well kill dazstudio as it would never recover.

    Last year or so, it usually gets over it after a wait, usually after about 6 to 15 repeats (of the message).

    Later, after my first succesful iray render, I tried loading that same scene again, but this time it took forever, using all CPU cores at 100%. It hadn't finished loading the next morning, so I killed DAZ.

    To verify my suspicion that it could be related to the renderer selected, I now switched to renderer Basic OpenGL and then tried to load the scene. It loaded in a minute. I'm currently rendering it with iray.

    Is this a know issue? Should I / do people switch back to a simple renderer in order to open scenes??

    I often get Scene Loads never completing - sometimes the thread message is evident, sometimes not. If it got stuck, kill studio [  # pkill DAZStudio.exe ] relaunch, and try to load again - Sometimes it might load 1 times out of 3. Year or so ago, Daz on Wine wouldn't load any scenes, so things are improving.

    Never thought of OpenGL render - I've not used it since my first experiments in 2016. I'll have to check that out. As far as I know, it's not a known issue, not even for Wine Daz users.

    Yeah, could be. I'll investigate later. It's KDE. For now I'm happy with the workaround.

    The Nvidia proprietary drivers are not a good combo with KDE Plasma - especially with multi-monitor. I've heard that Kwin devs say Nvidia is just not interested in helping track it down. There are a few Xorg config setting which might help a bit, but they don't help much.

    Post edited by GafftheHorse on
  • antadev66antadev66 Posts: 37
    antadev66 said:

    002b:err:ntdll:RtlpWaitForCriticalSection section 0x7f988cdb37e0 "wine-staging-5.5-r1/work/wine-5.5/dlls/winex11.drv/window.c: win_data_section" wait timed out in thread 002b, blocked by 0064, retrying (60 sec)

    I get that a fair bit. It's Wine struggling with Windows multi-threading.

    Couple of [Wine] releases ago (maybe Wine version 4), when that message repeated, I might as well kill dazstudio as it would never recover.

    Funny, that's not my experience. Under wine4 I had troubles loading scenes, but they eventually loaded, albeit often the next day. Perhaps I was too patient. (I had not yet noticed this errormessage then).

    I often get Scene Loads never completing - sometimes the thread message is evident, sometimes not. If it got stuck, kill studio [  # pkill DAZStudio.exe ] relaunch, and try to load again - Sometimes it might load 1 times out of 3. Year or so ago, Daz on Wine wouldn't load any scenes, so things are improving.

    Hm again, curious, my experiences are different: I could load scenes with Daz under wine 4, but they consistently took a very very long time. (Maybe I AM too patient) ;)

    Because of the consistent behaviour I never thought to look deeper, I just "got used to it".

    The Nvidia proprietary drivers are not a good combo with KDE Plasma - especially with multi-monitor. I've heard that Kwin devs say Nvidia is just not interested in helping track it down. There are a few Xorg config setting which might help a bit, but they don't help much.

    Ah. That's good to know, but bad news... Can you point me to a resource, like a bug or a forum thread on this? So far I didn't really notice the performance troubles. But yes, during renders, scrolling in all other apps resembles blowing marbles through a garden hose...

  • GafftheHorseGafftheHorse Posts: 567
    antadev66 said:
    antadev66 said:

    002b:err:ntdll:RtlpWaitForCriticalSection section 0x7f988cdb37e0 "wine-staging-5.5-r1/work/wine-5.5/dlls/winex11.drv/window.c: win_data_section" wait timed out in thread 002b, blocked by 0064, retrying (60 sec)

    I get that a fair bit. It's Wine struggling with Windows multi-threading.

    Couple of [Wine] releases ago (maybe Wine version 4), when that message repeated, I might as well kill dazstudio as it would never recover.

    Funny, that's not my experience. Under wine4 I had troubles loading scenes, but they eventually loaded, albeit often the next day. Perhaps I was too patient. (I had not yet noticed this errormessage then).

    I'm not certain it was during Wine 4 (hence 'maybe'). I never used to get multithread block messages, but then, perhaps Wine was either not multithreading then or Daz wasn't (2017-2018 - again I think).

    What I do recall for certainty - prior to Daz version 4.10 and Wine 4 - the Sliders barely worked (most didn't) which resulted in having to enter numbers to move figures and furniture about, and limb posing by moving slider only worked on old figures. It popped up as an improvement during 4.11 Beta - You needed both the new Daz (Beta at the time and Wine 4) - I checked with a Debian Stable user of Daz (Debian Stable being very long support and lagging behind on Wine version)

    antadev66 said:

    I often get Scene Loads never completing - sometimes the thread message is evident, sometimes not. If it got stuck, kill studio [  # pkill DAZStudio.exe ] relaunch, and try to load again - Sometimes it might load 1 times out of 3. Year or so ago, Daz on Wine wouldn't load any scenes, so things are improving.

    Hm again, curious, my experiences are different: I could load scenes with Daz under wine 4, but they consistently took a very very long time. (Maybe I AM too patient) ;)

    Because of the consistent behaviour I never thought to look deeper, I just "got used to it".

    Perhaps you are patient - my limit was the time it took for dinner - and it usually failed to load after a three courser with brandy and cigar time in another time zone. So I just didn't bother saving - art had to be created in one session. Again - not sure exactly when loading times improved.

    antadev66 said:

    The Nvidia proprietary drivers are not a good combo with KDE Plasma - especially with multi-monitor. I've heard that Kwin devs say Nvidia is just not interested in helping track it down. There are a few Xorg config setting which might help a bit, but they don't help much.

    Ah. That's good to know, but bad news... Can you point me to a resource, like a bug or a forum thread on this? So far I didn't really notice the performance troubles. But yes, during renders, scrolling in all other apps resembles blowing marbles through a garden hose...

    Do a search Google or Duck Duck or the eco engine : "plasma desktop on nvidia proprietary drivers" There are plenty if forums, Nvida dev forum (surprisingly useless - gamers mostly, reddit, Ubuntu, arch, manjaro - all complaining of poor Plasma performance on Nvidia drivel.

    Nvidia don't give much of a crap about Linux desktop usage. They keep promising improvements and not delivering. The VESA drivers are pretty fast on Plasma (Nouveau), but Nouveau drivers lack Cuda and are pretty lagging on recent cards due to Nvidia firmware is now signed, locking the devs from their work (they started doing that just after I bought my current card).

    I'll not be buying Nvidia again.

  • brainmuffinbrainmuffin Posts: 1,198

    This thread is really 5 years old?

  • GafftheHorseGafftheHorse Posts: 567

    This thread is really 5 years old?

    Apparently

    I only came to Daz at the end of 2016 - the 64bit version didn't really work on Wine at all reliably, so sort of relied on the 32bit version.

    Then Wine hit 2.0 - the 64bit Daz became increasingly usable since.

    The most recent usability milestone was Daz 4.11 with Wine 4.0 (they still don't work well in 4.10) - since then, the sliders have worked.

  • maelstrommaelstrom Posts: 34

    @brainmuffin

    Really. But it is still actual, isn't?

  • brainmuffinbrainmuffin Posts: 1,198
    maelstrom said:

    @brainmuffin

    Really. But it is still actual, isn't?

    I'm surprised that a thread would take this long to get to page 35. I haven't tried Studio and WINE in quite some time.

  • GafftheHorseGafftheHorse Posts: 567
    maelstrom said:

    @brainmuffin

    Really. But it is still actual, isn't?

    I'm surprised that a thread would take this long to get to page 35. I haven't tried Studio and WINE in quite some time.

    I goes quiet for long periods. Peeps only usually come here when they've problems.

  • NylonGirlNylonGirl Posts: 1,777

    I've been interested in running DAZ on Linux for a while but I figured getting it initially working required a whole lot of things. And if I asked what all the steps were, it would drive people crazy since those things have probably been asked and answered many times. And maybe if I had a few weeks, I could read through this whole thread and find the answers. But because I don't want to do that, I've been putting the whole thing off.

    I don't even have a computer running just Linux anymore. But I have a Chromebook. So I'd be running Linux on top of Chrome OS, and Running DAZ on the WINE virtual machine inside of that. And it would all be running on the Chromebook's core i3 with 4 gigs of ram. That would be something to see.

  • GafftheHorseGafftheHorse Posts: 567
    edited June 2020
    NylonGirl said:

    I've been interested in running DAZ on Linux for a while but I figured getting it initially working required a whole lot of things. And if I asked what all the steps were, it would drive people crazy since those things have probably been asked and answered many times. And maybe if I had a few weeks, I could read through this whole thread and find the answers. But because I don't want to do that, I've been putting the whole thing off.

    I don't even have a computer running just Linux anymore. But I have a Chromebook. So I'd be running Linux on top of Chrome OS, and Running DAZ on the WINE virtual machine inside of that. And it would all be running on the Chromebook's core i3 with 4 gigs of ram. That would be something to see.

    You should really at least skim Forum threads, it'd not take weeks, maybe an hour or two.

    There was an Installation Guide Posted a few pages back. I started it from scraps posted to the forum and other sources by others (I'd hoped others would help add and improve it), anyway, here it is reposted for your convenience.

    On a Chromebook with 4GB RAM you might struggle to do that much with Daz Studio though.

    You can still get nice images with 3Delight though. I used to do quite largish scenes with 16GB RAM on a 4-core with an onboard GPU.

     

    txt
    txt
    Daz Forum Thread Installation Guide-Daz Studio on Wine.txt
    11K
    Post edited by GafftheHorse on
  • antadev66antadev66 Posts: 37
    NylonGirl said:

    I've been interested in running DAZ on Linux for a while but I figured getting it initially working required a whole lot of things. And if I asked what all the steps were, it would drive people crazy since those things have probably been asked and answered many times. And maybe if I had a few weeks, I could read through this whole thread and find the answers. But because I don't want to do that, I've been putting the whole thing off.

    I don't even have a computer running just Linux anymore. But I have a Chromebook. So I'd be running Linux on top of Chrome OS, and Running DAZ on the WINE virtual machine inside of that. And it would all be running on the Chromebook's core i3 with 4 gigs of ram. That would be something to see.

    Not to discourage you or anything, but I have an 8-core machine with 32GB ram plus an nvidia card and I have seen Daz Studio getting killed due to out-of-memory conditions 3 times the past 2 weeks.  Then again not everyone uses the same resources but... since chromebooks are notoriously underpowered...

  • antadev66antadev66 Posts: 37

    I only came to Daz at the end of 2016 - the 64bit version didn't really work on Wine at all reliably, so sort of relied on the 32bit version.

    Then Wine hit 2.0 - the 64bit Daz became increasingly usable since.

    The most recent usability milestone was Daz 4.11 with Wine 4.0 (they still don't work well in 4.10) - since then, the sliders have worked.

    Hm. I'm still on 4.10. I also do not even plan to upgrade to 4.11 or 4.12 because I need the nvidia rendering functionality which reportedly only works with 4.10 for now. The sliders work... badly. I can grab one and move it, but its error prone. I have gotten used to just type in the numbers by now though, or repeat-clicking. Just as I need to move the pointer into the viewer area to force a redraw to see my changes. I got used to it, pesky as it is...

  • GafftheHorseGafftheHorse Posts: 567
    antadev66 said:

    I only came to Daz at the end of 2016 - the 64bit version didn't really work on Wine at all reliably, so sort of relied on the 32bit version.

    Then Wine hit 2.0 - the 64bit Daz became increasingly usable since.

    The most recent usability milestone was Daz 4.11 with Wine 4.0 (they still don't work well in 4.10) - since then, the sliders have worked.

    Hm. I'm still on 4.10. I also do not even plan to upgrade to 4.11 or 4.12 because I need the nvidia rendering functionality which reportedly only works with 4.10 for now. The sliders work... badly. I can grab one and move it, but its error prone. I have gotten used to just type in the numbers by now though, or repeat-clicking. Just as I need to move the pointer into the viewer area to force a redraw to see my changes. I got used to it, pesky as it is...

    Fix for Nvidia Rendering on Studio > 4.10 discovered by @maelstrom and posted a page or two ago.

    Backup you current /plugins/dzirayrenderer.dll  and /libs/iray folders first.

     - Actually, probably better to create a new Wine prefix/bottle, and install current Daz there and copy over the 4.10 files and folder.

    (I've Wine bottles for 4.10, 4.11, 4.12 and the main Daz one which has DIm and Beta installed - this is the only one that gets auto updated via DIM. - Also I keep a 32bit Daz bottle - the 4.12 one is the only one with the 4.10 files applied)

    "Iray from 4.10 plugged in! Just copied `DAZ 3D/DAZStudio4/plugins/dzirayrenderer.dll` plugin file and `DAZStudio4/libs/iray` folder.

    I still cannot belive, that it was so easy! Just a dumb trick!
    Of course, it needs hard testing with real scenes, complex shaders and moar, but it works!
    It may eat your cat and trash all your data also, be warned."

    Of course, you'll probably not get the recent upgrades to Iray - such as noise reduction and efficiencies.

    I've a Ryzen 7, GTX1080 and 32GB RAM - but I find rendering on the GPU results in a rather unusable system while the render is in progress.

  • antadev66antadev66 Posts: 37
     

    Fix for Nvidia Rendering on Studio > 4.10 discovered by @maelstrom and posted a page or two ago.

    Ah? I casually read that, but apparently misjudged the importance of it. That's mighty interesting.

    I've a Ryzen 7, GTX1080 and 32GB RAM - but I find rendering on the GPU results in a rather unusable system while the render is in progress.

    Same here except for the card which is a GTX1060.  Same finding, but I try to cope. How did/do you cope? This will not change, iray rendering has always been like this, also on windows. This why for the past 3 years I did offline rendering on a remote computer using 3Delight engine. Alas that system broke, the renderer now crashes on every job and there doesn't seem to be a standalone 3Delight renderer available anymore, so no update or nothing. Fubar.

    I gotta say: the iray renders are soooo much nicer than 3Delight... so I would probably not go back even if I could.

     

  • maelstrommaelstrom Posts: 34
    antadev66 said:

    I have seen Daz Studio getting killed due to out-of-memory conditions 3 times the past 2 weeks

    Maybe, bigger swap helps you out.
    Also, if you don't have space for a swap, you may find ZRam useful.

     

  • GafftheHorseGafftheHorse Posts: 567
    antadev66 said:

    Same here except for the card which is a GTX1060.  Same finding, but I try to cope. How did/do you cope? This will not change, iray rendering has always been like this, also on windows. This why for the past 3 years I did offline rendering on a remote computer using 3Delight engine. Alas that system broke, the renderer now crashes on every job and there doesn't seem to be a standalone 3Delight renderer available anymore, so no update or nothing. Fubar.

    I gotta say: the iray renders are soooo much nicer than 3Delight... so I would probably not go back even if I could.

    I don't often use my wine prefix with Daz 4.12 with 4.10 iray plugins applied - I usually do scenes that blow the video memory limit anyway - so there's little benefit in using it usually.

    The laggy system while GPU renders are in progresss may be down to rendering on the same card that is driving screen output - dual GPUs is something I've considered for this reason (although mostly as it'd be nice to have a linux desktop that isn't riddled with caveats due to the non-native nvidia drivers). I've no idea if the latter would be the case.

    Just checked - something appears up - The usual 3Delight page has been gone for some time - Here's a link to Wayback Machine entry. You can still pick up the package from there.

    The Daz 3Delight implementation hasn't kept pace with 3Delight or even the Renderman standard it used to follow (3Delight has embraced OSL (open Shading language) rather than RSL (renderman). You can access better results using Path tracing via scripted rendering with Wowies Awe Shaders. (see Awe Shader Test Thread Page 1 for download links).

    Results with Awe and scripted 3delight can't compare with the realness of an unbiased engine like Iray, but the results are far better than regular Daz 3Delight (my Awe Gallery - early pics are mostly issue posting).

  • GafftheHorseGafftheHorse Posts: 567
    edited June 2020
    maelstrom said:
    antadev66 said:

    I have seen Daz Studio getting killed due to out-of-memory conditions 3 times the past 2 weeks

    Maybe, bigger swap helps you out.
    Also, if you don't have space for a swap, you may find ZRam useful.

    The advice on Swap that it should be twice the size of RAM is out of date.

    Swap Size

    Ubuntu advises if your RAM is 4GB, a 2GB Swap is sufficient, unless you use hibernation, in which case, 6GB is suggested.

    Post edited by GafftheHorse on
  • GafftheHorseGafftheHorse Posts: 567

    Heads up

    I've been getting rather a lot of sudden crashes (so sudden, not even the Daz crash dialogs popup) on Wine 5.9

    On update to Wine 5.10 - Wineboot cacks out with 'nodrv' on every prefix

    downgraded to Wine 5.9 - but it's really unreliable. Nothing unusual on terminal output after crashes - I'll have to set up debug

    I'm on the cutting edge on Archlinux - so hopefully those on more stable distros shouldn't see this by the time this release gets to you.

     

  • maelstrommaelstrom Posts: 34

    @GafftheHorse, swap is a crunch, as it always was. Useful, but  a cruch anyway. Real values greatly vary from one scenario to another. ZRam is also crunch, but some different kind: it tradeoffs CPU for RAM saving. And, with swap priority, it still can be backed up by ordinary swap.

    For years I had preference to have swapless system, nowadays I used to have zswap over 2÷16GB ordinary swap. It is… satisfying.
    Praise the Abyss, I'm in a wigwam now.

    The Linux Postgresql CMS lib setup just acts as a bridge to the Wine run one.

    Really, no. If you are using external postgresql server, you can drop out DAZ internal CMS server and it's database completely, without any penalties. Up to remove package, or not install it at all, as I do.
    And native DB runs much faster and more reliable than emulated.
    Also you will posses a little bonus: no hung CMS engine in DAZ bottle, no hanging bottle, and DAZ itself tends to be hangy on start quiet less.

  • maelstrommaelstrom Posts: 34

    Heads up

    I've been getting rather a lot of sudden crashes (so sudden, not even the Daz crash dialogs popup) on Wine 5.9

    On update to Wine 5.10 - Wineboot cacks out with 'nodrv' on every prefix

    downgraded to Wine 5.9 - but it's really unreliable. Nothing unusual on terminal output after crashes - I'll have to set up debug

    I'm on the cutting edge on Archlinux - so hopefully those on more stable distros shouldn't see this by the time this release gets to you.

     

    Sad. On ubuntu 18.04 with winehq plugged in, 5.10 in upstream.
    So, it may suffer too.

  • GafftheHorseGafftheHorse Posts: 567
    maelstrom said:

    @GafftheHorse, swap is a crunch, as it always was. Useful, but  a cruch anyway. Real values greatly vary from one scenario to another. ZRam is also crunch, but some different kind: it tradeoffs CPU for RAM saving. And, with swap priority, it still can be backed up by ordinary swap.

    For years I had preference to have swapless system, nowadays I used to have zswap over 2÷16GB ordinary swap. It is… satisfying.
    Praise the Abyss, I'm in a wigwam now.

    The Linux Postgresql CMS lib setup just acts as a bridge to the Wine run one.

    Really, no. If you are using external postgresql server, you can drop out DAZ internal CMS server and it's database completely, without any penalties. Up to remove package, or not install it at all, as I do.
    And native DB runs much faster and more reliable than emulated.
    Also you will posses a little bonus: no hung CMS engine in DAZ bottle, no hanging bottle, and DAZ itself tends to be hangy on start quiet less.

    Oh!

    Someone (here or DA) told me it was to act as a bridge.

    I've never tried to remove the Daz supplied one.

    Sad. On ubuntu 18.04 with winehq plugged in, 5.10 in upstream.
    So, it may suffer too.

    I've had a few ocassions Daz becomes unrunable due to a library mismatch or some other problem - about twice a year for no more than a week. There was an entire month I ran 'wineconsole' instead of 'wine' as it was the only way it'd start.

  • antadev66antadev66 Posts: 37

     

    antadev66 said:

    Same here except for the card which is a GTX1060.  Same finding, but I try to cope. How did/do you cope? This will not change, iray rendering has always been like this, also on windows. This why for the past 3 years I did offline rendering on a remote computer using 3Delight engine. Alas that system broke, the renderer now crashes on every job and there doesn't seem to be a standalone 3Delight renderer available anymore, so no update or nothing. Fubar.

    I gotta say: the iray renders are soooo much nicer than 3Delight... so I would probably not go back even if I could.

    I don't often use my wine prefix with Daz 4.12 with 4.10 iray plugins applied - I usually do scenes that blow the video memory limit anyway - so there's little benefit in using it usually.

    The laggy system while GPU renders are in progresss may be down to rendering on the same card that is driving screen output - dual GPUs is something I've considered for this reason (although mostly as it'd be nice to have a linux desktop that isn't riddled with caveats due to the non-native nvidia drivers). I've no idea if the latter would be the case.

    I read 'somewhere' a long time ago that iray is pretty bad in this regard. Even people that have multiple cards and render on a dedicated card while using another card for display, reported heavy slowdowns during renders. I think it's the CPU.  But since I can't remember where I read that, don't take my word for it. And obviously, things may have changed since 2017.

    Just checked - something appears up - The usual 3Delight page has been gone for some time - Here's a link to Wayback Machine entry. You can still pick up the package from there.

    Thanks... I checked, I seem to have used 3delight-12.0.137-Linux-x86_64.tar. The download is dated April 2017, sounds about right. Recently it started crashing on 80% of renders, but in a random fashion. Dunno what's up with that. But again, I love the iray results, so I doubt I'll turn back.

     

    The Daz 3Delight implementation hasn't kept pace with 3Delight or even the Renderman standard it used to follow (3Delight has embraced OSL (open Shading language) rather than RSL (renderman). You can access better results using Path tracing via scripted rendering with Wowies Awe Shaders. (see Awe Shader Test Thread Page 1 for download links).

    Results with Awe and scripted 3delight can't compare with the realness of an unbiased engine like Iray, but the results are far better than regular Daz 3Delight (my Awe Gallery - early pics are mostly issue posting).

    Before settling on 3Delight I tried to go Luxrender with the Reality plugin but that was a major let-down.  :(  The reality plugin isn't meant to be used on a different system -never mind a linux one-, it looks for the files in their original locations, like C:\Program Files\ so that was utterly useless. At least DAZ Studio had the foresight to provide a button "Collect and localize" that gathers all required files and makes all paths relative. Otherwise it would have been a no-go.

  • GafftheHorseGafftheHorse Posts: 567

    I read 'somewhere' a long time ago that iray is pretty bad in this regard. Even people that have multiple cards and render on a dedicated card while using another card for display, reported heavy slowdowns during renders. I think it's the CPU.  But since I can't remember where I read that, don't take my word for it. And obviously, things may have changed since 2017.

    I wonder if this was two Nvidia cards, or an AMD to drive the video and an Nvidia to ty to get the advantage of GPU rendering.

    Honestly, with a Ryzen 7 and 32GB memory, I don't find CPU rendering that bad - the default Iray timeout of one and a half hours is usually sufficient for a good render - and if it's still fireflies after than, double the time, up the quality and Resume.

    Thanks... I checked, I seem to have used 3delight-12.0.137-Linux-x86_64.tar. The download is dated April 2017, sounds about right. Recently it started crashing on 80% of renders, but in a random fashion. Dunno what's up with that. But again, I love the iray results, so I doubt I'll turn back.

    Odd. I seldom see crashes with 3Delight - once in a while the render cacks out with a rib file error.

    Did you check out my Awe gallery? Regular 3DL materials can't hold a candle to Awe as they are PBR - light transmission isn't as good as iray (or any unbiased engine) and there is a real dearth of easy shader presets, but it's usually quick on Progessive render.

    Before settling on 3Delight I tried to go Luxrender with the Reality plugin but that was a major let-down.  :(  The reality plugin isn't meant to be used on a different system -never mind a linux one-, it looks for the files in their original locations, like C:\Program Files\ so that was utterly useless. At least DAZ Studio had the foresight to provide a button "Collect and localize" that gathers all required files and makes all paths relative. Otherwise it would have been a no-go.

    I got Reality to work - but it's not as robust as Daz Studio and frequently crashed trying to transfer large scenes.

    I preferred how the alternate Luxrender plugin, 'Luxus' operated. Not as well set up with a materials conversion system, but more integrated. Unfortunately it's never been updated to cope with the new Luxcore render - and still depends on the old render engine.

    Octane now has a Free tier, but as it requires a connection to the internet to work - I've been doubtful it'd work - I've registered, but not gotten around to trying to get it working.

    I'm kind of hoping someone will do a plugin for AMDs Prorender.

    There are some rumours Daz is working on an Eevee style engine.

  • brainmuffinbrainmuffin Posts: 1,198
    maelstrom said:
    antadev66 said:

    I have seen Daz Studio getting killed due to out-of-memory conditions 3 times the past 2 weeks

    Maybe, bigger swap helps you out.
    Also, if you don't have space for a swap, you may find ZRam useful.

    The advice on Swap that it should be twice the size of RAM is out of date.

    Those of us who have been saddled with RedHat from time to time, that advise was out of date nearly 20 years ago.

  • GafftheHorseGafftheHorse Posts: 567
    maelstrom said:
    antadev66 said:

    I have seen Daz Studio getting killed due to out-of-memory conditions 3 times the past 2 weeks

    Maybe, bigger swap helps you out.
    Also, if you don't have space for a swap, you may find ZRam useful.

    The advice on Swap that it should be twice the size of RAM is out of date.

    Those of us who have been saddled with RedHat from time to time, that advise was out of date nearly 20 years ago.

    Really 20 years?

    I stuck to that rule up until memory got above 2GB (early 2010s), which sort of matches that table on the link I added.

  • antadev66antadev66 Posts: 37

    The advice on Swap that it should be twice the size of RAM is out of date.

    Those of us who have been saddled with RedHat from time to time, that advise was out of date nearly 20 years ago.

    yup. I tried a swapless system for a short while, but the drawback is that you get zero distress signals from your system, it just suddenly goes "OOM, killing your baby!" and takes often your entire X down. The sweet spot for me is to have enough swap so that you notice the slowdown in time to react and choose what to process to kill yourself -either a runaway one or one that isn't important- before the kernel makes that choice for you. For my 32GB system I have 16GB swap. For laptops I reserve relatively more swap, just to be able to hibernate.

Sign In or Register to comment.