Less than 2 weeks after I've set Eulora's client down, the resolution came of course to... pick it back up! Nothing like a bit of up-down to hm, build muscle? Anyways, there's nothing lost for the exercise and quite a lot gained really since I got some time to unload more than just the code¹ and the resulting discussion sets a clearer way to move further:

mircea_popescu: anyways, to complete the frame here : http://trilema.com/2020/get-back-to-me/ eventually was resolved through discussion here, specifically : 1. that the expectation we'll have to produce a data model constituent part of the original dilemma was in fact produced by 2. an unstated assumption that we'll resolve the reuse-or-rewrite dilemma in the sense of re-write, 3. driven in turn by the felt pain of dealing with the damned thing as it exists.
ossabot: Logged on 2020-01-27 11:26:47 diana_coman: the way I see it, there are 2 main ways to get the gfx back in: a. use what already works, hence client 1.2b b. implement own aka go from the existing prototypes in 2.0 to production stuff so yes, including non-stiff etc
mircea_popescu: but the correct decision is to reuse, on the grounds that however painful we might be aware it actually is, in the most organic sense of awareness, nevertheless the alternative is actually specifically the sort of thing we're trying to avoid.
mircea_popescu: as in, the ever-circling avoidant behaviour of great recent fame, that'll never complete nor does ever produce anything else but enlargements of scope, in a reminiscent threadmill.
ossabot: Logged on 2020-01-10 08:13:57 mircea_popescu: with the alt-pantsuit conceptual threadmill, the "counter"-cultural, by-and-for-goffy-kids yet JUST AS PANTSUIT (in the only important sense) threadmill, where nothing is replaced with ever "larger" nothing on a dilated schedule.
[..]
diana_coman: mircea_popescu: specifically and for full clarity though: what's desired next step currently?
mircea_popescu: either a working 2.0 with 1.2 gfx stack or a detaled failure report.

Given the above desired next step combined with this situation of having set down the code for a few days at least, I took first some time to look in parallel at the currently deployed client (1.2) and the prototype client (2.0), as I picked essentially both of them up again.

The result of all this looking was some barf of course but more usefully an initial map as to what needs to be done. And given the goal to get the gfx stack fully back in, I focused first on cementing some "default" loaders for each *type* of graphics asset that is going to be of any use: terrain, water, air, character (cal3d), item/structure (CS mesh), sound, icon, skin. Those defaults will be as minimal as possible and will serve as placeholders whenever needed - if an asset is missing or the client doesn't know about it because reasons², then the client will use the default for that type and be done with it. Sure, everything will look the same and/or confusing if there's too much of this going on but if you don't like that, you are warmly invited to get off your ass and make a better client already, there's your motivation for it. You're welcome.

The last attempt at getting to the bottom of terrain creation with CS ended up with a very mirror-like terrain that is really not quite good enough since one can hardly see much with all that reflection. So I've spent the past few days going again through it all, mapping out all the various bits and pieces from xml files everywhere to CS's terrain2 plugin and interfaces and whatnots.

To start with, since it's defaults and pragmatism all around this time, I've set the prototype client to just load the main shaders anyway since the rest of the code can't really do anything remotely reasonable without them. Let them be there, part and parcel of "the client" and none of server's concern otherwise. This bit already was funny since it turns out that there is one list of shaders where you'd perhaps expect it, namely in data/shader so the usual "inventory xml" file: shaderlist.xml. Except, this list is very small compared to the full set of shaders that ship with both CS and legacy client. So what gives? Well, it turns out that there's further listing of shaders from within the...materials' inventory! Now add to this the fact that each shader may reference snippets and other shaders that are perhaps not in the list and you might get some idea as to where this leads if one follows it blindly.

By now though I have no intention to follow anything blindly and so I don't care about its references, I'm not reimporting PS's full-blown dependency-dragging loader either³ and I'll use instead CS's basic loader to do the best it can. So I've set it explicitly and yes, hardcodedly, to load a list of shaders as I extracted it out of the current "shaderlist" and "materials.cslib" leaving it to handle or not the rest, who cares all that much. Surprisingly enough - or maybe not - it turns out it even works so I marked this part as done and moved on to making a default "Terrain" that will be used for any sector if need be.

While the naive approach with respect to terrain would consider the heightmap to be everything that's needed, the reality is of course rather messier than that. The legacy client does in fact several dances back and forth on this, to the point where the same files are in two places and the same mesh is defined in parts in the world xml file - I have no idea why really, there's no requirement for that and it certainly makes the whole thing rather confusing to follow.

Anyways, turning the terrain2 plugin inside out this time, I got at least to figure out the crucial bits: yes, the heightmap is needed; so is the base material in fact, despite what one might think at first - it's really this base material that does the first and most crucial layer of work. Setting this base material as it is in the legacy client requires the basic texture of the terrain, its lightmap, materialmap and normalmap as well as the three basic materials (texture+normals for each of them) that are to be used throughout.

The less than ideal news is therefore that "defaults" in this case end up being 11 .png and .dds files rather than just the one heightmap.png. The good news is that I figured out the idiotic shader and shader vars setting for this particularly convoluted thing⁴ and the result manages to actually look -perhaps unexpectedly- like some terrain after all:

If you don't quite like the rather rough look of the terrain above, note that it's indeed a very basic default terrain. The legacy client adds to the above several passes of rather intricate specifications of generating 3d grass/sand/rock of sorts with windspeed and density maps (aka yet another set of .png + .dds files that would need to get added to the defaults dir). At this stage I'm not even really sure that this side of things is really much concern for S.MG and the server - let the client prettify any terrain as it sees fit, after all.

For future reference, I'll note here that the whole dance with a "material palette" from which supposedly the terrain plugin selects and blends the materials based on the height of each point turned out in practice to make very little difference by itself. And so while I wrote the code to do that too, I'm not even sure it will make it to the production version as anything other than a note in the comments. This "palette" is such a pretense: there are at all times precisely 3 materials and nothing more, since they are otherwise specified via yet another .png and taken as the red, green and blue values respectively, so no, no space for more than 3 anyway. The only thing that may change at all are the 3 materials themselves.

For now I'm happy with the above default terrain, as rough as it might look. Next week I'll move on to setting in stone the rest of the defaults and see what cans of worms await to be squashed there.

1. Though this very same purposeful and focused unloading *also* highlighted just how much I'm carrying otherwise at all times - still am, yes, and looking back have been for longer than I have online references to point at. ↩

2. Those have to do mainly with that idiotic expectation of knowing everything upfront. ↩

3. This would be the one reading the xml and all that shit. ↩

4. Because it's a base material set on the default cell of the factory for terrain, the route is not exactly the very same as in other parts. Well, it wouldn't be all that fun otherwise, would it. ↩

Category: Coding, Eulora

Comments feed: RSS 2.0