I had a quick question, looking at the new APIs that come with the ECS there’s now a group of numeric struct types like float2, float3, quaternion (lower cased), etc.
What’s the reason for these existing instead of the regular Vector2, Vector3, Quaternion, etc. ? The APIs the new types provide look similar to the old ones, with the addition of swizzle properties, etc.
I guess it’s not final yet. Seeking answers as well. Ideally I would like to be able to use Unity.Math or Unity.Mathematics and the api remains familiar.
However what is familiar? This looks C# → compute friendly as an API. I guess I never asked this question.
They are all lower cases because of being struct instead of class for jobs purpose. I think there is a video of Joachim on YT that explains this question.
The regular Vector2, Vector3, etc. are also structs. What I’m asking is why the new types exist and why the old ones weren’t used?
I am sure there is a reason, I just have not found it.
I think here’s an explanation:
Primarily I believe it is for the Burst compiler as they are more designed around the speed ups it can provide.
The reason is speed. The Unity.Mathematics structures are exactly what the graphic API want for input. A NativeArray of them are ready to go without extra processing. The Vector3 has some extra fields so you have to copy them into the right format first, then send them to the graphics API.
Vector3 doesn’t have any extra fields. They’re both 12 byte structs with exactly an x, y and z field.
void Start() {
unsafe {
Debug.Log(sizeof(Vector3)); //12
Debug.Log(sizeof(float3)); //12
}
}
So I’m pretty sure that if you cast them to a byte-pointer, they’ll have the exact same bytes in the same order.
That being said, it is for speed. Looking at float3 in the decompiler, the difference seems to be that everything done in float3 is unsafe. As an example, the indexer for Vector3 just goes “if the index is 1, return y” and so on. The indexer for float3 does some pretty gnarly pointer juggling.
So float3 is the same struct layout, but with a lot faster methods. I don’t know why they didn’t just go and make Vector3 fast, but unsafe. Maybe that breaks backwards compatability somewhere?
Also now, the naming fits with what you use in shaders. You send in a float4 and get a float4 in the shader.
Yeah thought so.
Yeah, while this new stuff does look great, I reaaally wonder why VectorX could not be made to work like that. There’ll be a constant stream “hey please add float3 overloads” requests for a long time 
What is the long term plan? Will Vector3 be deprecated or are we supposed to use both?
[quote=“Baste, post:8, topic: 695809, username:Baste”]
Vector3 doesn’t have any extra fields. They’re both 12 byte structs with exactly an x, y and z field.
[/quote]I was thinking there was a 4th field, but it is actually a const, so you are right, they are both the same size.
Changing something from being safe code to unsafe code is sure to cause problems somewhere unless you want to do a full audit of all code that ever used Vector3. 
Vector3 if you are using GameObjects and float3 if you are using ECS/Jobs. Both if you use both. It is more painful right now since it is not complete. For example, there is no way to create meshes from a Job without converting to Vector3 (and others) first.
Using both sounds horrible. Are we supposed to write overloads for all of our math utils / other functions? Or pay the cost of implicit conversions all the time?
float3 being unsafe does require an audit, but just of that little unsafe code, which I’m sure unity has gone over. Also worst case they could just conditionally compiled the unsafe parts if unsafe is enabled
This is an early preview so it is far from feature complete. The conversions are temporary and we are just waiting on the new APIs which are being worked on now.
Sure but it’s not just unity’s API (which will be a large enough task as is), it’s also all user code, asset store code, etc.
There are obvious reasons to have MonoBehviours and ECS at the same time - but so far just can’t find the reason why we needed Vector3 and float3 at the same time.
The reason for float1234 etc was to establish a math library with a more consistent & simpler API. One that is also better fitting into a model where the compiled code should be automatically vectorized.
It’s very much work in progress.
While I do not mind adding an extra types for the job system, what I do not understand is the naming; didn’t you (or someone else) from Unity sayyou will release all new APIs using the Microsoft C# naming/coding standards?
Yes but this is math. We look at these types as builtins.
Yeah… I was surprised by some of the names too. Things like math.lengthSquared() are going to trigger a lot of people’s OCDs for sure. Would it hurt to just name it Math.LengthSquared()? 