WebGL client + SSL support

[ememisya]

Meridian 59 should be ported to JavaScript using WebGL browser features, with the added bonus of websocket native SSL support. Have a look at https://github.com/Triang3l/WebQuake , this would push the modern browser capabilities to its max, and make it easier for new users to register as they won't need to download and run anything to start playing. (Not to mention provide an excuse for the crappy graphics in this day and age, hey it's the best a browser can do 👍)

[uusmatt]

Hi,

I did a little work last year and showed you could render the existing map structure in webGL (using three.js), I actually put the test code in a Git repository. The main issue is the huge amount of work that would need doing to the server code to support web sockets, and i don't know c / c++ well enough to do this work myself however (and don't have the time either!).

The issues the JavaScript has mapping textures in the posts below could be fixed, it was only ever a proof of concept really. I even went as far as to test loading times, hosting it on a raspberry Pi via my broadband at home and loading maps and got them to load fairly well. It really needs someone else to get involved and sort the server side and someone with more time than me to develop the client side though as with my Work commitments currently, i just don't get any time to get near a project like this!

There is a Git repository linked with the code in in the forum post below and i'm more than happy for someone to take this and take it further.

Two limitations you will have is i estimate to run a full client in Chrome is going to cause the browser to consume something well over 500mb+ of ram and i have no idea how that would perform or how stable it would be (It currently consumes around 300mb ish and is ok, but there are memory leaks in Webgl in Chrome and Three.js and most likely in my code as well...). I got around loading times by pre-loading all the textures which works well, but consumes vast amounts of ram, and more if higher res textures were to be used.

Of the various minor rendering / texture mapping issues (although the geometry is basically working from memory) one that is a WebGL / three.js limitation is the transparent textures not layering themselves properly. In Marion for example, look at a forest wall, through a fence and one texture ends up going white and odd. In order to overcome this you would have to calculate directly in JavaScript the layering correctly which is a complex bit of code (if you could even do it fast enough).

What I started to play with but struggled with was trying to write some sort of translation layer that takes a web socket connection, and relay's it to an old school socket connection to the existing server which would definitely be do-able (although I never really got this working although I never spent much time on it), but in reality the lag introduced into this may not be workable if the server is handling a mix of Web / desktop clients. The Desktop clients would always have much less lag. It would probably be better to make the existing server support Web-sockets but that is a huge task.

Overall, it's something that's definitely do-able, and i did do a fair bit of research into it but it's just such a big project, you'd almost be better off getting a team together and re-writing the whole server again from scratch to handle this, but use the existing assets, and build it so it is Meridian, but the whole UI / server structure is built around the web. The UI would handle Mobile clients and desktop (and actually my proof of concept does work ok ish on a decent phone).

http://openmeridian.org/forums/index.php/topic,679.0.html

Matt

[ememisya]

Relevant issue: cyberjunk/meridian59-dotnet#279

I will go ahead and track it there, it makes more sense to port the Ogre client powered by emscripten via WebAssembly given the engine has already been ported.