Feedback Custom function graph node possible?

I'm not so sure but I can't find it in node editor. I think it should be possible to write custom function node like shadergraph could. Some math expression would be simpler if we write it as a code

Is it possible to have?

 

This is the best way I've found: https://github.com/landonth/unity-vfx-custom-addons

 

Such an important feature I;''m surprised it is not implemented since it is already present in shader graph.
This could solve all the messy graphs I have got and speed up my development drastically.

 

how is thi not implemented.. Such a basic thing

 

Custom blocks are such a force multiplier that I can't understand why they are such low priority.

If you give us custom blocks we can fill in so many missing features ourselves. Implement this and you can all take 3 months off and leave us to it!

Anything that unblocks users from implementing things themselves should be bumped up the list. Make the tools flexible and open to extension. That was always Unity's core strength.

 

It is interesting that shader graph actually has it.
https://docs.unity3d.com/Packages/com.unity.shadergraph@13.1/manual/Custom-Function-Node.html

Sorry for simplification but is "this" and "that" a shader in the end ?

Is VFX team and shader graph team completely separate. The goals looks so aligned that such a decision seams hard to justify ?

 

Well, they are separate teams.

 

If they don't cooperate than this is some serious waste of productivity.

 

There will be always some prioritization and someone unhappy, but koriat probably also meant, that there would be probably a lot of benefits if teams cooperated/communicate each other a bit more. I have no perspective from internal side, but from my perspective there is good example - graph package. Both teams (shader and vfx) worked on graph UI, both of them separately, while they are almost "the same" tool. In result (at least in my opinion) vfx team did way better job than shader team - overall better tool, while both of them could be capable of the same.
For instance swizzling in vfx is incomparable better than shader graph.

 

This statement concerns me greatly. Henry Ford probably didn't actually say “If I had asked people what they wanted, they would have said faster horses” but this springs to mind here. User requests should be a data point and nothing more. A strong product vision and an understanding of how features combine should be the driving force.

I could write a short novel about how asking users what they want is not the right way to design a product (I don't actually have to as Jason Fried has written several) and I can list several flaws with the current roadmap voting system even if I was to accept that votes should guide features.

Most of your users don't know about the roadmap and most of those don't vote. It's statistically misleading and not granular enough. And it ignores a core fact - that the utility of some features is not immediately obvious to people in advance. I would argue that this applies especially strongly to custom function nodes. It would enable a small group of users to provide features that would help a much larger group.

 

One of the popular sentiments on this forum is that Unity does not listen to their users, but when they say that they base their decisions on user feedback, people say that they actually should not have listened, because features they wanted were not popular enough to implement Sorry, my actual point is that it is impossible to talk about the internal processes looking from the outside because we have no idea how the feedback is actually evaluated and how decisions are made.

 

You can't rebut my point by saying that "popular sentiment has said otherwise". If that's the popular sentiment then I'm specifically arguing against it!

> Sorry, my actual point is that it is impossible to talk about the internal processes looking from the outside because we have no idea how the feedback is actually evaluated and how decisions are made.

True. I think it's more the case that the voting/roadmap is a convenient excuse on occasion. I doubt it drives the roadmap entirely. I just don't like it when it's wheeled out in place of a more cogent argument against a particular priority.

My thinking is thus - features such as the one under discussion - which empower users to fill major gaps in functionality will most likely turn out to be useful far in excess of it's development cost.

 

In other thread it was already said that roadmap is huge guide, but actually the dev team is picking what they think is important (might be they just made a mistake). Well, we can only speculate, but I guess the reason is the fact it has no such big value as shader graph custom node, plus it might be time consuming to implement.
I 100% agree custom node allows to fill all missing gaps, so it has great value overall, but to be very honest I can't see many gaps to fill. Great number of functionalities is already implemented and almost anything custom you might need can be build with operator blocks.

 

https://github.com/landonth/unity-vfx-custom-addons

Based on work done by Thomas Iché - Unity employee.

I've used it. It works well. It's simple to maintain compatibility with updates to VFX Graph and it's proved invaluable.

But an official solution would result in more uptake and a higher chance of people sharing code with the wider community. An ecosystem of custom nodes would be very nice.

With regards to utility, at it's simplest it's a huge time saver. If I want something like "sqrt(cos(x)) + 4*smoothstep(0,0.7,sin(x+t))" that's a massive pain with nodes and seconds if I can write custom functions.

And suddenly wanting to change sqrt(cos(x)) to cos(sqrt(x)) ? yeah - horrible with nodes, trivial with text. I often do things like this many times when experimenting. Nodes are a huge creativity killer in this regard.

(https://github.com/IxxyXR/Parametric-VFX is where I used custom nodes)

 

Assuming this is all what is needed to implement custom function, plus works correctly and does not break anything (I just checked files, not test), then I don't understand why it is not implemented yet.
Still, let's not exaggerate, changing sqrt(cos(x)) to cos(sqrt(x)) is not so time consuming, unless you do it 30 times a day.

 

That's exactly the point. When I'm experimenting - I change equations around dozens of times. I treat the VFX graph like a creative coding environment and I use it in an exploratory way.

So yes - I do change graphs 30 times or more sometimes and no, I'm not exaggerating.

A creative tool should be fluid and malleable. And nodes are in many ways less creative than a text-based tools for me.

 

Agreed, using nodes for complex math equations is a total joy killer.
I would also say that even non complex equations makes graphs complex.

 

Thanks Vlad,

Very reasonable.

And FWIW - I agree that nearest neighbour is probably more valuable than custom function nodes (mainly because I'm salivating about FluvioFX being resuscitated). And access to VertexID between VFX graphs and Shader Graphs is huge.

 

Totally agree with you vlad, this custom block, even though the UI does most of the common routine tasks is only scratching the surface of the capabilities of a block and is still really error-prone if you don't know what you are doing with it, I have put some simple access to variables (curves and gradients) and currently there is absolutely no promise my proof of concept will be maintained or improved in the future.

Another custom function that I'd loved to have worked on, is a custom function operator that parses a string and auto exposes inputs/outputs based on an AST, but it's a whole other level of complexity to do as it does not generate HLSL but VFXExpressions instead, but TBH is way beyond my ability.

 

Which are all arguments in favour of an official solution

Even a very simple hard to use custom block that was officially maintained would be better than an unofficial, simple, hard to use custom block - which is the current status quo.

"The perfect is the enemy of the good" and all that.

That sounds fantastic (and complex to implement). I think this discussion has clarified in my head that there's two different things that I think custom blocks help with:

1. adding new functionality that would be hard or impossible to implement with nodes
2. Hugely speeding up workflows that involve building expression trees

I think there's an slightly overlooked user - someone who might not regard themselves as a developer in the widest sense but isn't afraid of writing code snippets or short scripts. Unity seems to be catering for this type of user less and less - the push seems to be for more complexity on the C# API side of things and "we must hide all traces of code lest we scare away technical artists" at the other.

 

I just noticed name "Block" mentioned many times in this discussion.
But I assume OP and me have more like an "Operator" on our mind.
Is it the same for all of us?

Also it's not like a custom function Block would be a bad thing.

 

I guess it does not matter, becuase both of them would be most likely capable of doing the same thing (at least for testing).
Operator is better for sure as you can plug result anywhere you want.

 

https://docs.unity3d.com/Packages/com.unity.visualeffectgraph@17.0/manual/CustomHLSL-Common.html
Nuff said.
Thank you unity.

 

Custom Function is great. Now it allow while loop and greatly simplified math node

But still, are there anyway we can reference to shader property in blackboard? Direct naming are not found in HLSL
It would be more convenient, and also it seem like the HLSL function can only taken 4 arguments (it report some error when I include 5th argument). So if HLSL function can reference the property directly without using argument slot it would be more handy

Another thing I would like to request is, there should be a way to send Count along with StructuredBuffer. So we could send dynamic list for looping instead of sending

int count

separated from buffer

 

Thank you very much for your explanation

What I mean is not the native count of the buffer (which actually is capacity?). I mean I also use the buffer as a list, making it 64 slot but sometimes just send data less than that. And use it in a loop. So I need to send both the dynamic count and buffer itself

What I wish is we could just send the buffer object and access the count in hlsl directly

Code (CSharp):

1. //current approach
2. float Sum(in StructuredBuffer<float3> points,in int count)
3. {
4.     float3 value;
5.     while(count > 0)
6.     {
7.          count--;
8.          value += points[count];
9.     }
10.  
11.     return value;
12. }
13.  
14. // What I wish
15. float Sum(in StructuredBuffer<float3> points)
16. {
17.     int count = points.count;
18.     float3 value;
19.     while(count > 0)
20.     {
21.          count--;
22.          value += points[count];
23.     }
24.  
25.     return value;
26. }

 

Guys you got errors in documentation In some of "Supported Types" descriptions.
https://docs.unity3d.com/Packages/com.unity.visualeffectgraph@17.0/manual/CustomHLSL-Common.html

In:
VFXGradient
StructuredBuffer
ByteAddressBuffer

Is ByteAddressBuffer also a GraphicsBuffer ?