impromptu vector field painter, a tool for making vector fields

A tool I made a long time ago with a little help from the excellent Turfster is my Vector Field Painter, made to be used in VR. It’s a standalone application that’s basically a VR game where you use your hands to “paint” direction and magnitude into a 3D vector field, preview the result using particles, and output it as a file to be used in your own games or whatever; things like particle systems in Unreal. I’ve occasionally heard of someone seeing it in use at their work, including someone at Double Fine during the development of Psychonauts 2. Presumably it was the lynchpin of the entire project.

At the time (eight years ago apparently???) you’d see vector fields thrown around a lot to do impressive but not-that-interesting things with big clouds of particles. It was clearly a cool data type (weird thing to say) but I was mostly seeing fields that were random or barely-directed noise, generated by some Maya script, and my suspicion was that this was just because there was no good way to author them “by hand”. It’s 3D data, so even click-dragging through a cloud of points (which nothing would let you do anyway) was bullshit. Painting them in VR seemed like the obvious answer, although I still appear to be the only one who has made such a thing.

Distribution for this one was a bit interesting. I submitted it to the Unreal Engine Marketplace, but they wouldn’t take it for one reason or another – sort of a grey area, I suppose, between “tool” and “example project”. It’s a tool that is an Unreal project, which you wouldn’t merge into your own project because there would be no point. What you really want is a packaged build to run as a standalone tool, so that’s how I distribute it through Steam and Itchio (project files included too). Didn’t make any money, but why would it – it’s too niche a tool.

It has occasionally attracted interesting queries, though – one or two about potential applications in medical imaging. I recieved a sort of bewildering offer at one point from someone who wanted to “acquire” the tool, selling it under their name instead of mine and giving me a cut, which I would have been open to if they had offered any money.

I return to this tool often as an example of a genuine need to move code from Blueprint to C++ for performance reasons – one of the only ones I’ve seen. Nativisation (as this is called) is something folks do all the time “as optimisation”, but rarely, I deem, is that the right word for it. In almost every case, the problem is that the code is bad, and will stay bad after you nativise it – if you’re shitting the bed, it doesn’t matter which bed. Rewriting within Blueprint is preferable, but nativising can be quicker, and is doable without really knowing the code (or learning it in the process). I once saw someone nativise a Blueprint function that contained only a “print string” node. They said “it all adds up”. It does not.

In this case, painting into a high-res vector field in real-time in a useful and responsive way is inherently super expensive. It’s a lot of numbers to crunch every tick – immense loops. Moving that into C++ was a no-brainer (although Turfster applied a large brain and some neat extra tricks), but nothing like this really happens in a game.

These days, thanks to Niagara, a lot of what folks were using vector fields for in 2017 is easier without them. Manually-painted ones were always a niche use case, and now vector fields seem less in-use generally, so they aren’t the on-hand tool even when a great fit. Oh well!