Exploring possible UI toolkits for the editor


(Richard Dodd (Dodj)) #22

I think dogfooding is a very good idea.

So there are a few parts to the problem

  1. Converting from a declarative description of a UI to 2D primitives.
  2. Converting those primitives to draw calls
  3. Rendering the draw calls to a texture
  4. Blit the texture into the final image (with 3D transformations if you so desire.

Using this approach encourages the use of vector graphics for UI, meaning that scaling works beautifully, and text is nicely relaid etc. There is an alternative - just use bitmaps and fixed widths, but this suffers from inflexibility.

1 is all the layout stuff above, 2 is lyon, 3 is a draw pass (or pipeline or stage, I need to understand rendering terminology better), and 4 is part of the final stage of compositing the final image.

In terms of a new crate, you could possibly try to abstract out the layout logic, although I think to start with I’d just like to build it into amethyst to keep things simple. It just instinctively feels like you’d need as much glue code in amethyst as you would need actual layout code if it was built in.

Or were you thinking of a crate in a different area?


(Joël Lupien) #23

@dodj

Please read those two links, and let me know what you think. Feel free to reply as a direct comment on them.

  1. https://github.com/amethyst/amethyst/issues/1072
  2. https://github.com/amethyst/rfcs/pull/5

The discussion about how to implement the UI is out of scope of this thread however. This thread is to decide what will be used for the editor (built-in amethyst ui vs orbtk vs azul vs electron, etc).

Also, feel free to join the amethyst discord and hop in the ui channel. We are looking for people to help code the planned ui changes. :slight_smile:

Thanks!


(Fletcher) #24

I am strongly in favor of SVG having first-class support. Every digital/tech artist I know has that on their wishlist, because who doesn’t like making 25 different icons of varying resolutions…

I was more asking, can we build on an existing UI crate, such as OrbTK or Azul, that are also “complete” UI crates in that they do everything needed.


(Richard Dodd (Dodj)) #25

There are a lot of use cases and a lot of them are really complex. It would be easy to do like any other engine and just provide the basic elements, and let the game devs do their own custom elements. If you think about it however, if we are not able to provide those while we are the ones creating the engine, do you honestly expect game developers to be able to make them from the outside?

Also, if we can implement those using reusable components and systems, and make all of that data oriented, I think we will be able to cover 99.9% of all the use cases of the ui.

If we aim to provide a nicely stylable UI framework, I think it should be able to draw the UI for the editor, therefore I think dogfooding is a very good idea.


(Hilmar Wiegand) #26

@dodj Damn dude, that’s a very extensive and well thought out writeup! Thanks a lot for putting so much thought into it.

I have to say, in principle I’m a big fan of the idea (of using the engine to make the editor). This would enable (and force) us to implement proper layouting and styling for all of our components, and it would save us from doing the work twice. And like you said, there’s lots of great resources that would enable us to create something from scratch here.

Right now, there would be a few blockers making starting right now a little unpractical:

  • The UI side of things is currently undergoing a rewrite. In general, we could benefit by having more use cases right in front of us (which would show us the direction we want to go in while refactoring), but in practice, at least the drawing pass refactor would need to happen before it would make sense to try and integrate SVG/path drawing.
  • Text drawing is currently not implemented as we want it. It would make sense to have a separate text renderer for UI Elements though, as you’re mostly not changing the text size that much.
  • We’re currently using rayon for parallelizing our systems (or at least, specs is using it under the hood, which is our ECS implementation). There’s a bug that will cause the threads to spin while idle, making the CPU consumption very high. This would need to be resolved before we can consider an editor based on the engine ready for use.

However, I’m still very much in favour of at least trying it!


(Khionu Sybiern) #27

Fyi, I am currently writing an Amethyst Bundle for Nuklear. I don’t have any formal design notes, but I’m planning for it to be something like this:

  • Builder API to create a given GUI Context
  • Store elements as entities
  • Bundle systems for implementing core GUI management
  • Expose high-level events
  • Encourage creating GUIs in advance and toggle whether they’re active

#28

Hey there!

I am currently looking for a node-graph based editor in Rust. I thought it might be possible with the OpenGL canvas and render the UI directly but you managed to do it using the Azul components.
Do you have any shareable code that you wrote for the node-graph editor?