Hey @indexofrefraction,
but the proper way would be already to use InsertUnder if we're already in a shader type node list (?) using InsertShader in the middle of a shader list is not necessary and bad practice (?) a list with multiple shader gelist heads could (should?) be pruned of excessive heads (?)
Well, the answer to that all is sort of yesn't. I personally would for example consider the layer shader carrying its shader dependencies as direct children to be at least a regression of the classic API scene architecture, as the proper place would be the shader branch of the layer shader.
The layer shader engineers might have (somewhat) rightfully thought that it does not really matter, or even had some technical reason to store the shaders as direct children. There is nothing special about branches, they are just contextualized hierarchies. For an object and its tags, they are necessary, because if we would also store tags as direct children of objects, it would become very cumbersome to sort out what is what when tags and child objects would be mixed. For shaders this is not the case, as there is nothing which is naturally a child of shaders as child objects are of objects. But in the end, the 'right' place to store shaders attached to a GeListNode
is its shader branch. And other shader developers, both internal external, might have solved this differently and let their shaders store their shader dependencies in the 'Shader' branch of their shader. Which at end forces other developers to understand what each shader type does and imitate it when it must be handled in code.
There is no 'satisfying' answer, when a shader type stores its shader dependencies as direct children, you must use InsertUnder
, and when it does store its shader dependencies in the shader branch, you must use InsertShader
(which is just a shortcut for calling InsertUnder
on the shader branch GeListHead
of that node).
Cheers,
Ferdinand