Textures and skinning.

[ocornut]

Textures and skinning.

[enquel]

Hi @ocornut

I love Dear ImGUI, I love the entire paradigm, it makes visual apps feel truly dynamic again, and I think the skinning functionality would help popularize it further, to the mainstream. There is a huge demand for that.

I was thinking on the most painless way to expose skinning to the devs, and I don't think multiple UVs would do the job. Everything would get messy, convoluted, form-like.

My view? There should be a system that is position independent, relying on the widget functionality. I thought the best way would be to expose interface for the users to develop their own customizations of rendering -> so we have the default "raw" UI, and let's say some pixel meta class that holds info on the pixel's ownership, relative position (am I inside button/on the edge of button/on the corner, etc.). The user would then be able to run a "second pass", let's call it ornamentation pass, over the bare UI.

The question remains whether the most atomic unit would be a pixel, or a position inside a rectangle being a "body" of a widget.

Now, I don't know how performant that would be, and what the Dear ImGUI internals are, but this is a quick idea I got on the versatile system for skinning.

What do you think?

[ocornut]

Simon,

I had some thought about the feature. My intuition is that if you go down the route of trying to skin the interface it will end up being more complicated than just passing a set of UV coordinates.

• we have variety of widgets.
• as you point out a scaling box may require 9 pairs of UV coordinates + data for how to handle the central one (repeating).
• many of them have hovering and clicked/held state. is color tinting enough or do we want to use different textures?
• where do you draw the line on making the UI look nicer? once you get to that point you may want to incorporate transitions. And animations aren't the strongest point of an ImGui architecture.
• supporting the feature may get in the way of future UI development. can I change the size or behaviour of existing widgets without causing breakage on codebases that uses highly customised widgets and non-standard data? will change or addition of new widgets make people perceive an update version as partly broken?

So while it is perfectly possible, at the moment I don't think it is in the best interest of the library to pursue this route. If you still want to give it a try in a fork I'm curious to hear about where you get it to, and I can provide some assistance. I'm not sure how a meaningful relooking can be performed with just a simple set of UV coordinates.

As a side thought. I think one of the value of ImGui is also to enable quick iterations and empower individual programmers who aren't usually excited by creating UI. Based on this idea my belief is that making the interface look too good may get in the way of supporting this goal. I want to allow people to add misaligned buttons and not feel bad about it. Similarly I decided against using icons because once you start expecting icons the lack of them becomes a blocker or suddently your interface feels odd and unfinished. But that is one way we use ImGui here and I'm sure there's other ways (we also write elaborate and sturdy tools but there are still pretty much all in "developer land").

O.

PS: As you know it (based on your code) but some people may not, ImGui is already skinnable to some degree, that is, we can reconfigure colors and various sizes. I will try to provide screenshots of skinned versions to convey this information to newcomer. Additionally feel free to post screenshots of your tools if you have anything interesting to show!

[ocornut]

FYI I realise this is and will be an often requested feature so I am guessing it might go that route eventually. I just haven't groked all the implications of it yet and being a bit cautious.

[simongeilfus]

Hi Omar,
Thanks for your detailed answers.
I totally agree with what you're saying and I can only say that the goals you have for the library make a lot of sense. I constantly loose a lot of time trying to make things looks great even when I know that I'm probably going to be the only person to look. I guess this is a common workflow issue for programmers, and trying to solve that by limiting the amount of visual features makes sense.

On the other hand right after posting my first message, I quickly went to implement some very small additions just to assess what I was saying above.

You can find those small modifications on my fork here: https://github.com/simongeilfus/imgui/tree/skinning
There is a small piece of code and the necessary font and atlas in the "tests" folder.

Nothing fancy, just 2 uv's to grab the corner of a quad I added in the texture atlas. The colouring is made by your code and there's no scaling box or anything else. It's not even a proof of concept more a way for me to understand a bit better your rendering model.

• we have variety of widgets.

True. But if I'm not wrong at the moment, most of them seem to be rectangle based and the circle based widgets should be easier to texture.

• as you point out a scaling box may require 9 pairs of UV coordinates + data for how to handle the central one (repeating).

Maybe a really simple system could be enough to start and should work for both rectangles and circles. Here's an idea from the top of my head. Instead of storing the 8 texture coordinates (the dots in my drawing below), we could store only the opposite corners (red dots) and one extra float value for the distance to the inner corners (yellow dots). I guess most skin are probably going to be symmetrical and the center (between the doted lines) can probably be stretched in most cases.

That way we have only 4 Vec2 and 1 float to describe the texture mapping, we keep the 6 vertices that makes each quad and do the rest in the fragment shader (still have to think about a solution for this).

• many of them have hovering and clicked/held state. is color tinting enough or do we want to use different textures?

True! Having to deal with different states would complicate everything.

• where do you draw the line on making the UI look nicer? once you get to that point you may want to incorporate transitions. And animations aren't the strongest point of an ImGui architecture.
• supporting the feature may get in the way of future UI development. can I change the size or behaviour of existing widgets without causing breakage on codebases that uses highly customised widgets and non-standard data? will change or addition of new widgets make people perceive an update version as partly broken?

Indeed, that's always hard to define and I'm totally for not adding too much to the actual api. I actually love the fact that you don't have to size anything and that the layout options are very straightforward.

To be honest, the more I think about it, the more I think you're right in your first answer... I'll try to have a look at this a bit more this weekend and will let you know if I find anything interesting.

Thanks anyway for taking the time to think about it.

[r-lyeh-archived]

this is something i'd like to see as well

[ocornut]

I'm closing this for now. Feel free to reopen later if you feel it's something you want to work on, but right now this would definitively be very low in the priority list.

However I'm happy to hear about skinning improvements, such as improving the Style system (I was thinking of using something with less parameters and relying on variance in HSV space, so e.g. button can be defined by their hue and the "hovered"/"active" colors are variants in HSV space).
Not against supporting some form of gradient and anti-aliased shapes will come at some point.

[xetrics]

Maybe add tinting at the very least for the time being?

[ocornut]

Maybe add tinting at the very least for the time being?

You can already change the color of every element using PushStyleCol()

[SetLinux]

how is it going with this , any new news ?