RMGUI; High Performance, Code Based GUI

Work goes on;

Not very exciting stuff, but I've been putting a lot of time over the past couple of weeks into making everything as seamless as possible on the usability side. I've also built a generator for some hotpaths. One of these was the StackPanel- I moved the parameterised StackPanel system which dealt with direction, horizontal, and vertical alignment, into constant generated paths (36, to be precise- 4 directions, with 9 alignment combinations for each).

Shown here are all 36 possible paths. I made a simple setup to create a set of child entities in each group, and increased their "main" size (width for horizontal groups, height for vertical) along the group. In other words, what you see below are just simple side-by-side layouts of rectangles. This is just a test case to ensure that everything runs as intended, and I'm happy that the core layouts (including Tables, Grids, Radials, Anchors, etc.) are now very robust, giving you complete control over the precise placement of entities, without being verbose or confusing.

At 8 children per group;

​

And at 64;

​

That's about all that's good for screenshots, unfortunately- the rest is purely backend. I've been expanding the math utilities, improving the raycasting system, and changing how some critical systems sit in memory, to name a few. Just a little note from me that things are continuing.​

 

Hardened up the sprite slicing system today.

Sprite slicing is a deceptively difficult thing to do, because with very thin slice borders, if you aren't pixel-aligned, the "first" pixel of the border which actually ends up being rasterised can end up at position +/- 1 from the target. Because of UV interpolation on the GPU, this can result in a *lot* of jitter- for example, if you have a 1 pixel slice, and a transparent pixel next to it, the UV jitter can mean that the border will be invisble at certain scales.

I countered this by mixing several different rulesets which govern the slice generation. This ensures that pixels at the outer border are assigned the most important, so that, whatever the scale of the slice, the pixels at the edge of the sprite will always be rendered.

​

This scales down to a tiny fraction of it's original size, while maintaining clear borders;​

​

And not to bad-mouth UGUI, or anything, but I decided to test this against Unity's slice system, and it actually ended up demonstrating the issue perfectly;

All I've done above is place a UGUI Image, and resize the screen. As you can see, the thin borders result in very stange UV behaviour when those cases aren't handled properly.​

 

Hello,

I ws wondering if you have any ETA for a first public build ? Im really looking for a high performance UI solution and RMGUI really seems to be one.

Thx.

 

Hi,

Sorry for the slow response, I've been out of office for a few days. I hate to keep delaying it, but I still can't give an exact date, but it's almost there. I'm finalising the font system for the last time, to support dynamic MSDF fonts (i.e. CJK font support, atlases with thousands of characters and so on), which is turning out to be a massive headache, but I've arrived at a final design for the system. Once this is done I will be doing final polish and releasing, then updating and adding new features from there.

 

Looking to drop my current UI solution, been waiting a while for this one but the wait seems endless

 

Apologies to everyone waiting, as glad as I always am to have people following my work. Honestly I always take this long for releases, and this thread has been more of a devblog, so in hindsight it may have been a good idea to have announced it much later.

All the same, just to be clear where things currently are;

Overall, I'm sitting at about 160k lines of code (most of which you won't see through the API). RMGUI is a set of modules;

• Internal BCL, which is a .NET Standard 2.0 library of base Types. This includes the unmanaged memory systems which RMGUI is built on, which deal with allocation, fragmentation, garbage collection, and so on, and then packages all of the math utilities such as vectors, quaternions, matrices, and general low-level math functions. It also deals with GC-free strings, includes a fully unmanaged Unicode database with all 143k+ codepoints, and hundreds of languages which can be used for case conversion, automatic handling of text direction, and font generation. This library knows nothing about Unity or RMGUI.
• RMGUI Core, which sits on top of the BCL. Likewise, this knows nothing about Unity, and works with abstract representations of cameras and textures. This implements the API itself, turns library calls into UI trees, deals with styling and animation, and builds meshes.
• Rendering Backend, which is an agnostic C++ plugin which handles the native meshes built by the Core, binds materials, textures and shaders, and actually draws everything through a native graphics API.
  
• RMGUI Unity Bridge, which sits on top of the Core, and implements the abstractions in a way which can be used by Unity. On top of implementing textures, this includes things such as editor windows for tooling, generator links to have RMGUI run code generation when you edit your shaders, and lifecycle things such as dispatching tick calls to RMGUI in the player loop.

Just in case that sounds messy for users, bear in mind you won't see any of this- it's all neatly packaged so you only see the API level.

It really is mostly done at this point, but I'm still on text rendering, something which has been a pain since day 0. It's been redone many times over, going from Unity's font atlases to the renderer implemented by the OS, but it's all had issues in one way or another.

I haven't really posted any info on this yet, but for what will be the final system, it's based on an internal binary font type which is created by parsing TTF/OTF and pulling various tables and glyphs, and converting them to a high-performance memory-mapped format, where the glyphs will be rendered into a shared runtime atlas after RMGUI has started up. This will allow for full unicode support without worrying about atlas sizes, and batching strings with different fonts in the same drawcall.

Small glyphs are rendered as crisp bitmaps (with optional subpixel rendering), while large glyphs are rendered as scaled-up bitmaps for "8-bit" fonts, or scalable MSDFs for smooth fonts. SDFs are also generated for smooth effects, such as text glow. Another benefit is that this doesn't use any external systems whatsoever, so the results will be entirely consistent regardless of platform or architecture.

Once this is in, I'll be rebuilding the existing text engine on the new format, and then reimplementing text-based controls (i.e. text fields, areas, secure inputs for passwords, etc.), and that will wrap the core. I'll need to do final polish and testing after that.

As ever, it will unfortunately take as long as it takes, but I'm mindful that it's dragging on. Again, I really do apologise to anyone waiting, thank you for your interest, and hope to get this out there as soon as I possibly can.

 

Better late than never, it's almost certainly going to be worth the wait.

 

I just wanted to give my thoughts on support for XML/any text source. You mentioned earlier that you were thinking of doing a node based editor that generates code. That'll probably be an adequate solution for many cases. But, from my experience, being able to describe the data model, and have that drive the generation of the UI, would be very useful when making tools and in-game editors, where using a standardisable UI is sufficient.

For instance when adding support for modding, you could have an in-game asset editor where you could change all of the properties of the asset. Being able to describe the asset in a text format, and have the UI library create the UI, would save the developer a lot of time. As the developer, you could change the model, and update the code to respond to the player's input. No need to fiddle with rearranging UI elements.

 

Apologies for the slow reply, been a bit hectic lately.

I'm going to come back to this in the future but it's absolutely on the roadmap- I just don't know what form it's going to take yet (possibly even a dedicated standalone editor)- so I'll make sure that everyone's thoughts on this are taken into account when work starts on it. However it's done, one thing I'm sure of is that any input format will generate code so that designers can have their work output partials, and devs can easily extend them with hardcoded references for generated elements already wired up (particularly handy for data binding, for example).

Just a note from me to anyone reading, since I've been quiet for so long- I'm still alive, everything is carrying on as usual, and a hell of a lot of stuff has been massively improved since the last lot of updates. The old codegen has been gutted, and rebuilt with IL weaving (for many reasons), which I'm going to post about in a bit. I've said it for a while, but I'm also going to get some YouTube intros together before too long to start demoing everything.

Cheers,
-Josh

 

Haven't had any news for a while, hope you're alright first and foremost (especially with the world the way it is at the moment).

How's work progressing? Are we any closer to some demos / private testing?

 

Looks like this one is dead... Sad.