Ick

Published December 22, 2005
Advertisement
As per my promise to Deranged, I have been working on the Golem3D heightmap editor. It's coming along good, but I just wanted to pop in and say how much I really dislike UI work. You know, creating all the dialogs and widgets and what not. I'm working with Fox, and while it's pretty easy to use, I do not have a UI designer's aesthetic sense of placement and layout, and I muddle through things half-heartedly. I'm currently struggling with the best way to do the Terrain Brush, including some problems I have previously discussed with Deranged and which are proving as problematic as I thought they would.

You see, the problem is this. My new terrain blending scheme renders the terrain in passes, and each layer has an associated per-vertex alpha buffer that determines the blend of the terrain texture which is tiled across the map. Since the blend values of each layer exist independently of one another, it is entirely possible to have non-zero alpha in a layer that is subsequently obscured by a higher layer with non-zero alpha. Unless the higher layers are erased, the lower layer will not be visible. This could be tricky when the user is trying to 'paint' terrain of a lower layer, onto terrain that is already painted with a higher layer, since there will be apparently no visible result of his painting. Unless he actively erases the higher layers, that is.

So I am trying to figure out the best way of dealing with this. I could have the terrain paint brush automatically erase higher level blend values when painting with a terrain type that could be obscured. Or I could have the brush track toggles and weight values for all terrain layers, making it possible to paint and/or erase any combination of layers at once in a single stroke. Or I could just have the default configuration of painting a layer at a time, and forcing explicit erasure of top layers to expose painted terrain. This approach seems hacky and likely to cause me support headaches, but none of the other solutions I have come up with exactly lend themselves to elegance and style. It's a pain in the butt, I say.

And don't even get me started on the layout and resizing issues. I pregenerate a somewhat complicated structure of data when the map is initialized to implement the spacial partitioning scheme that allows me to draw the visible area of the map and maintain a high FPS. But I need to discard and rebuild this chunk of data whenever the GL viewport changes size, or I get weirdness. It's not too bad, but there is just a slight little hesitation when processing the resize event that I don't like.

Also, like I said, I like a UI pro's aesthetic sense when it comes to layouts. I'm struggling with the best way to handle the various brush options. I've settled on a toolbar for the tool selection (need some icons) and I am sort of thinking about a tabbed dialog that runs either along the side if I can figure out how to make a sideways tab page, or along the bottom if I can't. I'd rather have it on the side, to keep from screwing up the vertical space of the editing window, but we'll see how it goes.

At any rate, I've got design in place to do the following things:

Edit the map using cliff, terrain and blur brushes, as was implemented in the original version. Cliff and blur I have pretty much copied over directly, terrain is causing me some headaches.

Edit the elevation and blend buffers directly via script interface. A pre-packaged set of scripts will be provided to perform actions such as 'cliffing' (the process of assigning a certain type of terrain to nodes that exceed a certain steepness threshold), surface noise generation (giving the ground a bumpy, noisy texture to eliminate the ultra-smoothness that the terrain tools create; currently, this surface noise is a separate buffer, but I may just generate it on the fly as terrain is edited), Perlin noise buffer generation (the pre-packaged scripts would use some generally acceptable default parameters, or perhaps use a simple dialog to allow parameterization of the noise) and so forth. More complicated effects could be directly scripted using the provided interface.

I am thinking about providing a means for generating a point list, allowing the user to select the list option and click to place points on the map. This could be useful for parameterizing a road builder function, for instance; click to place the control points of the road curve, then let a pre-packaged road builder script build the road, tesselating the curve and applying any turbulence and randomness as specified in the script parameters. This road-builder functionality would operate, of course, pretty much as I have described previously in this journal, though absent the random generation of the point list for the road poly line.

I also want to allow export of height and blend buffers to .TGA greyscale images, and import from the same. As well as a custom integrated format to save and load all layers.

I thought about doing a limited Undo/Redo functionality, but right now it's not a priority, and I really don't grok how to do it without vastly increasing the complexity of this project. Anyway, more later hopefully. It's bedtime now.
Previous Entry Heh. Sweet.
Next Entry Gragaaaagh!!!
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement