Proposal: fract node

[pablode]

In addition to floor, ceil, etc., it would be nice to have a node that represents the fract instrinsic that many shader languages have.

The implementation is rather simple: x - floor(x).

As for the benefits, shading networks would be easier to read and less compex (trade two nodes for one).

[jstone-lucasfilm]

@pablode Although we have a standard answer for this -- modulo behaves identically to fract when its second argument is left at its default value -- this has been a common enough question that I believe we need to do a better job in the MaterialX project.

Would it help to document that modulo is a superset of fract in our specification? Or should we perhaps have a separate fract node that simply omits the second argument and is implemented in terms of modulo?

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md#node-modulo

[pablode]

I decided against using modulo because it's much more expensive to evaluate (in terms of GPU clock cycles). It simply includes operations that are not necessary for this specific purpose.

Besides, I believe that a node of the name fract conveys the intent more clearly.

[jstone-lucasfilm]

Ah, I see what you mean, and it's true that fract is potentially just a single ARB instruction, while mod requires more complex logic.

I'd be fine with adding a dedicated fract node to MaterialX, both for the potential performance savings and the artistic clarity, since this question has been brought up before by artists working with MaterialX.