Please add double2 / double3 and all of similar valuetype in unity mathematics into SerializedProperty so we can set those to SerializedObject without losing precision
That would be a waste of additional bloatware 
First of all PropertyField does already support double values as it uses MultiPropertyFieldInternal on the child properties and since they are double fields they will be handled as doubleValues. If you want to manually handle the double values, you are free to do that. The x,y and z components are separate child SerializeProperties. So you can use FindPropertyRelative or just use the property iterator like what MultiPropertyFieldInternal does.
The Mathematics is an external package with tons of compound types and it would not make any sense to add all of them to the core editor functions. All those can be broken down into the actual primitive types.
That was more of a reason for SerializedObject to support unity vector with double component so instead of get and set each field as double separately we can set all of it as one double3 or even double matrix
So you want to have SerializedProperty to have individual properties for
double2
double2x2
double2x3
double2x4
double3
double3x2
double3x3
double3x4
double4
double4x2
double4x3
double4x4
What about the dozens of other compound types that come with the Mathematics package? First you argued about lack of precision support and now you just argue about convenience
Keep in mind that you can always create extension methods like this:
public static class PropertyDoubleExt
{
public static SerializedProperty SetDouble3(this SerializedProperty aProperty, double3 aNewValue)
{
var xP = aProperty.FindPropertyRelative("x");
var yP = aProperty.FindPropertyRelative("y");
var zP = aProperty.FindPropertyRelative("z");
xP.doubleValue = aNewValue.x;
yP.doubleValue = aNewValue.y;
zP.doubleValue = aNewValue.z;
return aProperty;
}
public static double3 GetDouble3(this SerializedProperty aProperty)
{
var xP = aProperty.FindPropertyRelative("x");
var yP = aProperty.FindPropertyRelative("y");
var zP = aProperty.FindPropertyRelative("z");
return new double3(xP.doubleValue, yP.doubleValue, zP.doubleValue);
}
}
This could probably be generalized for double4 and use the same code for double2/3/4. But it’s probably not worth it.
This was being said from the start
so we can set those to SerializedObject without losing precision
I request double2 / double3 being know full well there is already double property. And I have written that kind of code you presented and felt it was very annoying so I post this request
There is absolutely zero point in adding serialized properties for structs, especially structs that exist in a package. You can already access it via SerializedProperty.boxedValue anyway.
A better request would be for an entire replacement system for the aging SerializedObject/Property system.
That may be the case, but whatever replacement you may come up with, would need to be quite similar. The main advantage of the SerializedObject is that it can represent multiple instances at the same time to allow multi object editing out of the box. Yes, it’s certainly far from perfect, especially when we now mix in polymorphism with SerializeReference. Its initial design has “duct-taped” changes all over the place and some of the property names are quite ambiguous. Though given the functionality it provides it’s quite difficult to design a better system. Though I agree that it would be great to have some solutions for some of the long term shortcomings.
Odin Inspector has had a strictly better system for years, known as the PropertyTree. It’s how the plugin provides all its extra functionality: it tosses out the old garbage SerializedObject system and replaces it with a entirely different, far better replacement. It can even be used on any arbitrary data, serialized or not: How to Use The PropertyTree | Odin Inspector for Unity
So Unity pretty much already have a template for a better system. Even if they gave us 10% of what Odin does, it would be a massive upgrade.
1 Like
Yes, sure. But Odin currently builds on top of Unity’s serialization system. So it currently just adds another layer of complexity and overhead on top to do what it does. Unity’s serialization sytem isn’t just about serializing C# / script data but also the data on the native engine side. Yes, they probably should simply seperate the two worlds and focus on a robust scripting only solution as that’s what we as users most of the time interact with.
Odin packs a lot of overhead on top of Unity’s serialization system. Of course for most cases it’s kinda irrelevant. I’m implemented quite a few custom specialized solutions on top of Unity’s serialization system that bypasses some of the limitations in exchange of slightly more overhead.
Of course the biggest issue, as always, would be that changing to a completely new system would be a huge breaking change. Literally everything in Unity is built around the current serialization system. That would mean an almost complete re-write of their own UI and as a bonus, all third party systems (including odin) would no longer work. Staying backwards compatible would of course just result in an even bigger mess. So it’s not that easy to do the switch to a new system. I think those are the main things that are holding them back.
But yes, a new system which should also open up access to metadata from the assetdatabase would be great. So we can actually develop save game solutions when we can directly address and lookup built-in assets. The Addressables were also just some patch on top and isn’t as convenient as having access to the built-in assets. Custom solutions are always free to introduce completely new concepts. However changing existing structures is always a real pain. Hopefully they find a solution and that they can provide transitioning solutions. But that would take quite some time.
That’s the thing… the PropertyTree doesn’t care about the specific serialization in use! It doesn’t require Odin serialisation to function. It’s just a data structure to represent how a particular given piece of data should be drawn, serialized or not, with cleaner access to the underlying values.
You can still have the old SerializedObject system hanging around, but newer systems can use the new system as a drop-in replacement. Same as UI Toolkit, where IMGUI still exists but we can opt to use the new system as wanted/required.
1 Like