![]() Supporting 2D vectors properly avoids having to add a "write 3D as 2D" option, which would complicate code and UX.Currently when writing to a 2D vector attribute, the type is changed to 3D, which can make working with UVs harder Maybe most importantly, we can still have a near 1-1 mapping between node types and socket types.The image texture node input becomes clearer, helpful as a teaching tool.Generally I've noticed that this "wrong data type" has more of a UX impact than I expected, that's only anecdotal though. In terms of usability, it's not the most important thing, but I think there are many places it acts as a teaching tool, saves effort, and simplifies nodeattribute exchange. Then it's just a few UI changes if we want to use the socket type somewhere, which IMO are pretty trivial. However, at the cost of a bit of performance, 2D vectors could just be handled as 3D vectors internally. There I have less experience, so I definitely won't try to tell you "it's simple!". For texture nodes, since the implementation would be started from scratch, hopefully in a rather type-agnostic way, I don't think this would be a problem at all.īut I'm guessing you're really referring to the current state of the code, particularly in shader nodes. This will get better when we have multi-type sockets implemented ( #95448).Ĭode should be written so that this is easy, and indeed, where we've used templates and other concepts, it is. Almost all math is templated, so usually the most that's necessary is adding cases to switch statements, etc. The amount of work for geometry nodes beyond this initial patch adding the socket type is very small. Improvements to multi-function signatures and API (less clear on the details here, but I think some improvements would be possible). Dynamic type sockets in node declarations. Templated functions that can work on vectors of multiple lengths. Correspondence between socket types and the stored data is no longer simple. Areas that interact with node sockets also have to consider this, instead of just supporting another socket type. Type inference becomes more complicated, because a 3D vector socket also has a length to pass around. Currently there is a lot of boilerplate to handle sockets that could be avoided. This could potentially make it easier to implement overloaded functions in nodes. Internally the node will take the XY channels of any connected 3D vector, This also raises the idea of implementing this as a dynamic data socket with support for 4D data too. This would also make implementing dynamic nodes easier as only the socket UI flag would need to be set to show that the socket is processing 2D data. This UI flag would hide the Z channel in the user interface. > I think 2D sockets could be implemented as 3D/vector sockets but with a 2D UI. > This has advantages for the user so that when changing mode this does not change the links. I think in practice this would be more complicated though. The part of your argument I find most convincing is that we could support arbitrary length (2,3,4,etc.) vectors somehow. Improvements to multi-function signatures and API (less clear on the details here, but I think some improvements would be possible).Dynamic type sockets in node declarations.Templated functions that can work on vectors of multiple lengths. ![]()
0 Comments
Leave a Reply. |