Physically Based Rendering - Page 2

Physically Based Rendering

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 07 Oct 2018, 20:16

I've run a bunch of tests and indeed the bitangent value received from the engine:

Code: Select all

vec3 modelBitangent = gl_MultiTexCoord6.xyz;
vec3 worldBitangent = normalize(vec3(modelMatrix * vec4(modelBitangent, 0.0)));
and bitangent calculated as

Code: Select all

vec3 worldBitangent = normalize( cross(worldNormalN, worldTangent) );
have exactly the opposite sign.

The cross(N, T) produces correct normal mapping for me. At least on dae models.
I'm not sure what conclusions to draw from this result: does engine have them wrong?
1 x

MaDDoX
Posts: 49
Joined: 08 Jan 2006, 17:45

Re: Physically Based Rendering

Post by MaDDoX » 09 Oct 2018, 01:43

I can confirm the result of the commit I got is the exact same visual appearance as what I get in Substance or Sketchfab. Truly amazing, Unity for instance has some hard time getting the proper final look in a PBR-textured model. Animated gif from the final effect:

https://media.giphy.com/media/5bb7C2Dk7 ... /giphy.gif

For a more detailed look into the normals we should probably use some more neutral/plain object, maybe a checkerboard covered sphere or something like that.
3 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 09 Oct 2018, 19:05

I talked to @Floris the other day. Between the lines he raised his concerns on how "difficult" it is to set PBR and how many params are in the file.
I'd like to reassure everyone that most (90%) of the params are not really necessary most of the time and have sane implicit defaults.

What one really needs to define are maps (which texture unit represents which map), texture filenames and whether or not flip UV (depends on texture file type). This is more or less it. The rest is fine tuning. Moreover if all models have same texture mapping, some form of common template can easily be introduced to reduce amount per-file lines. All-in-all don't get scared away by https://github.com/lhog/Zero-K/blob/pbr ... fy.dae.lua Think of it as a "wiki" example.
1 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 12 Oct 2018, 15:32

Hi again!

A small update: I've added softer on-model shadows to the PBR shader.

Image

Not only they work on the solid geometry, but also on the parallax mapped surfaces:
Image
Image

Note these parallax soft-shadows are extremely cheap, but they are merely a rough estimation, so sometimes fragments, that should be shadowed, won't receive any shadow. Still looks quite nice.
10 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6063
Joined: 29 Apr 2005, 01:14

Re: Physically Based Rendering

Post by FLOZi » 12 Oct 2018, 18:11

Utterly stunning work.
4 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 12 Dec 2018, 21:00

Since PBR framework for unit models is completed, I have decided to distill it into separate Github repo.
Here is the new home:

Don't hesitate to find me on Github, here or in Discord if you have implementation questions or suggestions.
2 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 17 Dec 2018, 11:34

Huge props to TurBoss, who tried to integrate my PBR unit shader into his game, found a bunch of glitches, that happened when I did the rip off from ZK repo and stayed patient until each and every bug was shut down.

Looking forward to see this guys on spring soilImage

P.S. Now I'm quite a bit more confident that current code can be easily integrated into 3rd party games.

P.P.S. Make sure to grab latest (maintenance, not develop!!!) engine for PBR, as the ugly cubemap seams were defeated by almighty Kloot. https://springrts.com/mantis/view.php?id=6099

P.P.P.S Screenshot from Jauria ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Attachments
screen00089.jpg
(314.57 KiB) Not downloaded yet
3 x

User avatar
Anarchid
Posts: 1375
Joined: 30 Nov 2008, 04:31

Re: Physically Based Rendering

Post by Anarchid » 18 Dec 2018, 15:26

I know i've seen that parallax before, but that parallax is awesome. I hear rumors of a map shader; a working parallax would be great there (as opposed to the current lsd trip that vanilla spring has)
1 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 19 Dec 2018, 00:11

Anarchid wrote:
18 Dec 2018, 15:26
I know i've seen that parallax before, but that parallax is awesome. I hear rumors of a map shader; a working parallax would be great there (as opposed to the current lsd trip that vanilla spring has)
Vanilla spring parallax mapping is simple and fast, however it's less accurate than Parallax Occlusion Mapping, that I use in my shaders.

I indeed work on PBR map shader, however it's much more complicated with maps:
  • With models PBR, I had a sample model, a bunch of PBR textures and a picture of result image that I was supposed to get in the end.
  • I got lots of great advises from MaDDoX, who knew the best practices. This way we could prototype and test ideas quickly
  • Existing custom shaders were simple and didn't do much, so I just rewrote everything from scratch
None of the above is the case with maps: I don't have a map, PBR textures nor someone who can author them quickly enough. Not to mention that I haven't found someone who would know how things are supposed to work from artist/technical artist point of view. Also the existing standard map shader covers a lot of rendering, so existing code cannot be just easily reworked in the way I like.

With lack of better ideas my current approach is just to augment three detail levels (map-wide, details, splats) with PBR textures and base rendering on the existing standard diffuse textures (per detail level) and these additional PBR textures. Whether it makes any sense remains to be seen.

That said, I welcome any contribution from the community side: map, PBR textures, ideas, advices, etc.

P.S. My parallax will certainly make it into the shader :lol:
2 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 21 Dec 2018, 23:28

Playing around with terrain types: https://shaderfrog.com/app/view/2818
1 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10008
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 22 Dec 2018, 00:59

Unlimited detail..

yes, its spectacular. I plan to do something with it over the xmas holidays.

Wish it could produce some fugly aproximation with default textures.
0 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 05 Jan 2019, 13:19

WIP. Map PBR shader:
Image
screen00115.png
(3.41 MiB) Not downloaded yet
5 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10008
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 05 Jan 2019, 16:40

Holy Moly
1 x

User avatar
azaremoth
Cursed Developer
Posts: 537
Joined: 17 Feb 2005, 22:05

Re: Physically Based Rendering

Post by azaremoth » 06 Jan 2019, 19:39

Wow - that looks impressive!
1 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 07 Jan 2019, 12:38

Added Ambient Occlusion, NdotL shadows and Shadow Mapping.
Also enabled materials' normal mapping just to showcase how they look.

Image

Wanted to point out that the current branch of Map PBR code lives here:
https://github.com/lhog/spring-map-pbr/tree/PBRv2

Also I'm looking for a brave soul who would put together a map using the Map PBR as an artist.

If anything this would help greatly to offload artist work from me and clean out the bugs (which must be there in abundance).

P.S. Small in game video (note the surface here is configured to be very glossy because I was troubleshooting reflections). https://drive.google.com/file/d/1yGK6Os ... ZXr_t/view
Attachments
screen00120.png
(3.89 MiB) Not downloaded yet
3 x

User avatar
ivand
Posts: 109
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 10 Jan 2019, 07:20

At this moment I'm working on materials blending.

The industry standard for this is more or less what's called height based blending. It's the blending mode, where two or more materials are mixed not only according to their distribution weight (which alone would give a very flat featureless picture), but with respect to the height/displacement provided along with texture materials as well. Here's the good explanation of what is materials blending and what each blending mode looks like (I'm aiming to replicate the look of the last picture):
http://www.gamasutra.com/blogs/AndreyMi ... atting.php

As always couple of pictures of what's been achieved so far:

Here you can see the gravel and ice material are mixed together linearly from left to right. The most interesting part is what happens in the middle, where both weight (changing from left to right) and height (which is the property of each material) play nicely together.
Image

And here's the zoomed in fragment, it's placed around the middle of the map, as described above. On the left side the gravel is almost "pure" with very little perceived amount of inclusion. In the middle, we can see ice patches occupy cracks between individual gravel stones. On the right side, ice has almost replaced the gravel patches as the latter are barely visible.
Image

What pictures above lack is the sense of volume, which in case of spring can be only emulated by use of the parallax occlusion mapping (POM).

Unfortunately with such diverse set of materials and the way they are currently described in Lua, the implementation of POM looks rather complicated, so it remains my stretch target. Practically this means, that I only do it in case there is some real interest/demand from the artists (see my previous post).

In the mean time you can entertain yourself by looking how materials blending might work with POM here: https://shaderfrog.com/app/view/2818
Attachments
screen00139.png
(4.25 MiB) Not downloaded yet
screen00138.png
(3.59 MiB) Not downloaded yet
2 x

Post Reply

Return to “Engine”