Hey all,

Does anyone know any techniques to manage multiple screens? The techniques I am seeing in the sdk samples and here on the forums seem to use user controls and <local:Class /> syntax but I think they are not yet supported. I want to animate these screens in and out of eachother with transitions and id like for them to be all separate xaml files. I have been doing them all in the single Page but it is getting messy. I feel like there should be some way to do this with the content presenter but I can't figure it out.

seem to use user controls and <local:Class /> syntax but I think they are not yet supported

UserControls are supported when using an integrated version of Studio, for example in the beta Unity/Unreal plugins. You can define UserControls with code-behind in the Unity/Unreal project and they will appear in the integrated Studio as any other control.

For C++ integrations we still have to publish the C++ SDK that will allow a similar workflow. This will come early next year.

I want to animate these screens in and out of eachother with transitions and id like for them to be all separate xaml files

Using the LoadContentAction you can assign any xaml to a ContentControl. Then you can use the Loaded event to launch a Storyboard that performs the transition in of your screen. And then use a StoryboardCompletedTrigger to detect when the Storyboard used for transition out of the screen is completed.

With all these pieces you can perform in-out transitions. But for a more advanced scenario you might want to implement your own transition control, which exposes a Content property, that when it is changed it transitions between the templates associated for the old and new content. We have plans to incorporate such class in Studio as an example in our Toolkit package.

Thank you for the information! I am with native sdk. I will try out your suggestion and write back my results

for my smallish game I was able to use the advice above to layer all my screens in my RootPage but still have them be their own xaml files. I then mirrored my VM structure similarly
And back in engine side i have a small state tree to manage moving between all my screens and popups, etc. This works well for now but I could see a more dynamic system build around this based on what viewmodels are in my "active screen" collection.

The difficulty I ran into is that it is sort of hard to do any kind of nesting of xaml pages in studios current state and it was a bit confusing. I cannot use components or user controls just yet, pages cannot embed into eachother through the UI ( must change the .xaml to add the content control bindings or its too obscure to find in the UI ). There is probably more about Templates in studio that I haven't learned that would be useful here. I'd really like to just be able to drag and drop things into the tree and not have to think about it so much.

I also didn't realize this at first, but your custom controls, UserControls and Components actually do show up in Noesis Studio and will work at design-time as long as Noesis has all the necessary "reflection" metadata. But if you go to the XAML file in the asset browser and try to drag and drop that into a container nothing will happen. Instead, you have to go to the [+] "Add Element" button and find/search for it in the list. I just confirmed it to double check and, yep, I was able to drag my whole "Views.MainMenuView" into another element and see it instantly appear and initialize itself in the designer window and work.



All those with the "Views." namespace/prefix are custom elements/controls ...

I also discovered that I can see my C++ view models at design time in Noesis Studio and confirm they're written properly and get rid of any human error or guesswork in how to bind things. I figured this out by experimenting and setting the data context in the canonical "InitializeComponent( )" method which was invoked by the constructor, although this is sort of a "bad practice" and Sergio might scold me for it, haha. The reason is that things aren't guaranteed to be fully initialized when the constructor is running and you'll get nasty "sometimes" bugs and exceptions this way. But I switched to a bit better way of doing things:

This is my temporary approach while in development so I can "browse" my view models in the designer and create bindings, confirm things work, etc ... It's "safer" doing it this way by capturing "Initialized" and then setting the data context, and the unpredictable exceptions at least went away. However, it's generally a better idea to have application/game logic control this ... I'm not sure if you're trying to build your own engine, integrate Noesis into a 3rd party engine or using Unreal or something else entirely, so it's hard for me to tell you if you're doing anything wrong in your code. Just remember the critical thing in C++ is the "reflection" metadata so Noesis can make sense of the custom components you define.

Noesis honestly isn't very easy to get started with, especially if you don't have a software engineering background and prior experience with C#/.NET and WPF to truly understand the spirit of its design. That's why the tutorials recommend studying WPF, the "theory" of MVVM architecture, etc before taking any personal or business risks. WPF (which Noesis emulates quite faithfully) is an insanely powerful framework for "enterprise" software ... there's nearly an infinite number of ways to implement an idea you have. Noesis is basically the same thing but a high-performance, low-latency version for 3D/real-time engines. However, these folks have made some huge strides toward making it easier and easier and empowering designers to do more on their own over the years and they go above and beyond to support their customers. So, is it worth it? Yes, absolutely ... the track record (the list of legendary titles built with it) honestly speaks for itself. I've been here (mostly quietly) for years, and was first attracted to it because there's really nothing else available to make the sort of 4X grand strategy and RPG games with "sophisticated" UIs that I love, except for Noesis (or investing years into building your own SDK).

So, Merry Christmas and stick with it ... it's worth it, dude!

Let me also comment on an alternative, pure MVVM approach to navigation and multi-screen UI.

- Define a distinct type for each screen (these can be design-time types created in Studio).
- Create a data template for each type. This can be stored in separate XAML file.
- Use a ContentControl to host and display the active screen.
- Implement a custom ContentControl that supports animated transitions when the content changes. This currently requires extending Studio (at the moment, this is supported only in Unreal and Unity). We are also working on an official control that will provide this functionality out of the box.

The source code for this approach is available in our Layered UI Sample.

UserControls and Components actually do show up in Noesis Studio

At the moment, this is only available in the Unity and Unreal beta builds with Studio integrated.

The C++ SDK with integrated Studio will be released very soon.

Thanks for your kind words, @arkaen!

I also didn't realize this at first, but your custom controls, UserControls and Components actually do show up in Noesis Studio and will work at design-time as long as Noesis has all the necessary "reflection" metadata. But if you go to the XAML file in the asset browser and try to drag and drop that into a container nothing will happen. Instead, you have to go to the [+] "Add Element" button and find/search for it in the list. I just confirmed it to double check and, yep, I was able to drag my whole "Views.MainMenuView" into another element and see it instantly appear and initialize itself in the designer window and work.



All those with the "Views." namespace/prefix are custom elements/controls ...

I also discovered that I can see my C++ view models at design time in Noesis Studio and confirm they're written properly and get rid of any human error or guesswork in how to bind things. I figured this out by experimenting and setting the data context in the canonical "InitializeComponent( )" method which was invoked by the constructor, although this is sort of a "bad practice" and Sergio might scold me for it, haha. The reason is that things aren't guaranteed to be fully initialized when the constructor is running and you'll get nasty "sometimes" bugs and exceptions this way. But I switched to a bit better way of doing things:

It's "safer" doing it this way by capturing "Initialized" and then setting the data context, and the unpredictable exceptions at least went away. However, it's generally a better idea to have application/game logic control this ... I'm not sure if you're trying to build your own engine, integrate Noesis into a 3rd party engine or using Unreal or something else entirely, so it's hard for me to tell you if you're doing anything wrong in your code. Just remember the critical thing in C++ is the "reflection" metadata so Noesis can make sense of the custom components you define.

Noesis honestly isn't very easy to get started with, especially if you don't have a software engineering background and prior experience with C#/.NET and WPF to truly understand the spirit of its design. That's why the tutorials recommend studying WPF, the "theory" of MVVM architecture, etc before taking any personal or business risks. WPF (which Noesis emulates quite faithfully) is an insanely powerful framework for "enterprise" software ... there's nearly an infinite number of ways to implement an idea you have. Noesis is basically the same thing but a high-performance, low-latency version for 3D/real-time engines. However, these folks have made some huge strides toward making it easier and easier and empowering designers to do more on their own over the years and they go above and beyond to support their customers. So, is it worth it? Yes, absolutely ... the track record (the list of legendary titles built with it) honestly speaks for itself. I've been here (mostly quietly) for years, and was first attracted to it because there's really nothing else available to make the sort of 4X grand strategy and RPG games with "sophisticated" UIs that I love, except for Noesis (or investing years into building your own SDK).

So, Merry Christmas and stick with it ... it's worth it, dude!

hey thanks for the info. I am unfortunately stuck in the native sdk as i have implemented this in my own engine ( well as an extension for an engine but this is complicated ). so a lot of the things like user controls i do not have access to yet. my background is engineering with many years in MVVM systems ( but not with xaml or wpf ) . I am now maybe 20 - 40 hours of in Noesis Studio with about 8 - 10 screens working and looking great in my game, and have a lot to say about it. Lots of things are really improved from other systems like Styles and Bindings and other things are incredibly difficult and limiting and there is no way a designer would be able to achieve them on their own, tho this is the case no matter what workflow you have and i am sure this will only be improved in Studio over time ( and once i can actually do code for it )

The only brick walls i am hitting these days are from not being able to do any advanced work like using User Controls or Components. There are a few ideas i am unable to build right now for instance a chat window that is anchored to the bottom of a virtualized collections scroll position unless scrolled.

Anyways I will look at all this info again when I have the new integrated studio SDK ( soon TM ). Merry christmas to you both and thanks to jsantos for their patience. Off topic but maybe there could be a Discord Server so more information and conversations could be had.

( PS I am surprised you are leaving UMG for Noesis, Slate / UMG ( tho not without its own quirks ) is the best game UI system / editor available IMO. Noesis only beats them by 1) actually be accessible outside unreal and 2) the data binding focus. For instance I miss the material graph 100% of the time and have no idea how i will do many of the effects I do in UMG in Noesis, and Noesis storyboards are way limited)

Let me also comment on an alternative, pure MVVM approach to navigation and multi-screen UI.

- Define a distinct type for each screen (these can be design-time types created in Studio).
- Create a data template for each type. This can be stored in separate XAML file.
- Use a ContentControl to host and display the active screen.
- Implement a custom ContentControl that supports animated transitions when the content changes. This currently requires extending Studio (at the moment, this is supported only in Unreal and Unity). We are also working on an official control that will provide this functionality out of the box.

The source code for this approach is available in our Layered UI Sample.

This is what i wanted to do at first but i couldnt work out the syntax in xaml or see how to do it in the UI. I will look at the sample linked and try again some time thank you. It sounds like I should be able to do everything except the last step now which there are plenty of workarounds for.

( PS I am surprised you are leaving UMG for Noesis, Slate / UMG ( tho not without its own quirks ) is the best game UI system / editor available IMO. Noesis only beats them by 1) actually be accessible outside unreal and 2) the data binding focus. For instance I miss the material graph 100% of the time and have no idea how i will do many of the effects I do in UMG in Noesis, and Noesis storyboards are way limited)

You might be surprised by how many studios (especially AAA teams) are migrating to Noesis. I’d suggest taking a look at the Games Released section to get a broader sense of its adoption in production.

Regarding the material graph: while Noesis doesn’t include a built-in equivalent to UMG’s material editor, similar results can be achieved via HLSL, or through a custom integration that exposes a shader-graph–like workflow. Noesis also follows a different design philosophy than UMG, XAML emphasizes structure and data binding, often reducing the need for material-driven effects.

Transitioning from UMG to XAML can take some time. If there are specific effects or workflows you’re finding difficult to replicate, opening a dedicated thread with concrete examples would be the best way to discuss solutions.

Finally, comments like “storyboards are very limited” are hard to act on without specifics. In the past, similar concerns turned out to be caused by issues in the integration code rather than limitations of Noesis itself. More detailed feedback would help keep the discussion constructive.

Thanks for sharing your thoughts.

Off topic but maybe there could be a Discord Server so more information and conversations could be had.

I have a Discord, and you're welcome to join. I grew up wandering the lonely road of building engines, and there's far too few people who still do it. :-)

---
Edit:
https://discord.gg/YnNK3jfWdX