-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Survey of type conversions #1895
Comments
The reason that the "MISSING" conversions are missing is because I couldn't think of a single obviously correct operation that would be what the user would expect in the vast majority of situations. If you're converting between a color and a color, the channels have known semantics, so it's easy to come up with a sensible thing to do to add or remove channels. Similarly if you try to convert between a float and either a color or vector: there's a sensible interpretation that's usually what you'd want. |
@dbsmythe - I'll try and separate out my thoughts in to sections that so that hopefully the uncontentious ones can get easy agreement, and we can debate the harder ones. (roughly in order of contentiousness... :) )
4a) Staying within the constraint of respecting similar color/vector semantics ( 4b) If we concede the usefulness of I understand your perspective around only supplying conversions that are completely unambiguous, and only have one clearly sensible conversion, I wonder if you could share cases where some of the MISSING conversions between color and vector types might have more than one practical use-case? My major motivation with trying to complete as much of the table above as is possible is to try and lower the cognitive burden when creating these more exotic conversions. Having previously worked at a studio where artists are frequently creating graphs with 100's or 1000's of nodes in, finding ways to simplify and remove as many nodes as possible helps increase clarity of the graph. It may also perhaps create slightly more efficient shaders. I'm guessing at the end of the day all the shader compilers would optimize away any unnecessary chained conversions resulting from multiple |
First off, I'm glad this discussion has come up- it's always good to reevaluate past decisions to see if they are still good or if they should be updated.
What do others think? |
Related to #1895 Fills out more of the "missing" convert nodes. Notably this moves a lot of the implementations to nodegraphs, to reduce the maintenance going forward and to ensure all shader generation targets are aligned.
A few times rencently I wanted to convert a
vector2
to acolor3
to debug some texture coordinates. I found that there is noconvert
node to do this conversion. That got me curious as to which type conversions are currently supported in MaterialX, so I decided to do a small survey.The column down the side is the "from" type and the top row indicates the "to" type.
Observations:
<constant>
or<dot>
node.MISSING (1)
can be constructed as combinations of multipleconvert
nodes.integer
orboolean
to one of the vector/color types (Missing (2)
), requires a<convert>
node to convert to afloat
and then chaining one or more<convert>
to get to the destination type.integer
andboolean
types cannot easily be converted between (Missing (3)
).integer
orboolean
requires multiple user input, so these seem reasonable to leave as chains of nodes. (<extract>
-><floor/ceil/round>
). Unless anyone else has any other suggestions?Proposals:
<convert>
nodes for each of the vector/color cases (MISSING (1)
) - thus avoiding chaining multiple nodes.<convert>
nodes for each of<integer>
and<boolean>
to vector/color cases (MISSING (2)
) - also avoiding chaining multiple nodes.ND_convert_boolean_integer
wheretrue=1
andfalse=0
.ND_integer_boolean
following the conventional C rules of any non-zero integer beingtrue
.Potential concerns:
convert
to be "more complete" but at the expense of having a larger node library? I personally think that having gaps in a node likeconvert
leads to confusion with users, especially those new to the system or less technically minded.The text was updated successfully, but these errors were encountered: