Incorrect implementation of SplitTB, RampTB and Ramp4 node types about materialx HOT 2 OPEN

This is a great catch as well, thanks @HardCoreCodin. If you have the bandwidth to address the two issues that you caught, feel free to propose PRs for these!

from materialx.

Thank you @jstone-lucasfilm for your consideration. I would not be looking to fix those, as I've only looked at 2 of the backends and am not actually using any of them (I use a different backend). I am using existing graph editors like Material Graph Editor that comes with the library and QuiltiX, as a way of authoring MaterialX node graphs and then importing them into a rendering application. My backend implements the nodes according to the MaterialX spec, so most importantly - I am using these editors to visually validate my implementation against them. Especially the built-in Material Graph Editor that comes with the library, should be considered safe to use as reference point, in my opinion. It gets a bit confusing when my nodes are up to spec and yet my results appear different from what's in the library's editor. As far as I understand, all these editors use the library's backends for code generation so inherit these issues when these backends aren't to spec.

from materialx.