Having set Eulora's soil in stone (and grass and sand), I turned my attention this week to the waters that should naturally be found around an island - if it's meant to be any sort of island at all. You know, those deep-deep euloran waters that hold all sorts of resources and unexpected benefits.

Last time I looked at water generation, I considered it had to be nothing other than some specific use of the procedural texture that CS supposedly provides for water rendering. A closer look at the corresponding CS plugin code¹ revealed however that it's yet another very specialised thing to the extent that it comes with methods for making "puddles" at a given point - supposedly what the surface should look like if you throw something into the water. At the core of it though, the whole "procedural texture" shtick is an animated texture aka a set of direct writings/changes to the render buffers using the engine's "ticks" as time units to play the desired sequence. Given this rather disappointing find, I don't quite see any strong reason to import into SMG's protocol those "procedural textures" as they are currently in CS, they seem to be utterly focused on client side rendering again and as such entirely client's concern and choice.

Having set to rest my hopes of procedural water generation, I turned to the existing client's pile of .xml files to extract from there just what and how it defines this water thing anyway, since the whole idea is to use whatever is currently in use, right? So in I went and here's what I gathered:

1. From island xml file (in art/world.zip), I found out that the "water" is but a mesh like any other so an "item/structure" in my hierarchy of data, only using a custom factory called "water".
2. Following the factory clue, from the water² xml file (in art/meshes.zip) I found out that the whole of Eulora's water is in fact but a 2D rectangle, a sheet of blue if you will, cutting through the whole world to show only where there's nothing else with higher rendering priority! And moreover, the whole thing is simply defined in the factory through its vertices, normals, texels (texture coordinates) and triangles - the minimal thing overall for a rectangle so that's 4 vertices (with corresponding normals and texels) plus 2 triangles. The whole illusion therefore has to be achieved through the thin veneer³ - aka material used - on top of this rectangle.
3. In search of the material therefore, it was off to art/materials.zip and the materials.cslib file within. A look inside of it revealed that the material "water_02" (as jotted down from the factory's definition) is a thing with 2 shaders (set as different types but using the same... shader; does this make any sense to you?) and 6 shader variables of which one is a texture but not the base texture but the normal texture (aka it's used for more precise definition of normals across the surface rather than as painted skin to spread upon the surface).
4. The "normal texture" from above turned out to be indeed defined simply in the same materials.cslib as a file that even exists where one would expect it to be (in art/materials.zip) except... its extension is missing, its type is actually unknown (it's not .ani as one might guess from the name, it's not .png, nor .jpg, nor .dds for sure) and the current client in fact complains loudly at this, if anyone ever paid attention: it can't load that "generic_water_001_ani" thing no matter what. So...uhm, ditch it then and use some reasonably named "w_normalmap" since it is meant to be a map of normals after all.
5. As for the shader with multiple uses, a look at it indicated that it's indeed the part doing in fact all the heavy water lifting so it got added to the list of defaults that the client loads.

With all the above set, the rest was simply a matter of writing the code to create then the default water precisely as defined in the current xml, only using CS directly from code and without requiring any xml at all. There were a few funny steps on the way including the water with error texture when I had to test that ani file just in case it could be loaded somehow:

Then the part where Foxy walked on water because the xml had this tag "colldet" that you might be forgiven to think it means adding collision detection as silly as that may sound when you render water - of course it does not mean such a simple thing; what it means is that you should *toggle* collision detection on if it's off and off if it's on and of course you just...know what it is anyway, right? It's also with a different water "normals" texture that I tried for testing purposes and it doesn't even look all *that* bad although the clear repetition is rather grating to my eyes:

And some funny legs reflections that are for now still in there, mainly because apparently that's how Foxy's current shape ends up reflected currently:

Finally, here's also an even reasonable shot of Foxy getting out of the water on to the Euloran harsh and unforgiving sand:

An interesting thing to note with this water-plane approach is the fact that it's currently... in the way of light at times so it introduces weird "dark" effects in places on the island. For the time being I'm not too bothered about it since it might anyway end up sorted when I look into default lights and moreover, it's again both a client-side concern only and the exact way in which the existing client works anyway. This being said, I still think this whole water-plane thing is silly - especially given that once you get inside the water fully, there's of course just... air aka "no water inside the water". Ain't this just a great illustration of how modern stuff turns out to be at a closer look, various sorts of no water inside water, right?

1. The main bit is in cs/plugins/proctex/standard/prwater.cpp if you are curious about it. ↩

2. There are actually TWO files in there, namely water and water2 but as it seems to be the usual case with the existing client, one is just not used currently at all. ↩

3. At which point my mind sniggered into song, of course, as this must clearly be what most people mean all along with all the heartfelt "river deeeeeeep and mountain hiiiiigh"; it fits this sort of water and this sort of deep, heh. ↩

Category: Coding, Eulora

Comments feed: RSS 2.0