This proposed patch fixes a corner case we were seeing during live rendering with ReParameterization.
We were experiencing a problem when ss->ReParameterize() wasn't successfully applying parameter changes for us.
In our situation, a shader's parameter, "A", was marked with lockgeom=0 (ie. "live" or "editable") and was set via ss->Parameter(). This parameter was connected (through a series of copies and network links) to another shader's parameter, "B", downstream whose initialized value (ie. the one specified in the .osl/.oso file) matched A's set value. When this happened, A's shading layer was getting marked as "mergeable" and deleted, and we wouldn't see any updates to A via "reparameterization" take effect.
Tests
We are using v3.13.2.3 locally and a similar fix (with b_sym->lockgeom() == 0 in lieu of this PR's b_sym->interactive()) resolved the issue. I can port my fix to the v3.12.3 branch if desired.
Description
This proposed patch fixes a corner case we were seeing during live rendering with ReParameterization.
We were experiencing a problem when
ss->ReParameterize()wasn't successfully applying parameter changes for us.In our situation, a shader's parameter, "A", was marked with lockgeom=0 (ie. "live" or "editable") and was set via
ss->Parameter(). This parameter was connected (through a series of copies and network links) to another shader's parameter, "B", downstream whose initialized value (ie. the one specified in the .osl/.oso file) matched A's set value. When this happened, A's shading layer was getting marked as "mergeable" and deleted, and we wouldn't see any updates to A via "reparameterization" take effect.Tests
We are using v3.13.2.3 locally and a similar fix (with
b_sym->lockgeom() == 0in lieu of this PR'sb_sym->interactive()) resolved the issue. I can port my fix to the v3.12.3 branch if desired.Checklist: