Forums | NoesisGUI

Good evening!

I use the native C++ sdk as part of my custom engine and so far I have implemented and used a single noesis View for screenspace UI.
Now I'm at a point where I need a solution for drawing many (50+) smaller Worldspace UI elements (think healthbars/nameplates) and wanted to get some input on best practices for implementing that.

So far I have two approaches in my head:
1. Transform the Elements into Screenspace based on the position and camera properties and render it on a canvas as part of my existing screenspace View.
2. Or create a separate View for each element and render those individually

Before I go and implement one of the two, is there an approach you would recommend? Maybe there is something other than the two mentioned?
How heavy (performance wise) would it be to have 50 views updated and rendered each frame? Is it something to avoid?

Any input from your experience would be greatly appreciated!

Thanks!

Separate Views are efficient (even with a large number of views), but there are a few associated challenges you’ll need to handle:

• Each view has its own input state, so you’ll need some form of focus/state manager.
• To avoid multiple GPU textures, you’ll likely want to use an atlas and render all views into the same render target. You’ll also need some kind of pooling mechanism.

The alternative is rendering the elements directly in 3D (World-Space UI). This approach is generally better, but it’s harder to integrate, you need to keep the 3D camera in sync with the projection used by the view.

There is an outdated sample in the C++ SDK (OculusVR), as well as one sample in Unity and Unreal (WorldSpaceUI) that demonstrates this approach. I recommend taking a look at them.

Hmm thanks for the input both of those sound doable for me.

I don't need those extra views to be intractable, so input management is not a concern.
Just to understand we are speaking about the same thing here: The ideal approach for rendering many views would be to render all views into the same rendertarget which I then use as a texture atlas and index into to texture a quad for each view and render the UI that way?

The other approach of using 3d Transforms sounds way simpler I think and I will try that first because of that? Or am I missing something here apart from keeping the matrices in sync which seems not too bad?

Thanks for the great input as always, this helps a lot!

I don't need those extra views to be intractable, so input management is not a concern.
Just to understand we are speaking about the same thing here: The ideal approach for rendering many views would be to render all views into the same rendertarget which I then use as a texture atlas and index into to texture a quad for each view and render the UI that way?

Yeah, if you are going to have a lot of Views, having a separate RenderTarget for each one is probably not a good idea. Using an atlas of views is an optimization I know a few clients are using, but you probably don't need that level of complexity for your first implementation

The other approach of using 3d Transforms sounds way simpler I think and I will try that first because of that? Or am I missing something here apart from keeping the matrices in sync which seems not too bad?

It is simpler, but the catch is that you need to manually sort the elements based on distance to the camera. Even with 3D transforms, Noesis renders elements in XAML order (Painter's Algorithm), not by depth. This means you will need to dynamically adjust the Panel.ZIndex or reorder the collection to ensure closer elements render on top of further ones.

In Unity we are doing something like this:
I hope this helps.

Sorry for the late reply, somehow overlooked it. Thanks for the extra context. This is all I needed.