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.

Moderator: Moderators

ivand
Posts: 310
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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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
ivand
Posts: 310
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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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?
ivand
Posts: 310
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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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
ivand
Posts: 310
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
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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.
ivand
Posts: 310
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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
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.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Physically Based Rendering

Post by Master-Athmos »

I have a question regarding the framework / how the engine handles unit shaders in general:
What is the draw order when applying shaders on units with regard to the map rendering?

In other words, is it possible to e.g. have an elevator shaft that goes deep down which the fragment shader draws after the map was rendered, so the shaft remains visible with the map's appearance itself being overwritten visually? And on top of that when I would create a platform that goes down that shaft as part of the elevator with a seperate PBR shaded unit attached to this platform, would there be any kind of concurrency between the shader applied to the elevator and the shader applied to the unit (i.e. something in the sense of Z-fighting issues)?
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Physically Based Rendering

Post by Beherith »

Map first always :/
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

I need some visual sketch as a support for this request.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Physically Based Rendering

Post by Master-Athmos »

Like this?

EDIT:
In terms of a feature request it probably would make sense to get a Lua interface to the terrain chunk rendering. As the terrain is divided into lots of tiny chunks what's missing is a way to identify the respective chunk(s) under a unit via its position on the map followed by the option to turn the/these chunk(s) invisible. Someone who is more keen in map development than me would have to answer though if these chunks have a general elmo size or if their dimension can vastly differ depending on the map creation process (which would be a problem as turning some chunks invisible should work on any map and not just on certain maps where the map chunk size fits nicely to the unit model)...
Elevator_Shaft.png
(431.46 KiB) Not downloaded yet
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

Speaks thousand words. But it's a tricky thing to do.
While you can render certain class of units with depth test disabled it's not going to help much here. I don't see an easy way right now, but will thing about it in coming days.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Physically Based Rendering

Post by Master-Athmos »

Yes - even when you could alter the draw order in a way that the unit is drawn after the map this of course then only would work in the standard top-down view i.e. when using a free camera which looks around at low altitude the unit easily could be drawn through mountains which should block the view depending on how the culling works...

That's why this wasn't really a feature request in the first place but I just wondered if e.g. the unit shaders are drawn last and you could enforce the desired behavior this way. In the end for this effect to really be possible you'd have to turn certain terrain chunks invisible and as that wasn't planned to be possible out of the box (at least to my knowledge) I guess enabling this would be a lot of work. As this would just be nice to have I wouldn't give this a high priority though - I just was curious if shaders would make such an effect possible...
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Physically Based Rendering

Post by Master-Athmos »

And another possibly "stupid" question: Are flat polygons being rendered double-sided? So when for example doing the blades of a windmill as just one flat polygon, would both sides of the blade be rendered just fine or will this lead to problems as the face has just one normal?
Post Reply

Return to “Engine”