FlowMap Painter

[update: check out version 0.9.1]

I’ve been neglecting this blog a bit, but I figured this FlowMapPainter might be a good excuse to post something up again.


Click to download FlowMapPainter v0.9

It’s been pointed out that the overlay feature doesn’t work. Bit of a bug there that’ll be fixed in an imminent update.

This is actually a bit of a port job. I’ve been working on a vertex painter for Unity as an editor extension, but at some point after adding flowmap painting, I realised it could be quite useful as a standalone (eg. for folks using Cry, Source, Unreal, etc). So I spent a weekend rewriting the relevant bits, and putting together a very rudimentary interface (since most of that wouldn’t port directly over from the Unity Editor API).

From the readme:

This here is a flowmap painter. It serves to make artist-authored (or -tweaked) flowmaps a viable option, where current methods tend to favor simulations via Houdini, for example.

The tool allows the artist to paint areas of flow, and uses a basic flow shader to immediately preview the results.
It also provides a couple of additional visualisations, such as the actual colors that are being painted, as well as a visualisation of the resulting flow lines.

It’s currently a little rough around the edges; for example, needing to type in the path to your output or custom texture, as opposed to having a proper file browser.


Any and all feedback is welcome, as I continue to work on this.



Shader Fun: Trading Accuracy for Variety

A little while ago, I was doing a bit of r&d for a potential alternative to one of our shader solutions. This particular approach never made it past gestation, though, since it would have required a fair amount of texture reauthoring and rejiggering to be viable. Long story short, I was looking at ways to maximise available variation in a single 8-bit channel. Bang for buck, if you will.

Now, I’d recalled Bronwen Grimes’ presentation on shader techniques in Left 4 Dead 2, and in particular that they had split their zombie color variation masks by value range. In a nutshell, they would split the masks in half (page 26), and then remapped those via a split gradient map, which ultimately gave them four value ranges to work with (page 38). I didn’t really see the split gradient map working for my purposes, and I also felt there should be a cleaner (and more versatile) method of splitting the value range.

After a bit of experimentation, and cracking my skull over a bit of math, I ended up with the following, surprisingly straightforward, function:

int bands = 4; //this is the number of value bands to split the range
float range = 1.0 / bands; //range of each band

float ReRamp(float val, int band)
//val is the pixel's luminance, band is the... band [index]
  float minRange = range * band;
  float maxRange = range * (band + 1);
  float c = min(saturate(val - minRange) / (maxRange - minRange), 1);
  c = c >= 1?0:c;
  return c;

This effectively allows you to split your value range into as many discrete bands as you please (however keeping in mind the need for a buffer between ranges to account for compression; page 39).

The returned value has been reramped from its original value range (eg. 0.25, for 4 bands) to the full 0-1 range, allowing you to do whatever you please with it, be that as a color mask, uv distortion, etc.

You don’t even need to split a texture up to benefit from this approach, either. Assuming you have, say, 4 different UV warping algorithms modulated by this channel, you could have 4 different textures (for 4 different assets), just being sure to keep each one in the required value range.

Now there are obviously drawbacks to this approach. As mentioned in the presentation, the various masked areas can’t overlap. Additionally, you’re sacrificing value range for file size (texture/channel count). The more bands you want, the coarser the value ramp.