Earlier I was trying to write a function that would return the relevant MemberInfo for a SerializedProperty (using propertyPath and targetObject), but I ran into a problem when I realized most (all?) of UnityEngine.Object properties when serialized are prefixed with “m_”.
I figured there must be some really well hidden properties with the “m_” prefix which while never directly accessed by the user, are there internally, but using reflection it appears they don’t actually exist.
I want to know what’s happening under the hood. I’ve looked at the decompiled Unity code and found nothing of note.
Pertaining to my function, I suppose I could check each property, if the container type has the namespace UnityEngine then correct the property name accordingly.
However I assume there’s a more elegant solution.
Anyway, I’m really just curious about this “m_” business. What’s the deal?
Sorry, I forgot to make this clear - I know what “m_” means as a convention for naming variables, my question is why does a variable like Renderer’s “materials” becomes “m_materials” when serialized?
I’m not sure if this behaviour occurs in all UnityEngine serializable classes, but I assume so.
I’ve also noticed there’s almost no reference to the variable m_materials (or m_anything) in the decompiled code, except for when referring to a SerializedObject’s property.
It appears from my POV there are a vast amount of hidden variables that these m_ variables refer to, but they aren’t visible through reflection… or - for some reason - Unity prefixes every variable with m_ when serializing a builtin object (anything that uses UnityEngine namespace).
It just strikes me as very strange behaviour and I can’t see the root of it.
This is Unity though… common sense doesn’t get you very far here.
I saw these “m_” variables in UI source code, a lot. They are fields whereas the ones without “m_” are properties. I believe Unity’s serializer doesn’t serialize properties and thus, the “m_” fields are serialized instead (the reason I believe that is that we can’t see properties in Inspector without a custom Editor script).
While scripting, we are not allowed to change “m_” fields directly as a change to that field might require some other field changes or internal function calls. Therefore, we change properties instead which handle these “other changes” automatically.