New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Textures and skinning. #17

Closed
simongeilfus opened this Issue Aug 15, 2014 · 7 comments

Comments

4 participants
@simongeilfus

simongeilfus commented Aug 15, 2014

Hi Omar,

This is not really an issue, but more a suggestion about the library. I wanted to open the discussion with you before trying to implement something and send a PR. Let me know what you think!

I noticed the handy system to change colors per call using the PushStyleColor/PopStyleColor. That made me think about adding a PushTexCoords/PopTexCoords. If I'm correct every draw call that is not a text have texcoords that point to the upper-left corner of the font texture atlas, where a white pixel allow everything to get coloured correctly. Adding the pushpop methods I'm suggesting would allow to bypass this system and specify the texture coordinate of a custom skin. Allowing the library to render widgets with a much more customisable and complete style. At the same time it will continue to leverage the texture atlas and have only one texture binding for the whole batch of draw calls. The PushTexCoord would allow to specify the position of the skin in the atlas, and the PopTexCoord will at some point come back to the default notexture (0,0).

To be able to properly texture the different rectangles, I guess that it means that we will have to double the number of vertices per rectangles (to properly scale the texture at the corners). This can probably be done in the fragment shader without changing the number of vertices.

Except for this last bit, I think it would be a relatively easy and awesome feature to add to the library. Skinning is never totally required for a gui library but when well designed, it definitely push it to the next level.

So that was my random thoughts about your already really nice library!

Cheers,
Simon.

@ocornut

This comment has been minimized.

Show comment
Hide comment
@ocornut

ocornut Aug 15, 2014

Owner

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!

Owner

ocornut commented Aug 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ocornut

ocornut Aug 15, 2014

Owner

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.

Owner

ocornut commented Aug 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@simongeilfus

simongeilfus Aug 15, 2014

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.

screen shot 2014-08-15 at 23 41 50

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.

texcoords

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.

simongeilfus commented Aug 15, 2014

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.

screen shot 2014-08-15 at 23 41 50

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.

texcoords

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 comment has been minimized.

Show comment
Hide comment
@r-lyeh-archived

r-lyeh-archived Aug 16, 2014

this is something i'd like to see as well

r-lyeh-archived commented Aug 16, 2014

this is something i'd like to see as well

@ocornut ocornut referenced this issue Nov 10, 2014

Closed

Images #73

@ocornut

This comment has been minimized.

Show comment
Hide comment
@ocornut

ocornut Mar 5, 2015

Owner

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.

Owner

ocornut commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@xetrics

xetrics Oct 16, 2016

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

xetrics commented Oct 16, 2016

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

@ocornut

This comment has been minimized.

Show comment
Hide comment
@ocornut

ocornut Oct 17, 2016

Owner

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

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

Owner

ocornut commented Oct 17, 2016

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment