+10
Completed

Property display names different to variable names

Andrei Nadin 10 years ago updated by Freya Holmér (Developer) 10 years ago 16

Should have brought this one up earlier (sorry)


I stick to property names such as MainTex, SpecMap, BumpMap (Unity default names) which correctly become _MaintTex, _SpecMap, _BumpMap


The beauty of this is swapping shaders around, we keep the already assigned textures..


Ideally though, I have


Albedo (RGB) or Diffuse (RGB) in the material inspector for _MainTex

Specular (RBG) Gloss (A) for _SpecMap


etc.


At the moment we get the whole name in the material inspector :)

Answer

Answer
Completed
This is now possible in RC 0.37 :)


The question is though, should you be able to completely unlink displayed vs internal, or should there be a dropdown to select any of the preset internal names (_MainTex, _BumpMap etc.), while being able to rename the displayed one however you like?

Hmm, good one.


I think I would vote for sticking to the 'standard' if we can call it that. It just make things easier. If Unity ever add more I guess Shaderforge could keep adding them..


Thats the problem of course, it makes Shaderforge less flexible and means we have to wait for updates from you if and when new internal names are required and if you make it say a drop down of internals + custom then might as well just have fully unlinked really. 


Whats simpler for you?

This is actually pretty important. I second this request as Unity relies on some specific variable names to drive other things.  From the documentation:
  • Self Illuminated materials will emit light tinted by the Color and Main Texture and masked by the Illum texture. The intensity of emitted light is proportional to the Emission property (0 disables emission).
I know from experience that if something is not "_Illum" and "_MainTex" in the shader, Beast won't like it. "_EmissionLM" is another variable that dictates the intensity of the beast illumination. I wish they didn't hardcode this stuff but there it is.. There are definitely more.
Yup and even more funny is that if you don't have the word Transparent in the shader name or _TransparencyLM in there somewhere, Beast renders all alpha'd/clipped textures as solid (making for very silly shadows). Maybe a good idea would be to have a Unity Keywords section in the properties that we can tick on or off?
Yes, please! I ran into this today when trying to write a script that copies textures from procedural materials to materials using ShaderForge shaders. Since I had named my properties "Diffuse", "Normal", etc., they did not match the built-in Unity shader properties "_MainTex", "_Bumped", and so forth. So I had to go back and change all my ShaderForge shader property names to ugly "_MainTex" (yuk!).
If you use the properties like 'Main Tex' it becomes _MainTex automatically
@Andrei: Yeah, but in a normal shader, you can tell it to use the Property "_MainTex", but use the Label "Diffuse" in the Unity inspector. This allows you to have labels that make sense in the inspector, but keep the properties consistent with other shaders (and there are benefits to doing so).

Property & Label example:
_MainTex ("Base (RGB)", 2D) = "white" {}

We would like to do the same thing in ShaderForge. Right now, in order to get your property to match "_MainTex", you have to call your label "Main Tex". Not terrible, but not ideal.
Yup, I know, I think Joachim will come up with a way to do tho eventually but as you can imaging it does add more complexity to the UI, mostly because we don't edit the nodes in a side bar IMO. There is not a lot of space to do this, kind of entry but perhaps we could edit both the display name and the derived name when you are editing. Like you say, it's not terrible as it is now and over the time with Unity I just relented and went Main Tex from Diffuse anyway. (should be called Albedo too really) ;)
I still want to do this, it's, like you said, just a bit of a messy thing to solve, interface wise!
(I'm quite picky when it comes to interface design)
Good, I am with you, the pixels matter!! 
Well, if it makes it easier, I would be happy just being able to change the label in the shader code directly. I tried to do this, but when I re-opened the shader in ShaderForge it automatically changed the label back to match the property name.

So if we could edit the labels in the shader code directly and have ShaderForge ignore the labels somehow, that would be a good compromise imo.
The goal is to make SF able to generate the entire shader from only its metadata, at some point, so I don't want it to read from the code itself.

It's not 100% independent, it reads the shader name from the code, but the rest should be indie, I believe :)
So... for compatibility with other things I find myself needing to have specific property names especially one that includes an '_' in the middle so I am hopping to bring this back to the please do pile.  I could certainly do with a way to be able to edit the auto generated name after its created.
Oorrr ... you could try to convince UT to get rid of hardcoded naming conventions as the ones required by Beast and to cook up something more generic and useful.
Sorry. Thats my April fools joke for today.
Answer
Completed
This is now possible in RC 0.37 :)