-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
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
NodeMaterial: Conflicting names for varying and temp var. #15666
Comments
This is easy to fix, I just want to see if I think any better name during this week.
Pretty cool, and this nodes is to your private use or will you make it public? |
Probably public, I'll see how it goes. I'm trying to write a loader that can parse a shader graph created in Shade and construct an equivalent NodeMaterial graph. Remap, in particular, is pretty common in their examples... it can be done with a bunch of OperatorNodes, but I found debugging much easier with a single node. |
Does Some way of using |
It will be amazing.
nVu0 = node variable uniform id
nVv0 = node variable varying id
// I think it should be this!?
nVt0 = node variable temp id It was an exotic and short name to prevent conflict with external names, but the idea today is to have control of all names, for example custom functions and be able to rename it if necessary in parse time. For example: // it is purely demonstrative
var normalize1 = new FunctionNode("vec3 custom_normalize( vec3 v ) { return normalize( v ); }");
var normalize2 = new FunctionNode("vec3 custom_normalize( vec3 v ) { return v / length(v); }");
material.color = normalize1;
// here "custom_normalize" must be renamed in parse to prevent name conflict.
material.emissive = normalize2; |
I think we could append user-provided names to that ( |
It was including something close to that in namespace
But still I think this process of rename would be better being automatic. The idea will be that the programmer and artist pick up different sources of nodes and never have conflicts with each other the same thing that happens in |
My concern is that it's hard to debug code like this, if the programmer isn't sure why their shader isn't working as expected: nVv2 = mod( instanceID, nVu0 );
nVv1 = vec3( nVv2, 0.0, 0.0 );
nVv5 = ( instanceID - nVv2 );
nVv4 = ( nVv5 / nVu0 );
nVv3 = vec3( 0.0, 0.0, nVv4 );
nVv0 = ( nVv1 + nVv3 ); But there are other ways to solve that too, like a visual editor or creating some |
I understand, really will be useful a label in name for debugging... About For example, |
I already figured out, it's the |
I could put |
@donmccurdy By me you can close the Issue. These doubts about |
The example is working for me yes, thanks! :) |
@sunag sorry this is a complex node graph and I haven't been able to come up with a simpler test case, but the "varying" created for my AttributeNode gets a name that conflicts with a temp variable, but has a different type, and causes a compile error:
JSON:
GLSL:
Error:
My temporary workaround is this hack in NodeBuilder:
The shader doesn't do anything particularly cool, so as long as it compiles I think the error is fixed.
The text was updated successfully, but these errors were encountered: