This is the library used by all our ECS demos. This library was also specially crafted to be compatible with the burst compiler
You can’t send yet a PR to this project, but we are working on providing a Contributor License Agreement (CLA) with a sign-over functionality as our UCL License doesn’t cover this yet.
Would be cool see the lib grow to include some 3D math utilities such as math.ShortestDistanceToPlane, math.IntersecionTwoPlanes, math.ClosestPointOnSegment, etc, etc… at some point. I guess this is the kind of thing the community could handle
Really cool to see that so many more project are put on Github!
I really dont understand why its made with a shader-like syntax though. I think its alienating the common Unity developer, who is used to C# naming conventions. To me it looks strange to read the examples so far, its not quite normal C# syntax. It does look like a C#/HLSL hybrid, and in my book that is not a good thing at all.
Sure its kind of neat you can use the using math; syntax, but its not what C# Unity developers are used to, and they are the overwhelming majority of your users. It feels very odd to me that 99% of the codebase adheres to one standard, and this special 1% does it differently. Graphics developers will feel out of place because its still C#, C# developers will feel out of place because its kind-of-shadery. Is the current Mathf library not adopted, and hard to use because of its syntax?
It also adds that one extra step to converting your code from the old system to the new, it will become harder to diff the old and new code. I understand that this new library might never fully replace Mathf, but lets at least make them a bit similar.
I can already see so many beginners asking why they have to write dot in one place and Mathf.Dot in some other.
Congratulations to the people at Unity! Hopefully you guys are able to sort out the legal stuff for this new repository and the C# source code repo so that people can start posting PRs
All jokes aside, the main thing that I’m concerned about is when this new math library reaches maturity and is fully integrated with Unity, is Unity going to drop the old math stuff? or are they going to live along side each other and people are going to have to consciously pick between the two libraries? (Vector3 vs float3, Matrix4x4 vs float4x4) Because if that’s the case then it would make things pretty confusing for everyone. And as people have pointed out the syntax is more like a C#/HLSL hybrid and C# developers might get irked by that. Either syntax Unity decides to pick, it won’t stop me from using the new math library and utilizing that sweet new Burst compiler
I think the HLSL syntax is the lesser of two evils. A different convention on the C# side when not working with the gpu is a minor annoyance especially if it’s clearly encapsulated to just that library. But when writing code that does work with the gpu, having the api on both sides match is a bigger deal. It’s not just the capitalization it’s the types also.
I don’t like the new syntax. You have now 3 different kinds of naming conventions across your engine:
The old Unity style
The new Unity style using the standard C# conventions
The math library
I don’t think this is a good idea for new Unity users who are learning programming with Unity.
It is a problem for your other users too. I know the Mathf library, but not much about shader programming. So I have to adopt to a new style because you think that graphic developers will be the gameplay programmers in the future?
I think Unity is slowly going to more professional route. Actually what I see the new math library is still the same thing at high level view. Maybe u you are not get used to the changes to capital letter API to small letter API and something like float2, float3. You still can use the old math library if u want but u will not able to gain best possible optimization. I see somewhere that mention new Unity library will have namespace using Unity.Something. Maybe Unity should create more detailed documentation to explain all these.
But this is supplemental. You can use mathf, or if your a graphics guy use this.
EDIT: I am mostly a c# developer, having used c# since 2010ish religiously, yet since writing shaders I do find it easier to think of data as what they are (3 pieces of floating point data, 4 pieces, etc), so having a choice is nice
A job system that handles fish movement is not working with the GPU, and still uses this syntax.
I understand that its supplemental, something next to the Mathf library. Wouldnt it be nice if the syntax was the same though, so its easier to switch between one and the other?
I dont understand, maybe I am just being obtuse, but this is how I see it:
This is going to do the same thing as mathf. So why would you make them match? That completely reverses the point of having an extra math library.
People who do C# syntax math have no problem using mathf. No change or extra library is needed for them. This is also not for them but for others, hence the different standards.
People who do GPU style math will need to acclimatize to mathf.
Now C# can use mathf, HLSL/GLSL can use this new library, and everything is written as you would expect if you use the one made for your syntax style. I really dont see any point in making a second library that is the same as the first.
Dont get me wrong, i’m super happy with the library!
I understand that it might cross compile, but that is even more of an argument to follow C# standards in my opinion. If you want non-gpu developers to use this, dont make it look like gpu code!
Right but isnt this a reason for it to use the style of syntax chosen?
I am still not understanding why you wouldnt want syntax to match the way its done everywhere else. Anywhere you are doing parralel math operations on (potentially) big sets of data, for visual stuff like games and digital media, its usually float3, float4 etc etc. (from my experience)
For me, mathf was always the odd one out as it was just plain odd compared to math in other engines or frameworks.
Anyway, I guess its just a matter of preference. I suppose people could define it to be the way they want using:
using Vector3 as float3 or something similar in their scripts (not a great solution for those who dont like the syntax, but still a way around it for now)
EDIT:
I feel you, I suppose if I felt the same way I would be finding it weird too. I am sure there will be some intermediate solution that pleases both parties at some point in the future, or at least hope so!
You’re right, its preference. And i agree with you, it shouldnt be the odd one out.
But 90% of our Unity codebase is C#, and 10% is shaders. Surely within a Unity context following the C# conventions cannot be the odd one out. Especially when writing C#! Adding a transpiler to make it easier for C# developers to do GPU code should be easiest for C# developers if you ask me.
Anyway, good things. Super cool to see this on github, and that there are plans to allow us to contribute as well. The very fact we can give feedback like this is a great improvement!
I have a feeling (which could be completely wrong) that is partly because with 2018.1, SRP, shadergraph, etc etc we are finally moving to a world where rendering and rendering related things are under our control. So before because we weren’t interacting with this stuff as much (or even could interact with it), it didn’t matter, but now that we are, having a more graphics oriented and SIMD compliant library is -potentially- beneficial for any users who are starting out fresh moving forward.
I do agree that it is confusing right now, my hopes are that during 2018.1 and 2 cycle, this all gets cleared up as not only here but everywhere as there are currently many places where there are like 2-3 ways of doing the same thing, with no real documentation on which is better or why that choice was made.
I also am super happy for all the stuff on GitHub, it makes it so much easier to keep track of development and reduces my need to ask about progress here on the forums, so keep that up unity!
I personally really like the new math convention. Matching HLSL offers a lot of benefits, for one its a very slick syntax, stuff like length instead of magnitude, which is more intuitive for beginners. plus stuff like float3, int3, half3, float4x4 is such a slick convention, i love it, especially for renaming. also there are tons of good math examples in HLSL, which can now be copy-pasted without a problem. It also matches more high performance math libraries out there. So i for one really like the new convention, it should also make it easier for people to pick up shaders in future.
Yeah I mean ultimately, if your fully new, then it doesnt matter what conventions are because its all new to you and your learning it for the first time. This will only really be a problem for those that have gotten very used to and comfortable with c# mathf conventions, and never tried to learn any graphics programming or shader programming or maths within other languages.
So really I actually think it will be easier for new users to adopt this than older users.
