Water as Time Dilator

Screen Shot 2017-02-10 at 18.11.43

Just some brief words this evening since I’m kind of weary and forgot to write anything while I was more coherent earlier in the day. Still working on v r 3, still running into frustrating but simultaneously interesting technical issues.

So I have finally, finally managed to put different kinds of Unity professional water into all my plinths. This included editing the water script itself and doing a little big of shader debugging, neither of which I envisaged needing to touch when I started the project. However, it now turns out that if you have all (or many) of the plinths in your visual field while playing the game (at least on the MacBook Air that I do everything on), the framerate drops significantly and everything gets a bit dodging-a-bullet-in-the-Matrix.

Clearly the work of rendering all these different planes of water at the same time is kind of killing the performance, which I guess is fair enough? I wouldn’t know. I think there’s already something strange and intriguing there, right? That water, ostensibly this innocuous physical substance can slow time itself is pretty remarkable. Game engines just do the darndest things. So water turns out to be, in some sense, expensive for the graphics rendering of the game, especially when you have the game rendering 24 different planes of different water, animating them, presumably performing reflection and refraction calculations etc. etc. Perhaps that’s just more than one should expect. So the water does time dilation. Fine.

Some investigation showed that even water that isn’t actually visible to the camera is still being rendered, which is a pain. It would be nice if the computer didn’t have to grind away on all the computation required to display water I can’t see. This led me down the rabbit hole of looking at occlusion in Unity thanks to Ben Gattet, and we managed to get these cool visualisations of what the avatar (camera) can see and what’s being rendered and so on. Water is definitely being rendered even when it’s technically not visible. And this is apparently because the things hiding it (e.g. the sides of the plinths) aren’t big enough to be considered for “occlusion culling” (the process by which the game engine decides whether or not something is hidden from view and thus doesn’t bother rendering it at all).

I tried a few tricks in this world, notably trying to define a much smaller definition of what could count as occluding something else, but that started to crash my computer and generate insanely large files storing all the data, so it doesn’t look like that’s a winner. In my daydreams I’ve been thinking about writing a custom script to hide all water a certain distance from the avatar, but I don’t know if that would work or just look horrible.

Which all leads to a question about the overall exhibition of water itself. If the idea is to demonstrate Unity’s professional water set up with different parameters, and if the act of doing so causes the game to slow down, am I right in trying to “fix” that problem, or is that actually part of how the water is experienced? Just as much as some water is see through and some is opaque and some is red and some is pixellated, isn’t it also the case that, as an overall exhibition, the water just happens to slow down time? Maybe that’s just a “physical” property of water in this setting. It definitely has the benefit of drawing attention to the technical status of the water, for one thing, which is kind of the core idea behind the show. Nothing says “this water is constructed from code” better than “the water code is not performing well right now”, right?

Wheels within wheels. Water within water. Though perhaps not the later, might crash the world.


My digital water’s like a swamp, full of bugs

Screen Shot 2017-02-02 at 14.43.28

Oh hi, I’m still working away on v r 3 at the times when I can do that, and it’s been quite the ride of highs and lows. Sometimes I’m really, really pleased with the overall idea and how I think it will look and feel when it’s done (and yes, I know this feeling may be limited to me and like two other people), and other times I’m feeling really, really down.

Because it turns out to be inanely difficult to put water in a bunch of plinths in a virtual gallery. It sounds easy, but it ain’t. As I’ve said before, a lot of it is fairly easy in terms of the basic physics of putting objects in a virtual space etc., in ways that would be hard to do in regular old reality. But it’s the weird technicalities that are proving remarkably resistant to my “vision”.

As I work with Unity’s free “professional water” more and more I’m getting considerably deeper into thinking about what it is and how it works, because I just keep running into incredibly frustrating mistakes and, perhaps, bugs. It’s really interesting to me that there’s this process of needing to understand what’s going on at lower and lower levels of this piece of technology (and, of course, that the water is a technology in the first place). It’s not enough to just grab a “prefab” (a pre-build example of water that comes with the software) and drop it into the gallery, because I have a bunch of constraints. The chief of which is needing multiple instances of water in my environment, rather than just the usual single body of water (like a lake or whatever), and importantly that those multiple instances explicitly need to have different parameters set on them (reflective, refractive, or not, etc.).

Because of my requirements, which make total sense to me, I’m having a lot of difficulty. It turns out, at least to this point of my knowledge of Unity’s water, that the water doesn’t seem to “want” to exist in multiple configurations in the same space. So if I make some water that’s only reflective, and some other water that’s both reflective and refractive, they will enter into some sort of weird “possible universes” situation where, depending on how you look at one of them, it will flip between being reflective or refractive and back again. Not the ideal behaviour for water. I’ve now reached the point of going all the way down to reading the underlying code that defines the water itself to try to figure this out, without too much luck as yet.

A weird addition to all this is that of course I could at some point choose to exhibit these weird behaviours as part of this “show” of water, or even a separate show of things that don’t work the way they’re meant to? On and on it goes…