little abstraction layer: IDX11ShaderVariableManager #319
Conversation
…ger. * DX11ShaderNode now can be used as a base class for a shader graph sink. * adjusted DX11ShaderVariableManager so that it also can serve as a base implementation of IDX11ShaderVariableManager. * removed PinName from IShaderPin as it felt unused (at least in this solution) please recheck
|
The changes shouldn't add/remove any functionality on your side. They just help to contribute to your class family. |
|
Not sure about that one, since the main shader nodes are critical to the functioning of the whole pack, and those classes should almost be considered as internals (I only did not so so as the only need to be accessible by the factory library and I dislike internalsvisibleto). I actually wanted to move toward splitting that project in 2 to more clearly emphasise the intent (VVVV.DX11.Lib and VVVV.DX11.Lib.Internals), but decided to eventually do it post node. Extracting interface does modify functionality a lot, since now I have to take into account that a lot of different implementations (potentially broken) can be added into shader node. Also, it means that suddenly the whole interface (and shader node) becomes frozen, which I believe will impact the whole system negatively (less room for improvements without breaking interface contract) Adding the whole part of shaderVariable as protected also sounds horrible, means now the class needs to take into account that any of their member can be modified separately, and without any consistency. About pin name, yes, that's a leftover from last changes, that can be removed (as well as in implementations) |
|
ok. no problem. thanks for having a look |
hi vux!
i have some few changes that would allow the community to play with shader graphs without the need of forking your repo. The main idea of the changes is just to abstract over the way how variables get routed to the shader.
abstracted over DX11ShaderVariableManager via IDX11ShaderVariableManager