Support for Custom render context

[W-Sebastian]

I want to use Stride as a 3D renderer for a cross platform project where the render window is integrated in the Avalonia UI.
Now both Stride and Avalonia, theoretically, would support this quite nicely but the issue appears with extending the Stride engine with a new rendering context (this means custom GameContext, GamePlatform, GameForm and GameWindow) which would be based on Avalonia native controls (rather then, for WinForms, based on System.Windows.Forms.Control). This is not a complicated extension as it would be, more or less, equal in implementation with the current WinForms.

The problem is that when using the Stride nuget packages (or the old Xenko ones), consumers of these packages are not allowed to provide custom instances to these classes because:

• GamePlatforms are created in a static internal method and based on an enumeration so there is no way to provide a custom implementation here;
• GamePlatform itself is marked as internal which means we couldn't inherit from it;
• GameWindow contains internal abstract methods which cannot be overloaded;
• There are various other properties or methods marked as internal that might be required in such an implementation but I don't currently have an exhaustive list for those.

Is there a design limitation for why a consumer of these assemblies couldn't provide custom classes for rendering concepts? From what I can tell, the rest of the code is neatly abstracted and should work regardless of what implementations we might have there.

Exposing the internal members outside the assembly and introducing a new overridable factory pattern for creating game platforms would allow one to fully implement these concepts in separate assemblies without having the need to modify the internal Stride code.

Of course, this would not have any impact on the GameEngine itself but would allow Xenko to be embedded in any kind of contexts.

Lastly, if there are no design limitations with my proposals or other issues I may not notice now, would a merge request be accepted? I can pretty easily fork the repo and maintain my own implementation of it but I feel it would be much better, if there are no downsides, to have it contained in the main repository.

[Eideren]

There's no reason I know of for it to be closed off like it is right now, and if there is I'm sure we can fix or work around that. You can go ahead and make a pr when it's ready :)

[tebjan]

That would be great! It has been asked frequently to integrate a 3d surface rendered by stride into Avalonia. In our fork, we have done some work regarding multiple windows, which also includes some changes to GamePlatform and GameWindow. You can look at our changes here: https://github.com/vvvv/stride/pull/7/files

It would be a very welcome change to open the entry point and be able to support more setup scenarios.

[tebjan]

@W-Sebastian did you make any progress on this end? this topic came up again in another discussion. just wanted to know whether there is any work in some branch or so?

[W-Sebastian]

Hey, yes, the changes are done and it looks fine so far, I managed to overload everything required but haven't managed to finish the integration between Stride and Avalonia; encountered some weird issues in which the rendering doesn't show so I am investigating that to see if there is anything else I may have missed. I see no point in creating a merge request for these changes if I don't manage to validate that they would indeed work.

Progress goes a bit slow though since I am also working on a totally different project in parallel.

[Agredo]

I wanted to embed Stride/Xenko inside a Xamarin.Forms Application and planning to create a custom renderer for it. I wrote down my thoughts of it here: xamarin/XamarinCommunityToolkit#549

The idea is to modify the 3D View (custom renderer) as simple as it works on UWP and writing code one time. Pretty similar to your attempt @W-Sebastian

[TheKeyblader]

I will start working this

[Aggror]

Related PR
#1315