Daz Studio and Linux

1212224262754

Comments

  • No IRAY on 32bit installations.

    I installed Wine 1.9.24, created a 64 bit Wine install (Play On Linux) and then Daz Studio 4.8 64bit using the same process as outlined above. I now have a 64bit working install of DS4.8 with IRAY (cpu rending only). One caveat though... I could not install "dotnet20 or dotnet40". I skipped them both on the newer Wine version hoping things would pan out. So far so good ...

  • Just an update.  I think I have finally gotten DS 4.9 completely working in Linux Mint 18.  I went back through and copied and pasted each of the directions instead of typing everything in myself.  I must have had a mistake somewhere, I just don't know where I made the mistake.  I was able to log in through DS 4.9 and it connected.  It's currently going through the long process of downloading metadata and Smart Content and, more importantly, Categories seems to now be working.  I'm going to dinner and, hopefully, it will be done with the metadata when I get back and I can take an in-depth look at what is actually working and what might still be broken.  I'm very pleased to finally have this working.  

  • mjc1016 said:
    kyoto kid said:

    ..Daz just needs to compile Studio, Carrara, Bryce, and Hexagon for Linux.

    Agreed. It is my understanding their toolkit will allow such. Not sure about DIM though.

    Although Qt is meant to be a cross-platform framework that doesn't appear to mean write-once-compile-all - there have been plenty of platform-specific issues of one kind and another, and DS does use code licensed from others (nVidia, DNA Reseach, and Optitex for example) which may or may not be cross-platform and may or may not be licensed for use in a Linux version.

    3DL should be doable....not sure if it would need another license/addendum or not, but the Linux 3DL version is actually the faster one.  There's also a Linux version of Iray.  Postgre would be another easy one...

    But those are the small things...the big one is that it's VisualC and not a more 'generic'/standard version...

    The programming environment and compiler used for the Windows version is irrelevant when they also have a native Mac version, since the same codebase is going to be used for all versions. Most of the Apple compiler tools are actually based on GCC, which is the native compiler for Linux, so the code will require some modifications to refer to Linux headers, but otherwise should be the same as for the other platforms.

  • mjc1016 said:
    kyoto kid said:

    ..Daz just needs to compile Studio, Carrara, Bryce, and Hexagon for Linux.

    Agreed. It is my understanding their toolkit will allow such. Not sure about DIM though.

    Although Qt is meant to be a cross-platform framework that doesn't appear to mean write-once-compile-all - there have been plenty of platform-specific issues of one kind and another, and DS does use code licensed from others (nVidia, DNA Reseach, and Optitex for example) which may or may not be cross-platform and may or may not be licensed for use in a Linux version.

    3DL should be doable....not sure if it would need another license/addendum or not, but the Linux 3DL version is actually the faster one.  There's also a Linux version of Iray.  Postgre would be another easy one...

    But those are the small things...the big one is that it's VisualC and not a more 'generic'/standard version...

    The programming environment and compiler used for the Windows version is irrelevant when they also have a native Mac version, since the same codebase is going to be used for all versions. Most of the Apple compiler tools are actually based on GCC, which is the native compiler for Linux, so the code will require some modifications to refer to Linux headers, but otherwise should be the same as for the other platforms.

    OS X uses LLVM since Lion. You can still download real GCC using brew, but it's kinda messy. LLVM supports most of the same stuff gcc does, but not everything which can be a pain. 

  • mjc1016 said:
    kyoto kid said:

    ..Daz just needs to compile Studio, Carrara, Bryce, and Hexagon for Linux.

    Agreed. It is my understanding their toolkit will allow such. Not sure about DIM though.

    Although Qt is meant to be a cross-platform framework that doesn't appear to mean write-once-compile-all - there have been plenty of platform-specific issues of one kind and another, and DS does use code licensed from others (nVidia, DNA Reseach, and Optitex for example) which may or may not be cross-platform and may or may not be licensed for use in a Linux version.

    3DL should be doable....not sure if it would need another license/addendum or not, but the Linux 3DL version is actually the faster one.  There's also a Linux version of Iray.  Postgre would be another easy one...

    But those are the small things...the big one is that it's VisualC and not a more 'generic'/standard version...

    The programming environment and compiler used for the Windows version is irrelevant when they also have a native Mac version, since the same codebase is going to be used for all versions. Most of the Apple compiler tools are actually based on GCC, which is the native compiler for Linux, so the code will require some modifications to refer to Linux headers, but otherwise should be the same as for the other platforms.

    OS X uses LLVM since Lion. You can still download real GCC using brew, but it's kinda messy. LLVM supports most of the same stuff gcc does, but not everything which can be a pain.

    True, but the point I was trying to make is that the code is, or should be as much as possible, compiler independent.

  • Okay, this may seem like a dumb question, but I've never used Connect before and have always installed with DIM.  I know how Categories and the Product A-Z listing in the older versions of DS.  I could create categories and see all of my DIM installed stuff there.  Now, with Connect, the only thing I see in these are the Connect things in Smart Content.  In the Content Library tab, I have the DIM installed stuff showing up under My DAZ 3D Library with the file tree in the Content Library tab, but it doesn't populate the Product Listing and I can't add things from there in the Categories.  Is this how DS 4.9 and Connect normally does things or do I still not have something set up right?  I don't have a problem just using Connect and reinstalling everything.  I'll back the DIM stuff up and burn it to a DVD and just use Connect if I need to.  I just want to make sure this is what is suppose to happen or if I still have something not working right.  Is there a way for the already installed stuff to show up in categories that I don't know about, maybe?

  • mjc1016mjc1016 Posts: 15,001

    True, but the point I was trying to make is that the code is, or should be as much as possible, compiler independent.

    I don't remember if it was earlier in this thread or a thread in the SDK forum, but it was explained that yes, it is more compiler dependent than it should be.

  • I could use some help figuring out why I can't get LAMH to install on my Linux install of DS 4.9.3.166.  I made a fresh wine bottle and installed the new version of DS 4.9.3.166 so I didn't mess up my previous DS 4.9.2.70 as I just managed to get cms and everything working and didn't want to mess it up.  I hadn't gotten around to installing LAMH on that setup as I was enjoying having it things finally working.

    I installed LAMH from inside playonlinux in my virtual drive where I have DS 4.9.3.166 installed with the .exe file downloaded from my Product Library page and it had an error that it couldn't write to the z: drive.  I'm not sure what it was trying to install there.  I tried installing again and it uninstalled the previous LAMH and seemed to have no problems the second time.  However, once I start DS, the whole thing crashes before loading up completely.  I tried running in terminal mode but got no errors back that I can tell.  This is the only thing in the terminal when after the crash:


    cathy@knittingmommy-To-be-filled-by-O-E-M ~ $ /usr/share/playonlinux/playonlinux --run "DAZStudio 4.9.3.166"
    Looking for python... 2.7.12 - wxversion(s): 3.0-gtk2
    selected
    [main] Message: PlayOnLinux (4.2.10) is starting
    [clean_tmp] Message: Cleaning temp directory
    Script started /home/cathy/.PlayOnLinux/shortcuts/DAZStudio 4.9.3.166
    [POL_System_CheckFS] Message: Checking filesystem for DAZStudio.exe
    [POL_Wine] Message: Running wine- DAZStudio.exe (Working directory : /home/cathy/.PlayOnLinux/wineprefix/DAZStudio4.9.3.166/drive_c/Program Files/DAZ 3D/DAZStudio4)
    [POL_Wine] Message: Notice: PlayOnLinux deliberately disables winemenubuilder. See http://www.playonlinux.com/fr/page-26-Winemenubuilder.htmlcathy@knittingmommy-To-be-fi
    [POL_Wine] Error: Wine seems to have crashed

    If your program is running, just ignore this message
    [POL_SetupWindow_Init] Message: Creating new window for pid 4978
    [POL_SetupWindow_Close] Message: Closing window for pid 4978
    [POL_Wine] Message: Wine return: 255
     

    I created an uninstall shortcut and then uninstalled LAMH and DS loads up again perfectly without crashing.  Does Kendall or anyone know the best way to get LAMH installed on Linux?

  • I could use some help figuring out why I can't get LAMH to install on my Linux install of DS 4.9.3.166.  I made a fresh wine bottle and installed the new version of DS 4.9.3.166 so I didn't mess up my previous DS 4.9.2.70 as I just managed to get cms and everything working and didn't want to mess it up.  I hadn't gotten around to installing LAMH on that setup as I was enjoying having it things finally working.

    I installed LAMH from inside playonlinux in my virtual drive where I have DS 4.9.3.166 installed with the .exe file downloaded from my Product Library page and it had an error that it couldn't write to the z: drive.  I'm not sure what it was trying to install there.  I tried installing again and it uninstalled the previous LAMH and seemed to have no problems the second time.  However, once I start DS, the whole thing crashes before loading up completely.  I tried running in terminal mode but got no errors back that I can tell.  This is the only thing in the terminal when after the crash:


    cathy@knittingmommy-To-be-filled-by-O-E-M ~ $ /usr/share/playonlinux/playonlinux --run "DAZStudio 4.9.3.166"
    Looking for python... 2.7.12 - wxversion(s): 3.0-gtk2
    selected
    [main] Message: PlayOnLinux (4.2.10) is starting
    [clean_tmp] Message: Cleaning temp directory
    Script started /home/cathy/.PlayOnLinux/shortcuts/DAZStudio 4.9.3.166
    [POL_System_CheckFS] Message: Checking filesystem for DAZStudio.exe
    [POL_Wine] Message: Running wine- DAZStudio.exe (Working directory : /home/cathy/.PlayOnLinux/wineprefix/DAZStudio4.9.3.166/drive_c/Program Files/DAZ 3D/DAZStudio4)
    [POL_Wine] Message: Notice: PlayOnLinux deliberately disables winemenubuilder. See http://www.playonlinux.com/fr/page-26-Winemenubuilder.htmlcathy@knittingmommy-To-be-fi
    [POL_Wine] Error: Wine seems to have crashed

    If your program is running, just ignore this message
    [POL_SetupWindow_Init] Message: Creating new window for pid 4978
    [POL_SetupWindow_Close] Message: Closing window for pid 4978
    [POL_Wine] Message: Wine return: 255
     

    I created an uninstall shortcut and then uninstalled LAMH and DS loads up again perfectly without crashing.  Does Kendall or anyone know the best way to get LAMH installed on Linux?

    LAMH is pretty hard on the OpenGL stack.  I haven't tested LAMH with DS under Linux/Wine since mid-4.8 due to problems getting DS running under Wine.  I may take a bit of time to play with it this weekend depending on other priorities.

    Kendall

  • I could use some help figuring out why I can't get LAMH to install on my Linux install of DS 4.9.3.166.  I made a fresh wine bottle and installed the new version of DS 4.9.3.166 so I didn't mess up my previous DS 4.9.2.70 as I just managed to get cms and everything working and didn't want to mess it up.  I hadn't gotten around to installing LAMH on that setup as I was enjoying having it things finally working.

    I installed LAMH from inside playonlinux in my virtual drive where I have DS 4.9.3.166 installed with the .exe file downloaded from my Product Library page and it had an error that it couldn't write to the z: drive.  I'm not sure what it was trying to install there.  I tried installing again and it uninstalled the previous LAMH and seemed to have no problems the second time.  However, once I start DS, the whole thing crashes before loading up completely.  I tried running in terminal mode but got no errors back that I can tell.  This is the only thing in the terminal when after the crash:


    cathy@knittingmommy-To-be-filled-by-O-E-M ~ $ /usr/share/playonlinux/playonlinux --run "DAZStudio 4.9.3.166"
    Looking for python... 2.7.12 - wxversion(s): 3.0-gtk2
    selected
    [main] Message: PlayOnLinux (4.2.10) is starting
    [clean_tmp] Message: Cleaning temp directory
    Script started /home/cathy/.PlayOnLinux/shortcuts/DAZStudio 4.9.3.166
    [POL_System_CheckFS] Message: Checking filesystem for DAZStudio.exe
    [POL_Wine] Message: Running wine- DAZStudio.exe (Working directory : /home/cathy/.PlayOnLinux/wineprefix/DAZStudio4.9.3.166/drive_c/Program Files/DAZ 3D/DAZStudio4)
    [POL_Wine] Message: Notice: PlayOnLinux deliberately disables winemenubuilder. See http://www.playonlinux.com/fr/page-26-Winemenubuilder.htmlcathy@knittingmommy-To-be-fi
    [POL_Wine] Error: Wine seems to have crashed

    If your program is running, just ignore this message
    [POL_SetupWindow_Init] Message: Creating new window for pid 4978
    [POL_SetupWindow_Close] Message: Closing window for pid 4978
    [POL_Wine] Message: Wine return: 255
     

    I created an uninstall shortcut and then uninstalled LAMH and DS loads up again perfectly without crashing.  Does Kendall or anyone know the best way to get LAMH installed on Linux?

    LAMH is pretty hard on the OpenGL stack.  I haven't tested LAMH with DS under Linux/Wine since mid-4.8 due to problems getting DS running under Wine.  I may take a bit of time to play with it this weekend depending on other priorities.

    Kendall

    Ah, that would be great, Kendall.  Let me know what happens if you get to it.  I have it installed and working on the Windows drive with DS 4.9.3.166 with no problems.  So, I'm not completely without it.  Would just like to be able to get everything working in Linux eventually.  :)

  • The interesting thing about the latest DS is that it seems to have fixed a few issues I was having with DS 4.9.2.70 with the viewport in Linux.  It is refreshing faster.  I also am not constantly losing my icons on the top right corner if I have panes open on both sides anymore which happened a lot with DS 4.9.2.70 even in Windows, but not with DS 4.8.  Old scene files seem to be loading faster than they were with the older version as well so I'm really pleased with the new upgrade right now and how it's working in Linux.  And, the only thing I needed to do to keep CMS working was copy one file over from the old install to tell DS which port to use for the ProstgreSQL so I was really happy about that.  It took me forever to get CMS working!

  • brainmuffinbrainmuffin Posts: 1,205

    For giggles I downloaded the Studio for Windows and run it under WINE. It cannot connect to the PostgreSQL database. Gonna try some more stuff.

  • For giggles I downloaded the Studio for Windows and run it under WINE. It cannot connect to the PostgreSQL database. Gonna try some more stuff.

    I had the hardest time getting that to work.  So relieved when I finally got it.  It is the first time I had ever played with PostgreSQL at all.  I followed these directions to get things up and running but I kept messing something up.  I finally ended up copying and pasting everything.  I was also using a newer version of ProstgreSQL (9.5) than the instructions to I had to change this:

    CREATE EXTENSION citext
    SCHEMA public
    VERSION "1.0";

    To this:

    CREATE EXTENSION citext
    SCHEMA public
    VERSION "1.1";

    Otherwise you get an error about extension not found.  If you are using ProstgreSQL 9.4 these instructions should work as is.

  • brainmuffinbrainmuffin Posts: 1,205

    For giggles I downloaded the Studio for Windows and run it under WINE. It cannot connect to the PostgreSQL database. Gonna try some more stuff.

    I had the hardest time getting that to work.  So relieved when I finally got it.  It is the first time I had ever played with PostgreSQL at all.  I followed these directions to get things up and running but I kept messing something up.  I finally ended up copying and pasting everything.  I was also using a newer version of ProstgreSQL (9.5) than the instructions to I had to change this:

    CREATE EXTENSION citext
    SCHEMA public
    VERSION "1.0";

    To this:

    CREATE EXTENSION citext
    SCHEMA public
    VERSION "1.1";

    Otherwise you get an error about extension not found.  If you are using ProstgreSQL 9.4 these instructions should work as is.

    Thanks for the info. I'm experitmenting with some older hardware running Mint. So far, WOW runs under WINE, but Diable III does not (I really don't play that game these days, so no worries). If I can get Studio and Adobe CC to run, I will give serious thought to a new Linux build and stop using my iMac. It is not just Apple's disturbing lack of hardware updates that is prompting me to do so. I really want to get two arm mounted screens and a smaller desktop so I can have more work area. I don't have enough space with my 27" iMac and two other desktop machines to have another screen. As far as desktop Mac's, the only option is the Mac Pro and it is way, way underpowered for the price. I've also given serious thought to a Hackintosh build. I need more horsepower and I really don't want to run Windows.

  • Question for Kendall Sears or anyone who has gotten LAMH to work under Linux:

    What's the easiest way to get LAMH, full version, working in Linux?  I've tried installing with the .exe, but I get an error about not being able to create the Z:/DAZ directory.  After that, a previously working DAZ 4.0.3.166 install, crashes before booting up all the way.  Uninstalling LAMH fixes that issue.  I must be doing something wrong.  I miss LAMH!

  • Hold tight a little bit longer.  We're working on an update for the 1.x series.  I'll see what I can do to get things working in Wine again.

    Kendall

  • Hold tight a little bit longer.  We're working on an update for the 1.x series.  I'll see what I can do to get things working in Wine again.

    Kendall

    Ah, thanks Kendall!  I still have an emergency install of DAZ and LAMH in Windows on a little 1 TB drive so I'm not completely without it and can still work on my LAMH project, but it does mean that I have to actually go into Windows every time I want to work on the fur.  Posing I can still do inside of Linux, which is where I'm at most of the time now, and then I can just take the posing .dufs over to the Windows install to fine tune the fur.  

    This little project of mine with AM's Wolf 2.0 has just taken a lot longer to finish than I had anticipated with all of my computer hiccups.

  • kyoto kidkyoto kid Posts: 41,042
    edited February 2017

    ...with MS moving towards "Windows as a Service" with W10 it will mean more OS updates more often which can disrupt rendering/work sessions and risk introducing more instability.  Home Edition users pretty much have zero control over their systems anymore meaning you have to drop 199$ for Pro which only lets you defer updates for a couple months. Cortana cannot be done away with unless you are really good at registry hacking, no matter which edition you have. With all security and general updates now using the bundle/rollup format (even for W7 and 8.1) it has become an "all or nothing situation, no more "cherry picking" updates to avoid bad ones or ones you don't need

    We really need Daz to seriously consider supporting one of the more heavily used "flavours" of Linux that would be the most stable and up to date version for all of their offerings.

    Post edited by kyoto kid on
  • brainmuffinbrainmuffin Posts: 1,205
    kyoto kid said:

    ...with MS moving towards "Windows as a Service" with W10 it will mean more OS updates more often which can disrupt rendering/work sessions and risk introducing more instability.  Home Edition users pretty much have zero control over their systems anymore meaning you have to drop 199$ for Pro which only lets you defer updates for a couple months. Cortana cannot be done away with unless you are really good at registry hacking, no matter which edition you have. With all security and general updates now using the bundle/rollup format (even for W7 and 8.1) it has become an "all or nothing situation, no more "cherry picking" updates to avoid bad ones or ones you don't need

    We really need Daz to seriously consider supporting one of the more heavily used "flavours" of Linux that would be the most stable and up to date version for all of their offerings.

    I will try again to respond.

    I too would really like to see DAZ give serious attention to Linux. I moved to Mac several years ago and have purchased both Bryce and Studio Pro. Only the latter still works on Mac and the Windows version of the former is only 32 bit. Several months ago I considered moving to Windows 10 as Apple doesn't seem to want to seriously update their hardware, but after researching all the security and privacy issues, I decided not. I found a replacement for Final Cut Pro (it is Lightworks) and tried a few of the games I run under WINE on some old hardware. Studio is the only program holding me back.

  • FossilFossil Posts: 166

    There's no reason to not stick with Win7 for graphics.  I keep my graphics computer offline and use Linux online. 

  • brainmuffinbrainmuffin Posts: 1,205

    Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

  • Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    WINE is focused on parts that are not DS centric.  If DS were DirectX based, then it is likely that it would work better than it currently does in WINE.  The WINE crew are, sadly, not focused on the OpenGL layers.  The other part is that even though DS is a Qt program, WINE is *not* stubbed to use the Linux Qt libraries, but instead tries to use Windows Qt routines.  This results is numerous accumulating errors resulting in problems.  So far, no one in the WINE project crew has taken an interest in stubbing Qt to the native OS libraries.

    Kendall

  • Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    WINE is focused on parts that are not DS centric.  If DS were DirectX based, then it is likely that it would work better than it currently does in WINE.  The WINE crew are, sadly, not focused on the OpenGL layers.  The other part is that even though DS is a Qt program, WINE is *not* stubbed to use the Linux Qt libraries, but instead tries to use Windows Qt routines.  This results is numerous accumulating errors resulting in problems.  So far, no one in the WINE project crew has taken an interest in stubbing Qt to the native OS libraries.

    Kendall

    I think it's likely because they may be trying to minimized the number of libraries that WINE is dependent on, since each would have to become a compile time option if someone wasn't planning to use applications that required Qt, or other cross-platform GUI development toolkits.

  • Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    WINE is focused on parts that are not DS centric.  If DS were DirectX based, then it is likely that it would work better than it currently does in WINE.  The WINE crew are, sadly, not focused on the OpenGL layers.  The other part is that even though DS is a Qt program, WINE is *not* stubbed to use the Linux Qt libraries, but instead tries to use Windows Qt routines.  This results is numerous accumulating errors resulting in problems.  So far, no one in the WINE project crew has taken an interest in stubbing Qt to the native OS libraries.

    Kendall

    I think it's likely because they may be trying to minimized the number of libraries that WINE is dependent on, since each would have to become a compile time option if someone wasn't planning to use applications that required Qt, or other cross-platform GUI development toolkits.

    Indeed.  However, it doesn't change the point that this is a major reason that DS and other Qt based programs have such a bad time being hosted in WINE.  Even if someone *did* stub in the Qt libraries, the question becomes whether the WINE crew would accept the mods since Qt is not a part of the base Windows library set.  There are similar complaints about wx and other widget sets as well.

    Kendall

  • kyoto kidkyoto kid Posts: 41,042
    Fossil said:

    There's no reason to not stick with Win7 for graphics.  I keep my graphics computer offline and use Linux online. 

    ...true to a point but once W7 reaches EOL in 2020, support from software vendors/developers will taper off. 

    For example, I've been using an open source character generator for a tabletop RPG I am involved in. Surprisingly the programme still supported XP until about a year an a half ago.  I have an old notebook that runs XP and was using that to maintain character and mission records without needing paper forms, as well as hold the complete library of rule/source books in fully indexed PDF format (a lot easier on the old joints than lugging 15 - 20 kilos of books around).  I could also make updates and record notes pertinent to the character at the time events in the game occurred (because of my arthritis, it is difficult and sometimes painful to print small enough to fill in the tiny spaces on pre printed record sheets as well as my handwriting is pretty illegible, even for me). 

    Now the oldest OS the programme supports is W7 which is only on the desktop system and thus not very "portable".  A W7 Home OEM probably costs more than the notebook is worth (and the programme above also does not support Linux). 

  • Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    As someone who has been using DS seriously in Wine for almost two months now, I'm wondering which things don't work well under Wine.  Other than the issue that some sliders don't work well while others are work perfectly, what features of the program itself don't work well?  I'm just curious.  I admit that I don't have all of my scripts and plug-ins installed yet so I'm sure some might be broken like LAMH with the recent update.  Day to day rendering in Iray seems to work fine.  Even the little bit I do in 3Delight seems to work well when I try it excluding user error.  What do I need to look out for that might give me problems with DS run under Wine?  

    I do have to say that, so far, it seems to be much more stable than it was when I was in Windows 10.

  • kyoto kidkyoto kid Posts: 41,042

    Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    WINE is focused on parts that are not DS centric.  If DS were DirectX based, then it is likely that it would work better than it currently does in WINE.  The WINE crew are, sadly, not focused on the OpenGL layers.  The other part is that even though DS is a Qt program, WINE is *not* stubbed to use the Linux Qt libraries, but instead tries to use Windows Qt routines.  This results is numerous accumulating errors resulting in problems.  So far, no one in the WINE project crew has taken an interest in stubbing Qt to the native OS libraries.

    Kendall

    I think it's likely because they may be trying to minimized the number of libraries that WINE is dependent on, since each would have to become a compile time option if someone wasn't planning to use applications that required Qt, or other cross-platform GUI development toolkits.

    Indeed.  However, it doesn't change the point that this is a major reason that DS and other Qt based programs have such a bad time being hosted in WINE.  Even if someone *did* stub in the Qt libraries, the question becomes whether the WINE crew would accept the mods since Qt is not a part of the base Windows library set.  There are similar complaints about wx and other widget sets as well.

    Kendall

    ...all the more why Daz needs to support Linux natively rather than relying on widgets.

  • kyoto kid said:

    Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    WINE is focused on parts that are not DS centric.  If DS were DirectX based, then it is likely that it would work better than it currently does in WINE.  The WINE crew are, sadly, not focused on the OpenGL layers.  The other part is that even though DS is a Qt program, WINE is *not* stubbed to use the Linux Qt libraries, but instead tries to use Windows Qt routines.  This results is numerous accumulating errors resulting in problems.  So far, no one in the WINE project crew has taken an interest in stubbing Qt to the native OS libraries.

    Kendall

    I think it's likely because they may be trying to minimized the number of libraries that WINE is dependent on, since each would have to become a compile time option if someone wasn't planning to use applications that required Qt, or other cross-platform GUI development toolkits.

    Indeed.  However, it doesn't change the point that this is a major reason that DS and other Qt based programs have such a bad time being hosted in WINE.  Even if someone *did* stub in the Qt libraries, the question becomes whether the WINE crew would accept the mods since Qt is not a part of the base Windows library set.  There are similar complaints about wx and other widget sets as well.

    Kendall

    ...all the more why Daz needs to support Linux natively rather than relying on widgets.

    The widgets in question are used on all three platforms for the user interface elements, rather than native ones; it's how software developers manage to keep the same look and feel of software between very different operating systems.

  • Another angle to this is understanding why Studio behaves so poorly under WINE. Perhaps a program more intune would work better and thereby be an option, even without direct Linux support.

    WINE is focused on parts that are not DS centric.  If DS were DirectX based, then it is likely that it would work better than it currently does in WINE.  The WINE crew are, sadly, not focused on the OpenGL layers.  The other part is that even though DS is a Qt program, WINE is *not* stubbed to use the Linux Qt libraries, but instead tries to use Windows Qt routines.  This results is numerous accumulating errors resulting in problems.  So far, no one in the WINE project crew has taken an interest in stubbing Qt to the native OS libraries.

    Kendall

    I think it's likely because they may be trying to minimized the number of libraries that WINE is dependent on, since each would have to become a compile time option if someone wasn't planning to use applications that required Qt, or other cross-platform GUI development toolkits.

    Indeed.  However, it doesn't change the point that this is a major reason that DS and other Qt based programs have such a bad time being hosted in WINE.  Even if someone *did* stub in the Qt libraries, the question becomes whether the WINE crew would accept the mods since Qt is not a part of the base Windows library set.  There are similar complaints about wx and other widget sets as well.

    Kendall

    True; there are always ways to do it, but it would be nice if the official version did this for us.

  • brainmuffinbrainmuffin Posts: 1,205

    As someone who has been using DS seriously in Wine for almost two months now, I'm wondering which things don't work well under Wine.  Other than the issue that some sliders don't work well while others are work perfectly, what features of the program itself don't work well?  I'm just curious.  I admit that I don't have all of my scripts and plug-ins installed yet so I'm sure some might be broken like LAMH with the recent update.  Day to day rendering in Iray seems to work fine.  Even the little bit I do in 3Delight seems to work well when I try it excluding user error.  What do I need to look out for that might give me problems with DS run under Wine?  

    I do have to say that, so far, it seems to be much more stable than it was when I was in Windows 10.

    I will fire up the Linux workstation and catalog them. Perhaps I've not tried hard enough.

Sign In or Register to comment.