Daz Studio Pro BETA - version 4.15.0.30! (*UPDATED*)

1568101126

Comments

  • Richard Haseltine said:

    jbowler said:

    nicstt said:

    I seem to recall we were recommended to use a specific type, is that still the case with Game Ready or Studio?

    NVidia recomments the Studio drivers and Daz (in the troubleshooting file) recommends running the driver in TCC (not WDDM) mode if there is no monitor attached however the latter prevents the card being used for dForce.  So far as I can see the drivers with an identical version number are identical; the difference is that NVidia normally release the Studio driver after the Game Ready driver, I suspect so that the GR driver has been tested in the field.  When there is a really serious bug in the released driver it seems that Studio and GR get released simultaneously.

    TCC is not an option for most consumer cards

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

  • WendyLuvsCatzWendyLuvsCatz Posts: 37,924
    edited January 2021

    jbowler said:

    WendyLuvsCatz said:

    oh BTW on the issue I am only having because I am using Filament (and presumably HDR files others are not using) the very same scene the HDR I added shows in iray, if I save the scene using Filament adds the ruins one back even after using purge or clear undo stack, iray still shows the correct one.

    It is working for me however there is a LONG delay before the update when using 16k HDRIs from hdrihaven.  The change to the dome seems to be happening in the background; I can load a new HDRI then go back to the filament render and pan the view a few times, maybe 10s, before the new dome displays.  This is on an system with 64GByte of DRAM and a fast processor (a couple of years old now).

    What's happening in the parameters tab?  I.e. select the "Environment Options" node in the scene, go to Parameters and however over the picture of the dome in the "Environment Map" setting?  I see the new HDRI appear there when I load it (from Browse... on that setting), then after 10s or so the Filament view updates.  It's comparable to the time to show the Environment Parameters pane the first time; I assume DAZ is loading the HDRI into memory in both cases.

    It is true that the HDRI scaling issue has been fixed in the beta; in the original versions (and I think, still, the general release but I haven't checked) the Filament display would show the HDRI at completely the wrong scale, as though it had calculated the angle to display from the focal length incorrectly.

    what you describe is happening with most other HDR images but those particular ones are the problem it seems DTSS-Substance-#.HDR

    I actually think they are meant to be textures but I have all my HDR files copied to one folder for ease of access

    https://www.daz3d.com/strange-substances-pack-2

    they render fine with iray but Filament just won't accept them at all, they show in the parameter thumbnail

    I want them for scifi effects

    Post edited by WendyLuvsCatz on
  • jbowlerjbowler Posts: 745

    MeneerWolfman said:

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

    A Titan XP in my case.  It took me the length of time to discover DAZStudio doesn't support dForce; I had previously compared the Titan XP dForce with the CPU dForce and discovered the latter was unusably slow (I do do a lot of dForce) and that it didn't actually produce the same results as the XP; at the very least the explosions were different.  Since I use dForce so much TCC mode is not an option, unless I buy another one specifically for dForce, or maybe something cheaper that does OpenGL well (I think that is what dForce requires.)  The problem is that the XP on Amazon still costs more than the 3090 on NVidia's site; $1900 for an XP on Amazon, $1500 for a 3090 on NVidia.  Amusingly I apparently have a valuable antique; the Titan XP [Founder's edition no less] I got from NVidia on 1/16/2018 cost me $1200, $700 bucks profit, probably have to declare that.  eBay calls [not].

    Maybe I should just work out how to script Iray renders, then I could pull the XP out of my current rig, plonk it into a headless bitcoin miner style setup and just let it render the multi-hour renders I have the XP for elsewhere (in the garage to be precise).  So long as I have an on-board GPU to do test Iray renders a little faster than the CPU that actually runs the edit end of DAZStudio and to run dForce PDQ that would work.  I don't see any problem mirroring my content library to a render rig, that's an excellent application of rsync.

  • nicsttnicstt Posts: 11,714

    MeneerWolfman said:

    Richard Haseltine said:

    jbowler said:

    nicstt said:

    I seem to recall we were recommended to use a specific type, is that still the case with Game Ready or Studio?

    NVidia recomments the Studio drivers and Daz (in the troubleshooting file) recommends running the driver in TCC (not WDDM) mode if there is no monitor attached however the latter prevents the card being used for dForce.  So far as I can see the drivers with an identical version number are identical; the difference is that NVidia normally release the Studio driver after the Game Ready driver, I suspect so that the GR driver has been tested in the field.  When there is a really serious bug in the released driver it seems that Studio and GR get released simultaneously.

    TCC is not an option for most consumer cards

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

    Good to know, ty

     

  • RayDAntRayDAnt Posts: 1,122
    edited January 2021

    nicstt said:

    MeneerWolfman said:

    Richard Haseltine said:

    jbowler said:

    nicstt said:

    I seem to recall we were recommended to use a specific type, is that still the case with Game Ready or Studio?

    NVidia recomments the Studio drivers and Daz (in the troubleshooting file) recommends running the driver in TCC (not WDDM) mode if there is no monitor attached however the latter prevents the card being used for dForce.  So far as I can see the drivers with an identical version number are identical; the difference is that NVidia normally release the Studio driver after the Game Ready driver, I suspect so that the GR driver has been tested in the field.  When there is a really serious bug in the released driver it seems that Studio and GR get released simultaneously.

    TCC is not an option for most consumer cards

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

    Good to know, ty

    As a fellow Titan RTX owner, can also back this up. The rendering performance gain you get (something like 5-8%) from TCC mode simply isn't worth the practical drawbacks of not having the (likely) most multi-tasking capable graphics card in your system available for general graphics purposes.

     

    jbowler said:

    Maybe I should just work out how to script Iray renders, then I could pull the XP out of my current rig, plonk it into a headless bitcoin miner style setup and just let it render the multi-hour renders I have the XP for elsewhere (in the garage to be precise).  So long as I have an on-board GPU to do test Iray renders a little faster than the CPU that actually runs the edit end of DAZStudio and to run dForce PDQ that would work.  I don't see any problem mirroring my content library to a render rig, that's an excellent application of rsync.

    If you haven't yet, you should give Iray Server a try (the first month's a fully featured free trial.) Not only does it handle all the Iray render batch processing/cueing for you, it makes needing to duplicate your Daz content library between computers unecessary. The only downside (other than it being subsciption-ware after that first month) is that Daz has yet to tap into Iray Server's built-in animation rendering capabilities (which are actually quite powerful) available through the Bridge portion of the Iray API.

    Post edited by RayDAnt on
  • jbowlerjbowler Posts: 745
    edited January 2021

    WendyLuvsCatz said:

    what you describe is happening with most other HDR images but those particular ones are the problem it seems DTSS-Substance-#.HDR

    I actually think they are meant to be textures but I have all my HDR files copied to one folder for ease of access

    https://www.daz3d.com/strange-substances-pack-2

    they render fine with iray but Filament just won't accept them at all, they show in the parameter thumbnail

    I want them for scifi effects

    I've not tried using a texture for an HDRI until now.  I have used some of DimensionTheory's HDRIs.  I  just played with Platinum Pack 1, the room scene, and it seems to behave just as expected in Iray and identically with Filament.  The camera seems to be set 140cm above the floor and I think the dome may be tilted wrt the horizontal plane; I had to tilt my camera -1.2 degrees to get the near verticals vertical (using an 18mm lens to get a 90 degree FoV).

    When using a simple rectangular image Iray maps it in the [inverse of the] same way it maps a dome to an image with the lens distortion.  I used a 5184x3888 TIFF I have of a picture of an ice flow in Iceland, it's not exactly 2:1 aspect ratio, so the Iray mapping squishes the image, but the spherical lens distortion does reproduce the original image (the dome is rotated 90 degress in all these examples, this is why the "join" is down the middle):

    image

    So that really is the original image demonstrating the transform Iray uses (by the absence of any net transform, other than the squish).  When I render the scene in Iray using a 9mm lens (to get a 120 degree view) I get what I would expect.  When I render with Filament I get Ruins; so Filament ignores the set dome and goes back to the underlying DAZStudio default:

    Iray:  image  Filament: image  Iray rendering with the default (Ruins) background: image

    The difference in the last two renders is down to the 2EV difference in speed of Iray vs Filament; Filament is 2EV faster than Iray.  (There were also issues with the falloff of DAZStudio lights in Filament vs Iray, but I have not checked if those have been fixed.)  I guess just using a backdrop, not a dome, will probably work correctly although it won't provide any light.  An easier approach is to convert the texture into an HDRI using Iray, spherical lens distortion (2:1 aspect ratio), no tonemapping and a canvas; that converts the TIFF/PNG/whatever from the dome into a .exr which Filament should load correctly.

     

    Iceflow background, Iray render, spherical lens.jpg
    47K
    Iceflow background, Iray render.jpg
    48K
    Ruins HDRI, Filament render.jpg
    22K
    Ruins HDRI, Iray render.jpg
    22K
    Post edited by jbowler on
  • WendyLuvsCatzWendyLuvsCatz Posts: 37,924
    edited January 2021

    weird as it is in HDR format and Filament happily loads HDR I made myself from 360 and other images converted in Gimp

    I can try saving it from Gimp of course

    Facebook is fussy about the 2:1 ratio for 360 so that could be it

    Post edited by WendyLuvsCatz on
  • jbowlerjbowler Posts: 745

    WendyLuvsCatz said:

    weird as it is in HDR format and Filament happily loads HDR I made myself from 360 and other images converted in Gimp

    According to the web page DimensionTheory used HDR because the images have high dynamic range data, i.e. pixel values outside the range of sRGB, but the images are still rectangular (like my TIFF).  The high dynamic range isn't necessary for an environment dome but the image does need to be spherical; when DAZ/Iray maps my Iceland TIFF to an environment dome it is making some totally arbitrary decisions about how to do it.  So long as the rectangular images tile in X (horizontally), which of course my TIFF doesn't, the method I suggested will map the HDR rectangle to a seamless spherical HDR.  The GIMP or PhotoShop can probably do that as well and would give you more control; since the images are actually square (2048x2048) a better mapping might be to join the corners together, i.e. map the center of the square be at (0,0,-inf) and the corners (all) at (0,0,+inf).  I'm assuming the squares do tile on all edges so there won't be a seam, there will be distortion away from the center but it will probably be less obvious that the distortion which results from the default Iray behavior above (if you can see the images I posted; I should probably have re-encoded them as JPEG...)

  • RayDAnt said:

    nicstt said:

    MeneerWolfman said:

    Richard Haseltine said:

    jbowler said:

    nicstt said:

    I seem to recall we were recommended to use a specific type, is that still the case with Game Ready or Studio?

    NVidia recomments the Studio drivers and Daz (in the troubleshooting file) recommends running the driver in TCC (not WDDM) mode if there is no monitor attached however the latter prevents the card being used for dForce.  So far as I can see the drivers with an identical version number are identical; the difference is that NVidia normally release the Studio driver after the Game Ready driver, I suspect so that the GR driver has been tested in the field.  When there is a really serious bug in the released driver it seems that Studio and GR get released simultaneously.

    TCC is not an option for most consumer cards

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

    Good to know, ty

    As a fellow Titan RTX owner, can also back this up. The rendering performance gain you get (something like 5-8%) from TCC mode simply isn't worth the practical drawbacks of not having the (likely) most multi-tasking capable graphics card in your system available for general graphics purposes.

     

    jbowler said:

    Maybe I should just work out how to script Iray renders, then I could pull the XP out of my current rig, plonk it into a headless bitcoin miner style setup and just let it render the multi-hour renders I have the XP for elsewhere (in the garage to be precise).  So long as I have an on-board GPU to do test Iray renders a little faster than the CPU that actually runs the edit end of DAZStudio and to run dForce PDQ that would work.  I don't see any problem mirroring my content library to a render rig, that's an excellent application of rsync.

    If you haven't yet, you should give Iray Server a try (the first month's a fully featured free trial.) Not only does it handle all the Iray render batch processing/cueing for you, it makes needing to duplicate your Daz content library between computers unecessary. The only downside (other than it being subsciption-ware after that first month) is that Daz has yet to tap into Iray Server's built-in animation rendering capabilities (which are actually quite powerful) available through the Bridge portion of the Iray API.

    It isn't enough for the API to be available, it has to be matched up to DS (or rather, vice versa). The fact that it isn't currently supported doesn't imply that daz is ignoring the feature.

  • RayDAntRayDAnt Posts: 1,122
    edited January 2021

    Richard Haseltine said:

    RayDAnt said:

    nicstt said:

    MeneerWolfman said:

    Richard Haseltine said:

    jbowler said:

    nicstt said:

    I seem to recall we were recommended to use a specific type, is that still the case with Game Ready or Studio?

    NVidia recomments the Studio drivers and Daz (in the troubleshooting file) recommends running the driver in TCC (not WDDM) mode if there is no monitor attached however the latter prevents the card being used for dForce.  So far as I can see the drivers with an identical version number are identical; the difference is that NVidia normally release the Studio driver after the Game Ready driver, I suspect so that the GR driver has been tested in the field.  When there is a really serious bug in the released driver it seems that Studio and GR get released simultaneously.

    TCC is not an option for most consumer cards

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

    Good to know, ty

    As a fellow Titan RTX owner, can also back this up. The rendering performance gain you get (something like 5-8%) from TCC mode simply isn't worth the practical drawbacks of not having the (likely) most multi-tasking capable graphics card in your system available for general graphics purposes.

     

    jbowler said:

    Maybe I should just work out how to script Iray renders, then I could pull the XP out of my current rig, plonk it into a headless bitcoin miner style setup and just let it render the multi-hour renders I have the XP for elsewhere (in the garage to be precise).  So long as I have an on-board GPU to do test Iray renders a little faster than the CPU that actually runs the edit end of DAZStudio and to run dForce PDQ that would work.  I don't see any problem mirroring my content library to a render rig, that's an excellent application of rsync.

    If you haven't yet, you should give Iray Server a try (the first month's a fully featured free trial.) Not only does it handle all the Iray render batch processing/cueing for you, it makes needing to duplicate your Daz content library between computers unecessary. The only downside (other than it being subsciption-ware after that first month) is that Daz has yet to tap into Iray Server's built-in animation rendering capabilities (which are actually quite powerful) available through the Bridge portion of the Iray API.

    It isn't enough for the API to be available, it has to be matched up to DS (or rather, vice versa). The fact that it isn't currently supported doesn't imply that daz is ignoring the feature.

    To the best of my knowledge, the following DS changelog excerpt is the most recent official update made by the Daz development team regarding its progress on implementing animation rendering support via Iray Server:

    DAZ Studio : Incremented build number to 4.9.3.163

    • Source maintenance

    • Support for remote rendering via NVIDIA Iray has been updated to include the “batch” render mode for individual frames; support for animations requires more extensive/risky changes and is therefore not currently provided

    • Relabeled the “Cloud [BETA]” page, found on the Advanced page of the Render Settings pane when NVIDIA Iray is set as the active render engine, to “Bridge [BETA]”; this is consistent with the name now used by NVIDIA to refer to the feature

    • Added a “Connection” option to the “Bridge [BETA]” page for NVIDIA Iray > Advanced; allows a user to choose between “Iray Server” (default) and “Visual Computing Appliance (VCA)”

    • Added a “Port” option to the “Bridge [BETA]” page for NVIDIA Iray > Advanced that is displayed when Connection is set to Iray Server; allows the user to set which port on the server to communicate through

    • Encapsulated options on the “Bridge [BETA]” page for NVIDIA Iray > Advanced that relate to the “streaming” remote rendering mode in a “Streaming” group box

    • Added an “Add to Queue[…] button to the “Bridge [BETA]” page for NVIDIA Iray > Advanced; clicking the button will prompt for a Job Name if the Image Name property, found in the General > Destination property group on the Editor page of the Render Settings pane, is empty; clicking the button will use the specified configuration/authentication data to connect, upload the current frame of the scene and then disconnect

    • Extended DzIrayRenderer scripting API; added exportRenderToBridgeQueue()

    • Made changes to avoid [re]loading images for Iray Bridge renders once animations are supported

    • Made changes to naming of Iray Bridge snap shots; now uses jobName % '-' % frameNumber % '-' % uniqueName

     This statement is currently more than 4 years old... and if you go to the Bridge tab under Render Settings > Advanced in even the most current Beta release of Daz Studio (4.14.1.38), you will see that the feature implementation for Iray Server rendering remains identical to what is described in this 4+ year old changelog.

    Post edited by RayDAnt on
  • RayDAnt said:

    Richard Haseltine said:

    RayDAnt said:

    nicstt said:

    MeneerWolfman said:

    Richard Haseltine said:

    jbowler said:

    nicstt said:

    I seem to recall we were recommended to use a specific type, is that still the case with Game Ready or Studio?

    NVidia recomments the Studio drivers and Daz (in the troubleshooting file) recommends running the driver in TCC (not WDDM) mode if there is no monitor attached however the latter prevents the card being used for dForce.  So far as I can see the drivers with an identical version number are identical; the difference is that NVidia normally release the Studio driver after the Game Ready driver, I suspect so that the GR driver has been tested in the field.  When there is a really serious bug in the released driver it seems that Studio and GR get released simultaneously.

    TCC is not an option for most consumer cards

    Speaking as someone who has a card that can do TCC (Titan RTX), I can tell you it does bunk all in Daz and made using Daz a pain in the ass. Set it back to WDDM after a week of trying it out.

    Good to know, ty

    As a fellow Titan RTX owner, can also back this up. The rendering performance gain you get (something like 5-8%) from TCC mode simply isn't worth the practical drawbacks of not having the (likely) most multi-tasking capable graphics card in your system available for general graphics purposes.

     

    jbowler said:

    Maybe I should just work out how to script Iray renders, then I could pull the XP out of my current rig, plonk it into a headless bitcoin miner style setup and just let it render the multi-hour renders I have the XP for elsewhere (in the garage to be precise).  So long as I have an on-board GPU to do test Iray renders a little faster than the CPU that actually runs the edit end of DAZStudio and to run dForce PDQ that would work.  I don't see any problem mirroring my content library to a render rig, that's an excellent application of rsync.

    If you haven't yet, you should give Iray Server a try (the first month's a fully featured free trial.) Not only does it handle all the Iray render batch processing/cueing for you, it makes needing to duplicate your Daz content library between computers unecessary. The only downside (other than it being subsciption-ware after that first month) is that Daz has yet to tap into Iray Server's built-in animation rendering capabilities (which are actually quite powerful) available through the Bridge portion of the Iray API.

    It isn't enough for the API to be available, it has to be matched up to DS (or rather, vice versa). The fact that it isn't currently supported doesn't imply that daz is ignoring the feature.

    To the best of my knowledge, the following DS changelog excerpt is the most recent official update made by the Daz development team regarding its progress on implementing animation rendering support via Iray Server:

    DAZ Studio : Incremented build number to 4.9.3.163

    • Source maintenance

    • Support for remote rendering via NVIDIA Iray has been updated to include the “batch” render mode for individual frames; support for animations requires more extensive/risky changes and is therefore not currently provided

    • Relabeled the “Cloud [BETA]” page, found on the Advanced page of the Render Settings pane when NVIDIA Iray is set as the active render engine, to “Bridge [BETA]”; this is consistent with the name now used by NVIDIA to refer to the feature

    • Added a “Connection” option to the “Bridge [BETA]” page for NVIDIA Iray > Advanced; allows a user to choose between “Iray Server” (default) and “Visual Computing Appliance (VCA)”

    • Added a “Port” option to the “Bridge [BETA]” page for NVIDIA Iray > Advanced that is displayed when Connection is set to Iray Server; allows the user to set which port on the server to communicate through

    • Encapsulated options on the “Bridge [BETA]” page for NVIDIA Iray > Advanced that relate to the “streaming” remote rendering mode in a “Streaming” group box

    • Added an “Add to Queue[…] button to the “Bridge [BETA]” page for NVIDIA Iray > Advanced; clicking the button will prompt for a Job Name if the Image Name property, found in the General > Destination property group on the Editor page of the Render Settings pane, is empty; clicking the button will use the specified configuration/authentication data to connect, upload the current frame of the scene and then disconnect

    • Extended DzIrayRenderer scripting API; added exportRenderToBridgeQueue()

    • Made changes to avoid [re]loading images for Iray Bridge renders once animations are supported

    • Made changes to naming of Iray Bridge snap shots; now uses jobName % '-' % frameNumber % '-' % uniqueName

     This statement is currently more than 4 years old... and if you go to the Bridge tab under Render Settings > Advanced in even the most current Beta release of Daz Studio (4.14.1.38), you will see that the feature implementation for Iray Server rendering remains identical to what is described in this 4+ year old changelog.

    And as you stress, it says "support for animations requires more extensive/risky changes and is therefore not currently provided" - that suggests they are going to proceed with caution, and that it may have to wait until they are going to have to make changes in the related areas anyway. We don't know how far-reaching the changes would be.

  • Dolce SaitoDolce Saito Posts: 148
    edited January 2021

    Just a heads up for the animators; with the latest beta, there is a very serious trigger (somewhere) which causes undo stack to completely mess up and not register any of the changes made on the scene. In my case, undo stack bugging after;

    - Changing total frames incrementally to >= 500 (evey time an animation is added/edited between 50 towards 500)

    - Timeline frame starts from >=50

    When the bug triggers, whatever change you made on the scene is ignored and the last undo point always becomes "Undo change total frames >500". All other actions are missing from the undo stack. Translations/rotations/etc. (Yes I always work with TRSOAH, and never uncheck them)

    Trying to create a scenario where this happens again. Just a warning though...

    Edit: When I checked the log; the time it was bugged, the shutdown sequence of the DAZ showed the following without any other information in the log:

    2021-01-05 20:45:09.689 Clearing Undo Stack...
    2021-01-05 20:45:09.965 WARNING: ..\..\..\..\..\src\sdksource\general\dzundostack.cpp(739): DzUndoStack::clearAll() called with a non-zero hold level. Possible unclosed beginHold().
    2021-01-05 20:45:09.966 Deleting Scene...
    2021-01-05 20:45:21.565 *** Scene Cleared ***

    Post edited by Dolce Saito on
  • Guys, I'm getting this error randomly in the beta version. Is there any fix available? I got a gtx 1080ti and a 2080ti and I'm using the latest game ready drive (460.89). 

     

    2021-01-05 21:16:19.271 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.271 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.273 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.273 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.274 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.275 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error synching on OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: Error destroying OptixPipeline event (CUDA error string: an illegal memory access was encountered, CUDA error code: 700)
    2021-01-05 21:16:19.276 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER ::   1.14  IRAY   rend error: optixPipelineDestroy(pop_ptr(m_pipeline)) failed: CUDA error

     

  • @GutoCrafts:

    Does it also happen if you render with just one card?

    What is the VRAM usage on each card when this happens?

    You didn't exactly give us a lot of context here.

  • VoxxaVoxxa Posts: 64

    Hi! The later versions of Daz Studio have begun to ignore my GPU. When unticking the CPU and only using my Graphics card, DAZ Studio refuses to render. Will this be fixed in 4.15? As for now I can only render using my CPU.

  • WendyLuvsCatzWendyLuvsCatz Posts: 37,924
    edited January 2021

    Voxxa said:

    Hi! The later versions of Daz Studio have begun to ignore my GPU. When unticking the CPU and only using my Graphics card, DAZ Studio refuses to render. Will this be fixed in 4.15? As for now I can only render using my CPU.

    is it an older unsupported card? I think gtx6## series and below no longer are 

    Post edited by WendyLuvsCatz on
  • darko66darko66 Posts: 38

    4.15 beta is here. Most silent minor version update of Studio I've seen.

    Currently, the Higlights thread doesn't show change log yet.

  • darko66 said:

    4.15 beta is here. Most silent minor version update of Studio I've seen.

    Currently, the Higlights thread doesn't show change log yet.

    The Change Log itself has been updated.

  • jbowlerjbowler Posts: 745

    darko66 said:

    4.15 beta is here. Most silent minor version update of Studio I've seen.

    The 4.15 general release seems to be there too...

  • EnvixerEnvixer Posts: 58

    4.15 hasn't fixed the issue of environment settings not being saved if the map is set to none...

  • jbowlerjbowler Posts: 745

    Envixer said:

    4.15 hasn't fixed the issue of environment settings not being saved if the map is set to none...

    I think it is a bug in reading the scene; 4.14 is saving the environment settings (e.g. turn on "Draw Dome") but it seems to ignore the "image":null entry; turn on "Draw Dome", save the scene, read it back in and "Environment Options" gets created but the map is set to Ruins.  A Render Settings... preset will, however, set the map to None as in the attached Render Settings... preset (I edited it to remove the Iray and General settings that remain even when they are not selected):

    "scene" : { "extra" : [ {
    "type" : "studio_render_settings",
    "render_options" : {
    "render_elements" : [{
       "id" : "Environment Options",
       "channels" : [{
          "channel" : {
          "id" : "Environment Map",
          "type" : "float",
          "current_value" : 2,
          "image" : null
       }}]
    }]}}]}

    duf
    duf
    Set Environment map to None.duf
    725B
  • jbowlerjbowler Posts: 745

    It looks like no improvements have been made to the long open/load/close times in 4.15.  Here are the results from timing (mainly based on times in the log file) for a test scene with architecture, props, a dome, 2 G8F and one G8M:

    Scene load time: 4:04.371 (from log file)
    DAZStudio close time: 3:58.118 (from log file; "Deleting Scene" to the last entry in the log file).
    Close time with my work-round: About 1 minute (based on the time from the end of the load to the last entry in the log file - almost exactly 1 minute).

    There seems to have been a correction to the 2EV overexposure problem in Filament rendering; I'm still checking that out but the viewport Filament rendering is now much closer in exposure to the Iray render.

  • jbowlerjbowler Posts: 745

    jbowler said:

    There seems to have been a correction to the 2EV overexposure problem in Filament rendering; I'm still checking that out but the viewport Filament rendering is now much closer in exposure to the Iray render.

    That's incorrect.  The 2EV bug with respect to dome (Environment Map) illumination is still present.

  • Daedalus-7Daedalus-7 Posts: 198
    edited January 2021

    Just updated to 4.15. I disabled my CPU in both interactive and Photoreal modes. 

    Rendering happens with no issues in both modes. Pretty fast too. Graphics card is a GTX 1060 with 6GB.

    Post edited by Daedalus-7 on
  • FrinkkyFrinkky Posts: 388
    edited January 2021

    I'm getting the same issue as 4.14 - opening the program brings up the splash screen, the main program window appears and within a couple of seconds it freezes - no element responds to mouseover or click. hen he program just closes. The last few lines in the log file are:

    2021-01-09 13:46:30.153 Creating Script Engine...2021-01-09 13:46:30.169 WARNING: 3DConnexion Plug-in Error: Could not create Device, CoCreateInstance failed2021-01-09 13:46:30.169 3D mouse support library could not be loaded.2021-01-09 13:46:30.170 Creating Main Window...2021-01-09 13:46:30.171 Creating Viewport Manager...2021-01-09 13:46:30.213 Successfully created OpenGL viewport for Viewport1.2021-01-09 13:46:30.303 Successfully created OpenGL viewport for Viewport2.2021-01-09 13:46:30.362 Successfully created OpenGL viewport for Viewport3.2021-01-09 13:46:30.419 Successfully created OpenGL viewport for Viewport4.2021-01-09 13:46:30.526 Creating Action Manager...2021-01-09 13:46:30.537 Creating Pane Manager...2021-01-09 13:46:30.706 Successfully created OpenGL viewport for AuxViewportView.2021-01-09 13:46:31.362 WARNING: QFile::flush: No file engine. Is IODevice open?2021-01-09 13:46:31.473 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_pslJpegSaveQuality_valueChanged(int)2021-01-09 13:46:31.478 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_sldAniImageQuality_valueChanged(int)2021-01-09 13:46:31.484 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_bbnRestartDriver_released()2021-01-09 13:46:31.564 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_ptbEditNodeGraph_released()2021-01-09 13:46:33.841 Started in: C:/Program Files/DAZ 3D/DAZStudio4 Public Build2021-01-09 13:46:33.841 DAZ Studio Started2021-01-09 13:46:33.842 Creating Pixel Buffer2021-01-09 13:46:33.867 Pixel buffer - Width: 1024 Height: 10242021-01-09 13:46:33.868 Compiling OpenGL Shader...

     

    So it seems to be an opengl issue...

    I'm running this on a 4790K cpu (iGPU disabled), 32gb ram and a 1070ti. 

    Any ideas would be appreciated. As stated above, I've been having this problem since 4.14 beta so presumably Filament related? I won't try a 4.14 or 4.15 main release as that would overwrite my only working version (4.12).

    It does work on my laptop, 8750H 16gb + 1070 8gb.

    Post edited by Frinkky on
  • Frinkky said:

    I'm getting the same issue as 4.14 - opening the program brings up the splash screen, the main program window appears and within a couple of seconds it freezes - no element responds to mouseover or click. hen he program just closes. The last few lines in the log file are:

    2021-01-09 13:46:30.153 Creating Script Engine...2021-01-09 13:46:30.169 WARNING: 3DConnexion Plug-in Error: Could not create Device, CoCreateInstance failed2021-01-09 13:46:30.169 3D mouse support library could not be loaded.2021-01-09 13:46:30.170 Creating Main Window...2021-01-09 13:46:30.171 Creating Viewport Manager...2021-01-09 13:46:30.213 Successfully created OpenGL viewport for Viewport1.2021-01-09 13:46:30.303 Successfully created OpenGL viewport for Viewport2.2021-01-09 13:46:30.362 Successfully created OpenGL viewport for Viewport3.2021-01-09 13:46:30.419 Successfully created OpenGL viewport for Viewport4.2021-01-09 13:46:30.526 Creating Action Manager...2021-01-09 13:46:30.537 Creating Pane Manager...2021-01-09 13:46:30.706 Successfully created OpenGL viewport for AuxViewportView.2021-01-09 13:46:31.362 WARNING: QFile::flush: No file engine. Is IODevice open?2021-01-09 13:46:31.473 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_pslJpegSaveQuality_valueChanged(int)2021-01-09 13:46:31.478 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_sldAniImageQuality_valueChanged(int)2021-01-09 13:46:31.484 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_bbnRestartDriver_released()2021-01-09 13:46:31.564 WARNING: QMetaObject::connectSlotsByName: No matching signal for on_ptbEditNodeGraph_released()2021-01-09 13:46:33.841 Started in: C:/Program Files/DAZ 3D/DAZStudio4 Public Build2021-01-09 13:46:33.841 DAZ Studio Started2021-01-09 13:46:33.842 Creating Pixel Buffer2021-01-09 13:46:33.867 Pixel buffer - Width: 1024 Height: 10242021-01-09 13:46:33.868 Compiling OpenGL Shader...

     

    So it seems to be an opengl issue...

    I'm running this on a 4790K cpu (iGPU disabled), 32gb ram and a 1070ti. 

    Any ideas would be appreciated. As stated above, I've been having this problem since 4.14 beta so presumably Filament related? I won't try a 4.14 or 4.15 main release as that would overwrite my only working version (4.12).

    It does work on my laptop, 8750H 16gb + 1070 8gb.

    What is the OS version,video card and driver version?

  • FishtalesFishtales Posts: 6,045

    Just downloaded the Beta and loaded an old scene. Clicking on the Render button opens up the Save image window.

  • mikmodmikmod Posts: 65
    edited January 2021

    Fishtales said:

    Just downloaded the Beta and loaded an old scene. Clicking on the Render button opens up the Save image window.

    It's probably because "Render Target" option is set like this in Render settings? When there's no filename in "Image Name" text field, like in this screen shot, "Save Image" window will indeed pop up.

    2021-01-09 173707.png
    393 x 171 - 31K
    Post edited by mikmod on
  • FishtalesFishtales Posts: 6,045

    mikmod said:

    Fishtales said:

    Just downloaded the Beta and loaded an old scene. Clicking on the Render button opens up the Save image window.

    It's probably because "Render Target" option is set like this in Render settings? When there's no filename in "Image Name" text field, like in this screen shot, "Save Image" window will indeed pop up.

    Thank you. That was it although I have never changed that from New Window since I started using Studio years ago :) 

  • glaseyeglaseye Posts: 1,311

    jbowler said:

    darko66 said:

    4.15 beta is here. Most silent minor version update of Studio I've seen.

    The 4.15 general release seems to be there too...

    Where? It's not in my product library. (and just for the record; I don't use any content mangler systems, strictly manual dl and install to my specific installation needs for my content and various 3d-programs setup)

Sign In or Register to comment.