I would like to extend a humble request, and maybe to ask whether it falls within the realm of expectation, that primitive Matrix types are included to substance function graphs. It seems something rather trivial that I never really understud the absence of.
Considering my personal anecdotal experience for the past many many years and also the ones from other collegues in the industry, I seems like the need for that is frequent, systematic and it is often met with an excessive amount work and underoptimized logic in order to get around this deficiency.
I think people would do many more cool things if stuff like working in homogenous coordinates wasn't prohibitively laborous and yielded slower results. The only thing preventing that is the lack of a way to input (and especially to output!) matrix types from from a substance function graph. Imagine how much simpler it would be to make custom splatters, ray marches, custom 3D shapes, etc, if one could only store and manipulate transformations of higher dimensions or that support translation in a single operable object, especially now that we can do loops :D. In addition, sometimes you just need to output more then 4 values as a result of an expensive calculation that you dont want to do more than once. I even see nodes in the built in substance graph library itslef that would have largely benefited from something like that, for example pbr_render2.
I don't see any fundamental technical hurdles with supporting matrix types, considering these are natively supported in all math libraries and GPUs of relevance since forever.
The only rather mild trouble that I could anticipate is usability. Since there are so many dimensionality permutations and possible swizzle between types, there would significantly increase the amount basic Substance Function nodes necessary. To which I would simply respond: Just do float 4x4, that will allow people to implement their own lower dimentionality variants if they need.
AdChoices