PBR - Physics Based Rendering

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
Pherim
Posts: 140
Joined: 27 Aug 2014, 15:37

Re: PBR - Physics Based Rendering

Post by Pherim » 17 Feb 2017, 18:49

MiroslavXO wrote:I use latest .fbx that ships with Maya 2017. So I'm using StingrayPBS material and that's probably why you can't open in Blender.
But here is the axe mesh as .obj and all the maps I have created.

http://www.filedropper.com/axenew


So in Blender or any other similar application it should look something like this when you apply material and maps.
There is no .mtl file, so it does not import the texture, but I added it back after importing... here it is with just the normal map:
screenshot001.jpg
The normal map's red channel had to be inverted to make it work correctly in OpenMW.
The size was already quite good (at least for a one-handed weapon), so I did not change it, although I guess it could be a bit bigger. The other textures I could not really use, you'd have to make a specular map instead of the metallic and roughness ones.

Here it is, ready for use with OpenMW:
axe.zip
(1.89 MiB) Downloaded 36 times
It will replace the steel war axe. If OpenMW is configured to use normal maps and specular maps as described here, you can just place the specular map in the textures folder (preferably as a .dds file, but Morrowind also supports .tga and .bmp, and so does OpenMW, I believe; don't know about .png, though) as axe_small_spec.dds, and it will be used automatically, just like the normal map.

Ignis
Posts: 8
Joined: 01 Nov 2016, 20:05

Re: PBR - Physics Based Rendering

Post by Ignis » 17 Feb 2017, 19:03

Capostrophic wrote: It has many limitations.
Any render model has own limitations. Also, I would like to remind you, that PBR isn't a render system. It's a set of ideas. And each render engine has own way to implement those ideas. And those possibilities, which were made in MGE XE-PBR already can be made with current OpenMW render too.
Chris wrote: PBR is intended to better model how light actually works, so there's less guesswork involved in generating the values, and it reacts appropriately to changing environments. You can make a screenshot using the old standard pipeline look just as good as a similar screenshot that uses PBR. But move around the objects and change the lighting, and PBR will retain appropriate lighting behavior and still look accurate, while the non-PBR results will need more tweaking to make it look right again.
Nope. It looks right with different environments, I've checked it. But your arguments has some merit: proper artist really can reach the same result with old pipeline too ;)
MiroslavXO wrote: I guess it's personal preference, but I really think you are wrong here, especially for the first two sentences.
It gives you super and easy workflow, plus accuracy.
Mhm... As I see at your art-station profile, this axe nearly your fist try... So when you are more experienced, you will understand that for now PBR is really overrated technique. But it also has a really good PR company ;) And yes, R/G textures can be easily converted to M/R with such soft as Substance Painter, for example.

P.S.The only problem that has this render now is organic surfaces (I don't talk about dynamic shades, but when they are re-implemented, too hard shades on such surfaces as human skin and flower petals will become more then obvious too). So it would be wonderful if developers make something with it. But implementing of PBR-shadering would be a good PR :)

User avatar
MiroslavXO
Posts: 97
Joined: 13 Feb 2016, 01:07

Re: PBR - Physics Based Rendering

Post by MiroslavXO » 17 Feb 2017, 19:36

Yeah, I did not include .mlt thinking that you will not be able to open it.
Ehehe I see my UV seams, but it works, even if it looks flat without other maps, it's nice to see it in the game.

http://imgur.com/ZsSoK21

What I rly wanna try to do is concept of stalhrim dagger, that would be nice.

@Ignis

It just works. :D

User avatar
Pherim
Posts: 140
Joined: 27 Aug 2014, 15:37

Re: PBR - Physics Based Rendering

Post by Pherim » 17 Feb 2017, 19:49

MiroslavXO wrote:Yeah, I did not include .mlt thinking that you will not be able to open it.
It is needed to load the textures... anyway, if you need any help with getting meshes into the game, just ask.

Chris
Posts: 1499
Joined: 04 Sep 2011, 08:33

Re: PBR - Physics Based Rendering

Post by Chris » 18 Feb 2017, 01:02

Ignis wrote:It looks right with different environments, I've checked it.
"Looks right" and "is right" are two separate things. Especially without some reference image, something can "look right" because it's close enough to what your mind thinks should happen. But when shown a more physically accurate result you can realize it's off. Similar things happened with gamma-correct lighting, sub-surface scattering, etc.. people would say how realistic graphics were despite how wrong the calculations were, and then correcting it by adding those features improves the overall visual quality and makes it "more realistic".

User avatar
MiroslavXO
Posts: 97
Joined: 13 Feb 2016, 01:07

Re: PBR - Physics Based Rendering

Post by MiroslavXO » 26 Feb 2017, 00:18

Pherim wrote:It is needed to load the textures... anyway, if you need any help with getting meshes into the game, just ask.
Do you know how to import trees and grass if I give you mesh and textures?
Something like this, doing some tests.

http://i.imgur.com/JLFIxHq.png
http://i.imgur.com/vppKQmm.png

User avatar
Pherim
Posts: 140
Joined: 27 Aug 2014, 15:37

Re: PBR - Physics Based Rendering

Post by Pherim » 26 Feb 2017, 10:04

MiroslavXO wrote:
Pherim wrote:It is needed to load the textures... anyway, if you need any help with getting meshes into the game, just ask.
Do you know how to import trees and grass if I give you mesh and textures?
Something like this, doing some tests.

http://i.imgur.com/JLFIxHq.png
http://i.imgur.com/vppKQmm.png
Meshes are meshes, and textures are textures, so yes, I could do it. As long as it doesn't have to be animated, I don't see any problems (I can do some animation, though, but it would take much longer ;) ). But my first mods were plant meshes and textures, so I have some experience. :D

User avatar
halbe
Posts: 58
Joined: 14 Feb 2017, 03:55

Re: PBR - Physics Based Rendering

Post by halbe » 07 Mar 2017, 22:47

Pherim wrote:
MiroslavXO wrote:
Pherim wrote:It is needed to load the textures... anyway, if you need any help with getting meshes into the game, just ask.
Do you know how to import trees and grass if I give you mesh and textures?
Something like this, doing some tests.

http://i.imgur.com/JLFIxHq.png
http://i.imgur.com/vppKQmm.png
Meshes are meshes, and textures are textures, so yes, I could do it. As long as it doesn't have to be animated, I don't see any problems (I can do some animation, though, but it would take much longer ;) ). But my first mods were plant meshes and textures, so I have some experience. :D
Would you recommend sticking to .nif files for now or .osg? And what about textures?
If anyone's an expert on this sort of thing it'd be you.

VoidHymn
Posts: 3
Joined: 24 Sep 2017, 19:54

Re: PBR - Physics Based Rendering

Post by VoidHymn » 25 Sep 2017, 23:44

I'm aware I'm bumping an old-ish thread here, but this seemed like the most relevant place to post a couple of thoughts I had today.

Seeing as PBR seems to be something a few people around here are interested in having as a post-1.0 feature for the engine, would it be worth looking at the code for Godot 3's new physically based renderer? Godot 3 is still in alpha, but the renderer is more-or-less feature complete and does everything one could want in a physically based setup (linear-space lighting, Cook-Torrance BRDF, ubershader-esque material system, reflection probes, cascaded shadowmapping... heck there's even fast voxel cone-traced GI in there) with the bonus of running on OpenGL 3.3, and using a forward, rather than deferred shading setup. The code is all MIT-licensed, too.

Of course I wouldn't be so naive as to suggest that you could just dump Godot's rendering code on top of OSG - the way it's set up is by the lead developer's own admission pretty different from a lot of other game engines, but I'm going to take a guess that there might be at least some code there that would be useful in working out how to implement this stuff in OpenMW? It could potentially be less work than figuring out how to do a from-scratch implementation.

If anybody's interested, the project's lead recently posted an overview of the renderer's design here: https://godotengine.org/article/godot-3 ... -explained

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests