You may write you own using MDL block or use the way it is now in Uberiray to get the same effect with IOR and SSS as was in the Handbook by using the Transmitted color +Transmitted Distance+SSS Amount+IOR skipping the Translucent channel for creating semi opaque materials like glass or others , the Amount of SSS is a density of the model (thickness of the walls ) so I don't see the effect of RGB color here for that function you have Transmitted color +Transmitted Distance under SSS , in Uberiray you have 2 ways of creating SSS surfaces, one via translucency +SSS and another with IOR +SSS for volumetric glass or water shader with absorption .
When I use Optix ON with 1 to max 3 cards the render time is very much slower on my system for example 1 card Optix ON = 3 min , 1card Optix Off =1 min Optix ON reduce the GPU scale with 1 to 3 cards, but with 4 cards Optix ON improve the speed and GPU scale ..
Short question: Iray 2016.1 supports Subsurface Scattering in full color now, instead of previously only in greyscale (like explained in chapter 7.5 "Subsurface scattering as a model of glass" of the Material Definition Language — Handbook). Will we get a RGB color input field on the Sufarce Tab for the SSS Amount parameter replacing the slider there? Like the one we already have for Transmitted Color.
Nice work on the most recent Iray renderer plugin. Since the very first Beta I usually run some (five) testrenders to see how fast the new build would render, using the default "Material Ball" scene (Instancing Optimization: Speed, Optix Prime Acceleration: ON and GPU Only, on a Gainward GeForce GT 730 2048MB SilentFX). DS 4.8.0.55 needed 935 iterations and 3 minutes 36 seconds, average, to reach default threshold for that scene.
DS 4.9.1.30 had a 158% increase (192 iterations and 5 minutes 42 seconds average), and the actual DS 4.9.2.70 still a 133% increase in render time (1057 iterations, 4 minutes 48 seconds average). Slightly faster, but not as fast as the initial Iradium General Release. Initialisation times had been increased from 4.9 seconds average (4.8.0.55) to 72.7 seconds (4.9.1.30), and again decreased to 14.7 seconds average for 4.9.2.70.
DS 4.9.3.56 (Beta) is now the first one to be acually faster than the initial Iradium General Release, with 532 iterations and 2 minutes 30 seconds average it's around 31% faster, and initialisation time's now at 4.5 seconds average.
You may write you own using MDL block or use the way it is now in Uberiray to get the same effect with IOR and SSS as was in the Handbook by using the Transmitted color +Transmitted Distance+SSS Amount+IOR skipping the Translucent channel for creating semi opaque materials like glass or others , the Amount of SSS is a density of the model (thickness of the walls ) so I don't see the effect of RGB color here for that function you have Transmitted color +Transmitted Distance under SSS , in Uberiray you have 2 ways of creating SSS surfaces, one via translucency +SSS and another with IOR +SSS for volumetric glass or water shader with absorption .
When I use Optix ON with 1 to max 3 cards the render time is very much slower on my system for example 1 card Optix ON = 3 min , 1card Optix Off =1 min Optix ON reduce the GPU scale with 1 to 3 cards, but with 4 cards Optix ON improve the speed and GPU scale ..
I'm sorry to have to disagree with you, Cath, but the SSS Amount determines how much of the light is scattered at the distance of measurement (an amount of 0.75 f.e. means, that 75% of the photons are scattered before they have a chance to travel through the specified distance of measurement).
In real-world, the scattering of light within a material depends on the wavelength. For the visible range of light, at blue it will be the most, a bit less at green and at red the least. Like it is for absorption, which is determined with the help of our transmission parameter (Transmitted Color). The greyscale SSS Amount was just a simplified method (or placeholder) until a soulution in full color will be implemented. Since a more accurate method (by using measured scattering coefficients) to determine wavelength-dependent scattering is available now in Iray 2016.1 and beyond, it would be nice (and locical) to have a proper "User Parameters" input field for that, without doing a split meddling with the bricks in the Shader Mixer Tab.
That's funny. With Optix OFF the render times on my system are increased by approximately 15%. And around the same amount when selecting "Instancing Optimization" Memory instead of Speed. I'm also using still the 353.30 driver, the ones including mostly improvements for Win 10 didn't turn out to work that great. And the day I'd change to Win 10 would be the one when Eastern and Christmas will fall on the same day and hell freezes over.
I just translated it to a simple way what is exactly what you said just less technical for that reason you can use thickness maps with SSS amount to determine the level of scattering light ;) ( thickness-dense-opaque ) when you use maps like that with a water shader you can easy control how deep the rays will enter the water as I said there are 2 ways to make the same surfaces with different channels . I am using colors for Transmitted Color options not just gray scale , but you know I have always my other ways doing thin,gs and it works excellent for what I need . I do miss measured scattering coefficients , But I am afraid any changes to Uberiray may not works well with materials we already use or buy , however you can still make your custom MDL shader with the all new functions if needed .
Regarding the Optix you correct , when using memory or speed there will be different GPU scaling results , I am using speed for the best GPU scaling with multiple devices because with memory it get slower for me , I am running 12.000 cuda cores and 4 GPUs from the same series , but you know each system will perform different as there are no main settings just for one unit
You may write you own using MDL block or use the way it is now in Uberiray to get the same effect with IOR and SSS as was in the Handbook by using the Transmitted color +Transmitted Distance+SSS Amount+IOR skipping the Translucent channel for creating semi opaque materials like glass or others , the Amount of SSS is a density of the model (thickness of the walls ) so I don't see the effect of RGB color here for that function you have Transmitted color +Transmitted Distance under SSS , in Uberiray you have 2 ways of creating SSS surfaces, one via translucency +SSS and another with IOR +SSS for volumetric glass or water shader with absorption .
When I use Optix ON with 1 to max 3 cards the render time is very much slower on my system for example 1 card Optix ON = 3 min , 1card Optix Off =1 min Optix ON reduce the GPU scale with 1 to 3 cards, but with 4 cards Optix ON improve the speed and GPU scale ..
I'm sorry to have to disagree with you, Cath, but the SSS Amount determines how much of the light is scattered at the distance of measurement (an amount of 0.75 f.e. means, that 75% of the photons are scattered before they have a chance to travel through the specified distance of measurement).
In real-world, the scattering of light within a material depends on the wavelength. For the visible range of light, at blue it will be the most, a bit less at green and at red the least. Like it is for absorption, which is determined with the help of our transmission parameter (Transmitted Color). The greyscale SSS Amount was just a simplified method (or placeholder) until a soulution in full color will be implemented. Since a more accurate method (by using measured scattering coefficients) to determine wavelength-dependent scattering is available now in Iray 2016.1 and beyond, it would be nice (and locical) to have a proper "User Parameters" input field for that, without doing a split meddling with the bricks in the Shader Mixer Tab.
That's funny. With Optix OFF the render times on my system are increased by approximately 15%. And around the same amount when selecting "Instancing Optimization" Memory instead of Speed. I'm also using still the 353.30 driver, the ones including mostly improvements for Win 10 didn't turn out to work that great. And the day I'd change to Win 10 would be the one when Eastern and Christmas will fall on the same day and hell freezes over.
I just translated it to a simple way what is exactly what you said just less technical for that reason you can use thickness maps with SSS amount to determine the level of scattering light ;) ( thickness-dense-opaque ) when you use maps like that with a water shader you can easy control how deep the rays will enter the water as I said there are 2 ways to make the same surfaces with different channels . I am using colors for Transmitted Color options not just gray scale , but you know I have always my other ways doing thin,gs and it works excellent for what I need . I do miss measured scattering coefficients , But I am afraid any changes to Uberiray may not works well with materials we already use or buy , however you can still make your custom MDL shader with the all new functions if needed .
Yeah, I know you do. Many ways leads to Rome, all you need is make care of, you doesn't bomb the bridge you need to cross...
Okay, I know about those two differrent approaches you speak of, but I'm not sure how you put your thickness map into SSS Amount, for that parameter even doesn't have a texture slot. A parameter that would make sense in this case could be Refraction Weight, whis has one. But that way you'd be mapping Refraction Weight, and not SSS Amount. (Yeah, picky, I know...)
Ah, well, I guess there's some kind of misunderstanding. I really doubt the Iray Uber would have to be modified, the change from greyscale to full color is already implemented into the actual version of the renderer. Although the input parameter treats the parameter as a float, the renderer uses a RGB color for the calculation of the SSS Amount. And so it is done since the very first Iradium Beta.
All DAZ need to do is change the User Parameters field for the SSS Amount from slider to color input. Creating a custom MDL wouldn't make much sense, since without a change to that brick you'd also ned to fiddle with that first everytime you make a new material including full color SSS, for the SSS Amount would be still a slider.
When you currently adjust the slider or put a value into, let's say 0.75, the interface tells the renderer that R(ed) is 0.75, G(reen) is 0.75 and B(lue) is 0.75.
With a color input field identical to that of the Transmitted Color you could put in R(ed) is 0.75, G(reen) is 0.50 and B(lue) is 0.25, and it should work without any change to the Iray Uber, because the renderer already treated it as a color ever since. With the current "User Parameters" layout we would be unable to use an updated native feature of Iray on the Beta, and if not changed, in the upcoming General Release, too, which would be sad, wouldn't it?
Come on, Cath, don't fight me here, if you want to make use of a full color SSS as you mentioned, just say "I want a color input field, too!".
I don't fight with you !I want a color input field, too!
regarding the input for the thickness maps under SSS Amount , what I mean, I wish there was one ! as now I have to use it under IOR only and ok but not the same result , as you remember there was no input color option under Transmitted color in the beginning and they added it later and it was so important without it I would never made my PBR skin shader
If you can control the SSS Amount with a maps you could create cool volumetric effects on one material surfaces , as I have a tones of ideas for this , so I hope they do add this input option as well .
I just translated it to a simple way what is exactly what you said just less technical for that reason you can use thickness maps with SSS amount to determine the level of scattering light ;) ( thickness-dense-opaque ) when you use maps like that with a water shader you can easy control how deep the rays will enter the water as I said there are 2 ways to make the same surfaces with different channels . I am using colors for Transmitted Color options not just gray scale , but you know I have always my other ways doing thin,gs and it works excellent for what I need . I do miss measured scattering coefficients , But I am afraid any changes to Uberiray may not works well with materials we already use or buy , however you can still make your custom MDL shader with the all new functions if needed .
Yeah, I know you do. Many ways leads to Rome, all you need is make care of, you doesn't bomb the bridge you need to cross...
Okay, I know about those two differrent approaches you speak of, but I'm not sure how you put your thickness map into SSS Amount, for that parameter even doesn't have a texture slot. A parameter that would make sense in this case could be Refraction Weight, whis has one. But that way you'd be mapping Refraction Weight, and not SSS Amount. (Yeah, picky, I know...)
Ah, well, I guess there's some kind of misunderstanding. I really doubt the Iray Uber would have to be modified, the change from greyscale to full color is already implemented into the actual version of the renderer. Although the input parameter treats the parameter as a float, the renderer uses a RGB color for the calculation of the SSS Amount. And so it is done since the very first Iradium Beta.
All DAZ need to do is change the User Parameters field for the SSS Amount from slider to color input. Creating a custom MDL wouldn't make much sense, since without a change to that brick you'd also ned to fiddle with that first everytime you make a new material including full color SSS, for the SSS Amount would be still a slider.
When you currently adjust the slider or put a value into, let's say 0.75, the interface tells the renderer that R(ed) is 0.75, G(reen) is 0.75 and B(lue) is 0.75.
With a color input field identical to that of the Transmitted Color you could put in R(ed) is 0.75, G(reen) is 0.50 and B(lue) is 0.25, and it should work without any change to the Iray Uber, because the renderer already treated it as a color ever since. With the current "User Parameters" layout we would be unable to use an updated native feature of Iray on the Beta, and if not changed, in the upcoming General Release, too, which would be sad, wouldn't it?
Come on, Cath, don't fight me here, if you want to make use of a full color SSS as you mentioned, just say "I want a color input field, too!".
I don't fight with you !I want a color input field, too!
regarding the input for the thickness maps under SSS Amount , what I mean, I wish there was one ! as now I have to use it under IOR only and ok but not the same result , as you remember there was no input color option under Transmitted color in the beginning and they added it later and it was so important without it I would never made my PBR skin shader
If you can control the SSS Amount with a maps you could create cool volumetric effects on one material surfaces , as I have a tones of ideas for this , so I hope they do add this input option as well .
Yay! Now we're at least two! Now, altogether...
Yeah, me, too. Unfortunately, none of Iray's volume distribution functions does support texture maps, they need a RGB color or float to work. But I have been told "right now not at all in iray" so there's still hope they plan to will implement it someday.
Neither could layer thickness truly defined per parameter, layering in MDL is strictly a layering of BSDF. I planned to write a specific MDL skin shader last year and asked about that at the NVIDIA forums. But all the ideas I had were impossible to implement, so I dropped the project. That was when I learned they planned to implement the full color scattering solution, which I waited for since then like a kid on christmas.
Ah, there you had me... After reading you mention a PBR skin shader I immediately went to the shop to see why I had missed that. Haven't that published that by now?
Not yet , it is PBR procedural true skin shader I am still working on that does not use color photo textures , it have 7 proper layers and react with touch or clothing , if you make a skin cut ( normal map ) you cut the skin and layers are exposed .. it is not for everyone just for those that know what it is about , it is also not magic replacement for skin textures , but as close as you can get with PBR .. but still work in progress
I don't fight with you !I want a color input field, too!
regarding the input for the thickness maps under SSS Amount , what I mean, I wish there was one ! as now I have to use it under IOR only and ok but not the same result , as you remember there was no input color option under Transmitted color in the beginning and they added it later and it was so important without it I would never made my PBR skin shader
If you can control the SSS Amount with a maps you could create cool volumetric effects on one material surfaces , as I have a tones of ideas for this , so I hope they do add this input option as well .
Yay! Now we're at least two! Now, altogether...
Yeah, me, too. Unfortunately, none of Iray's volume distribution functions does support texture maps, they need a RGB color or float to work. But I have been told "right now not at all in iray" so there's still hope they plan to will implement it someday.
Neither could layer thickness truly defined per parameter, layering in MDL is strictly a layering of BSDF. I planned to write a specific MDL skin shader last year and asked about that at the NVIDIA forums. But all the ideas I had were impossible to implement, so I dropped the project. That was when I learned they planned to implement the full color scattering solution, which I waited for since then like a kid on christmas.
Ah, there you had me... After reading you mention a PBR skin shader I immediately went to the shop to see why I had missed that. Haven't that published that by now?
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
4.9.3.71
NVIDIA Iray
Transmitted color map in the Iray Uber Material is now ignored due to a limitation described in the Iray programmers guide; "The material's volume coefficients are varying in MDL, however, Iray Photoreal only supports uniform coefficients"
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.
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?
Not yet , it is PBR procedural true skin shader I am still working on that does not use color photo textures , it have 7 proper layers and react with touch or clothing , if you make a skin cut ( normal map ) you cut the skin and layers are exposed .. it is not for everyone just for those that know what it is about , it is also not magic replacement for skin textures , but as close as you can get with PBR .. but still work in progress
7 layers?! And I thought, the 5-layer-layout I had in mind would turn out to be a "renderer monster". Sounds interesting.
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).
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?
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.
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.
TY again.
Guess I'll have to look at how to accommodate it; at least not all bought characters have a texture in that slot.
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.
TY again.
Guess I'll have to look at how to accommodate it; at least not all bought characters have a texture in that slot.
I really think you are missing the point.
Having a texture in that slot NEVER DID ANYTHING. It had no effect. Period. Ever. People put one there, but it didn't do anything. Any effect was entirely based on the color in the channel and not the texture.
No monster at all , it is the fastest skin shader ever , and with layers I mean skin layers , blood, collagen, fat, dermis, upper dermis, melanin, veins etc.. all separate for dimensional skin
Not yet , it is PBR procedural true skin shader I am still working on that does not use color photo textures , it have 7 proper layers and react with touch or clothing , if you make a skin cut ( normal map ) you cut the skin and layers are exposed .. it is not for everyone just for those that know what it is about , it is also not magic replacement for skin textures , but as close as you can get with PBR .. but still work in progress
7 layers?! And I thought, the 5-layer-layout I had in mind would turn out to be a "renderer monster". Sounds interesting.
No monster at all , it is the fastest skin shader ever , and with layers I mean skin layers , blood, collagen, fat, dermis, upper dermis, melanin, veins etc.. all separate for dimensional skin
Aye, me, too. My planned approach also included several Transmission and SSS values for most of the skin layers, for they're mostly very different for each (that's very complicated to do, because you can't easily determine a layer thickness (in mm, cm, whatever) in MDL for Iray). Yours, too?
Sounds even more interesting. Have an ETA?
BTW: what has happened to your "Greek Hoplite" project. Still working on?
No sadly you can't put exactly the values and even if you can , skin thickness have a different values and a lot of them in different parts so only maps work here no mathematics however it works just fine . Also for best result you need polarized displacement maps as Normal usually will cut the layers too deep exposing second layers too much so for true PBR skin you need to work with the geometry .
I have a lot of projects right now that I am working on so not specific agenda, what is first finished going on sale .. don't want to go into discussion here since we are in the wrong thread ;)
No monster at all , it is the fastest skin shader ever , and with layers I mean skin layers , blood, collagen, fat, dermis, upper dermis, melanin, veins etc.. all separate for e dimensional skin
Aye, me, too. My planned approach also included several Transmission and SSS values for most of the skin layers, for they're mostly very different for each (that's very complicated to do, because you can't easily determine a layer thickness (in mm, cm, whatever) in MDL for Iray). Yours, too?
Sounds even more interesting. Have an ETA?
BTW: what has happened to your "Greek Hoplite" project. Still working on?
BTW since the update of iray 2016.1.2 I am getting issues with texture limits on instances , it shut down GPU devices . BUT No issues with DS 4.9.2.70 General Release build it render just fine
2016-08-18 21:06:14.885 WARNING: libpng warning: iCCP: known incorrect sRGB profile
2016-08-18 21:08:52.108 Iray INFO - module:category(MATCNV:RENDER): 1.0 MATCNV rend info : Material instance 'DS_Tree (2)__leaves_311_99' uses MDL JIT compilation.
2016-08-18 21:08:52.110 WARNING: dzneuraymgr.cpp(261): Iray WARNING - module:category(MATCNV:RENDER): 1.0 MATCNV rend warn : Reached internal texture limit on material instance 'DS_Tree ,at least 9 textures are dropped.
2016-08-18 21:09:01.932 WARNING: dzneuraymgr.cpp(261): Iray ERROR - module:category(IRAY:RENDER): 1.7 IRAY rend error: CUDA device 2 (GeForce GTX TITAN X): unspecified launch failure (while launching CUDA renderer in core_cuda_host.cpp:352)
2016-08-18 21:09:01.981 WARNING: dzneuraymgr.cpp(261): Iray WARNING - module:category(IRAY:RENDER): 1.3 IRAY rend warn : All available GPUs failed.
2016-08-18 21:09:56.882 WARNING: cloud\dzcloudtasknotifier.cpp(178): peer performed orderly shutdown errno=0
2016-08-18 21:10:23.150 Iray INFO - module:category(IRT:RENDER): 1.1 IRT rend info : Shutting down irt render plugin.
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.
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.
TY again.
Guess I'll have to look at how to accommodate it; at least not all bought characters have a texture in that slot.
I really think you are missing the point.
Having a texture in that slot NEVER DID ANYTHING. It had no effect. Period. Ever. People put one there, but it didn't do anything. Any effect was entirely based on the color in the channel and not the texture.
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.
TY again.
Guess I'll have to look at how to accommodate it; at least not all bought characters have a texture in that slot.
I really think you are missing the point.
Having a texture in that slot NEVER DID ANYTHING. It had no effect. Period. Ever. People put one there, but it didn't do anything. Any effect was entirely based on the color in the channel and not the texture.
Really? hah! I was just thinking the effects were really subtle. So they were really, really, really subtle then. :)
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.
TY again.
Guess I'll have to look at how to accommodate it; at least not all bought characters have a texture in that slot.
I really think you are missing the point.
Having a texture in that slot NEVER DID ANYTHING. It had no effect. Period. Ever. People put one there, but it didn't do anything. Any effect was entirely based on the color in the channel and not the texture.
Really? hah! I was just thinking the effects were really subtle. So they were really, really, really subtle then. :)
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.
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?
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.
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.
Comments
You may write you own using MDL block or use the way it is now in Uberiray to get the same effect with IOR and SSS as was in the Handbook by using the Transmitted color +Transmitted Distance+SSS Amount+IOR skipping the Translucent channel for creating semi opaque materials like glass or others , the Amount of SSS is a density of the model (thickness of the walls ) so I don't see the effect of RGB color here for that function you have Transmitted color +Transmitted Distance under SSS , in Uberiray you have 2 ways of creating SSS surfaces, one via translucency +SSS and another with IOR +SSS for volumetric glass or water shader with absorption .
When I use Optix ON with 1 to max 3 cards the render time is very much slower on my system for example 1 card Optix ON = 3 min , 1card Optix Off =1 min Optix ON reduce the GPU scale with 1 to 3 cards, but with 4 cards Optix ON improve the speed and GPU scale ..
I'm sorry to have to disagree with you, Cath, but the SSS Amount determines how much of the light is scattered at the distance of measurement (an amount of 0.75 f.e. means, that 75% of the photons are scattered before they have a chance to travel through the specified distance of measurement).
In real-world, the scattering of light within a material depends on the wavelength. For the visible range of light, at blue it will be the most, a bit less at green and at red the least. Like it is for absorption, which is determined with the help of our transmission parameter (Transmitted Color). The greyscale SSS Amount was just a simplified method (or placeholder) until a soulution in full color will be implemented. Since a more accurate method (by using measured scattering coefficients) to determine wavelength-dependent scattering is available now in Iray 2016.1 and beyond, it would be nice (and locical) to have a proper "User Parameters" input field for that, without doing a split meddling with the bricks in the Shader Mixer Tab.
That's funny. With Optix OFF the render times on my system are increased by approximately 15%. And around the same amount when selecting "Instancing Optimization" Memory instead of Speed. I'm also using still the 353.30 driver, the ones including mostly improvements for Win 10 didn't turn out to work that great. And the day I'd change to Win 10 would be the one when Eastern and Christmas will fall on the same day and hell freezes over.![smiley smiley](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/regular_smile.png)
I just translated it to a simple way what is exactly what you said just less technical for that reason you can use thickness maps with SSS amount to determine the level of scattering light ;) ( thickness-dense-opaque ) when you use maps like that with a water shader you can easy control how deep the rays will enter the water as I said there are 2 ways to make the same surfaces with different channels . I am using colors for Transmitted Color options not just gray scale , but you know I have always my other ways doing thin,gs and it works excellent for what I need . I do miss measured scattering coefficients , But I am afraid any changes to Uberiray may not works well with materials we already use or buy , however you can still make your custom MDL shader with the all new functions if needed .
Regarding the Optix you correct , when using memory or speed there will be different GPU scaling results , I am using speed for the best GPU scaling with multiple devices because with memory it get slower for me , I am running 12.000 cuda cores and 4 GPUs from the same series , but you know each system will perform different as there are no main settings just for one unit
Yeah, I know you do. Many ways leads to Rome, all you need is make care of, you doesn't bomb the bridge you need to cross...![wink wink](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/wink_smile.png)
![smiley smiley](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/regular_smile.png)
Okay, I know about those two differrent approaches you speak of, but I'm not sure how you put your thickness map into SSS Amount, for that parameter even doesn't have a texture slot. A parameter that would make sense in this case could be Refraction Weight, whis has one. But that way you'd be mapping Refraction Weight, and not SSS Amount. (Yeah, picky, I know...)
Ah, well, I guess there's some kind of misunderstanding. I really doubt the Iray Uber would have to be modified, the change from greyscale to full color is already implemented into the actual version of the renderer. Although the input parameter treats the parameter as a float, the renderer uses a RGB color for the calculation of the SSS Amount. And so it is done since the very first Iradium Beta.
All DAZ need to do is change the User Parameters field for the SSS Amount from slider to color input. Creating a custom MDL wouldn't make much sense, since without a change to that brick you'd also ned to fiddle with that first everytime you make a new material including full color SSS, for the SSS Amount would be still a slider.
When you currently adjust the slider or put a value into, let's say 0.75, the interface tells the renderer that R(ed) is 0.75, G(reen) is 0.75 and B(lue) is 0.75.
With a color input field identical to that of the Transmitted Color you could put in R(ed) is 0.75, G(reen) is 0.50 and B(lue) is 0.25, and it should work without any change to the Iray Uber, because the renderer already treated it as a color ever since. With the current "User Parameters" layout we would be unable to use an updated native feature of Iray on the Beta, and if not changed, in the upcoming General Release, too, which would be sad, wouldn't it?
Come on, Cath, don't fight me here, if you want to make use of a full color SSS as you mentioned, just say "I want a color input field, too!".![wink wink](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/wink_smile.png)
![smiley smiley](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/regular_smile.png)
I don't fight with you ! I want a color input field, too!
regarding the input for the thickness maps under SSS Amount , what I mean, I wish there was one ! as now I have to use it under IOR only and ok but not the same result , as you remember there was no input color option under Transmitted color in the beginning and they added it later and it was so important without it I would never made my PBR skin shader
If you can control the SSS Amount with a maps you could create cool volumetric effects on one material surfaces , as I have a tones of ideas for this , so I hope they do add this input option as well .
Yay! Now we're at least two! Now, altogether...
Yeah, me, too. Unfortunately, none of Iray's volume distribution functions does support texture maps, they need a RGB color or float to work. But I have been told "right now not at all in iray" so there's still hope they plan to will implement it someday.
Neither could layer thickness truly defined per parameter, layering in MDL is strictly a layering of BSDF. I planned to write a specific MDL skin shader last year and asked about that at the NVIDIA forums. But all the ideas I had were impossible to implement, so I dropped the project. That was when I learned they planned to implement the full color scattering solution, which I waited for since then like a kid on christmas.![smiley smiley](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/regular_smile.png)
Ah, there you had me...
After reading you mention a PBR skin shader I immediately went to the shop to see why I had missed that. Haven't that published that by now? ![sad sad](http://www.daz3d.com/forums/plugins/ckeditor/js/ckeditor/plugins/smiley/images/sad_smile.png)
Not yet , it is PBR procedural true skin shader I am still working on that does not use color photo textures , it have 7 proper layers and react with touch or clothing , if you make a skin cut ( normal map ) you cut the skin and layers are exposed .. it is not for everyone just for those that know what it is about , it is also not magic replacement for skin textures , but as close as you can get with PBR .. but still work in progress
A new build (4.9.3.71) has been posted.
-Rob
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
4.9.3.71
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?
7 layers?!
And I thought, the 5-layer-layout I had in mind would turn out to be a "renderer monster".
Sounds interesting.
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.
TY again.
Guess I'll have to look at how to accommodate it; at least not all bought characters have a texture in that slot.
I really think you are missing the point.
Having a texture in that slot NEVER DID ANYTHING. It had no effect. Period. Ever. People put one there, but it didn't do anything. Any effect was entirely based on the color in the channel and not the texture.
No monster at all , it is the fastest skin shader ever , and with layers I mean skin layers , blood, collagen, fat, dermis, upper dermis, melanin, veins etc.. all separate for dimensional skin
Aye, me, too.
My planned approach also included several Transmission and SSS values for most of the skin layers, for they're mostly very different for each (that's very complicated to do, because you can't easily determine a layer thickness (in mm, cm, whatever) in MDL for Iray). Yours, too?
Sounds even more interesting.
Have an ETA?
BTW: what has happened to your "Greek Hoplite" project. Still working on?
No sadly you can't put exactly the values and even if you can , skin thickness have a different values and a lot of them in different parts so only maps work here no mathematics however it works just fine . Also for best result you need polarized displacement maps as Normal usually will cut the layers too deep exposing second layers too much so for true PBR skin you need to work with the geometry .
I have a lot of projects right now that I am working on so not specific agenda, what is first finished going on sale .. don't want to go into discussion here since we are in the wrong thread ;)
Thanks Rob ,
BTW since the update of iray 2016.1.2 I am getting issues with texture limits on instances , it shut down GPU devices . BUT No issues with DS 4.9.2.70 General Release build it render just fine
That is what i found too
Really? hah! I was just thinking the effects were really subtle. So they were really, really, really subtle then. :)
That's a positive way to spin it. I like that.
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.
...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.
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.
They do not use this channel at all so no wories ..