Eulora's Default Island: Sand, Grass, Rocks and Nothing Else

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 code1 and the resulting discussion sets a clearer way to move further:

mircea_popescu: anyways, to complete the frame here : 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 reasons2, 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 either3 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 thing4 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. 

3 Responses to “Eulora's Default Island: Sand, Grass, Rocks and Nothing Else”

  1. Surprisingly enough - or maybe not -

    Rather, not.

    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.

    Try as I might, I don't manage to substantiate the "less than" clause. They seem to me exactly equally ideal. Am I missing something ?!

    the result manages to actually look -perhaps unexpectedly-

    No, honestly, this is exactly what I was expecting to hear.

    At this stage I'm not even really sure that this side of things is really much concern for S.MG and the server

    Indeed not.

    For now I'm happy with the above default terrain, as rough as it might look.

    I don't see the problems. Arch-sufficient.

    just how much I'm carrying otherwise at all times

    The republic as self-improvement, yes, this is what it is.

  2. Diana Coman says:

    The answer and discussion, from #eulora logs:

    diana_coman: glad to hear it; re the ideals there, I'd have preferred to have *no* files needed for defaults at all, tbh
    diana_coman: but that's way too far a step for legacy client & cs.
    mircea_popescu: why not ?
    mircea_popescu: i mean, what sense does it make ?
    diana_coman: it makes for fewer possibilities for defaults to fail; I like my defaults unfailing, lolz.
    mircea_popescu: yes, but think logically, how could there be a display default file-less ?
    mircea_popescu: it's like default computer generated voice without some kinda saved sound parameters somewhere.
    diana_coman: uat? simple: it's anyway a bloody list of vertices and triangles etc
    diana_coman: wtf
    diana_coman: it can be in the code as it can be in the file on disk
    mircea_popescu: humans are peculiar, to make the display work you gotta somewhere inform the machine of some of those peculiarities no ?
    mircea_popescu: but it can't be in the "code" unless let a = 1,0,0,0,0,1,0 counts as code to you
    diana_coman: well, it counts as code to client, what can I tell you
    diana_coman: the point there was re "won't fail no matter what", not re "let it be actual code" since this last part is not code
    mircea_popescu: imo it's better to have the few piles of arbitrary parameters needed to bridge the biogap in dedicated raster files than in "code" which is just adnotated... raster files.
    diana_coman: and for that matter even code: let it have the function to generate the bloody vertices
    mircea_popescu: i do not believe this'd have been an improvement.
    mircea_popescu: you expect files implicitly fail somehow ?
    diana_coman: but as above, why "too far a step for cs/client": because can't define the terrain procedurally directly in cs atm
    mircea_popescu: diana_coman, and when you can, you'll want to also define the gui procedurally ?
    diana_coman: no, that I want gone :D
    mircea_popescu: so how is someone to switch tools ?
    diana_coman: shortcut keys !
    mircea_popescu: and how do they know they did it or just misclucked ?
    diana_coman: what do you mean? if tool is switched, they did it; if not, they didn't; or what ?
    mircea_popescu: how do they SEE they did, if no gui.
    diana_coman: ah, you meant the whole display rather than just the interaction part? (didn't quite make sense since terrain part of display); at any rate, if cli, then it *says* ack.
    mircea_popescu: you're a software radical.
    diana_coman: getting to the...root of it!
    mircea_popescu: let's put it this way : while 0 files is indeed a recognizable ideal, which in some circumstances (such as, it being available) might even be better than current situation ; nevertheless 1 is exactly equal to 11.
    diana_coman: I can see that; and as seen, I can work fine with it, as such.
    mircea_popescu: now in other practical concerns, does the vierwport change still work ?
    mircea_popescu: ie, switch from camera view to first person ?
    diana_coman: the camera modes are still there and working, yes; when I got to make the camera working, I got this back in as well.
    mircea_popescu: cool.
    mircea_popescu: i really don't see problems here.
    mircea_popescu: i honestly don't even see the problem with ditching the "gui" and using cli.
    diana_coman: cool, I'll move next week to go through the rest and make defaults and I'll see there; the cal3d might be the most intricate as far as I can currently see, but I'll know exactly when I get to it.
    diana_coman: well, iirc the idea was to avoid being pegged as "cli only" or other such nonsense; but at any rate, my idea was that once 2.0 is out there, since things are more separated *anyway*, it won't be all that big deal to make myself a cli client out of it too, pretty much one cut and done.

  3. [...] set Eulora's soil in stone (and grass and sand), I turned my attention this week to the waters that should naturally [...]

Leave a Reply to Diana Coman