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.