Loading...
> >

Daz Studio Pro BETA - version 4.9.3.166! Release Candidate 5 (*UPDATED*)

1…5681011…29

Comments

  • kyoto kidkyoto kid Posts: 41,213
    Richard Haseltine said:
    kyoto kid said:
    Richard Haseltine said:
    nicstt said:
    Richard Haseltine said:
    nicstt said:
    rbtwhiz said:
    MEC4D said:

    Thanks Rob does that mean no more Transmitted color map ? if the map is ignored then all my shader work fall apart ..since it control the dermis skin layer  so I can place things like tattoos between the skin layers and not on top  , I need to install and check it out for myself

    Despite the fact that the property is mappable (i.e., varying) in Daz Studio (which we implemented based on the MDL spec stating that the coefficients are varying), Iray Photoreal only supports uniform (i.e., non-mapped) values (refer again to the quoted excerpt from the Iray Programmer's manual). This is basically notification that we've suppressed the warnings/errors in the log by (temporarily?) ignoring the map. Iray itself must support it before we can.

    -Rob

    To clarify, I'm taking from this that the Transmitted colour no longer has an effect? See image.

    So changeing the colour makes no changes? So pointless to add a texture?

    Maps are ignored, a colour value isn't if I am reading this correctly - the property has to be constant (a flat colour), not varying (an image map).

    Cheers. That sucks. Shant be upgrading then; I presume it will change when fixed?

    My reading is that this is DS adapting to the way Iray works - and it will change when Iray changes.

    ...so what does this mean for older texture maps converted with the generic Iray Uber Shader?

    Do the conversions even place a map in Transmitted colour? In any event, this is not a change in the way that Iray works (that's the point of the modification) but rather bringing the UI into alignment with the way iray works.

    ...apologies, I was geting confused with Base (which in 3DL is "Diffuse") colour.

  • RuphussRuphuss Posts: 2,631
    Richard Haseltine said:
    hzr said:

    Do you even care about improving the posing workflow in DS anymore? Or have you just abandoned doing anything in that regard? I have not seen any improvement in the most essential part of the program in years, and there are persistent bugs in regards to the power pose tools, and the pins not staying properly pinned in their translations, and many many other things that can turn this into a real chore.

    Pinning has been discussed on many previous ocasions, it is not a bug though I would agree it would be nice if the pins could be more resistant to movement, forcing the joints to bend instead. There's a thread discussing the Power Pose tool. The rest of your complaint is not clear - what changes are you wanting? There have been numerous tweaks - such as the addition of guides and snapping, and the ability to vary the coordinate system used.

    i think the question is not about discussions but if there is any intention to evolve things by the devs

  • nicsttnicstt Posts: 11,715
    kyoto kid said:
    Richard Haseltine said:
    kyoto kid said:
    Richard Haseltine said:
    nicstt said:
    Richard Haseltine said:
    nicstt said:
    rbtwhiz said:
    MEC4D said:

    Thanks Rob does that mean no more Transmitted color map ? if the map is ignored then all my shader work fall apart ..since it control the dermis skin layer  so I can place things like tattoos between the skin layers and not on top  , I need to install and check it out for myself

    Despite the fact that the property is mappable (i.e., varying) in Daz Studio (which we implemented based on the MDL spec stating that the coefficients are varying), Iray Photoreal only supports uniform (i.e., non-mapped) values (refer again to the quoted excerpt from the Iray Programmer's manual). This is basically notification that we've suppressed the warnings/errors in the log by (temporarily?) ignoring the map. Iray itself must support it before we can.

    -Rob

    To clarify, I'm taking from this that the Transmitted colour no longer has an effect? See image.

    So changeing the colour makes no changes? So pointless to add a texture?

    Maps are ignored, a colour value isn't if I am reading this correctly - the property has to be constant (a flat colour), not varying (an image map).

    Cheers. That sucks. Shant be upgrading then; I presume it will change when fixed?

    My reading is that this is DS adapting to the way Iray works - and it will change when Iray changes.

    ...so what does this mean for older texture maps converted with the generic Iray Uber Shader?

    Do the conversions even place a map in Transmitted colour? In any event, this is not a change in the way that Iray works (that's the point of the modification) but rather bringing the UI into alignment with the way iray works.

    ...apologies, I was geting confused with Base (which in 3DL is "Diffuse") colour.

    Difuse is what many render engines call it; base seems specific to IRAY.

  • Arnold CArnold C Posts: 740
    nicstt said:
    kyoto kid said:
    Richard Haseltine said:
    kyoto kid said:
    Richard Haseltine said:
    nicstt said:
    Richard Haseltine said:
    nicstt said:
    rbtwhiz said:
    MEC4D said:

    Thanks Rob does that mean no more Transmitted color map ? if the map is ignored then all my shader work fall apart ..since it control the dermis skin layer  so I can place things like tattoos between the skin layers and not on top  , I need to install and check it out for myself

    Despite the fact that the property is mappable (i.e., varying) in Daz Studio (which we implemented based on the MDL spec stating that the coefficients are varying), Iray Photoreal only supports uniform (i.e., non-mapped) values (refer again to the quoted excerpt from the Iray Programmer's manual). This is basically notification that we've suppressed the warnings/errors in the log by (temporarily?) ignoring the map. Iray itself must support it before we can.

    -Rob

    To clarify, I'm taking from this that the Transmitted colour no longer has an effect? See image.

    So changeing the colour makes no changes? So pointless to add a texture?

    Maps are ignored, a colour value isn't if I am reading this correctly - the property has to be constant (a flat colour), not varying (an image map).

    Cheers. That sucks. Shant be upgrading then; I presume it will change when fixed?

    My reading is that this is DS adapting to the way Iray works - and it will change when Iray changes.

    ...so what does this mean for older texture maps converted with the generic Iray Uber Shader?

    Do the conversions even place a map in Transmitted colour? In any event, this is not a change in the way that Iray works (that's the point of the modification) but rather bringing the UI into alignment with the way iray works.

    ...apologies, I was geting confused with Base (which in 3DL is "Diffuse") colour.

    Difuse is what many render engines call it; base seems specific to IRAY.

    It's just the naming, in a PBR system the diffuse color is called Albedo. The main difference between a common Diffuse Map and an Albedo Map is, that the Albedo Map shouldn't contain any directional light or ambient occlusion (which unfortunately is the case for most of the texture maps for the older DAZ figure generations).

  • kyoto kidkyoto kid Posts: 41,213

    ...so with this move to to bring the UI more into alignment with Iray, will that have an effect on 3DL?

  • MEC4DMEC4D Posts: 5,249

    It is only for the portion when Iray engine is selected to render and Uberiray base shaders  what are separate from 3DL

    kyoto kid said:

    ...so with this move to to bring the UI more into alignment with Iray, will that have an effect on 3DL?

     

  • kyoto kidkyoto kid Posts: 41,213

    ...concerned because it seems so many content creators are abandoning 3DL for Iray.  As content sales is what keeps Daz in business, I feel a bit worried for 3DL's future.

  • almahiedraalmahiedra Posts: 1,353

    Creating new shaders for shader builder is also broken in this beta  like in the general  version.

  • evilded777evilded777 Posts: 2,465

    It would appear that there may be something wrong with procedural shaders.  I first noticed it with A Touch of Dirt, Barbult reported the same issue and V3Digitimes said she experienced the same thing with her own shader and with Mec4D's procedural fabric shaders (I have not tried that yet). GPU fails to launch for rendering with these shaders.

  • Ghosty12Ghosty12 Posts: 2,065
    edited August 2016
    kyoto kid said:

    ...concerned because it seems so many content creators are abandoning 3DL for Iray.  As content sales is what keeps Daz in business, I feel a bit worried for 3DL's future.

    From what I am seeing in the store to me at least is that, pretty much most of the PA's here have completely abandoned 3DL in favour of Iray.. Which suits me fine since now don't have to worry about finding the funds to purchase their products.. At the rate things are going I reckon there will be little to no new 3DL compatible content by the end of next year or so which will be very bad for those of us who don't want/need Iray..  And that probably the last bastion of 3DL compatible content will be PC+ which is not so bad..

    Post edited by Ghosty12 on
  • V3DigitimesV3Digitimes Posts: 3,209
    evilded777 said:

    It would appear that there may be something wrong with procedural shaders.  I first noticed it with A Touch of Dirt, Barbult reported the same issue and V3Digitimes said she experienced the same thing with her own shader and with Mec4D's procedural fabric shaders (I have not tried that yet). GPU fails to launch for rendering with these shaders.

    Finally only Touch of Dirt crashes this version of Daz Studio(980 Ti), or "fails GPU" (GTX 980M). The procedural fabric shaders seem to be ok.

  • hzrhzr Posts: 207
    Richard Haseltine said:
    hzr said:

    Do you even care about improving the posing workflow in DS anymore? Or have you just abandoned doing anything in that regard? I have not seen any improvement in the most essential part of the program in years, and there are persistent bugs in regards to the power pose tools, and the pins not staying properly pinned in their translations, and many many other things that can turn this into a real chore.

    Pinning has been discussed on many previous ocasions, it is not a bug though I would agree it would be nice if the pins could be more resistant to movement, forcing the joints to bend instead. There's a thread discussing the Power Pose tool. The rest of your complaint is not clear - what changes are you wanting? There have been numerous tweaks - such as the addition of guides and snapping, and the ability to vary the coordinate system used.

    It IS a bug because the powerpose pinning works perfectly fine on figures prior to genesis3. And I assume that the pins are moving due to the newly introduced twist bones inside the joint structure. Something regarding to those probably is responsible for the pins not staying in place. And this makes posing with powerpose completely annoying, because the pins wont stay fixed - which is one of the main advantages of powerpose in the first place.

    Same goes for power pose pins becoming giant in size the further you move a figure away from the scene root coordinates, something I posted over a year ago and not even got a single response to it from any of you.

    The posing itself could be improved alot by allowing for quicker rotations with mousewheel etc, I posted some ideas about this years ago, just check my posts if you like to see what I mean.

    Dollying with the mouse around figures randomly stutters, or completely stops sometimes as if theres some magical barrier where the mouse doesnt want to drag anymore, that happens sometimes, not always though.

    There are so many annoying things regarding to workflow in DS, and all I see in additions during the last couple years have been render engine related and the new content management stuff. I dont want to bash your effort in those areas, but to me it is a shame that an application that is there for posing those figures, still feels rather clunky when it comes to actually posing the figures.

     

    To your question of what I want :

    - Efficient and intuitive posing controls.

    - Translate and Rotate gizmos that you can properly identify as to which direction the rotations are facing, and which you can properly hit without unselecting them and accidentally selecting something beneath them.

    - Multiple joints selected in viewport and the ability to move them at the same time within the viewport and not just inside the parameters tab.

    - an alternate rig that is comparable to what you can do in Maya or other 3d tools. Thats asking alot I know, but you asked me what I want :)

     

    And dont get me wrong. Not everything in DS is bad, but the posing really needs alot of improvement as it stands now. I have been using it since 2010 and do something with it almost every day, posing for image series, which means I pose ALOT and the more you use it, the more obvious it becomes that things could and should be improved. DS is your platform where users get hooked to the figures, which then brings in more sales for you, so you should make sure that the users have a comfortable time with it, that goes beyond just loading a prefab pose, put on some clothes and hit render with iray and then wait 2 hours.

  • MEC4DMEC4D Posts: 5,249
    edited August 2016

    I noticed couple of shaders not working in Beta but maybe because there is no base included with Beta .. the GPU fail to render as I posted early with some custom shaders as well and nobody know why , I hope they fix it until the general release .

    evilded777 said:

    It would appear that there may be something wrong with procedural shaders.  I first noticed it with A Touch of Dirt, Barbult reported the same issue and V3Digitimes said she experienced the same thing with her own shader and with Mec4D's procedural fabric shaders (I have not tried that yet). GPU fails to launch for rendering with these shaders.

     

    Post edited by MEC4D on
  • MEC4DMEC4D Posts: 5,249

    My procedural shaders from vol.2  working just fine .. I checked it the other day  no issues with any of my shaders from the store

    the only error I found with other custom shaders was the limit of textures allowed was reached and GPU fails .

    V3Digitimes said:
    evilded777 said:

    It would appear that there may be something wrong with procedural shaders.  I first noticed it with A Touch of Dirt, Barbult reported the same issue and V3Digitimes said she experienced the same thing with her own shader and with Mec4D's procedural fabric shaders (I have not tried that yet). GPU fails to launch for rendering with these shaders.

    Finally only Touch of Dirt crashes this version of Daz Studio(980 Ti), or "fails GPU" (GTX 980M). The procedural fabric shaders seem to be ok.

     

  • barbultbarbult Posts: 24,781

    Mec4D, I don't understand what this means: "no base included with Beta". Can you explain further, please?

  • MEC4DMEC4D Posts: 5,249

     Base shader MDL block , but forget about they are included in Beta at Program Files\DAZ 3D\DAZStudio4 Public Build\shaders\iray\nvidia , just checked 

    the issue with some shaders may be with the new iray build 2016.1.2 and maybe MDL edition ,  Uberiray works fine but some custom shaders does not work anymore and the fact that they was made from the same MDL blocks is weird , I wonder what changed and what will change again with iray 2016.2 in the future , I know there are issues with shaders on instances in the last 2 Betas .. 

    barbult said:

    Mec4D, I don't understand what this means: "no base included with Beta". Can you explain further, please?

     

  • Richard HaseltineRichard Haseltine Posts: 102,464
    hzr said:
    Richard Haseltine said:
    hzr said:

    Do you even care about improving the posing workflow in DS anymore? Or have you just abandoned doing anything in that regard? I have not seen any improvement in the most essential part of the program in years, and there are persistent bugs in regards to the power pose tools, and the pins not staying properly pinned in their translations, and many many other things that can turn this into a real chore.

    Pinning has been discussed on many previous ocasions, it is not a bug though I would agree it would be nice if the pins could be more resistant to movement, forcing the joints to bend instead. There's a thread discussing the Power Pose tool. The rest of your complaint is not clear - what changes are you wanting? There have been numerous tweaks - such as the addition of guides and snapping, and the ability to vary the coordinate system used.

    It IS a bug because the powerpose pinning works perfectly fine on figures prior to genesis3. And I assume that the pins are moving due to the newly introduced twist bones inside the joint structure. Something regarding to those probably is responsible for the pins not staying in place. And this makes posing with powerpose completely annoying, because the pins wont stay fixed - which is one of the main advantages of powerpose in the first place.

    Same goes for power pose pins becoming giant in size the further you move a figure away from the scene root coordinates, something I posted over a year ago and not even got a single response to it from any of you.

    The posing itself could be improved alot by allowing for quicker rotations with mousewheel etc, I posted some ideas about this years ago, just check my posts if you like to see what I mean.

    Dollying with the mouse around figures randomly stutters, or completely stops sometimes as if theres some magical barrier where the mouse doesnt want to drag anymore, that happens sometimes, not always though.

    There are so many annoying things regarding to workflow in DS, and all I see in additions during the last couple years have been render engine related and the new content management stuff. I dont want to bash your effort in those areas, but to me it is a shame that an application that is there for posing those figures, still feels rather clunky when it comes to actually posing the figures.

     

    To your question of what I want :

    - Efficient and intuitive posing controls.

    - Translate and Rotate gizmos that you can properly identify as to which direction the rotations are facing, and which you can properly hit without unselecting them and accidentally selecting something beneath them.

    - Multiple joints selected in viewport and the ability to move them at the same time within the viewport and not just inside the parameters tab.

    - an alternate rig that is comparable to what you can do in Maya or other 3d tools. Thats asking alot I know, but you asked me what I want :)

     

    And dont get me wrong. Not everything in DS is bad, but the posing really needs alot of improvement as it stands now. I have been using it since 2010 and do something with it almost every day, posing for image series, which means I pose ALOT and the more you use it, the more obvious it becomes that things could and should be improved. DS is your platform where users get hooked to the figures, which then brings in more sales for you, so you should make sure that the users have a comfortable time with it, that goes beyond just loading a prefab pose, put on some clothes and hit render with iray and then wait 2 hours.

    Do you mean Power Pose or Active Pose? The pin and drag tool is Active pose, which I haven't used for a while.

    - Multiple joints selected in viewport and the ability to move them at the same time within the viewport and not just inside the parameters tab.

    have a look at the current beta, try enabling Secondary Nodes in Tool Settings.

  • barbultbarbult Posts: 24,781

    Why am I getting this repeatedly in my log file?

    2016-08-23 18:19:59.440 WARNING: cloud\dzcloudtasknotifier.cpp(178): Failed to read https://hpclscruffy.daz3d.com/Server/ping?SID=9skohid92ud8e6v5brfqiugv00 trying again, curl error was: Timeout was reached

     

  • RobotHeadArtRobotHeadArt Posts: 917
    barbult said:

    Why am I getting this repeatedly in my log file?

    2016-08-23 18:19:59.440 WARNING: cloud\dzcloudtasknotifier.cpp(178): Failed to read https://hpclscruffy.daz3d.com/Server/ping?SID=9skohid92ud8e6v5brfqiugv00 trying again, curl error was: Timeout was reached

     

    I think DAZ's infrastructure is having a meltdown from today's traffic.  I can't login to DIM or Connect in DAZ Studio, guessing you're already logged in?

  • barbultbarbult Posts: 24,781
    RobotHeadArt said:
    barbult said:

    Why am I getting this repeatedly in my log file?

    2016-08-23 18:19:59.440 WARNING: cloud\dzcloudtasknotifier.cpp(178): Failed to read https://hpclscruffy.daz3d.com/Server/ping?SID=9skohid92ud8e6v5brfqiugv00 trying again, curl error was: Timeout was reached

     

    I think DAZ's infrastructure is having a meltdown from today's traffic.  I can't login to DIM or Connect in DAZ Studio, guessing you're already logged in?

    Yes, I am already logged in.

  • SpyroRueSpyroRue Posts: 5,020

    So I am having an issue with the beta (the last several actually), apparently its ignoring that I have ticked only the GPU and Unticked CPU entirely in the advanced hardware tab in both devices. I have had several renders that are taking an unusually long time for me, and I discovered its ran my CPU up to 100% instead of my specified graphics card with a 0% load. Is DS supposed to ignore that I specified only the Gpu? Im guessing its exceeded the memory... Just its annoying that it ignored my setting.

  • barbultbarbult Posts: 24,781
    SpyroRue said:

    So I am having an issue with the beta (the last several actually), apparently its ignoring that I have ticked only the GPU and Unticked CPU entirely in the advanced hardware tab in both devices. I have had several renders that are taking an unusually long time for me, and I discovered its ran my CPU up to 100% instead of my specified graphics card with a 0% load. Is DS supposed to ignore that I specified only the Gpu? Im guessing its exceeded the memory... Just its annoying that it ignored my setting.

    The same thing happens for me. If it exceeds the memory of my card, it renders with the CPU, even though I have CPU unchecked. I am currently running 4.9.3.71.

  • JackFosterJackFoster Posts: 143
    edited August 2016

    Yes, it's always done that, ever since Iray was released for DS. Even if CPU is unchecked, if all GPUs fail for any reason, it will render with CPU. That's not new to the beta.

    However, it would be nice if the render would just cancel if CPU was unchecked and the GPUs fail. Now that I'm used to GPU speed, I don't even want to bother with CPU rendering. I'd rather just have it immediately cancel so that I can find a way to get the GPU working.

    Post edited by JackFoster on
  • MEC4DMEC4D Posts: 5,249

    That have to do with the shaders you use or instances with shaders , the shaders need to be edited to make it works in beta .  

    SpyroRue said:

    So I am having an issue with the beta (the last several actually), apparently its ignoring that I have ticked only the GPU and Unticked CPU entirely in the advanced hardware tab in both devices. I have had several renders that are taking an unusually long time for me, and I discovered its ran my CPU up to 100% instead of my specified graphics card with a 0% load. Is DS supposed to ignore that I specified only the Gpu? Im guessing its exceeded the memory... Just its annoying that it ignored my setting.

     

  • MEC4DMEC4D Posts: 5,249

    I never had this issues until now and not with the Beta as a bad build but with some of the shaders that was created for the early DS build versions . 

    If the CPU was unchecked your program would crash and you can get Blue screen when the display fail or even damage the system as it happened to me 2 days ago the kernel was damaged after the system shut down and need repair my System thanks to custom shader I used ( not mine )  this is serious issue but easy to fix , if you experience any issue like that with the Beta do not use the shader you expecting to do that , and any other than Uberiray can do that error. Check your log files for warnings and errors  and report the shader bug

    JackFoster said:

    Yes, it's always done that, ever since Iray was released for DS. Even if CPU is unchecked, if all GPUs fail for any reason, it will render with CPU. That's not new to the beta.

    However, it would be nice if the render would just cancel if CPU was unchecked and the GPUs fail. Now that I'm used to GPU speed, I don't even want to bother with CPU rendering. I'd rather just have it immediately cancel so that I can find a way to get the GPU working.

     

  • JackFosterJackFoster Posts: 143
    MEC4D said:

    I never had this issues until now and not with the Beta as a bad build but with some of the shaders that was created for the early DS build versions . 

    If the CPU was unchecked your program would crash and you can get Blue screen when the display fail or even damage the system as it happened to me 2 days ago the kernel was damaged after the system shut down and need repair my System thanks to custom shader I used ( not mine )  this is serious issue but easy to fix , if you experience any issue like that with the Beta do not use the shader you expecting to do that , and any other than Uberiray can do that error. Check your log files for warnings and errors  and report the shader bug

    No, I've definitely never experienced that from the release version. I don't have the beta, I'm just saying that it's always reverted to using CPU if the GPU(s) fail, even if CPU is unchecked. I thought that was all SpyroRue and barbult were referring to.

  • BBlogoBBlogo Posts: 54

    Is it normal that everytime I add items in a product by 'copy > paste reference' all the metadatas are lost ??

  • MEC4DMEC4D Posts: 5,249

    Yeah the CPU is set this way in all build versions i't is your security  to protect your scene files and I think very good , it give you a chance to save the scene and prevent from crashing 

    JackFoster said:
    MEC4D said:

    I never had this issues until now and not with the Beta as a bad build but with some of the shaders that was created for the early DS build versions . 

    If the CPU was unchecked your program would crash and you can get Blue screen when the display fail or even damage the system as it happened to me 2 days ago the kernel was damaged after the system shut down and need repair my System thanks to custom shader I used ( not mine )  this is serious issue but easy to fix , if you experience any issue like that with the Beta do not use the shader you expecting to do that , and any other than Uberiray can do that error. Check your log files for warnings and errors  and report the shader bug

    No, I've definitely never experienced that from the release version. I don't have the beta, I'm just saying that it's always reverted to using CPU if the GPU(s) fail, even if CPU is unchecked. I thought that was all SpyroRue and barbult were referring to.

     

  • SpyroRueSpyroRue Posts: 5,020
    MEC4D said:

    That have to do with the shaders you use or instances with shaders , the shaders need to be edited to make it works in beta .  

    SpyroRue said:

    So I am having an issue with the beta (the last several actually), apparently its ignoring that I have ticked only the GPU and Unticked CPU entirely in the advanced hardware tab in both devices. I have had several renders that are taking an unusually long time for me, and I discovered its ran my CPU up to 100% instead of my specified graphics card with a 0% load. Is DS supposed to ignore that I specified only the Gpu? Im guessing its exceeded the memory... Just its annoying that it ignored my setting.

     

    I only use Iray Uber at this stage, not too many have made standalone shader, mostly are all material/shader presets for Uber. It is possible remnants of the old 4.8 version of Iray Uber coming through from older scene files Ive merged in... I should refresh the code by reapplying the shader I suppose. But I was and have been using instances a lot, its been part of my workflow for a very long time. I did notice since 4.8 they've been much more resources hungry, maybe they chewing up excessive memory. A friend of mine pointed out switching instancing mode from Speed to Memory, something I overlooked too, maybe the root of my problem.

    In the past I have not had DS switch itself to CPU when specifically only GPU was selected, perhaps I just didn't exceed my Vram. Maybe I am just getting a little too ambitious laugh 

  • WendyLuvsCatzWendyLuvsCatz Posts: 38,535
    edited August 2016

    Yes   @SpyroRue I found that out using Howies Harpwood lane it crashes with speed

     

    Post edited by WendyLuvsCatz on
Sign In or Register to comment.