RFC: Texture range selector design
September 20, 2009
Here’s your chance to help KDE: I need some quick opinions on the design of a widget, for which I’ve made a mockup.
Basic situation: Kolf needs a new configuration interface for its texture blender. The task of this texture blender is to create a texture for a given heightmap. It uses several base textures and inserts these base textures into the result at different height ranges. For example, low heights might be painted with a water texture, medium heights with a grass texture, and high heights with some stone texture. That’s what the interface looks like currently:
On the left side is a list of all base textures. Each base texture has three values (out of a range from 0 to 255, where 0 is the lowest height level, and 255 is the highest one). The left and right value are the minimum and maximum height where this base texture is used. The middle value is the height where the base texture is inserted in the texture in a completely unaltered manner. (I call this “median height” from now on. Above and below this height, the texture is darkened and lightened to create a depth impression.) Everyone here should agree that this configuration interface is completely obscure (would you have guessed that you have to click on the textures to edit these heights?) and much too techy.
Gladly, one of our artists has proposed a new interface, and I have made a simple mockup (only for the left side, the texture preview at the right which will stay there):
This design is based on a layered “stack” of base textures (at the left). The higher a base texture is in this stack, the higher are the heights at which this base texture is used. One can drag the textures along the vertical axis to re-order them. The right side is the actual height range selection. The first, third and fifth marker stand for the aforementioned median heights, while the second and fourth marker denote the area where one texture is gradually replaced by the next one.
One special note: The textures on the left axis are not on the same height as the median markers on the right axis. This is intentional because this restriction might cause texture images on the left axis to overlap, which is something which I want to avoid.
Here is my RFC: What do you like and dislike this mockup? Do you have further ideas on how I can improve this interface? How should user interaction be implemented? I have some basic ideas for the last point, but am eager to hear your ideas and do not want to bias you. Apart from the obvious mouse interaction (i.e., dragging the base textures to reorder them, and dragging the markers to change the height ranges), the user needs to be able to add new base textures, and delete base textures from the stack. Also, keyboard control might be good for accessibility and convenience.


September 21, 2009 at 05:24
Hi,
i think it would be an nice idea to use an Slider with three handels for that problem.
September 21, 2009 at 08:22
You mean something like the QRangeSelector which I presented here last week? I originally created this widget for exactly this purpose, but the new mockup is conceptually better in my opinion: It does not allow for height ranges without any base texture, and has fewer values to adjust.
September 21, 2009 at 14:18
You can extend the idea of your last post and do the QRangeSelector with 3 range Items.
Then draw lines to the left side from each of the range values then add a texture in grayscale by using a KPushButton as basetype and add the image of the combined 2 values (grayscale texture + colorrange on the right).
Then you can click the KPushButton to open a new GrayScale texture that is layerd upon the button.
You could add another “row” on the right that would mark the 2/3/4 range colors the QRange colors would range.