Idea: Play Plasma from another engine

General debates and discussion about the Guild of Writers and Age creation

Idea: Play Plasma from another engine

Postby Sirius » Sun Oct 01, 2017 5:36 am

Hey folks.

I've been having this idea for the past few days, and the more I think about it, the better it sounds to me.
However even I don't know how feasible it is.
Normally I'd just keep the idea for myself, and try to come up with a proof-of-concept of an actual working program before telling you about it. But I don't know how much time creating that proof-of-concept would require. And... what good is an idea if you don't share it ?

So I figured I might as well write about it now, since I'm curious about what you people think about it. For now, this is still highly theoretical.

------

So. As you know, Plasma is outdated, and I fear it's driving people away from Uru for various reasons - bad graphics, too hard to create Ages on it, etc.
We have good coders, but they are too few to be able to upgrade Plasma to today's standards. Also, Plasma doesn't have a dedicated editor for building Age like most modern engines do, which explains why it's so hard to create an Age.

The solution would be switching to another game engine. The problem is, no one really wants it: only Plasma can read Cyan's Ages, our tools and tutorials are designed for Plasma, and Plasma offers working multiplayer without the need for builders to setup anything. Plasma is convenient.

We simply can't switch to another engine, because that means starting from scratch with zero Age to explore and rethinking the whole Age building workflow and pipeline. Then teach that workflow to Age builders.

I've been thinking about it recently, and thought of an alternative: making the other engine compatible with Plasma and its tools.
This alternative engine would be able to read Plasma's PRPs and replicate Plasma behavior, similarly to how "clients" work for MOULa (the only difference is this client wouldn't be able to connect to MOULa-based Shards, since it would use the new engine's native networking).
On the other hand, it would still be capable of loading levels designed with its own editor - thus enabling builders to create Ages with better graphics or exotic gameplay, without Plasma's limitations. Among the other advantages are VR support for all existing Ages, builtin UruAgeManager, portability to Linux and Mac (and probably even cell phones), etc.

------

Now, the question is: is it doable ?
Technically, yes. Modern engines are very flexible, and we have both HSPlasma and Plasma's own source code.
However this means a lot of work - not the kind of thing you would do unless you had VERY good reasons to think it's Uru's future.

Once I can get my hands on a 64 bit version of HSPlasma and it's python bindings, I'm going to try to get Unity to load Uru environments straight from PRPs, and see how playable I can make it. Just for the sake of it. It's basically rebuilding the PyPRP importer into Unity, which is similar to what I did recently. Should be fun.

In the mean time I'd like to hear about what you people think about this idea. At least on a theoretical level, to see if it's worth it.
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Idea: Play Plasma from another engine

Postby Deledrius » Tue Oct 03, 2017 1:07 am

I think this is probably the least-bad of the Uru-On-Other-Engines idea, which has its own share of baggage and problems. I mean, completely rebuilding the game from scratch in another engine would be the absolute best, but one may as well wish for world peace. Doing a smart conversion of the assets to be compatible with a mildly-customized modern game engine would be an interesting experiment, and if successful probably a fun way to play (and even slowly phase in new content made for that engine).
User avatar
Deledrius
Gehn Shard Admin
 
Posts: 1014
Joined: Mon Oct 01, 2007 1:21 pm

Re: Idea: Play Plasma from another engine

Postby Sirius » Tue Oct 03, 2017 10:05 am

Deledrius wrote:I mean, completely rebuilding the game from scratch in another engine would be the absolute best, but one may as well wish for world peace.

Yeah, switching engines is not that simple, due to the sheer amount of Ages only available as PRPs and still under some form of copyright. That's one of the reasons various project like AndyLegate's never really picked up I guess. Having another engine mimic Plasma is not a whole lot simpler, but it's worth a shot to me.
I got the idea from someone who made an environment viewer for Dark Souls archive files using Unity. The whole unpacking and reading of assets was done in memory :shock: Then I thought about how ResidualVM emulated Myst3's behavior, and thought it might work for Plasma too.
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Idea: Play Plasma from another engine

Postby Sirius » Wed Oct 04, 2017 8:57 am

Well, Deledrius was kind enough to send me his own build of HSPlasma 64 bits, so I tinkered a bit with it.

So far so good... The code is really rushed but it's able to load Ahnonay's cathedral inside Unity, loaded directly from Uru's install location:
Show Spoiler

Looks good, but that was the easiest part to be honest. Next step will be cleaning up then importing multilayer materials - my favorite nemesis.
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Idea: Play Plasma from another engine

Postby Sirius » Thu Nov 09, 2017 1:25 am

So, update on this project.

It works to some extend. I can link to a few Ages and some areas are identical to their Plasma counterpart, down to the pixel. I can even walk around freely since the collision is imported too.

However, I'm still using the Python bindings of HSPlasma. And there is the massive drawback: "opening" Ages in Unity is s---l---ooo---ww... I guess there is too much marshalling from C++ to Python to C# to C++ and then to the GPU. The culprit being of course the list of vertices for meshes and the pixel array for texture.
It takes 1 to 3 minutes to import an Age into Unity, which is way too much when you're only testing one line of code. And then I have to restart Unity anyway because the Python VM I'm using crashes Unity when exiting play mode.

Anyway... And there are other problems, which are small but numerous. Most of them could be solved by using C++, but unmanaged languages are a real pain to work with. I don't have time currently to tinker with messy C++ anyway.

Show Spoiler
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Idea: Play Plasma from another engine

Postby dendwaler » Thu Nov 09, 2017 5:00 am

Wow, that is really great Sirius, what you have achieved so far.
I am i right that you can see inside Unity the wrong perspectives from Plasma, or is only a 16:9 vs 4:3 window issue.
Those wonderfull Worlds are called " Ages" , because that is what it takes to build one.

Image

Watch my latest Video Or even better..... watch the Cathedral's Complete Walkthrough made by Suleika!
User avatar
dendwaler
 
Posts: 863
Joined: Mon Jun 22, 2009 10:49 am
Location: Nederland

Re: Idea: Play Plasma from another engine

Postby Sirius » Thu Nov 09, 2017 6:32 am

The Unity perspective is fine. These images are neither 16:9 nor 4:3 because the editor was in windowed mode, which might be unsettling. That, or maybe the images are too big to be displayed in your browser and are cropped on the right (in which case ctrl + scroll wheel will allow you to zoom out).
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Idea: Play Plasma from another engine

Postby Deledrius » Thu Nov 09, 2017 11:27 am

Wow, impressive! Any idea why the dynamic objects aren't being lit correctly by the engine? Also, I wonder if you can convert those waveset surfaces to a native water shader...

Sirius wrote:However, I'm still using the Python bindings of HSPlasma. And there is the massive drawback: "opening" Ages in Unity is s---l---ooo---ww... I guess there is too much marshalling from C++ to Python to C# to C++ and then to the GPU. The culprit being of course the list of vertices for meshes and the pixel array for texture.

The library bindings have not really been written or optimized with live usage in mind, so this doesn't really surprise me (though I hadn't even really thought about this aspect). It's too bad. It might be possible to do something about the meshes at least, since that's a specific bottleneck. I guess there are a lot of layers for it to move through. There was a C# library at some point, but I don't think it was nearly as complete.
User avatar
Deledrius
Gehn Shard Admin
 
Posts: 1014
Joined: Mon Oct 01, 2007 1:21 pm

Re: Idea: Play Plasma from another engine

Postby Sirius » Thu Nov 09, 2017 4:19 pm

Deledrius wrote:Wow, impressive! Any idea why the dynamic objects aren't being lit correctly by the engine?

Yup, simply because they aren't :lol: I didn't have the time to write lit shaders.
Because I don't have runtime shader compilation available from the managed API, I have to write all shaders in advance. Problem is, every time Plasma exposes a "flag" in its layers, I have to write a new variant of the shader (since shaders don't support boolean variables and have limited support for if-else branching). As you can guess this grows up VERY quickly.
So far, I have 20 or so shaders just because of fog, additive blending, zoffset and alpha testing. I was going to add lighting and cubemaps, but decided it would be too much bother. Especially once I realized cubemapping meant reatlas the Plasma cubemaps to Unity's format all in Python. While Python's lists are really fun to work with, they are extremely inefficient for pixel arrays.

Deledrius wrote:Also, I wonder if you can convert those waveset surfaces to a native water shader...

Oh, wavesets are Direct3D shaders already, so it's definitely possible. I don't understand the math it uses, but I know that from a shader viewpoint it's only displacement mapping, combined with cubemapping and alpha blending - it's pretty standard.

Deledrius wrote:The library bindings have not really been written or optimized with live usage in mind

The Python bindings of HSPlasma are less than half of the overhead really. I'm calling the C# Unity API every two or three instructions, that alone is a very bad idea.

Sigh... I guess the ideal solution is writing a C++/CLI library that taps into both HSPlasma and Unity's shader compiler. I might try that on a very lucky day. But it always hurts my pride when Visual Studio stubbornly attempts to compile a library with my program instead of link against it - ROTF.
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Idea: Play Plasma from another engine

Postby Sirius » Sun Nov 19, 2017 6:05 am

Smallish update on this project.

I put the Python importer aside for now (since it's too slow to be useful), and instead went the "usual" way: manually import the Age in Blender, then export it to Unity and redo materials by hand. The goal was again to get the original Plasma look, without visual upgrades.
The result is pretty good.
Show Spoiler

Still no dynamically lit objects, and I replaced the wavesets with something more basic for now. But everything else accurately matches the Plasma counterpart - lightmaps, cubemaps, even animated water cascades and water ripples.

Aaaand then I exported the whole thing to my cell phone, to play it in VR using Daydream (like I did a while ago with Direbo). Couldn't resist :D
And once again: it works and is playable :shock: I can walk through the whole neighborhood.
There is a bit of lag, but it doesn't cause any motion sickness since the view remains stable no matter what (thanks to VR async timewarp wizardry).
This is pretty cool. Usually VR is about having a big bulky headset wired to a big PC with a complex setup of sensors. Daydream requires only a compatible phone and the headset itself is much more comfortable. Much easier to carry around too.
User avatar
Sirius
 
Posts: 957
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 4 guests