GLSL PBR Shader for viewport

Hi
Is there any known reason why I cannot install it on Blender 2.78?

Itā€™s not something you install in Blender, itā€™s a whole separate branch of Blenderā€™s code.

just support blenderā€¦ developers are always looking for great things like that and ton tooā€¦ I truely believe. I mean Im sure or hope they do.. :D but Im sure they do. PBR with clement`s work is in the pipeline. Just support blender. It is a great community.

I have a problem with the windows versioN. hOW CAN i TROUBLE SHOOT?

I have amd 390x, intel i7, windows 10, Blender glsl pbr v0.4. Everything is black except the selected object which is orange. I used the test file for v0.4.

I dont quite understand why this is called GLSL Physically Based Rendering? It appears to use inputs from Cycles nodes which does not appear to have any sort of standardized methodology to specify Physically Accurate lights or input PBR material definitions.

Which part of this is Physically Based? I am not being pedantic or disputing, I am just confused what PBR means in a rendering pipeline if the input is arbitrary and there is no clear relativitiy to actual Physical materials or lighting.

  1. Is there a workflow here that facilitates a relative comparison of the Cycles nodes to known materials?
  2. Does this provide a bunch of PBR input nodes?
  3. Does it transform Cycles nodes into virtual PBR input and then render it?
  4. It appears that PBR in this instance refers to a method of rendering as opposed to the materials+lights pipeline?
  5. It appears that the theoretical point of a PBR is to not have to define multiple texture sets for different lighting conditions and with enough support, presumably have portions of material definitions be interchangable with good results (ala the Fox engine).
  6. Is there a way to output the Cycles nodes to a set of PBR textures?

Even a simple lambertian reflectance is PBR, so shut up. If you want 100% physically accurate results, then try to make a renderer that calculates photons reacting to atoms which consist of protons, electrons, neutrons, which all again consist ofā€¦ It is and will never be possible to be physically accurate.
And in present PBR does mean blending cubemapped images of different roughness/blur levels.

I am trying to do an animation using object > Cubemap from Viewport Probe but it seems on every ā€œframeā€ the reflected object freezes from the first frame.
I thought the V0.4 would work the Mirror in Real Time Animation using the Viewport Probe which is really good to see.

As far as I know, You can animate using the Viewport Probe Planar which updates every Frame or even in Real time.

I explicitly said, I was not being pedantic or argumentive. I have no interest in arguing or causing any apprehension. I only seek to learn, clarify and in this instance urge for clearer nomenclature.

I did not understand that PBRā€™s intent is offering correct rendering of a materialā€™s texture set under different lighting conditions as opposed to the previous workflow of allegedly presumably having to provide a different texture sets for different lighting conditions of the same material.

My previous understanding was that PBR is largely about specifying materials in a standardized form and relative to known materials as opposed to a rendering implementation.

I still am soliciting answers to the questions I posed as I think they:

  1. Would lead to a more complete roadmap to bringing a full real time PBR solution to blender using this GLSL preview implementation.

  2. I think it would be valuable in specifying the exact naming terminology to portions of what I would presume in the future to be:

A) multiple real time PBR rendering implementations
a) this PBR GLSL preview (at this time, the documentation states that the goal here is accuracy not performance)
b) FOX engine PBR style implementation (they apply a lot of mat-id shading, atleast itā€™s my understanding)
c) Unity engine PBR style implementation

B) a PBR gamma correct asset pipeline.

Amen.
For the last several versions of Blender, weā€™ve had this capital Z option in the 3D view,
that causes instant rendering, so, to me, what this PBR innovation does is unclear.
Is it, basically, a re-write of Cycles entirely in GLSL?
Does such a rewrite include all the current Cycles nodes, including the (OSL) Script node?

What imagenesis is hinting at is that it would be convenient to have a set of nodes
labeled ā€œlamp blackā€, ā€œPyrex glassā€, ā€œSterling silverā€ (with polish and tarnish options), etc.

For my part, Iā€™m less interested in physical correctness than in showing all the information
that I want to show, and for that, Iā€™m forever defining materials with vector math and emission
(often with OSL), as opposed to inserting unrealistic ad-hoc light sources in the scene, so,
if we ever get a standardized library of ā€œphysically correctā€ materials, I hope it will be
as groups of render-oriented nodes, that can then be expanded and modified by the artist/user.

im simple words, its modern viewport , same like unreal engine and unity,but please dont go too deep into understanding it at such a begining stage and please dont start discussion about how it has to be , if someone dont understand what it does, then please visit the clementā€™s website , or email him about your confusion , i m sure he will answer your questions more better

im having an issue in the v0.4a where lamps are not working in cyclesā€¦ none of them. in cycles.

i have a GT 210,

but i dont think the graphics card is the problem i because in another file it was working just fine. i quickly read through the thread but canā€™t find any solution. please help.

Hello guys!

As some of you may know Iā€™ve been hired by the Blender foundation to improve the shading capabilities of the GLSL viewport for the 2.8 release. This is a big change for me and a wonderful opportunity for my carrer. Iā€™m heading to the foundation right know for a kickoff session to clear out what are the short term goals.

This means this branch will be left as it is. I know there is some bugs and one in particular. Actually Iā€™ve patch the said bug but did not released it as I was busy with work. But now itā€™s outdated and Iā€™ve no reason to keep it. If you want and updated version you may want the 2.8 pbr branch that Dalai did for reference. That said itā€™s untested.

And this is all thanks to you guys! This would have never been possible without you spreading the word!

On the side note I may start a blog on tech stuff related to rendering and realtime and the viewport developpement.

Iā€™ll be in the #blendercoders IRC channel for thoses who use it. But you can always send me an email or drop in the viewport mailling list!

And now Iā€™m going to anwser the questions of imagenesis:

Q: Is there a workflow here that facilitates a relative comparison of the Cycles nodes to known materials?
A: No

Q: Does this provide a bunch of PBR input nodes?
A: No

Q: Does it transform Cycles nodes into virtual PBR input and then render it?
A: No

Q: It appears that PBR in this instance refers to a method of rendering as opposed to the materials+lights pipeline?
A: Yes

Q: It appears that the theoretical point of a PBR is to not have to define multiple texture sets for different lighting conditions and with enough support, presumably have portions of material definitions be interchangable with good results (ala the Fox engine).
A: Yes

Q: Is there a way to output the Cycles nodes to a set of PBR textures?
A: Yes/No/Maybe (iā€™m working on somethingā€¦ canā€™t tell Top Secret :x)

Let me shed some light upon this.

Going back to the definition. PBR stands for is Physically <b>Based</b> Rendering. The ā€œbasedā€ is important because we are just trying to replicate light/matter interaction in a plausible way. The problem comes from the fact that rendering trully physically correct interractions would be really slow. Thatā€™s why we have BRDF/BSDF/BSSSDFs. They are mathematical representation of the said interractions at microscopic (sub-pixel) level.

Some BSDFs are more physically accurate than other given a certain target look.

So in short PBR is just a way of caracterizing a rendering process that (tries to) take care of energy conservation and use real light/model interaction (insert fresnel here).

In this way all cycles BSDF/BSSSDF shader nodes are energy conserving, but only individually. Itā€™s up to you to mix then in a physically based approach or not.

As an artist you need to know that PBR textures are defined by the renderer and may vary from engine to engine.
But you are right about the unique textures under multiple lightning condition.

Itā€™s a broad topic so I hope it helps.

1 Like

thanks for your hard work and good luck with official blender :smiley:

Heā€™s back! Heā€™s awake! Heā€™s hired! Whooppee!!

Thank you, Ton Roosendaal.

Good luck to Clement and all the 2.8 viewport team!!!

Is there any ā€œupdatedā€ version of that viewport build ?

So trying to get my Alembic animated mesh cache export into UE4 did not work too well as I hoped for, and I recon the use of Alembic in UE4 is not intended for large frame-range animation caches. So I thought to give hypersomniac or rather ClĆ©ment Foucaultā€™s PBR viewport built a try. What a surprise, I really managed to get far with a hybrid solution, a ā€œbeautyā€ pass with his Viewport giving me Ā± 4 seconds per frame, and a Cycles renderlayer EXR render Ā± 40 sec per frame for Depth, Emission, ID, Normals and Vector to push the image further in comp. Iā€™m really excited about the 2.8 release. I will post a basic animation 300 frame video shortly. Thanks for this Blender build ClĆ©ment!




Those side thrusters still needs smoke :slight_smile:

Looking great Andre!!! And I like those render speeds!!!

As promisedā€¦

I brought in and posed the character, hereā€™s a very quick (pun intended) render

[ATTACH=CONFIG]467445[/ATTACH]