Surface Dialog

[greebo]

I started creating the new surface dialog which should combine the functionality of the old Surface Inspector and Patch Inspector dialogs. This is the first draft (left) in comparison to the current one (right):

 

 

What's not yet there is the patch vertex editing stuff (fixed tesselation and such). I'm not quite sure where to put it yet, but I plan to expand the dialog window downwards (perhaps with in a "dropdown" manner like "Advanced Patch Editing >>").

 

Thoughts, comments?

[OrbWeaver]

I don't see any problems there, a couple of possible improvements though:

 

* Use Up/Down arrows for the vertical scale/shift operations rather than Left/Right

* Align widgets using the 6/12 rule from the HIG -- 6 pixel separation for related components (like up/down buttons), 12 pixels for non-related components (i.e the gaps between each line of controls).

* I wonder if we can replace the "Brushes" and "Patches" button with single buttons that behave appropriately whether a brush or patch is selected. For example, perhaps "Axial" and "Natural" could be single control for both brushes and patches. Do we even know what "Cycle CAP" does? I have never figured out its purpose.

* I would be tempted to say don't merge the patch vertex editing stuff in here, because this is currently a purely texture-based dialog, and adding in extra stuff that is not always applicable could confuse the issue. There is nothing wrong with having a separate patch editing dialog, the current problem is that it duplicates texture alignment functionality that should only exist in this dialog.

 

Some more advanced/labour intensive ideas:

 

* Use icons to illustrate each operation, such as a "Flip horizontal" icon on the appropriate button. This adds some colour to the dialog and helps you find the operation you need quickly.

* Lay out the scale and shift operations in a North/South/East/West block with the scale factor in the middle (with nice big arrows on them). This would make it very easy to find the right button to move the texture in the direction you want.

* Use a slider for angle, that runs between -180 and +180 (or 0 and 360, whichever is more appropriate). Dragging this slider would immediately rotate the texture and provide very quick and easy control over rotations.

* As well as the NSEW shift arrows, provide a slider which runs from 0.0 to 1.0 and allows precise and real-time control over the UV offset. This would obviously have to be updated when the world-space shift buttons were clicked in order to keep it in sync.

[greebo]

* Use Up/Down arrows for the vertical scale/shift operations rather than Left/Right

Ok, I'll put that in, although I fear that may add some confusion, but I'll try it out and we'll see.

 

* Align widgets using the 6/12 rule from the HIG -- 6 pixel separation for related components (like up/down buttons), 12 pixels for non-related components (i.e the gaps between each line of controls).

I tried to keep as close as possible to this sample dialog from the HIG: http://developer.gnome.org/projects/gup/hi...ges/layout2.png

Although this dialog doesn't follow the 6/12 rule either, because it has 5 pixels as distance between the entry fields and far more than 12 pixels for the left indentation.

 

Additionally it's not always perfectly possible to keep that 12 pixel gap between the label and the according entry field, because if anything widenes the dialog window, the alignment gets screwed up. GTK can be a real pain to do correctly what one intends, this reminds me a bit of cross-browser css, but I'll try to do my best.

 

* I wonder if we can replace the "Brushes" and "Patches" button with single buttons that behave appropriately whether a brush or patch is selected. For example, perhaps "Axial" and "Natural" could be single control for both brushes and patches. Do we even know what "Cycle CAP" does? I have never figured out its purpose.

"Natural" is possible to affect both brushes and patches (it would just apply the default scale to the brush, nothing more).

 

"Axial" is not yet done for patches, but I could add that functionality. I planned to desensitise that button when a patch is selected.

 

I think "Cycle CAP" is intended for texturing the end caps and works similar to "Axial", but I have to check the code. Maybe we could remove that one completely in favor of the mouse copy/paste tools.

 

* I would be tempted to say don't merge the patch vertex editing stuff in here, because this is currently a purely texture-based dialog, and adding in extra stuff that is not always applicable could confuse the issue. There is nothing wrong with having a separate patch editing dialog, the current problem is that it duplicates texture alignment functionality that should only exist in this dialog.

That makes sense, so I'll go that way and strip the patch inspector from the texturing controls.

[SneaksieDave]

That looks really nice. And vertical, woot!

 

Only thing I'm wondering, where is 'Match Grid'? (actually I'm not even sure what it does). That's great including texture lock and flip tools.

 

I still think I'd want the 'Tesselation' and 'Details' frame contents though... I've actually made use of the 'Details' to correct some texture distortion. And 'Tesselation' by itself seems so minimal that it might not justify a full dialog.

[greebo]

Match Grid aligns the step sizes to the grid size, but I'm pretty sure that's mostly useless.

[SneaksieDave]

Here's one: It would be useful if the S and T fields (whether they wind up on the texture dialog or a separate one) have up/down arrows as well. It's a pain typing 0.03586798 into that box and then adjusting it by hand till you get it just right.

[greebo]

Agreed, please put that one to the Bugtracker.

[greebo]

I just checked the code for CAP Texture and I think it should be the patch equivalent of Axial. But it doesn't work, and I think the command can be ditched along with the weird code. It seems to be trying to calculate a normal out of the control vertices and this normal is checked for its axis dominance (which component of the vector has the largest absolute value). A projection is then performed on to that axis, but this doesn't seem to be functional.

 

Given the fact that we already have better tools to texture such (inverted) endcaps, I vote for removing that thing.

[greebo]

This is the next iteration of the dialog:

 

 

I haven't got to putting in the vertical arrows yet, as I'm still unsure of how to pack them most effectively without stretching them to much in the horizontal direction. It would be nice if the up/down controls would align nicely with the left/right ones. Any ideas of how to pack that, OrbWeaver?

[OrbWeaver]

I haven't got to putting in the vertical arrows yet, as I'm still unsure of how to pack them most effectively without stretching them to much in the horizontal direction. It would be nice if the up/down controls would align nicely with the left/right ones. Any ideas of how to pack that, OrbWeaver?

 

I'm not sure I understand your question. I don't think images are stretched normally, instead the button should shrink to fit. If your "up arrow" and "down arrow" images are the same dimensions as the left/right arrows, the buttons should all be the same size.

[greebo]

Nevermind, this is what it looks like with vertical arrows:

 

 

What do you think about this?

[OrbWeaver]

Looks OK to me -- I think rotation should be left/right though, since the concept will be more familiar.

[SneaksieDave]

Groovy. Agreed on the rotation L/R suggestion.

 

Do I dare ask what happens to tesselation and XYZST? Are they in fact on their own dialog? S,T are texture adjustments afterall, but it'd be silly to break 'em up... I kinda liked the expand/Advanced button idea. I'm trying to think, what if the user is adjusting S and T (with our user friendly new spin controls ) but realizes they also need some texture sizing or shifting? Open both dialogs. :-/

[greebo]

I'd prefer having two dialogs open (when I need them) instead of one large one (with seldom used widgets). I don't know how much work the expand thingy is, but I can have a look at it.

[greebo]

I was curious and re-enabled the compilation of this ominous TexTool (which was disabled compiler directives) and surprisingly it compiled without complaints. This is what I found:

 

 

Pretty damn cool, if you ask me. It basically visualises the location of the selected brush face in texture space and allows you to manipulate the thing with mouse clicks (translation/rotation). The behaviour is similar to the UV mapper in blender, but without vertex drag manipulation. And it only works for single brush faces.

 

Judging from the comments in the code, it most probably has some major flaws (being the reason why it was disabled in the first place), but I feel an urge to get that tool working!

 

I put up a new snapshot for this tool so that SneaksieDave can have a look at it too: http://208.49.149.118/TheDarkMod/download/...8.x.rev1004.zip

[OrbWeaver]

That's pretty cool actually, I wonder if we can integrate and improve it. I noticed it was disabled but never got round to actually testing it.

[greebo]

I opened the issue in the bugtracker as child of the surface dialog issue. From fiddling around it indeed seems to be a bit unpolished.

 

I checked the changelog and it seemed to be part of GtkRadiant since 2000, it has been rewritten one or two times and finally been disabled in 2004. Shamus seemed to be the last one who worked on that feature.

[SneaksieDave]

That's interesting. That looks like a definite candidate for an Advanced/pop-out button though, as it would not be used all the time, and it would take up a ton of space the rest of the time.

 

But man, if you could get patches and vertex manip working with it...

[greebo]

The new Surface Dialog is feature complete and the TexTool is up and running. Do we still need the Patch Surface Inspector (Shift-S) as a dialog window or should I incorporate it into the menu as "Curve > Edit Tesselation"?

[SneaksieDave]

Does the new tex tool make Row, Column, X, Y, Z, S, and T obsolete? Perhaps it does. I hadn't really thought about it. Tesselation per brush/patch as a menu item shouldn't have any problems, I think?

[greebo]

It does make the S and T entries kind of obsolete, because you can drag it per mouse anyway. Perhaps it might be handy to leave the X,Y,Z coord manipulators still there for (rare) editing and diagnostic purposes. I will open the according issue on the Bugtracker.

[SneaksieDave]

Maybe the easiest way is just to chop the whole right half of the patch properties window off, and leave the existing one for special cases where it's needed. Then you've got rows, column, S...T, and tesselation all on one dialog with no further work.

[greebo]

Already done.

[greebo]

That's what the new PatchInspector looks like: I wanted to strip the unused elements from the old dialog first, but the code was hard to clean up so I thought I'd be faster taking the new Surface Inspector as a template.

 

 

All the controls get inactivated if there is more or less than exactly one patch selected.

[SneaksieDave]

Lookin' good.