Eevee is quite cool

[Sirius]

Hey guys.

Have you tested Blender 2.8's Eevee rendering ? I've been using it recently (both for work and in my free time). It rocks ! Have a look, I did a quick import of Relto in it... (I didn't bother with some materials but I think it's still a good showcase). These images are pre-rendered for higher quality, but you can also render them in realtime. Well, almost - you have to let the view stabilize a few frames, because some effects are quite noisy when in movement. But still, really cool.

The material editor is pretty good too. You can easily blend textures together using UV maps, make realistic metallic materials, etc. The materials (and most of the rendering) will look the same in both Eevee and Cycles, which is an impressive feat considering the two render engines work differently.
(Okay, to be honest, coming from regular shader programming, there are a lot of things I don't like about the material editor. I've been pulling my hair out figuring out some of Eevee's limitations But well, Blender is geared towards artists, not programmers, so it makes sense for it to be somewhat dumbed down, and it's still much more flexible than the old "internal" renderer.)

Oh, and do some of you remember how alpha blending causes all sorts of issues with face sorting and rendering ? Well, Blender has a very cool alternative: alpha hashing. It's a bit like alpha clipping, but dithered. It solves most issues alpha blending has (can even handle partially transparent shadows to some extent), at the cost of pixel noise - which is then filtered by temporal anti-aliasing. It won't work on all types of objects (for instance it's too noisy for high-density grass), but works really well for Relto's pine and maple trees. I copied the idea to use in Unity, works really well

Anyway. Unfortunately, the material editor is now completely incompatible with Plasma's own material system, I have no idea how Korman will deal with that. Unless in the future MOUL can ditch the old material system and handle custom shaders in PRPs ? Not going to happen soon I guess. But it's still fun to experiment with.

[Aloys]

It rocks !

My GPU disagrees. But that must be because it's 6 years old.

Boy, seeing real time shadows makes Uru look so great.. Relto with its low rise lighting is a great show case for that. I'd love to see how Teledhan would look like. I imported in Unreal Engine years ago (back when it was still UDK), with Andy Legate, and it did look pretty spiffy. Seeing the Carvern with proper lighting should be quite a sight. Lighting has always been Uru's big weakness (although it made sense in 2003).

Unfortunately, the material editor is now completely incompatible with Plasma's own material system, I have no idea how Korman will deal with that.

I'll file that one under "doesn't look good".

Every couple months someone comes around saying how it would be totally awesome to port Uru to a new engine. And off course it'd be more trouble than it's worth, but still; those images show that just having a better lighting solution, without even changing the assets around (just updating some shaders) leads to a dramatic improvement... Sirius, do you have any idea how long it took you to make all this? (importing, plus updating the materials)

[Sirius]

My GPU disagrees. But that must be because it's 6 years old.

Eevee is intended to be "somewhat realtime". It's still not optimized for game-level realtime On my PC I get an average of 20-30 fps on Relto. (Oh, and here is a video of what it looks like in the viewport.)
Still, it's an incredible upgrade to Blender now you can preview a scene without doing an ultra slow render. It's also convenient when making content for Unity, as the two renderers are fairly similar now. Makes it easier to create a mesh and get it to look right on the first import.

Boy, seeing real time shadows makes Uru look so great.. Relto with its low rise lighting is a great show case for that.

Yeah, the shadows (along with volumetric lighting) really give it a nice touch. I didn't bother with normalmapping, but that would be even better.
These screenshots are still a bit too dark for my taste, but I can't modify the ambient lighting without increasing the sky's brightness... (yeah, ambient lighting is directly computed from the skybox !).

I'd love to see how Teledhan would look like. I imported in Unreal Engine years ago (back when it was still UDK), with Andy Legate, and it did look pretty spiffy.

I loved seeing those screenshots Andy posted back in the days. Yeah, Teledahn with realtime lighting would look really nifty due to the moving shadows... Now imagine Sharper's office with Unity's realtime GI, having the sun brighten the inside every once in a while would look really great.

Seeing the Carvern with proper lighting should be quite a sight.

I ported Ae'gura to Unity a while ago. Some areas looked pretty cool, but I had a lot of trouble correctly lightmapping such a big area. Outdoors and smaller areas are generally easier to get right without spending hours on it...

Every couple months someone comes around saying how it would be totally awesome to port Uru to a new engine. And off course it'd be more trouble than it's worth, but still; those images show that just having a better lighting solution, without even changing the assets around (just updating some shaders) leads to a dramatic improvement... Sirius, do you have any idea how long it took you to make all this? (importing, plus updating the materials)

Something like 10 hours ? Importing the scene was no big deal as ZLZ does it correctly. But since ZLZ uses Blender 2.79 and I'm reopening the file in Blender 2.8, all materials are emptied and must be redone from scratch (ideally, I would make a version of ZLZ which is compatible with 2.8... maybe later). Yeah, materials are definitely the bulk of the work.
I'm getting pretty good at it given how many times I did it on various engines A proper port could use reworked assets, though. Otherwise it looks like the early version of RMME before Cyan upgraded the models and textures - it's good but looks a bit odd.
But yeah, moving to another engine is a lot of trouble. Actually, now I'm realizing the visuals are actually the easy and fun part. Turns out the logic is the real PITA Why ? Because those Ages were designed with Plasma in mind, and there is no engine better to mimick Plasma features than Plasma itself. The architecture of other engines constantly fights against Plasma's own the more you try to get the two to work together. That's the general issue I'm currently facing with UPlasma...

[Aloys]

I ported Ae'gura to Unity a while ago. Some areas looked pretty cool, but I had a lot of trouble correctly lightmapping such a big area. Outdoors and smaller areas are generally easier to get right without spending hours on it...

Unity has a nasty performance problem when you bake lightmaps for large areas; even if the lightmaps themselves are small. For the game I'm currently working on we're using centimeter as the units in our source assests, but Unity's default unity is the meter. So basically ou main scene is 100x "too" large. And even when exporting our single main lightmap (1024x1024), it took stupid amounts of time to bake....

moving to another engine is a lot of trouble. Actually, now I'm realizing the visuals are actually the easy and fun part. Turns out the logic is the real PITA

Yep. Switching of engines for a game is never a good idea. Assets are easy enough to deal with. But for the gameplay, usually you have to start from scratch... Eventhough Uru's core gameplay might looks simple on the surface, there's actually a lot going on. And I'm not even talking about the online part. I don't know Plasma's source enough to pass informed judgement here, but from experience usually you can't really port a game's gameplay from an engine to another. You can only keep the assets, and then you recreate the rest from scratch. If you are really lucky some of the work can be automated, but not much.

[Sirius]

Forgot to reply earlier, might as well do it now...

Unity has a nasty performance problem when you bake lightmaps for large areas; even if the lightmaps themselves are small. For the game I'm currently working on we're using centimeter as the units in our source assests, but Unity's default unity is the meter. So basically ou main scene is 100x "too" large. And even when exporting our single main lightmap (1024x1024), it took stupid amounts of time to bake....

Yeah, that's one of the reasons I prefer to stick to meters... But if it makes you feel any better, using meters has its own problems. For instance, the shadow near plane for point and spot lights cannot be anything lower than 10 centimeters, which is a big issue when trying to light small areas like desktops (especially in VR)... It's also a pretty stupid limit, because the math could easily handle much lower distances without issues.
(Oh, and I digged up my old port of Ae'gura - looks really cool. I'll see if I can post a few pictures at some point...)

Yep. Switching of engines for a game is never a good idea. Assets are easy enough to deal with. But for the gameplay, usually you have to start from scratch... Eventhough Uru's core gameplay might looks simple on the surface, there's actually a lot going on. And I'm not even talking about the online part. I don't know Plasma's source enough to pass informed judgement here, but from experience usually you can't really port a game's gameplay from an engine to another. You can only keep the assets, and then you recreate the rest from scratch. If you are really lucky some of the work can be automated, but not much.

That's true. Currently, what I'm trying to do with UPlasma is to rely as much as possible on Unity's features. Well, unfortunately, Unity's tools often don't have the features that Plasma has, which means you can't automate asset conversion.
The best recent example I can find is trying to convert Plasma animations to Unity's format. Plasma supports quaternion rotations in animations. Unity doesn't - the editor "cheats" by resampling each frame into euler angles when building the game. Add issues like handling negative object scaling into the mix, and the only solution is to rewrite the animator from scratch - which defeats the purpose of switching to Unity in the first place...
So yeah, interesting but complex stuff. It's always about finding a middleground between two rather inadequate solutions.