Read on Twitter
I'm gonna put @Needle_Mirror to good use and try to bring https://github.com/UnityLabs/procedural-stochastic-texturing back to light (that is, make it available again as a ShaderGraph node).
A thread with git, @git_fork, @unity3d, some
investigation and finally some dark Unity magic.
1/
A thread with git, @git_fork, @unity3d, some
investigation and finally some dark Unity magic.1/
First, we need to understand what their actual changes to ShaderGraph have been.
The Readme mentions it's based on ShaderGraph 6.7.1, so let's get that version from @Needle_Mirror:
https://github.com/needle-mirror/com.unity.shadergraph/releases/tag/6.7.1
Forking that ShaderGraph repo looks like this in @git_fork:
2/
The Readme mentions it's based on ShaderGraph 6.7.1, so let's get that version from @Needle_Mirror:
https://github.com/needle-mirror/com.unity.shadergraph/releases/tag/6.7.1
Forking that ShaderGraph repo looks like this in @git_fork:
2/
Now, we can add another remote, namely https://github.com/UnityLabs/procedural-stochastic-texturing. This will give us everything in one local repo to figure out what changes have been made.
Adding the remote and filtering the relevant branches:
3/
Adding the remote and filtering the relevant branches:
3/
Next up, let's make a "stochastic" branch so we can start moving stuff over.
We're gonna try and rebase that right onto 6.7.1.
4/
We're gonna try and rebase that right onto 6.7.1.
4/
As expected, there are some conflicts to resolve - a different Readme. Let's go with the original ShaderGraph one.
5/
5/
Now, the next conflict is interesting - turns out the Stochastic repo is actually based on ShaderGraph 6.7.0, not 6.7.1!
Unfortunately version 6.7.0 was never on the Unity Registry, so rebasing might not go as smooth as hoped...
6/
Unfortunately version 6.7.0 was never on the Unity Registry, so rebasing might not go as smooth as hoped...
6/
The next step actually brings in the code we're caring about, some custom nodes and the generator code for ProceduralTexture2D.
7/
7/
Now that we have a "clean" rebase, we can do that again, this time squashing all changes into a single commit.
Fork's "Interactive Rebase" can easily do that!
8/
Fork's "Interactive Rebase" can easily do that!
8/
Now we can see that the actual difference (as expected) is just a single folder, which contains the stochastic nodes.
And a docs folder came along, seems "CodeFunctionNode" renamed to "CustomFunctionNode" between 6.7.0 and 6.7.1.
We can remove that folder using "Amend".
9/
And a docs folder came along, seems "CodeFunctionNode" renamed to "CustomFunctionNode" between 6.7.0 and 6.7.1.
We can remove that folder using "Amend".
9/
So, we now have that single folder, what's next?
We could rebase that onto a current ShaderGraph version, but that would mean we're stuck with the same issue (no easy way to use it unless you want to replace everything).
Instead, it's time for some
Black Magic .
10/
We could rebase that onto a current ShaderGraph version, but that would mean we're stuck with the same issue (no easy way to use it unless you want to replace everything).
Instead, it's time for some
Black Magic .10/
I know, I know, custom nodes aren't support! Right?
Well, turns out a trick that works for ages now is using AsmRefs to add code to Unity packages that needs internals access.
Let's make a new 2020.2 project with URP 10.2, add the folder, make an AsmRef into ShaderGraph:
11/
Well, turns out a trick that works for ages now is using AsmRefs to add code to Unity packages that needs internals access.
Let's make a new 2020.2 project with URP 10.2, add the folder, make an AsmRef into ShaderGraph:
11/
The code now "lives" inside ShaderGraph! Let's fix errors.
Generation API has changed quite a lot between 6.x and 10.x:
- visitor.AddShaderChunk > sb.AppendLine
- RequiresMeshUV > true for now
- GetNodeFromGuid >GetNodeFromId
- precision > concretePrecision.ToShaderString
12/
Generation API has changed quite a lot between 6.x and 10.x:
- visitor.AddShaderChunk > sb.AppendLine
- RequiresMeshUV > true for now
- GetNodeFromGuid >GetNodeFromId
- precision > concretePrecision.ToShaderString
12/
It's time to add some test data.
Let's create a ProceduralTexture2D asset, add a nice pattern, press Apply:
13/
Let's create a ProceduralTexture2D asset, add a nice pattern, press Apply:
13/
And a URP/Lit graph for testing. Since we already have this in a "compiling" state, and the AsmRef just adds our new node to ShaderGraph itself, the nodes are "just there" to use:
14/
14/
Turns out this is already working! and doesn't look bad at all:
More info and hopefully a package release will follow later :)
15/15
and doesn't look bad at all:More info and hopefully a package release will follow later :)
15/15
