I admit it took me some time to figure out what the hell PBR (Physically-Based Rendering) textures are.
When working in Blender, it takes quite a lot of manipulations to set up the nodes for albedo, normal, specular, ambiant occlusion, metallic and whatnot maps and it wasn’t obvious to understand that all of that is in fact completely useless since modern game engines can do all the job!

So, how does it work?
Let’s say I need to build some walls. I’ll start from photographs I took in one of the many medieval castles around my home place.

Then, in Photoshop, I’ll make the picture seamless, which means I can replicate any number of those images next to each other without seeing any seam between them.

Then comes into play Materialize, a – free! – software to make PBR textures. All I have to do is supply the seamless picture and from there let the software create all the maps I need according to the – numerous – options.
And here you go!

The PBR texture looks like a 3D thing while in fact it’s only a set of 2D images that the game engine uses to give the illusion of it being in 3D. That’s quite some maps, usually 5, and they are pretty heavy, reason why modern games take gigabytes on disk, but the engine can then give the illusion it’s displaying a very complex 3D object while in fact it’s only a few polygons.

For example, if I wanted to create a well, the above PBR texture would perfectly fit on a 32 polygons cylinder model and look like a multi thousands one.

It’s magic!

The more I use it, the more I like it.
The engine is quite complicated but not in a cumbersome way, rather in an overwhelming way: nothing is difficult but there is – a very – lot to learn.

At the moment, I’m sticking with blueprints, the visual programming approach and not going into C++ yet – thank you Microsoft for the free Visual Studio license I was just granted, I didn’t expect that.
Visual programming is something I’ve been interested in since the ’90s really, with a revolutionary Macinstosh programing language which, unfortunately, never took off and which I can’t remember the name of either. Displaying logic blocks visually is a very nice prototyping tool and good practice. So, until I have very lengthy code to write, like AI, I won’t be bothering with C++
It is worth noting that in many instances fragments of the code I wrote over the years for NWN is reusable under UE4.

I can pretty much link all the pieces together now, but not confidently: I still need crutches to walk and can’t even think about running!

Dominique has started learning Blender, she seems to enjoy it – fingers crossed ! – and could be one of the assets I desperately need to build the elements of the upcoming universe.

TL;DR
Probability of ever seeing Althea 3 on Unreal Engine 4 raised from 20 to 50%
Expected development time decreased from 5 to 4 years.
Both can only improve.

All translation is done! I’m going to publish today the first English only module ever.
There’s only one dungeon which will remain in French, the PMT, for historical reasons and it would lose all its sense translated anyway.

I plan on revamping craftskills soon. Soon meaning after I feel confident enough using Unreal Engine. Which is coming nicely, but it’s a hell of a beast, when I’ll have succeeded in mastering that engine, which supposes some mastery degree in Blender, Substance Painter, Photoshop, Fuse, Mizamo and various other pieces of software, I’ll be a the same point as the guy beginning to use the NWN Aurora toolset. Excepted I’ll have control over absolutely everything in the slightest details.

The Althea server has been removed from the servers list and is reachable through direct connect. It will get back on the server list when I’m done with crafting or the console version gets published, or NWN shaders get revamped or the Unreal version becomes playable, whichever first.