...So the proxies (i.e. the Horizontal/Vertical Offset sliders on the Parameters tab) will be set up when the prop, with 3Delight materials, is loaded.
But what will happen to the proxies and the linking when I apply an iRay material ?...
I just tried a slightly different approach, creating separate 3Delight and Iray versions of the prop, and 3Delight and Iray material presets to apply different texture maps. (Note: no post-load stuff in the material presets)
- The 3Delight prop works fine.
- The Iray prop works fine
- The 3Delight material presets work fine (i.e. maintain the proxies) when applied to the3Delight prop. But they don't work (i.e. fail to maintain the proxies) when applied to the Iray prop. That's not a big surprise, because of the extra 'Geometry' group in the Iray 'Tiling'path
- But the Iray material presets don't work (i.e. fail to maintain the proxies), when applied to the Iray prop. That was a surprise.
(and they don't work (i.e. fail to maintain the proxies) when applied to the 3Delight prop either - that wasn't a surprise at all)
Which leaves me rather puzzled, because the 'Post_Load_Material_Proxy_Link_Properties.dsa' script that relinks the properties is only called from the Prop DUFs, not from the material presets. Which I guess means that the 3Delight material presets don't cut the proxy links, but the Iray ones do.
So it looks to me as if the Iray material presets (based on the DAZ '!Iray Uber Base' shader preset with Mixing = 'PBR Specular/Glossiness') are screwing upthe proxy linking. But I can't see how, which makes the problem difficult to resolve.
Try (if it's not too fiddly) with a non-default 3delight shader, or the AoA SSS shader. I suspect it may have to do with the way non-default shaders are applied (if you look at the scripting developer docs there are different types of material).
...and I also just created a new Iray Uber Base version of the prop plus new Iray Uber Base material presets (I made a minor mistake with the the first one which I don't think matters,but just to be certain...)
This confirms my earlier result that the Iray material presets don't even work* with the Iray prop.
So, in summary:
- The Ds Default material presets ONLY work with the DS Default prop.
- The AoA SSS material presets ONLY work with the AoA SSS prop.
- The Iray Uber Base material presets DO NOT EVEN work with the Iray Uber Base prop.
(by 'work' I mean maintaining the proxies. All three types of material preset apply the correct shader and texture image to all three types of prop. )
I'm slightly surprised that anything but the Daz default material retains the proxies.
Fortunately Rob saw this thread and has supplied some advice. As I suspected, applyng a (non-default, at least) does cause DS to build a new material and so loses the existing links. His suggestion is to set up DzCallBacks on the material when you are aplying the links so that when the material is rebuilt you can have DzApp (the App object) run the script to reinstate the links on the new properties. He does caution that you need to be careful to tidy up the callbacks when done so that they don't cause a memory leak as they accumulate. I've never used a post-run call-back, only listening to signals within a script, so i can't add any detail.
I'll have a look at the DzApp and DzCallBack documentation and the Post-Load Callback examples on the samples page under the 'Elements' sub-heading about ⅔ of the way down (or on the samples >elements page)
I've had a brief look at that stuff... my first impressions are that it's rather too complicated for me*.
Especially as it would be just to get around the problem of the Iray material presets breaking the proxy links.
For a freebie prop.
That I'm just doing a 'simple' Poser to DS conversion on.
So, since the 3Delight DS Default material presets work fine (assuming of course that the prop was created with a DS Default material), I'm inclined to just go with that.
Maybe I'll create a version of the prop with an Iray material but without any ERC or proxy linking. With a note in the readme that if an Iray user wants to change the book selection they'll have to do it manually via the tiling offsets on the surfaces tab. With multiples of -0.03125 for the vertical offset.
However, I did notice on the Element Post-Load Create Callbacks sample page, under the Overview section,that it says "This is accomplished using a DzCallBack, instead of a DzERCLink (which does not allow circular references)"
So if I wasn't** concerned about the bidirectional aspect , then would a DzERCLink be an easier option ?
Or perhaps even simpler (and talking UNIdirectional) - is there a way to combine the proxying of the Tiling Offsets with the ERC freeze ?
I.e. to create an ERC link so that a new integer slider on the Parameters tab directly controls a tiling offset on the Surfaces tab ?
I only ask because that comment on the Element Post-Load Create Callbacks sample page makes me think that there is.
Anyway, here's an annotated screenshot collage type thing showing how the thing works from a UI POV:
And here's the2x32 grid of books texture map (from this post on my books freebie thread)
*while I understand and appreciate the basic idea of OO, for me personally it has always stood for Object Obfuscation when it comes to actual implementations !
**I'm NOT: because (1) I already use UNIdirectional ERC between the integer 'Texture' sliders and 'Tiling' proxies on the Parameters tab; (2) I was planning to make the 'Tiling' proxies on the Parameters tab hidden; (3) Having 'Texture' sliders on the Parameters tab was intended to avoid the need toeven open the Surfaces tab.
Applying a nwe material, even one using the same (non-default, possibly) shader, will not preserve ERC Links so no, that wouldn't help (indeed, it was ERC links we were discussing).
Am I confusing the terminology ?
- The 'ERC links' are between two parameters both on the Parameters tab. Set up using ERC Freeze. Nothing to do with materials/surfaces - except indirectly if the dependent parameter is a proxyfor asurface parameter.
- The 'Proxy links' are between original parameters on the Surfaces tab and the duplicated parameters on the Parameters tab. Set up via the 'post_load_material_proxy_create.dsa / post_load_material_proxy_link_properties.dsa' scripts.
Applying a new material maintains the ERC links within the Parameters tab (i.e. the green arrows/text on the diagram in the previous post)
- regardless of whether the prop that was loaded had a DS Default, AoA SSS, or Iray Uber Base material.
- regardless of whether the material preset is a DS Default, AoA SSS, or Iray Uber Base.
It's only the proxy links between the tiling parameters on the Surfaces tab and their proxies on the Parameters tab that are getting broken (i.e. the red arrows/text on the diagram in the previous post).
ERC links can be set only between properties on the Parameters tab via the UI. But it's still ERC if you use a script to create a link between a material property and a node proeprty (on the Parameters pane).
Okay, maybe I'm being a bit pedantic. Of course the links between the original material properties on the Surfaces pane and the proxy node properties on the Parameters pane are a form of enhanced remote control, but I'm guessing that they're not 'Enhanced Remote Control' as implemented by the DzERCLink class.
But as usual, I may well be wrong.
I've been assuming* that 'ERC' is explicitly UNIdirectional, and still basically what Rob came up with way back.
Also I assume that internally DS uses the DzERCLink class to implement all ERC ?
However, the links that the 'Post_Load_Material_Proxy_Create.dsa' / 'Post_Load_Material_Proxy_Link_Properties.dsa' scripts set up between material properties (Surfaces pane) and node properties ( Parameters pane) are BIdirectional (i.e. they DO contain circular references).
So I'm assuming that they don't (can't?) use the DzERCLink class.
Which I assumed was the reason that the documentation referred to them as 'Proxy' rather than 'ERC' links.
*Just to check I tried to create a circular ERC reference via the UI by setting xTran and zTran to 1 and using ERC Freeze. First I slaved zTran to xTran - no problem. Then I slaved xTran to zTran to make it circular - not surprisingly DS(4.8) hung up for a while and then crashed.
Applying a nwe material, even one using the same (non-default, possibly) shader, will not preserve ERC Links...
But my tests have indicated that applying a (non-default) AoA SSS material preset to a prop that originally had an AoA SSS material actually does preserve the ERC links (i.e. even the proxy links between the original material properties on the Surfaces pane and the proxy node properties on the Parameters pane).
Maybe the AoA SSS shader is almost-default... ? ;o)
Okay, maybe I'm being a bit pedantic. Of course the links between the original material properties on the Surfaces pane and the proxy node properties on the Parameters pane are a form of enhanced remote control, but I'm guessing that they're not 'Enhanced Remote Control' as implemented by the DzERCLink class.
But as usual, I may well be wrong.
I've been assuming* that 'ERC' is explicitly UNIdirectional, and still basically what Rob came up with way back.
Also I assume that internally DS uses the DzERCLink class to implement all ERC ?
However, the links that the 'Post_Load_Material_Proxy_Create.dsa' / 'Post_Load_Material_Proxy_Link_Properties.dsa' scripts set up between material properties (Surfaces pane) and node properties ( Parameters pane) are BIdirectional (i.e. they DO contain circular references).
So I'm assuming that they don't (can't?) use the DzERCLink class.
Which I assumed was the reason that the documentation referred to them as 'Proxy' rather than 'ERC' links.
*Just to check I tried to create a circular ERC reference via the UI by setting xTran and zTran to 1 and using ERC Freeze. First I slaved zTran to xTran - no problem. Then I slaved xTran to zTran to make it circular - not surprisingly DS(4.8) hung up for a while and then crashed.
Yes, but I had originally been suggesting (or at least thinking of) ERC objects.
Applying a nwe material, even one using the same (non-default, possibly) shader, will not preserve ERC Links...
But my tests have indicated that applying a (non-default) AoA SSS material preset to a prop that originally had an AoA SSS material actually does preserve the ERC links (i.e. even the proxy links between the original material properties on the Surfaces pane and the proxy node properties on the Parameters pane).
Maybe the AoA SSS shader is almost-default... ? ;o)
Hmm, that's surprising - the AoA shader is (underneath) an Shader Mixer network.
Yes, but I had originally been suggesting (or at least thinking of) ERC objects.
Ah yes, your first reply to my question about slaving a surfaces slider to a parameters slider.
But I just went with the two sample scripts that maclean pointed to in the next post assuming that was the same thing, but it wasn't.
So it is actually possible to create, via script, a DzERCLink between a parameter on the Surfaces tab and a parameter on the Parmameters tab ?
But applying a new material, even of the same type (possibly with the exception of DS Default) would break the link.
Yes, but I had originally been suggesting (or at least thinking of) ERC objects.
Ah yes, your first reply to my question about slaving a surfaces slider to a parameters slider.
But I just went with the two sample scripts that maclean pointed to in the next post assuming that was the same thing, but it wasn't.
So it is actually possible to create, via script, a DzERCLink between a parameter on the Surfaces tab and a parameter on the Parmameters tab ?
But applying a new material, even of the same type (possibly with the exception of DS Default) would break the link.
Yes and as I understand it yes (or at least, it can't be assumed that it won't break any existing links).
Comments
I just tried a slightly different approach, creating separate 3Delight and Iray versions of the prop, and 3Delight and Iray material presets to apply different texture maps. (Note: no post-load stuff in the material presets)
- The 3Delight prop works fine.
- The Iray prop works fine
- The 3Delight material presets work fine (i.e. maintain the proxies) when applied to the3Delight prop.
But they don't work (i.e. fail to maintain the proxies) when applied to the Iray prop. That's not a big surprise, because of the extra 'Geometry' group in the Iray 'Tiling'path
- But the Iray material presets don't work (i.e. fail to maintain the proxies), when applied to the Iray prop. That was a surprise.
(and they don't work (i.e. fail to maintain the proxies) when applied to the 3Delight prop either - that wasn't a surprise at all)
Which leaves me rather puzzled, because the 'Post_Load_Material_Proxy_Link_Properties.dsa' script that relinks the properties is only called from the Prop DUFs, not from the material presets. Which I guess means that the 3Delight material presets don't cut the proxy links, but the Iray ones do.
So it looks to me as if the Iray material presets (based on the DAZ '!Iray Uber Base' shader preset with Mixing = 'PBR Specular/Glossiness') are screwing upthe proxy linking. But I can't see how, which makes the problem difficult to resolve.
Which 3Delight shader were you using?
DS Default
Try (if it's not too fiddly) with a non-default 3delight shader, or the AoA SSS shader. I suspect it may have to do with the way non-default shaders are applied (if you look at the scripting developer docs there are different types of material).
Okay, I tried that, doing exactly the same as I did with the 3Delight DS Default material and Iray DAZ !Iray Uber Base material versions
I created an AoA SSS version of the prop, and AoA SSS material presets to apply different texture maps.
- The AoA SSS material presets work fine with the AoA SSS prop.
- The DS Default material presets applied to the AoA SSS prop break the proxy links
- The AoA SSS material presets applied to the DS Default prop break the proxy links
...and I also just created a new Iray Uber Base version of the prop plus new Iray Uber Base material presets (I made a minor mistake with the the first one which I don't think matters,but just to be certain...)
This confirms my earlier result that the Iray material presets don't even work* with the Iray prop.
So, in summary:
- The Ds Default material presets ONLY work with the DS Default prop.
- The AoA SSS material presets ONLY work with the AoA SSS prop.
- The Iray Uber Base material presets DO NOT EVEN work with the Iray Uber Base prop.
(by 'work' I mean maintaining the proxies. All three types of material preset apply the correct shader and texture image to all three types of prop. )
I'm slightly surprised that anything but the Daz default material retains the proxies.
Fortunately Rob saw this thread and has supplied some advice. As I suspected, applyng a (non-default, at least) does cause DS to build a new material and so loses the existing links. His suggestion is to set up DzCallBacks on the material when you are aplying the links so that when the material is rebuilt you can have DzApp (the App object) run the script to reinstate the links on the new properties. He does caution that you need to be careful to tidy up the callbacks when done so that they don't cause a memory leak as they accumulate. I've never used a post-run call-back, only listening to signals within a script, so i can't add any detail.
Thanks Richard/Rob,
I'll have a look at the DzApp and DzCallBack documentation and the Post-Load Callback examples on the samples page under the 'Elements' sub-heading about ⅔ of the way down (or on the samples >elements page)
I've had a brief look at that stuff... my first impressions are that it's rather too complicated for me*.
Especially as it would be just to get around the problem of the Iray material presets breaking the proxy links.
For a freebie prop.
That I'm just doing a 'simple' Poser to DS conversion on.
So, since the 3Delight DS Default material presets work fine (assuming of course that the prop was created with a DS Default material), I'm inclined to just go with that.
Maybe I'll create a version of the prop with an Iray material but without any ERC or proxy linking. With a note in the readme that if an Iray user wants to change the book selection they'll have to do it manually via the tiling offsets on the surfaces tab. With multiples of -0.03125 for the vertical offset.
However, I did notice on the Element Post-Load Create Callbacks sample page, under the Overview section,that it says "This is accomplished using a DzCallBack, instead of a DzERCLink (which does not allow circular references)"
So if I wasn't** concerned about the bidirectional aspect , then would a DzERCLink be an easier option ?
Or perhaps even simpler (and talking UNIdirectional) - is there a way to combine the proxying of the Tiling Offsets with the ERC freeze ?
I.e. to create an ERC link so that a new integer slider on the Parameters tab directly controls a tiling offset on the Surfaces tab ?
I only ask because that comment on the Element Post-Load Create Callbacks sample page makes me think that there is.
Anyway, here's an annotated screenshot collage type thing showing how the thing works from a UI POV:
And here's the2x32 grid of books texture map (from this post on my books freebie thread)
*while I understand and appreciate the basic idea of OO, for me personally it has always stood for Object Obfuscation when it comes to actual implementations !
**I'm NOT: because (1) I already use UNIdirectional ERC between the integer 'Texture' sliders and 'Tiling' proxies on the Parameters tab; (2) I was planning to make the 'Tiling' proxies on the Parameters tab hidden; (3) Having 'Texture' sliders on the Parameters tab was intended to avoid the need toeven open the Surfaces tab.
Applying a nwe material, even one using the same (non-default, possibly) shader, will not preserve ERC Links so no, that wouldn't help (indeed, it was ERC links we were discussing).
Am I confusing the terminology ?
- The 'ERC links' are between two parameters both on the Parameters tab. Set up using ERC Freeze. Nothing to do with materials/surfaces - except indirectly if the dependent parameter is a proxyfor asurface parameter.
- The 'Proxy links' are between original parameters on the Surfaces tab and the duplicated parameters on the Parameters tab. Set up via the 'post_load_material_proxy_create.dsa / post_load_material_proxy_link_properties.dsa' scripts.
Applying a new material maintains the ERC links within the Parameters tab (i.e. the green arrows/text on the diagram in the previous post)
- regardless of whether the prop that was loaded had a DS Default, AoA SSS, or Iray Uber Base material.
- regardless of whether the material preset is a DS Default, AoA SSS, or Iray Uber Base.
It's only the proxy links between the tiling parameters on the Surfaces tab and their proxies on the Parameters tab that are getting broken (i.e. the red arrows/text on the diagram in the previous post).
ERC links can be set only between properties on the Parameters tab via the UI. But it's still ERC if you use a script to create a link between a material property and a node proeprty (on the Parameters pane).
Okay, maybe I'm being a bit pedantic. Of course the links between the original material properties on the Surfaces pane and the proxy node properties on the Parameters pane are a form of enhanced remote control, but I'm guessing that they're not 'Enhanced Remote Control' as implemented by the DzERCLink class.
But as usual, I may well be wrong.
I've been assuming* that 'ERC' is explicitly UNIdirectional, and still basically what Rob came up with way back.
Also I assume that internally DS uses the DzERCLink class to implement all ERC ?
However, the links that the 'Post_Load_Material_Proxy_Create.dsa' / 'Post_Load_Material_Proxy_Link_Properties.dsa' scripts set up between material properties (Surfaces pane) and node properties ( Parameters pane) are BIdirectional (i.e. they DO contain circular references).
So I'm assuming that they don't (can't?) use the DzERCLink class.
Which I assumed was the reason that the documentation referred to them as 'Proxy' rather than 'ERC' links.
*Just to check I tried to create a circular ERC reference via the UI by setting xTran and zTran to 1 and using ERC Freeze. First I slaved zTran to xTran - no problem. Then I slaved xTran to zTran to make it circular - not surprisingly DS(4.8) hung up for a while and then crashed.
But my tests have indicated that applying a (non-default) AoA SSS material preset to a prop that originally had an AoA SSS material actually does preserve the ERC links (i.e. even the proxy links between the original material properties on the Surfaces pane and the proxy node properties on the Parameters pane).
Maybe the AoA SSS shader is almost-default... ? ;o)
Yes, but I had originally been suggesting (or at least thinking of) ERC objects.
Hmm, that's surprising - the AoA shader is (underneath) an Shader Mixer network.
Ah yes, your first reply to my question about slaving a surfaces slider to a parameters slider.
But I just went with the two sample scripts that maclean pointed to in the next post assuming that was the same thing, but it wasn't.
So it is actually possible to create, via script, a DzERCLink between a parameter on the Surfaces tab and a parameter on the Parmameters tab ?
But applying a new material, even of the same type (possibly with the exception of DS Default) would break the link.
Yes and as I understand it yes (or at least, it can't be assumed that it won't break any existing links).
Started a new thread Creating dependencies between settings on the Surfaces tab and Parameters tab over on the DAZ Script Developer Discussion forum