This PR requires #7 to be merged first as it's based on this branch. Reason is that part of the code that has to be added for the layers is in a chunk that is modified by the first PR.
Apart from the changes in #7 , the changes here are that we're adding one more token in TokenizedOutputs called layer_tok and we're reading one more token c6.
We need to make the tokens "testing" more robust, since there are several optional tokens that make the logic a bit complicated.
The rationale is as follow :
the first token can eventually be a camera. To verify this, we check if there is such a node in the current universe, and if it's a camera. In that case c0 is the camera, c1 the AOV name, etc.. otherwise c0 is the AOV name.
the following mandatory tokens are always "aov name", "aov type", "filter name", "driver name"
the last token can eventually be HALF to specify that this AOV is meant to be half precision
After the mandatory tokens, but before the eventual HALF token, there can be a token for the layer name.
This PR reproduces this logic parsing the output lines.
Note that, in setup_new_outputs when we create the "rank" AOVs (e.g. crypto_material00, crypto_object01, etc...) we copy the "parent" AOV (e.g. crypto_material) and modify the aov name and filter. Now, if a layer name is present we also need to modify it, otherwise this new output would conflict with the parent one. The logic I'm using here is to add the same "rank" suffix to the layer than the one we add to the AOV. So if crypto_material has a layer name called kryptonite, then crypto_material00 will have a layer name set to kryptonite00, etc...
In theory, this PR shouldn't change anything when no layer name token is present, but it does change the logic of parsing the outputs, so it needs to be tested carefully to ensure it's not causing any regression
This PR requires #7 to be merged first as it's based on this branch. Reason is that part of the code that has to be added for the layers is in a chunk that is modified by the first PR.
Apart from the changes in #7 , the changes here are that we're adding one more token in
TokenizedOutputscalledlayer_tokand we're reading one more tokenc6. We need to make the tokens "testing" more robust, since there are several optional tokens that make the logic a bit complicated. The rationale is as follow :c0is the camera,c1the AOV name, etc.. otherwisec0is the AOV name.HALFto specify that this AOV is meant to be half precisionThis PR reproduces this logic parsing the output lines.
Note that, in
setup_new_outputswhen we create the "rank" AOVs (e.g. crypto_material00, crypto_object01, etc...) we copy the "parent" AOV (e.g. crypto_material) and modify the aov name and filter. Now, if a layer name is present we also need to modify it, otherwise this new output would conflict with the parent one. The logic I'm using here is to add the same "rank" suffix to the layer than the one we add to the AOV. So ifcrypto_materialhas a layer name calledkryptonite, thencrypto_material00will have a layer name set tokryptonite00, etc...In theory, this PR shouldn't change anything when no layer name token is present, but it does change the logic of parsing the outputs, so it needs to be tested carefully to ensure it's not causing any regression