Physically Based Rendering - Page 4

Physically Based Rendering

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

Moderators: Moderators, Moderators

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

Re: Physically Based Rendering

Post by ivand »

Hey Picasso!

It's actually my fault to not update this topic as frequently and thoroughly as I probably should (I genuinely thought no one cares about this stuff).

The original repository (the one you referenced) of the PBR is practically stale, these days I don't recommend anyone should use it. The original units PBR implementation was over-engineered in some parts and lacking in the others. Don't use it.

The map PBR is currently on pause too. It's a bit overcomplicated too, but has some interesting ideas implemented nonetheless. I might revisit it some day, although it's not very likely to happen without some blessing in the sky.

Consequentially the only alive and actually well working PBR implementation exists in BAR: https://github.com/beyond-all-reason/Be ... efault.lua Unlike the previous unit PBR attempts it works a lot better in the diverse map conditions and includes quite advanced stuff like the implementation of spherical harmonics for irradiance map convolution. That said BAR implementation is coupled with the rest of BAR a bit too tightly and secondly it uses old implementation and style of api_cus and shader. These two were improved quite a bit in TA Prime and Zero-K.

I guess what I'll need to do then is to distill units PBR implementation from BAR and the improvements from ZK/TAPrime and make a drop in ready-made units PBR package. Stay tuned.
1 x

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

Re: Physically Based Rendering

Post by PicassoCT »

So to get this working, one must switch to BAR Lua and Model+Texture standard..
This will be a lot of work.. BAR had a Texture atlas if i remember
0 x

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

Re: Physically Based Rendering

Post by ivand »

Whether it is atlas or per-unit texture does not matter. What matters is that every unit to be rendered as PBR has to have at least two textures: tex1 as usual, tex2 composed in a certain way that channels represent emissiveness, metalness and roughness.

Normal map is desirable, but not required; in case normal map is there your model has to have so-called tangents (this is usually the case).

That is it, there are no other dependencies.
0 x

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

Re: Physically Based Rendering

Post by PicassoCT »

The fallback to normal unit rendering, if those two textures are not there.. is still existing?
0 x

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

Re: Physically Based Rendering

Post by ivand »

Yes, the fallback for missing tex2 is possible. Trees, rocks and wrecks are rendered that way in BAR.

For that one will need to supply some static, empirical per model or per models values for emissiveness, roughness and metalicity.
0 x

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

Re: Physically Based Rendering

Post by PicassoCT »

Emissivness: (log(max(RGBA)-255)/255)*-1
Roughness: Computate a sampler, of difference of all neighbouring pixel values
Metallicity: Another Sampler, searching for characteristic metalliness reflection curves in a black&white lines - or just computate closeness to a phong shaded metall materialed texture bake..

Sorry, im out of glsl country since quite a while.. just best guesses
0 x

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

Re: Physically Based Rendering

Post by ivand »

E/R/M are artistic terms. You don't need to do any complicated math. Just put a grayscale intensity into each channel and combine them into RGB texture (tex2).

Also recap of what these terms mean https://youtu.be/PjGCtnEDDeU
0 x

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

Re: Physically Based Rendering

Post by PicassoCT »

ivand wrote:
20 Jan 2020, 18:56
E/R/M are artistic terms. You don't need to do any complicated math. Just put a grayscale intensity into each channel and combine them into RGB texture (tex2).

Also recap of what these terms mean https://youtu.be/PjGCtnEDDeU
Will check out the video.
For now will merge the channels i created as you said into a 2ndary texture and merge BARs stuff into my repo. Wish me luck, if i dont come back, avenge me.
0 x

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

Re: Physically Based Rendering

Post by ivand »

As said before you are not too likely to succeed on your own. The current code is to entangled with the rest of BAR. What you can do is indeed put together tex2 in the following way:

R(ed) - emissiveness intensity
G(reen) - metalness
B(lue) - roughness
A(alpha) - as usual, the fragment discard test

I'm gonna merge and clean up BAR and ZK assets. Not sure when, but sooner or later I'll do.
0 x

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

Re: Physically Based Rendering

Post by PicassoCT »

You underestimate my willingness to get barbarian..

Yep, its at least partially working.. it.. it lives.. <thunder claps in the distance>
And that after a afternoon of merge..

Lots of artefacts and not working stuff (distortion spheres are permanent after a explosion)


And yet.. i prefer this outcome.. thanks for pointing me to bar..


https://github.com/PicassoCT/MOSAIC/com ... 8e7e61c522
0 x

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

Re: Physically Based Rendering

Post by PicassoCT »

It was late that night - when the blue men group arrived to assasinate that poor guy.
Image
Attachments
screen00123.jpg
(225.94 KiB) Not downloaded yet
0 x

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

Re: Physically Based Rendering

Post by PicassoCT »

Merged the bar version with the dae config version into some frankenstein pbr abomination. It begs to kill me.. but not yet.

Image
First i inverted the teamcolour alpha..
Image
Which gave me some strange flickering abomination.. in correct colours..

Which rapidly began to turn dark..
While still flickering...

Image
https://www.youtube.com/watch?v=g1ED00ye5oU

You want it darker
We kill the flame

Now.. im not threatening anyone.. this is a free internet.. a very searchable internet, where every fail comes back to hunt you even by association.

:D

Let me transfer that in understandable concepts. If people google spring pbr implementation.. they are going to find us.. here.. shameless bitching for help..a suicide bomber of public fail..

This is what keeps great minds busy... the ants riding rodeo :D
Attachments
screen00143.jpg
(313.96 KiB) Not downloaded yet
screen00136.jpg
(267.72 KiB) Not downloaded yet
screen00134.jpg
(184.63 KiB) Not downloaded yet
2 x

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

Re: Physically Based Rendering

Post by PicassoCT »

Good news everyone. We have investigated.
The PBR is not working, but something else i drawing on top of springs default shaders - and thus we get it darker.
Also my game is full of bugs. Which is expected.
I added alot of stuff very fast.
1 x

Post Reply

Return to “Engine”