Stride: Switch to SharpDX.Mathematics

Created on 2 Aug 2018  路  9Comments  路  Source: stride3d/stride

As i understand, SharpDX.Mathematics is the same as: https://github.com/xenko3d/xenko/tree/master/sources/core/Xenko.Core.Mathematics

it might be a good idea to switch to that nuget, as it is maintaned and has probably a few bug fixes. i personally contributed a few over there. the big advantage would be that every other project that is using sharpdx doesn't need to convert vectors all the time. this is particularly bothersome when its basically the same code behind...

All 9 comments

The xenko mathematics is a fork of the SharpDX one.

IMO this would require effort better spent elsewhere and the current state of affairs actually has some advantages.

it would be interesting to know whether xenko changed/fixed anything compared to the sharp dx ones.

No idea if they kept it up to date with the SharpDX one. After a brief looking at the history of SharpDX doesn't look like a whole lot has been changed over the last couple of years. Not sure how much effort would be involved doing a compare etc.

another option would be the new SIMD enabled vectors of System.Numerics. the missing methods could be provided as an extension package.

SharpDX.Mathematics depends on SharpDX, which I think would be pretty undesirable.

Moving to System.Numerics seems a natural choice but I think any move needs a bit of research. .NET runtime people have been discussing hardware intrinsics like SIMD for a while but it's still a work in progress AFAICT.

.NET Platform Dependent Intrinsics
API Proposal: Add Intel hardware intrinsic functions and namespace

We might also consider the improvements offered by C# 7.2's readonly structs. One benefit of Xenko.Core.Mathematics is that it'd be a lot easier to update to using readonly structs than to try and update an external dependency like SharpDX.

I can't name a serious engine that doesn't maintain its own math library.

The reality is that the math library is tiny in relation to the rest of the engine -but- it is used everywhere. So this is a case where the premium on maintaining consistency/style with the rest of the engine is extraordinarily high. The benefits for switching should therefore likewise be extraordinarily high.

Agree with @jhorv and @jmkinzer that we better have math lib inside Xenko.

However, nothing prevent us from improving them (readonly structs etc...) and/or merging SharpDX changes. Feel free to open separate issues when there is a concrete improvement idea, closing this one.

I wanted to add to this discussion that, switching to something like SIMD enabled Vectors wouldn't actually replace much. The functionalities that comes with them should be well tested to be useful in Xenko's context while the functionalities that are unique to Xenko can still be added as extensions methods which still retains certain control over it.

It also allows Xenko to accept a wide variety of libraries that utilizes System.Numerics which should be a great plus to developers.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

domske picture domske  路  4Comments

meriaizen86 picture meriaizen86  路  5Comments

WhitePhoera picture WhitePhoera  路  3Comments

Qibbi picture Qibbi  路  4Comments

EternalTamago picture EternalTamago  路  3Comments