Having explored those past few days all the possible ways to get various aspects of air¹ showing up in Eulora's client, I'm left with a working "air" element of sorts, a bunch of screenshots (scroll down for them) to show as illustrations of the whole exploration and otherwise a lingering question of little import to computer graphics: if it's indeed a sphere but lacking any atmos, can it still be called an atmosphere?

Unlike the terrain and the water that I sorted out already, the "air" category doesn't have just one single element since CS and the current client don't bother with such lofty ideas as actually modeling anything. There are instead all sorts of bits and pieces that can be pieced together to make it seem like there is some sort of atmosphere: some sky, some clouds, some weather, some fancy potential effects of sorts and some ways for light to travel from the sun or any other source. So the rest of this article is a look at what I found out when taking each of those in turn and looking in practical detail at how and to what extent they can be made to work at all.

Light

To be able to see anything of the world at all, CS requires at the very least an amount of "ambiental" light (so light without a source as such, supposedly a sort of stand-in for the reflected light as it bounces off everything around) and a (some) source(s) of light overall. On one hand sources of light are more aptly items/structures in my hierarchy of objects and as such not really belonging here but on the other hand, the way the client works currently, there is the need for some "sources of light" that are simply environmental characteristics rather than items. So I went here with copying whatever such lights are defined in the current client: some ambiental light and 3 "suns" positioned through unknown methods in a way that "works" in the sense that you can see the stuff around and there is some apparent direction from where the sun shines or something. It's a mystical light basically and it will be fixed as default in there, nothing more to do about it as far as I can currently see, since it's certainly not the server's job or interest to fiddle default lighting so things are visible given one rendering or another.

When talking of lights, it's worth noting that the above fixed set of lights is not in fact the full story in the currently deployed client. The intensity and exact colour of light is made to depend on the time but at the moment this is not imported into the prototype client and I'm not fully sure it's something worth importing as such: the way it's done, there's an xml file (art/lighting.xml) that lists *for each hour of the day* the values (r,g,b) of various lights (identified by their fixed name...) in different sectors (again, identified by fixed sector names). Some manager or another in the PS client code proceeds then to use those values to adjust each light periodically, to match the time of the day, interpolating between the values given for the current and next hour.

Besides the clunkiness and clumsiness of the above approach, there's more trouble with importing it as found, with the most important problem being that the assumption of fixed sector names simply has no place at all in Eulora's client. Moreover, there's no good reason I can see for having this sort of hour by hour list in an xml if it's basically a set of constants anyway and entirely client's business too. So at the moment, it just remained outside entirely: in Eulora's default client it's always somewhere in the middle of the day, when things are quite visible. As a player I'm not even sure why the fuck would I actually *want* to have light dimming so I can't see things properly but then again, it's been already observed that I'm a sort of software radical, especially when dealing with graphics, so let me know if you have some reasons for which I should really spend some time to implement time-related changes to the overall light (and then possibly getting in a night sky too, I suppose, see below for the sky and clouds section).

For an illustration of the light conditions, here's a screenshot from a "shaded" spot so you can notice the light and shade divide as it happens with the current set of ambiental light and three suns:

Sky and Clouds

Looking at the currently deployed client in the usual places (art/world.zip/island.xml for the factory+mesh; then off to art/meshes.zip/sphere.xml for the definition of the factory; then art/materials.zip/materials.cslib for the definition of the relevant materials) reveals that the euloran sky is currently a generic mesh defined painstakingly through enumerations of vertices and corresponding texels (texture coordinates at each vertex), normals and colours (which are all set to 1 and probably of no use since the texture is added on top anyway but hey, it has to be there so it's there) as well as a whole set of triangles to piece up whatever shape the whole thing ends up to be (possibly an approximation of a sphere if the name is to be trusted indeed but I haven't really bothered to check). Such a brilliant way of describing the thing that there are - line numbers for the win! - about 2050 vertices and when you multiply that by 4 and add on top the list of triangles and a bit of xml tags too, the file ends up having a bit more than 8200 lines in total - just because it can!

While I could easily just use copy/paste to get the above horror as constants in the default code, I find the idea so abhorrent that it's just about the last thing I'd do - if there really was no other practical way to get some darned sky showing properly at all. Happily though, there is a more reasonable alternative in this case: with a bit of fiddling of parameters, it turns out that CS's code for generating programmatically a sphere can do the job quite fine: the fiddling was more a matter of figuring out the exact number of rim vertices that would fit the existing texture well rather than anything else. So instead of littering the code with those thousands of lines of constant numbers describing a sphere, it works sanely for once to simply call the code to *generate* the sphere a be done with it! I have no idea why exactly wasn't this done to start with but I am not even all that curious to find out really - what difference will it make anyway?

While the sphere - programmatically generated or boringly xml-enumerated - provides the so-called geometry of the "sky", the rendered image is as usual a texture. Aiming to figure out what options there are and how they work, I made a few attempts to see if the shaders provided as "sky" and "clouds2" are of any use - it turns out they aren't, at least not as they stand undocumented and without wasting a lot of time to get to the bottom of everything so that at least ~something shows up working. From what I could tell and for the very little that this is worth currently, the clouds2 shader aims to programmatically animate the texture so that you get supposedly moving clouds. Nevertheless, the default client will *not* get moving but fixed clouds, as already neatly painted in the image file that serves as texture for the sky cloud. Anyway, as part of the testing, I have tried out a different "sky" texture that I found in the "art" directory of the current client and the result was a rather weird-looking sky-thing:

Getting back to using the usual clouds texture works though and the sky looks reasonable again, even reflecting quite well in the water - along with Foxy's long and slender-by-water-effect legs, of course:

Effects

Since one might reasonably want some pretty sparks or something around, I went ahead and implemented in code the sparkly sphere that is currently defined in xml and shown on the beach in the client 1.2. It is using a particle systems and it goes on to tediously set quite a lot of parameters for the effector especially but with the right shader applied as well, the result can actually turn out quite prettily indeed, with both the "snowflake" texture and the currently used "spark" texture:

Weather: Rain, Snow and Fog

Moving on to weather effects, there's fog as the simpler part and then rain and snow that are just variations on putting together in some predefined manner some particle systems. As my previous attempt at sorting out the particle systems was rather frustrating and with dubious results, I started with them first. As it happens, my suspicion that the poor effects of last time were linked to not using a shader/the right shader incantation turned out to be correct. Combined with the fact that meanwhile I ate - if rather reluctantly - shaders for breakfast too, it didn't take all that long to obtain some pretty snow for instance:

The shader used by both snow and rain is "particles_basic" and one remaining wtf that I had to sort out - to the degree possible - before being able to obtain the pretty picture above was the meaning of "type of shader" as set in code and otherwise not really mentioned or listed anywhere. What I finally figured out is that there is a set of predefined types (which is however nowhere properly listed as such as far as I could tell and goddammit I did look in the code and in the manual and in the api and on the dark side of the moon too) and those in fact are linked to - but not named as, nooo - different rendering passes! So that you can use the right shader but if you use it with the wrong type aka in the incorrect rendering pass, you get bupkiss result and can go bang your head some more as there's no way to tell exactly why. This is by the way the solution to last article's puzzle re using the same shader 2 times only set with different "types" - it is indeed the same and will indeed be run twice only in different rendering passes so the effects accumulate/interact in whatever way they do it (in some cases there are even values passed between successive rendering passes for instance...). I suppose I should be happy I solved my own puzzle or something.

Leaving the above rendering passes mess aside for now, it further turned out at a closer look that this glorious particles_basic shader does precious little really to the point that the observed effect is simply one of ...making it work well with textures that use black for "transparent" instead of having an alpha channel. Doesn't this sound though like a truly mind-boggling reason to use a whole shader for? Because to me it does and to such extent that I couldn't just let it be - so I took the silly snowflake texture file and made the equivalent image only with transparency properly set through the alpha channel. After which, I made it snow again only without any bloody shader in the mix and lo and behold, you tell me the difference:

The even funnier part of the above great shader use though is what happens therefore if you do both aka you use the shader (that worked with texture having black stand for transparent) AND have transparency in the texture itself - it's snowing translucent cubes!

Both rain and snow are painstakingly set in code with all the emitters, effectors, material and shader(s) + shader variables, as quite specific to particle systems. The main difference is with respect to texture used (since a snowflake is meant to look different from a water drop) and otherwise the particle size range. The shader does exactly the same sort of not-much as for snow but I haven't bothered to add transparency to the water drop texture too so here's how the current texture looks with and without the shader applied:

Given that the main difference between rain and snow really is just a matter of texture, it's probably possible to simply fix the particle size and a lot of other parameters for the "effectors" and "emitters" and whatnots and then just have one single default "rain" that can then rain down even frogs if that's the texture given. However, it turns out that there's some deep trouble afoot with the current implementation of particle systems in CS: first, they are so inefficient that extending the rained upon area to the whole island basically doesn't quite work (there was an initial freeze while CS calculated whatever it calculated for it all and then it was still visibly suffering while pouring all that thick rain around); second, whenever rain and/or snow code is in, the exit ends up in a segfault - as this is many levels deep in CS, I haven't really spent time to investigate it and find the exact culprit but it seems to be related possibly to the specific emitter that rain/snow use since the trouble does not manifest for instance for the "sparkly globe" effect (see the previous section above) that uses a different emitter.

The fog is simply a property of the sector as a whole - there is no "local" fog even possible, unless you make perhaps your own as a particle systems I suppose (could have fog-particles perhaps?). One can set the "density" and the colour of the fog (r,g,b) - basically the effect is similar to putting on a pair of glasses tinted with the chosen fog's colour and having thicker or thinner lenses depending on density. There is also a further "mode" parameter that chooses -as far as I can tell- the way in which exact fog values are calculated in the distance with the available "models" being called CS_FOG_MODE_NONE, CS_FOG_MODE_CRYSTALSPACE, CS_FOG_MODE_LINEAR_CRYSTALSPACE, CS_FOG_MODE_EXP, CS_FOG_MODE_EXP2. The only one I could find used at all seems to be CS_FOG_MODE_CRYSTALSPACE but at any rate, I made some experiments with others and there is either little visible difference or the whole thing looks even worse than it does otherwise. Moreover, I can't say I see exactly any reason why I'd want fog in my client as a player but do let me know if you still think it should be in there - and in what form exactly. To get some idea of how it looks like, here are some pics of various "fog" experiments:

The bluish fog (r=0, g=0.1, b=0.1, density=0.02):

At one extreme, the fog so white that it...shines in your eyes:

At the other extreme, the fog so dark that everything turns into a black and white disco style:

Still shiny fog but toned down a bit:

When fog is more like darkness than like fog:

Possibly almost reasonable - if rather graying - fog:

Conclusion and Next Step

Given all the above, I'm overall satisfied that there is now some working default "air" for Eulora's sectors even though no depiction of weather or of day/night changes. The shiny globe effect seems to work surprisingly well so far so I'll keep it still on the list and possibly have another look at it after sorting out the items and characters to see if/how it can be attached to an item or to a moving character, if that is something of interest.

The next step for now is the potentially more time-consuming and iffier sorting out of a working default for characters with animations and all that included so there will likely be a longer wait until the next article in this series.

1. No, not various airs and not even various arias - though these might be in waiting when I get to look at sounds. ↩

Category: Coding, Eulora

Comments feed: RSS 2.0