Key Questions/Concerns before I invest more time

[najak3d]

I love what you've done here. It's a goldmine opportunity for better UI's inside Stride!

Here are some questions/concerns that I have before I dive deeper:

1. TODO: In your Tutorial, show some Screenshots of each step. You have 18 steps, but only 1 screenshot... Please add a dozen more, IMO. It should be easy to do as you follow your tutorial yourself. These screenshots helps the reader to know they are "doing it right". End it by showing a screenshot of the Game window that they should see after following your tutorial -- could just be a "Hello World" UI with a simple Stride Scene. https://github-wiki-see.page/m/TheKeyblader/Stridelonia/wiki/Getting-Started

2. Question: Regarding your WindowsGame -- I love this -- windows all over the place! However, to me it looks like ONLY Avalonia (which makes it less impressive) - yet you have Stridelonia linked, in, but aren't rendering anything 3D. Questions: Where all CAN You render Stride inside this game? Can you render it to the main invisible window (that keeps score?) Can you render it to the "Click Me!" buttons? I want to see what Stridelonia's added-value is to this game. Currently, it just looks like a plain vanilla Avalonia game.

3. Question: Do you have a Stride-Render Surface concept implemented? (where the application is a true Avalonia App, which simply has a specialized RenderSurface that enables Stride to render to it? If not there already (I didn't see it in code) - Do you have any ballpark idea for how difficult this will be to implement?

==== New features I may help you develop (by stealing techniques from Urholonia (Urho.NET + Avalonia)). Urholonia is able to render Avalonia inside Urho, but also then allows you to define an Urho View3D control inside Avalonia, which then renders an Avalonia Scene! In this way, they are able to create a Game Modding Toolkit.

I want an excuse to use Stride3D instead of Urho.NET, so if we can create a modding Toolset with Stridelonia -- let's please create a Proof of concept, to prove it... OR, if it can't be done yet, I might be able to help.

I am VERY excited about what you've done here. It's, IMO, what the .NET community NEEDS, allowing an avenue for .NET apps to render to a 3D view.

[najak3d]

Our team goal is to provide .NET Apps with a great way to add in a 3D rendering surface (for visualizations, etc).

And so making a raw Avalonia App work with Stride (without them starting all over and creating a Stridelonia base app). In short, they should just be able to reference a Nuget package, and then will be able to add the "StrideView" control into their layout, and it will bind to a Stride Scene (setup via the Code-Only approach for Stride).

Say it's an "Engine Service App" which has a database of "Fix procedures" for the mechanics. Currently they all rely on 2D diagram pictures. But there is a move to instead model the Engine in 3D, and then show the procedures as 3D animation they can step through -- and at will, they can Freeze Simulation and manually control the Camera to get the perfect view of the engine they are wanting to visualize. (For example, often they are trying to do things by "feel-alone" as they can't see that part of the engine because it's all crowded.)

Or imagine a IKEA wanting to provide online app that does the same for their assembly instructions.

etc... Making Stride "used by" other .NET apps, is the goal here. (not the other way around)

In short, we need to make it so that "apps can use Stride easily"... vs. just "Stride can now use Avalonia".

I hope you agree, and I'm willing to put my weight behind a project that I think has a good chance of achieving this. I'm guessing Stridelonia is that Holy Grail, once we finish it up.

[TheKeyblader]

TODO: In your Tutorial, show some Screenshots of each step. You have 18 steps, but only 1 screenshot... Please add a dozen more, IMO. It should be easy to do as you follow your tutorial yourself. These screenshots helps the reader to know they are "doing it right". End it by showing a screenshot of the Game window that they should see after following your tutorial -- could just be a "Hello World" UI with a simple Stride Scene. https://github-wiki-see.page/m/TheKeyblader/Stridelonia/wiki/Getting-Started

Yes, I need to put time into the getting started to be more easier.

Question: Regarding your WindowsGame -- I love this -- windows all over the place! However, to me it looks like ONLY Avalonia (which makes it less impressive) - yet you have Stridelonia linked, in, but aren't rendering anything 3D. Questions: Where all CAN You render Stride inside this game? Can you render it to the main invisible window (that keeps score?) Can you render it to the "Click Me!" buttons? I want to see what Stridelonia's added-value is to this game. Currently, it just looks like a plain vanilla Avalonia game.

Actually, Stridelonia allows just to render Avalonia in stride. This sample is demonstrate you can Avalonia inside a 3d Space or Screen Space. so with styles you can create ui like this

with 3d and screen ui

For rendering Stride inside Avalonia is possible but not implemented.

Question: Do you have a Stride-Render Surface concept implemented? (where the application is a true Avalonia App, which simply has a specialized RenderSurface that enables Stride to render to it? If not there already (I didn't see it in code) - Do you have any ballpark idea for how difficult this will be to implement?

Effectively I don't have Stride surface implemented. Actually, my main blocker is knowledge: "How to render 2d with 3d".

Here are some steps to get an idea of what to do.

1. Implement StrideRenderer for Avalonia. This will allow Avalonia to render directly to Stride with Graphics acceleration and agnostic to Graphics API because Stride do it for me.

2. Create components and components 🎉 The main scene will be SceneUserControl which uses custom operation and use RenderTexture to render an 3d scene. and create addionnal components to describe StridePrimitives (Cube,Sprite,Animation)

   Doing this we can end with library like that https://docs.pmnd.rs/react-three-fiber/getting-started/your-first-scene#the-result

[TheKeyblader]

So we can imagine two directions for Stridelonia.

• UI framework for Stride so Stride is hosting Avalonia just to allow easier UI Coding. (The actual state to Stridelonia)

• Use Stride as Renderer Platform for Avalonia. Which will allow Avalonia to gain functionalities Stridelonia will have additional UserControls to describe Stride Scenes We can summarize this as "Use Stride with Xaml"

For sure, the second direction is far more attractive because we will have all functionality of the first one and more advanced functionalities with Stride rendering inside Avalonia Window

[najak3d]

IMO, Ideally it does both, at the same time. In Game Toolset mode, Avalonia is the main app, with a Stride-Render-Surface that is rendering the Stride scene --- while inside of Stride, we have another Avalonia UI rendering inside the game window.

For Urho.NET we have this "net effect" -- but in truth, it's all just Urho.NET rendering Avalonia, but creates this effect. Only limitation here is that Avalonia Toolset must reside INSIDE the Urho.Net Game window. (Can't drag windows outside of the Urho window.)

But for Stride3D -- would be very nice if we can implement such that Avalonia is the "main app" simply Using Stride, by including a Stride Rendering surface into it's layout.

[TheKeyblader]

But for Stride3D -- would be very nice if we can implement such that Avalonia is the "main app" simply Using Stride, by including a Stride Rendering surface into its layout.

Using a Stride Rendering surface is easier to implement but you will have performance lost because you need to copy textures. In of case of nesting, it will be worst because you need to copy texture for each top-level or windows

Using RenderTexture and Mix textures at final stage I think will better. Avalonia does render only when is necessary so we can economize resources.

The easier solution will be to create a sub-window in Avalonia Window but we lose some possibilities (like Apply to shader to Avalonia text).

[najak3d]

Using a Stride Rendering surface is easier to implement but you will have performance lost because you need to copy textures. In of case of nesting, it will be worst because you need to copy texture for each top-level or windows

Using RenderTexture and Mix textures at final stage I think will better. Avalonia does render only when is necessary so we can economize resources.

Just to note, when in the mode of "Stride rendering to an Avalonia surface" - performance is of less concern, usually, and also the cost of copying textures is very cheap anyway (< 1 msec per frame, so at 60 FPS, < 6% of the total CPU of single thread).... So 6% cost is mostly negligible.

I agree if we can get Avalonia to render directly to a GPU Texture, that would be faster, but not mandatory (at least for now; optimization can be added later).

Key part of this add-on needs to have demo's that show all scenarios supported. The main ones being:

1. Avalonia App: Stride rendered to an Avalonia surface, in an Avalonia App.
2. Stride App: Avalonia rendered to a Stride Game window, as the in-game UI.
3. BOTH at same time - if possible. Avalonia App, rendering a Stride Surface, with an Avalonia UI inside it.

IMO, these 3 objectives, if all met, would make this add-on into a Homerun, and would attract considerable attention from many more people.

Initially, I think it might be easier if it's all done in a Code-Only environment (Stride Editor not required). Later, making it so that Stride Editor integrates into the environment more cleanly, will be a plus.

In short, your demos should remain "as is" with regard to not needing Stride Editor. You just load the .SLN, and run. And then tinker with the code to learn how it's done. Boom, user sold.

We could then add this project to the "Code-Only" samples now being worked on.

FYI, the next release of Avalonia is supposed to support Outlined Fonts, which is needed for Game UI's.

[najak3d]

So we can imagine two directions for Stridelonia.

• UI framework for Stride so Stride is hosting Avalonia just to allow easier UI Coding. (The actual state to Stridelonia)
• Use Stride as Renderer Platform for Avalonia. Which will allow Avalonia to gain functionalities Stridelonia will have additional UserControls to describe Stride Scenes We can summarize this as "Use Stride with Xaml"

For sure, the second direction is far more attractive because we will have all functionality of the first one and more advanced functionalities with Stride rendering inside Avalonia Window

Regarding "Use Stride with XAML"... Avalonia also now has a C# Composition method, which I am using solely ... avoiding almost all XAML. This C# uses the "Fluent Pattern" and the new add-on here:

https://github.com/AvaloniaUI/Avalonia.Markup.Declarative

For many "XAML" is a turn off. But the Fluent-Pattern C# markup is awesome, and far more easy to use and powerful.

So "Stride w/AvaloniaUI" might be the better name here. And IMO, most of our code examples can use the C# markup -- so it doesn't scare people away. The UI trend is away from XAML, and towards C# composition (Flutter/REACT).

[tebjan]

Doesn't Avalonia use Skia for rendering? If you use the ANGLE backend for Skia, as we do. you can render directly into stride textures with Skia/Avalonia. see: https://github.com/vvvv/VL.Stride/blob/preview/2021.4/packages/VL.Stride.Windows/src/SkiaRenderer.cs

This would make everything possible on the GPU, without copying to CPU, which would block rendering and has very bad performance.

[najak3d]

Doesn't Avalonia use Skia for rendering? If you use the ANGLE backend for Skia, as we do. you can render directly into stride textures with Skia/Avalonia. see: https://github.com/vvvv/VL.Stride/blob/preview/2021.4/packages/VL.Stride.Windows/src/SkiaRenderer.cs

This would make everything possible on the GPU, without copying to CPU, which would block rendering and has very bad performance.

I think you are correct, but not sure if there are any caveats (e.g. issues with shared GPU context).

But even if there is a worst case scenario where CPU-based copying is required -- for most scenarios this is negligible, and not a deal-breaker. Whatever gets us into the endzone fastest, for starters, should be good. The optimization (i.e. doing the handoff directly in the GPU) can be added later, if for some reason it's more difficult to add it upfront. That's my view on it.

[tebjan]

downloading GPU data, e.g. the stride render output to CPU is the problem, this will block or have a long delay. rendering on CPU and uploading to GPU is not a problem, most of the time...

[najak3d]

downloading GPU data, e.g. the stride render output to CPU is the problem, this will block or have a long delay. rendering on CPU and uploading to GPU is not a problem, most of the time...

I saw you in the Avalonia Gitter -- that's awesome. I think you are in a great position of knowing how to accomplish all this the best. I'm very glad to see you involved here. If we could assemble a demo similar to their UnrealEngine demo, Wow, that would be totally awesome.

Imagine Avalonia as the Game Modding Toolset, with Avalonia for the Game UI, as well as even In-Game 3D UI's. THAT would be an incredible accomplishment and demo.

I'm glad Stride3D is now connected to OpenCollective -- as it will likely translate the upcoming flood of new users/demands into higher revenue for the Stride devs, and an increased capacity for development.

[tebjan]

just for reference: https://github.com/vvvv/VL.StandardLibs/issues/115

[najak3d]

FYI, I'm back and have now begun the process of porting our game to Stride3D, with Avalonia, in a Code-Only approach.

@TheKeyblader - I'm very impressed with what you've accomplished here. I intend on making this work for our needs -- both as in-game UI as well as the Game Mod toolset, simultaneously (if Urho.NET can do it; so can Stride). I think you may have already done the majority of the heavy lifting required.