Flowmap Painter update (0.9.2)

I’ve made some updates to the flowmap painter, with the help of some really great feedback.

Click here to get it, though the version checker ought to notify you if you start up the program.

 

Changelist from the readme (I’ll write a bit more about the changes when I’ve had some sleep :p):

= 0.9.2 =
* 4 October 2012
* Tweaked pan/zoom behavior
* Added:
  - Spacebar as an alternative to Alt for pan/zoom
  - Zoom level indicator
  - option to flip red/green channels on bake
  - swizzle option (red/green --> red/blue)
  - ability to save/load session **superceded by next point
  - ability to load flowmap texture
  - slider to alter flow preview line length
  - optional wrapping (with tiling preview)
  - defaults.ini to remember your last-used paths between sessions
* Fixed overlay texture rotated 180 degrees
* Fixed custom tiling texture reverting to default when toggling vertex color preview
* Fixed version checker
* Optimised performance somewhat
* Known Issue: Flowmap preview doesn't tile correctly (shader problem?)
* Known Issue: Flow line preview mode is slowww

http://teckartist.com/?page_id=107

FlowMap Painter update (v0.9.1)

[update: version 0.9.2 has been released]

I’ve done a bit of an update to the FlowMap Painter I released a few days ago, and did up a holding page for it, where you can download the latest build (the version checker directs you there).

http://teckartist.com/?page_id=107

 

Download:

From the readme:

== Changelog ==

= 0.9.1 =
* 20 September 2012
* Added new brush modes (Pinch/Inflate, and Vortex)
-Currently, only way to switch modes is keyboard shortcuts (1, 2, 3)
* Added pan and zoom functionality (and reset view)
* Added rudimentary version checker and update notification
* Fixed broken overlay functionality from initial release.
-also defaults overlay to 50% opacity (instead of starting invisible)

 

I’ve also added a reminder that undo is available, just in case. Still no redo yet, though.

Additionally, I’m providing separate downloads for Win32 and OSX, because bundling them together seemed a bit silly.

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.

FlowMapPainter

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.
(https://developer.valvesoftware.com/wiki/Water_(shader)#Authoring_a_flow_map)

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.

 

Cheers,
Teck

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.

Ignore file for Git and Unity

After the initial bewilderment of starting up git for my personal projects (I’d previously used Subversion and Perforce), I’m finding it quite nice. For those of you thinking of going Git with Unity, here’s a working ignore file. It basically covers the files listed in Unity’s source control documentation, plus the Temp directory. Anything else in the project directory gets versioned.

Paste the following in a plain text file named .gitignore located in your project directory (the repo root):

*.apk
Thumbs.db
Temp/
Library/*
!Library/EditorBuildSettings.asset
!Library/InputManager.asset
!Library/ProjectSettings.asset
!Library/QualitySettings.asset
!Library/TagManager.asset
!Library/TimeManager.asset
!Library/AudioManager.asset
!Library/DynamicsManager.asset
!Library/NetworkManager.asset

If you want to add more files to ignore, the syntax is pretty simple:

*.Ext     : Standard wildcard
File.Ext  : Specific file
Dir/      : Entire directory
Dir/*     : All files in directory (there's a difference! Thanks to James O'Hare for pointing that out)
!Dir/File : Negates ignore flag (you'll need to use the aforementioned [Dir/*] for this. [Dir/] will effectively override the ignore flag)

 

Debug.Log(“Hello World!”)

So I haven’t done any blogging in positively ages, but I figure now that I’ve got this great domain name, I could stand to post up some tech art-related things here. Bit more permanent than throwing everything up on Google+, at any rate.

Actual content incoming…

Comments Off Posted in Misc