Page MenuHome

Dynamic socket hiding for single-operand math functions.
Needs ReviewPublic

Authored by Omar Ahmad (OmarSquircleArt) on Mar 30 2019, 9:21 PM.

Details

Summary

Dynamic socket hidding for single-operand math functions like sin, cos, abs, etc.

This is my first contribution to Blender, so I am still not familiar with the process or the code base. I mainly did this patch as an introduction to my proposal project for GSOC19.

Diff Detail

Repository
rB Blender
Branch
math-dynamic-socket (branched from master)
Build Status
Buildable 3270
Build 3270: arc lint + arc unit

Event Timeline

What happens if the user scrolls through the functions of the Math node now (for example ctrl + mousewheel) ?
Does it automatically disconnect the second Socket once it gets to Sin ?
Is the connection then lost for every other following function, i.e. add ?

That would be unfortunate.

Greying out Sockets would do too, imho.

@Christian Friedrich (rbx775) Yes, the link will get disconnected if the operation became a single operand one. And it will get reconnected again if the operation became two operand. See this gif:

Brecht Van Lommel (brecht) requested changes to this revision.Apr 2 2019, 6:56 PM

This breaks backwards compatible for cases where links were connected to the second socket. In general we always try to preserve compatibility unless there is a good reason to break it.

A solution could be to hide the first socket if there is a link to the second socket, and keep node_shader_exec_math and gpu_shader_math unchanged?

This revision now requires changes to proceed.Apr 2 2019, 6:56 PM

This breaks backwards compatible for cases where links were connected to the second socket. In general we always try to preserve compatibility unless there is a good reason to break it.

A solution could be to hide the first socket if there is a link to the second socket, and keep node_shader_exec_math and gpu_shader_math unchanged?

Maybe it would be better to reconnect the link in versioning code to the first input, when e.g. sin is selected?

This results in a minor api breakage, though. Not sure if it is a big deal in this context..

This breaks backwards compatible for cases where links were connected to the second socket. In general we always try to preserve compatibility unless there is a good reason to break it.

A solution could be to hide the first socket if there is a link to the second socket, and keep node_shader_exec_math and gpu_shader_math unchanged?

Aren't there some way to fix this upon file loading? Is that what the versioning_280.c file is for? Transferring links from the second socket to the first socket seems like a better option. It is very unlikely that someone used the second anyway, so we get cleaner code with little file loading overhead.

Edit: Sorry, didn't see Jacques' comment at first.

Versioning code would indeed work as well, just rather more complicated to implement.

I want to learn about the process. So I think I will take the versioning approach if you don't mind.

  • Added versioning code to math node.
Omar Ahmad (OmarSquircleArt) planned changes to this revision.Apr 2 2019, 10:42 PM

It seems the versioning code doesn't work when the nodes are inside node groups. So I will fix that and refactor the code based on suggestions by Jacques.

  • Refactor math node versioning code.

The versioning code still doesn't work when the math node is connected to a Group Input node. This is because the link to the Group Input node have a null fromnode member for some reason. @Brecht Van Lommel (brecht) Why does links to Group Input nodes have null fromnode members?