Getting the stride dependencies under control

[IceReaper]

Building stride is somewhat a pain in itself. A lot of dependencies are pre-compiled. Others are build-in and hugely outdated. And again others have proper replacements. Sometimes you need to find obscure old natives, and find out how to build those for the particular platform and cpu architecture. It would be nice to get this a bit under control, by moving to nuget based dependencies where possible and ensuring stride itself comes without any native (besides the ones the nuget packages provide).

Benefits i see here:

• Getting dependencies under control
• No need to struggle with any msbuild / make / gcc / whatever stuff to get the engine build
• Allow to build the engine (without gui ofcourse) on non-windows systems
• Allow to build the whole stack without having visual studio installed
• Easier upgrading of dependencies and implementation of features
• Making stride itself pure c#

Stride core natives

libCore (Stride.Core)

This natives basicaly contains two things:

• A thread sleep command. Can be replaced with .NET its own Thread.Sleep
• An LZ4 implementation. Can be replaced with https://www.nuget.org/packages/K4os.Compression.LZ4/ (if stide needs lz4 after all! c# has some buildin compression algorythms)

In my eyes this whole native can be replaced by c# stuff?

libStrideAudio (Stride.Audio)

This native basicaly wraps 4 different audio systems:

• Celt. Can be replaced with https://www.nuget.org/packages/Concentus/
• OpenAL. Can be replaced with https://www.nuget.org/packages/Silk.NET.OpenAL/
• OpenSLES
• XAudio2. Can be replaced with https://www.nuget.org/packages/Silk.NET.XAudio/

Technically OpenAL should be one-to-rule-them-all? Alternatively having XAudio for the Windows world is a nice addition, but this means maintaining two audio systems. Are Celt and OpenSL ES realy required and do they provide any benefit on supporting even more audio libraries?

libStride (Stride.Native)

This native wraps the following components:

• XInput. Can be replaced with https://www.nuget.org/packages/Silk.NET.XInput/
• FastTextRenderer. This one could be ported to c#
• Lightprobes. This one is complex. Leaving out for the moment, need to check what parts are used.
• SpriteBatchNative. This one could be ported to c#
• StrideNative. This one can be replaced with the c# buildin intrinsics

Stride module natives

libStrideNavigation (Stride.Navigation)

This one is basicaly the navmesh builder and pathfinder. While being dead, someone already started a managed version: https://www.nuget.org/packages/SharpNav/1.0.0-alpha2 But as this is quite complex, ill not go into detail here.

libStrideVR (Stride.VirtualReality)

This native basicaly wrapps VR systems. This is quite specific, but there is also https://www.nuget.org/packages/Silk.NET.OpenXR/ Silks OpenXR namespace contains several bindings to different (and more then stride current has) vr systems.

Dependencies

Basically stuff from the deps/ folder

• AssemblyProcessor
• AssImp - https://www.nuget.org/packages/Silk.NET.Assimp/
• ATITC - I think this should be removeable.
• BulletPhysics - I would suggest replacing this with https://www.nuget.org/packages/BepuPhysics/
• CppNet - I would suggest using a managed networking library like https://www.nuget.org/packages/LiteNetLib/
• ExpressionBlendSDK - Is this realy in use?
• FBX SDK - This should be part of AssImp. However i would suggest replacing FBX with GLTF. https://www.nuget.org/packages/SharpGLTF.Core/
• FFmpeg - https://www.nuget.org/packages/Xabe.FFmpeg/
• FreeImage - I would suggest replacing this by https://www.nuget.org/packages/SixLabors.ImageSharp/
• Freetype - I would suggest replacing this by https://www.nuget.org/packages/SixLabors.Fonts/
• HtmlRenderer - Where is this used? Do we realy need this? If its gui only, we now have stuff like https://www.nuget.org/packages/Microsoft.Web.WebView2
• Irony
• LibGit2 - Where is this used? Do we realy need this? If, we can use a package like for that https://www.nuget.org/packages/LibGit2Sharp/
• LLVM - This is just used for cross-compiling the natives. When no more natives are used, the whole LLVM stack can be removed.
• MoltenVK - This should be bundled with the vulkan wrappers.
• MonoLinker - Why is this used? Wont the building c# reflections be enough?
• MSDFGEN - This one could be ported to c# if we need it at runtime.
• NuGet - There is no need to include a nuget.exe as its buildin in modern .NET
• SSH.NET - Where do we need ssh bindings for? Anyway, there is https://www.nuget.org/packages/SSH.NET/
• TextureWrappers - Do we realy need this?
• VHACD - I guess its for efficient collision model generation? Need to do some research on this one...
• WindowsAPICodePack - What do we need this for? Video playback? Need to do some research on a proper video package...

Other stuff

I would suggest aiming for vulkan-first with Direct3D and OpenGL as fallback backends. https://www.nuget.org/packages/Silk.NET.Vulkan/ https://www.nuget.org/packages/Silk.NET.Direct3D12/ https://www.nuget.org/packages/Silk.NET.Direct3D11/ https://www.nuget.org/packages/Silk.NET.Direct3D9/ https://www.nuget.org/packages/Silk.NET.OpenGL/

For windowing, currently SDL is used. We could keep that or add in GLFW as alternative: https://www.nuget.org/packages/Silk.NET.SDL/ https://www.nuget.org/packages/Silk.NET.GLFW/

[manio143]

Thank you so much for making this issue! - I've added an Epic label to it, as it will cover a lot of work and it's something we should definitely look to do. Making Stride's dependencies easier to manage will go a long way to improve maintainability in the future.

[IceReaper]

Just a a note: It might also be in the interest of the SILK developers to have an engine as big as Stride using most of their libraries. That could eventually end up in a pretty nice cooperation.

[johang88]

I think my Assimp work in https://github.com/stride3d/stride/pull/1158 is mostly done, need to take another look at it, or maybe someone would like to take it over :D Not sure how suitable Assimp would be for FBX, I remember there being some issues with it before but it might work well enough nowadays.

[ykafia]

VHACD is exactly what you thought it was, just a C library running some possible OpenCL. There's a C# alternative here if anything : https://github.com/DesignEngrLab/MIConvexHull

[Perksey]

Note that while 2.X is trying to be conservative with new features to make way for 3.0, if there is need for bindings to more pure-C libraries do let me know and I'll see what I can do.

[manio143]

Are Celt and OpenSL ES realy required and do they provide any benefit on supporting even more audio libraries?

A note on how Celt is being used: we currently store all audio in OGG format. When the user references any audio asset in the game we run FFmpeg over the audio file to convert it to WAVE format and then use Celt to compress it to OGG before storing it as binary content. During runtime we again use Celt to decompress the stream and then use an audio framework such as XAudio or OpenAL to stream the audio from memory to the systems audio device.

[juliolitwin]

-> libStrideNavigation (Stride.Navigation)

Can be replaced with DotRecast - it's active port from recastnavigation and it's working very well.

[Jklawreszuk]

CppNet - I would suggest using a managed networking library like https://www.nuget.org/packages/LiteNetLib/

To clarify: Stride Engine does NOT provide a network library and the name CppNet is coincidental - is C# library used by Stride.Shaders. You you can find source code here: https://github.com/stride3d/CppNet.

My proposal:

1. Update and bump net version to net 8 like I did in my fork https://github.com/stride3d/CppNet/commit/7f147c1d52023fe0d441b412bb749d793a2cbf20
2. Publish and sign CppNet as nuget package from Stride organization

This way we can be sure that dependency is up to is up-to-date and trusted. Another benefit would be reducing size of repo. I can also publish package by myself, create PR and transfer later to stride organization if it would be possible. I ping @xen2 if you would like to comment 😅

[Doprez]

I think even if we dont include CPPNet in builds for now we wouldnt be missing anything? I dont see why we couldnt replace it with a full C# library in the future when someone can properly implement a networking library like the ET port from Ly.

[Kryptos-FR]

@Doprez despite its name, CPPNet is not a networking library.

[Doprez]

Ah my mistake, I saw a TCP library with the same name and assumed it was that.

[Ethereal77]

This CppNet is an old library that parses C/C++. It is used in the Stride's shader compiler to pre-preocess the shader files to expand pre-processor #defines, #ifdefs, etc.

[ykafia]

Cppnet will be updated to the latest or removed with the new shader compiler I'm working on!

[Ethereal77]

Nice to hear. We need however to ensure that current shaders work properly, as some of them have complex macros and #defines (IIRC). Look at FXAA shader for example.