I thought writing an explicit end-of-year sitrep for myself might be a good idea, so here goes. Thoughts on past year, plans for the next one.
2018 has seen me release Unwelcome Gaze as a series of prints, but unfortunately with little success in setting it up as an installation in a gallery. I’ve contacted at least a dozen galleries in Belgrade, and heard nothing back from them. I’ve also applied to a couple of official “call for entries” with no success. The closest I’ve come to that goal is that Unwelcome Gaze: Amazon (so only a third of the tryptich) was shown at the Heapcon conference in Belgrade.
I should also note that I’ve been contacted by FastCo for an interview, which we did over email. I’ve spent a good two hours or so to answer all their questions, after which point they fell silent, didn’t publish the interview, and stopped responding to my emails altogether. Very unprofessional.
While I’m not too happy about how the installation aspect came through, the prints have been received well and I’ve sold quite a few of them.
The bottom line is that I view Unwelcome Gaze as a partial success, but I will definitely think twice before working on a project as long as this one, and with such narrow distribution channels (“art world”, prints). This is also my last project using the Clojure/Java/OpenGL tech stack.
I’m finishing up Itinerant and I’m planning to release it on the iOS App Store in the first quarter of 2019. Progress has been good and I’m excited to be working on a small mobile app again, since that’s the most direct way people can interact with my art. It’s also not strictly an art project, since it will be quite a useful everyday data visualization tool, I think.
Potential 2019 projects
While I still haven’t given much thought about the next project I’ll be working on, I’m sketching out a couple of possible directions:
- I’ve received an artist invite for FRAMED and I’m thinking about converting Itinerant to a weather forecast art piece. The main challenge here will be FRAMED’s hardware specs which are quite outdated, and it might prove tricky to make Itinerant run smoothly on it since it’s quite GPU-heavy.
- I want to do a project which incorporates photogrammetry (and volumetric models in general) with my procedural volumetric tools. I have a couple of ideas I’m throwing around for this one.
- I’ve been thinking about screen savers. An interesting niche.
Last year I went all-in on Unity. I have two of my own custom toolchains I’m using and will be continuing to improve:
- The raymarching (GPU-heavy) toolchain based around signed distance fields. Realtime, very high fidelity and visual complexity, at the cost of being extremely hard on the GPU.
- The marching cubes (CPU-heavy) toolchain I’ve been slowly evolving all the way back from Medjed. Not-quite-realtime (for complexities I’m aiming for), less visual fidelity but much more GPU- and battery-friendly.
These will be my mainstay for 2019, with some more research going on around them.
I’ve been closely watching the new ECS/Burst tech stack the folks from Unity have been rolling out for the past couple of months. I see there’s real commitment to push this toolchain forward and to make it the default way of doing high-performance cross-platform work, so I’m very excited about this. I’ll definitely be porting some of my own multi-threaded volumetric meshing tools over to ECS/Burst at some point. I’ve done some proof-of-concept work on porting this over a couple of months ago, but I’ve seen ~4x slower execution times than my hand-rolled multi-threaded marching cubes solution. The main bottleneck seems to be the marshalling of data from the job system back into “main thread land” and then copying this data over onto the GPU, so I’ll need to put in some more work to optimize things there and avoid needless copying all over the place.
I’ll also be working on this “slow raymarching” concept I’ve been thinking about – instead of rendering a fully raymarched model each frame, divide the screen into tiles and then raymarch only a single tile per frame. Once all tiles have been rendered (over N frames), they are assembled back into a fullscreen texture and then the texture is animated (over the next N frames) onto the previously displayed texture, possibly using motion vectors for a more realistic result. This approach will only work for slow moving visuals when there’s no user interaction going on, so it’s not applicable for everything. Itinerant will probably be a good testbed.
The missing piece in my mesh-based marching cubes toolchain is animation. I want to make a “kinetic mesh” structure which will have a “current” and “next” mesh and will be able to automatically set up vertex attribute animations in such a way as to appear that the mesh hasn’t changed from current to next at all, but was rather just a single mesh slowly moving about.
Finally, I want to port my Clojure implementation of parallel transport frames into C#. PTF shapes are cheap and good looking.
This year I’ll be working more on mobile/Mac/PC projects. I want to make use of the “canvases” which people already have with them – phones, tablets, computer screens. I want to expand my reach and use wider distribution channels, instead of relying on “old school” ones. I also want to do more work on the road.