If the result of the blue nodes is 0.5, grass is chosen. Each of those have a weight from 0-1 then can be adjusted with sliders.Į.g. for splat textures it could contain dirt/grass/rock texture. Then the result of the blue (select) nodes will pick the item from the Select Item Group. (1 + 3 + 2 = 6)Blue * (1 + 3 - 2 = 2)Yellowįor the other outputs (splat/color/tree/grass/objects) a layer has another group, that I call the Select Item Group. In the TC2 mockup, the blue nodes generate output for the heightmap and it will be multiplied with the result of the yellow node group, which is the mask: Excellent work by you and Peter.Ĭlick to expand.A heightmap layer consists out of 2 node groups. Overall, this is IMO a stellar UI design. For final outputs, border those with a solid line, again in a generated contrasting color? (Or just use pure white for those borders, as long as there won't be any white nodes?) Since in a realistic graph, most of the nodes will be intermediate results at some level or another, perhaps let that be the default, and maybe for raw inputs (such as "Perlin noise" or "external bitmap") border those with a dashed line in a color that contrasts whatever the main color is for that node. For color choice, I think you've made a good decision to use color to indicate groups, but I still think some indication of "raw input" nodes and "final output" nodes would be useful. The layout and flow are now completely clear to me. This addresses 100% of my feedback about layout, and 90% of my feedback about color choices. The algebraic notation is perfect! Ironically, I almost suggested something like that, but then refrained because I was afraid I was asking for something that was not feasible at this stage of coding. I posted my other comments about blue and amber nodes before seeing the new mockup. This is just intended as raw "user experience" data for you I am not asking for any specific changes to the UI.Ĭlick to expand.Absolutely magnificent. I'm not trying to go down a proverbial rabbit hole, but I'm hoping that sharing the internal thought processes provides useful input from a "typical user" perspective. Conceptually, I find amber1 and amber2 have more in common with blue than they do with amber3.Īgain, thinking out loud, I wonder if you intended colors to represent layer groups or to represent node types? Maybe I have misinterpreted the whole notion of how color should be understood? If I try to analyze my mental process, I think what threw me off was amber3 being an intermediate result while amber1 and amber2 were raw inputs. ![]() Once I figured that part out, it became clearly readable to me, but it was decipherable rather than intuitive. It was not at first obvious to me that what's happening here is "amber3 = amber1 * amber2 amber4 = blue * amber3" - in other words, it's not immediately obvious where "blue" fits into the equation to its right. For example, in the second line from the bottom you have "blue ( amber1 amber2 ) ( amber3 amber4 )". It took some mental reorientation to figure out where the blue nodes at left were fitting into things. Looking at your UI overall, I think it's brilliantly designed. (I realize grey is already in use, so you'd have to replace its existing use with another color.) ![]() Or, perhaps even better would be to use grey borders for visualization nodes of partial results and full-white border for visualization nodes that are final outputs. I don't know how international the convention of "green = good" is, but to me having the visualization node bordered in green makes good sense. Click to expand.Agreed, the visualization is really helpful.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |