We are porting an existing commercial project from .NET 4 and .NET Compact Framework to .NET Standard 2.0. In doing so, we are converting a bunch of CPU-based draw calls to a GPU-driven renderer. (OpenGL preference)
Our first attempt has been to use UrhoSharp, which was Microsoft’s firm recommendation. As of Feb 2020, they were the only option ready-to-go for .NET Standard 2.0 support on UWP + Android + iOS. So we went for it. But… UrhoSharp is a “dead project” with a few defects that we can’t get fixed.
We are now considering switching to MonoGame, now that 3.8 has been released and supports .NET Standard 2.0, and runs on UWP+Android+iOS.
Our application is a heavy-weight GPS/Map application, that shows loads of vector and raster content, overlaid. We render it in 3D space, so that when you zoom out, we can convert it into a 3D global view (with curvature). When zoomed in, it’s a 2D mercator projection (simple).
We also have 3D Ground-View support (similar to Street View)… where we use 3D objects to represent various Vector data (e.g. buildings).
I’m wanting an assessment from experienced users of Monogame of any “gotchas/pitfalls” you might see for us, if we elected to port to MonoGame 3.8.
Also, wanting to make sure that we can write all shaders in OpenGL, and that we can avoid HLSL (so that we don’t need to versions of each shader). UWP is DirectX natively, but are hoping that MonoGame might enable OpenGL shaders to work on the UWP platform. That would be a bonus, since UrhoSharp forces us to write HLSL for UWP, and GLSL for Android/iOS - so we have 2 versions of every shader.
Sounds like you want just a graphics API yes? MonoGame does provide that but it also a bunch of other APIs tied to it including Audio. Do you need Audio?
Lithium, yes mostly we just need a renderer, to render output to a Xamarin Forms render surface. We probably won’t use the other functionality of MonoGame. It would be nicer if MonoGame were deployed as components to save on app size, but I’m betting the waste here is mostly negligible.
Martenfur - really? HLSL only, and it gets converted to GLSL? Well that is nice. How is that accomplished?
Lithium, thanks for the recommendations. We are a C#-shop and so only Veldrid is an option for us. There doesn’t appear to be a Veldrid “forums”, but only a gitter session.
We’re more interested in selecting a platform with more of a community, examples, and momentum. Thus Monogame seems to be an appropriate selection. Since Monogame is based on XNA, this whole platform is essentially about 15 years old now, and has quite a community (compared to Veldrid).
For now, we’re entrenched in UrhoSharp, but if we can’t revive this project (has been dormant for 2 years, and mostly dormant for 4 years), we may be looking for another platform. Monogame, as of now, seems to be our best alternative.
Martenfur - when you say “shader compilation works only on Windows”, I assume this simply means that you have to compile all shaders during “development” and that the compiled shaders are still deployed and work normally on all platforms, right? (iOS, Android, Windows…)
It’s been a while since I worked with the XNA pipeline for assets.
Ye, you cannot compile them natively on Linux. Compiled shaders themselves work just fine on all platforms. Although, you actually CAN by using some shaky Wine setup, and it works, but it’s a pain.