[Question] GlmSharp dependency

[discosultan]

First of all, great job with SharpVk! So far it seems to provide the most pleasant C# Vulkan API to work with and it's nice to have a Windows sample working out of the box.

I noticed SharpVk has a dependency to GlmSharp. Is this something that is set-in-stone or are there any future plans on this matter?

---

Here are my thoughts:

• A graphics/compute API could be completely independent of any external Math library and provide bare interop vector types on its own (like SharpDX does with its raw types). There's a downside to this as if I were to use, let's say GlmSharp, there would be no implicit way to cast between a type from GlmSharp to its raw type from the SharpVk API. Requiring explicit conversions would hurt the API usage, in my opinion.
• Alternatively, a graphics/compute API could have a dependency to System.Numerics.Vectors which is now part of the base class library in .NET Core. On first thought, its vector types should cover all the needs for Vulkan interop.

[FacticiusVir]

Hey, thanks!

I was hoping to use System.Numerics.Vectors - and that's the library I've defaulted to in the past - but it only supports floating-point vectors (Vector<T> exists, but does not have a fixed vector length) while the explicit use of vector types in the Vulkan API is in the union classes, like ClearColorValue, which have to support vectors of float, int & uint.

Outside of that, data types can be defined by the calling code to use whatever library suits them; Vulkan has explicit Extent2D/3D types where it needs 2/3-dimensional ranges, but for vertex data those types are submitted to Vulkan purely as byte arrays.

The dependency on GlmSharp is likely a temporary measure, at least for the core API; it's a perfect fit for the example code, and is also used in the Shanq library for shader interop (though that can also be generalized with a degree of auto-mapping). It'll need a better solution for submitting Clear Color Values in the meantime, but that might be as simple as hand-crafting those types with RGBA fields and letting the calling code convert when it has to.

[discosultan]

Right, yeah, the absence of fixed length vector types for other primitives than float is definitely an issue. Thanks for your comment on this!