Open Source PBR Shader Common Project.

[sebkaine]

Hi Guys ,

 

I would be curious to know if some of you would be interested to help me work on an Open Source Mantra Shader.

There are actually some very cool PBR shaders right now like those one :

 

http://forums.odforce.net/topic/18353-pbr-all-purpose-layered-shader/?hl=danylyon

http://forums.odforce.net/topic/20682-bsdf-bonanza-ggx-microfacets-disney-brdf-and-more/

http://forums.odforce.net/topic/21673-physhader/

 

The problem is that the first 2 are not accessible in VOP , you can't modify them yourself and thus you are not 100% free.

The last one is also very cool and will help me a lot to understand VEX more in depth.

 

But i would like to work on a modular shading tool. base on a core BSDF that you would then layer to build complex material.

Most shader are more UBER shader like the V-Ray MTL / Arnold Standard / MR MIA / Mantra Shader.

But i would like to have something closer from what you have in Maxwell or Octane. Where you combine BSDF.

 

I'm quite bad in complex math, but i guess by combining some brain power here on od force we could achieve something cool.

 

So i would have some questions before starting to work.

 

Q1 - what would be the most powerfull environment to develop a cool mantra shader  ?

- Material shader builder context inside houdini

- CVEX shader builder context

- external compile VEX code

- external compile CVEX code

 

Q2 - what would be the most elegant organisation to keep thing easy to read / maintain ?

- full VOP node organisation

- full VEX code organisation

- a mix of VOP and VEX with inline code

 

Q3 - what are the requirements if we want to be able to make it work in Reyes/Raytrace/PBR ?

- does CVEX shaders work in all mode ?

- how to emulate the compute lighting node in CVEX ?

 

 

For the moment i was thinking to start to work with those :

- Material Shader Builder Context

- mix of VOP for utilities and Inline Code for core shading functions

- VEX

 

I would be glad to have as much advise and pov on the subject !

 

Cheers

 

E

Edited May 1, 2015 by sebkaine

[up4]

Salut Emmanuel,

 

I posted something related a couple of weeks ago here. I figured since I've got zeeerooo answer that writing one's universal shader was some kind of mandatory arcane initiatic rite one has to go through. And I kind of understand and respect that "go alone in the woods" attitude now. I'm still alone in the woods, I might not survive, but I had to answer myself some of the questions you asked.

 

The answer I have for myself right now is this: I eliminated totally VOP+Inline except for prototyping and then I look at the generated VEX code and I clean it and incorporate it in the my main text-only code. Maintaining code allows using better text editors than the Houdini interface and versioning systems such as GIT/Subversion/CVS. I am still hesitating between writing it in plain c and then calling it via CVEX or direction using VEX. CVEX is appealing because Arnold shaders are written in C/C++ and you could thus share the same code base. But I tend towards VEX because I can rely on Houdini's optimization and using code snippets for modelling and simulation (not only for shading).

 

As a side note, I don't know about RIS: does it use RSL? I think I saw it was C/C++ but I'm not sure. If it is the case, then it's a +1 for CVEX (I guess).

 

I have the feeling that a lot of people/studios are working on universal PBR shader architectures right now. It is moving fast. Especially with the game/vr/realtime industry now catching on on PBR. I decided to do my own research now only to be able to understand what is going on and be prepared to incorporate ideas from other efforts as they are published/shared. If I can contribute an idea or two eventually, it'd be great. But there are some seriously involved intellectual/monetary forces that I simply cannot match. I just hope they share the love eventually.

 

So there you go. Hope it helps a little.

 

Vincent

[sebkaine]

Thanks for your very informative answer Vincent !

 

I posted something related a couple of weeks ago here. I figured since I've got zeeerooo answer that writing one's universal shader was some kind of mandatory arcane initiatic rite one has to go through. And I kind of understand and respect that "go alone in the woods" attitude now. I'm still alone in the woods, I might not survive, but I had to answer myself some of the questions you asked.

 

Yes it's really hard to attack complex subject like shader writing alone i agree.   I'm quite sure that many of us have already play with their own custom shading sandbox. But the sum of this work that usually vanish after a show could / should be merge in a centric place like od force.

 

I eliminated totally VOP+Inline except for prototyping and then I look at the generated VEX code and I clean it and incorporate it in the my main text-only code. Maintaining code allows using better text editors than the Houdini interface and versioning systems such as GIT/Subversion/CVS.

 

well after second thought i think you are right.

- I would not go the VOP way as coding with node is really not intuitive for me

- inline / vop was sexy at first but you keep the work houdini dependant

- pure code is i guess the way to go

 

Thanks for this wise advise !

 

. I am still hesitating between writing it in plain c and then calling it via CVEX or direction using VEX. CVEX is appealing because Arnold shaders are written in C/C++ and you could thus share the same code base. But I tend towards VEX because I can rely on Houdini's optimization and using code snippets for modelling and simulation (not only for shading).

 

As a side note, I don't know about RIS: does it use RSL? I think I saw it was C/C++ but I'm not sure. If it is the case, then it's a +1 for CVEX (I guess).

 

I am not as technically good as you in H. I didn't know that yu could call C throw CVEX, but when you think at it twice C + VEX could point you in the right direction ?

RIS/Arnold are both C++ base for shaders.

 

I agree with you that going VEX or CVEX is the way to go , 

- first the synthax is clean

- you can benefit from the existent code

- you stick with houdini dna

- you can prototype in SHOP

 

but my big question is VEX or CVEX ? cause VEX has some stuff CVEX don't have.

in the other hand you can feel that SESI is pushing CVEX has hell and the evolution of Attribute SOP is an other proof that CVEX is the futur.

 

But here start my complete ignorance :

- does CVEX could be render in reyes ?

- can we elaborate something as complex as the Mantra Shader in CVEX ?

- if it is the case then why SESI keep using VEX for Mantra Material ?

 

So like you my big hesitation would be CVEX or VEX ?

 

I would tend to say that going CVEX would be the best choice ... but  i have no real knowledge that could confirm that.

 

I have the feeling that a lot of people/studios are working on universal PBR shader architectures right now. It is moving fast. Especially with the game/vr/realtime industry now catching on on PBR. I decided to do my own research now only to be able to understand what is going on and be prepared to incorporate ideas from other efforts as they are published/shared. If I can contribute an idea or two eventually, it'd be great. But there are some seriously involved intellectual/monetary forces that I simply cannot match. I just hope they share the love eventually.

 

well i am not that impress by what studio develop, most of the stuff i've used in big house looks like clunky / old / cumbersome stuff.

the fact that most studios that were spending millions on in house solver and RSL shader writter switch to Houdini and Arnold is a sign of time imo ...

 

I think doing a cool PBR workflow where GLSL / VEX can work together in a coherent way is definitly do-able with some patience and time.

I also think that houdini could be a cool playground for such kind of lookdev.

 

Cheers

 

E

Edited May 1, 2015 by sebkaine

[sebkaine]

I create an other post to explain what i have in mind.

 

my main reference are

- Maxwell Material

http://support.nextlimit.com/display/mxdocsv3/The+BSDF

- Unreal Material

https://docs.unrealengine.com/latest/INT/Engine/Rendering/Materials/HowTo/Main_Material_Node/index.html

 

in both case you have a compact BSDF that is able to handle all possibilities

- reflection

- transmission

 

you have a very simple set of controllers but if you combine this atomic BSDF you can benefit from infinite possibilities.

you can combine it in 2 ways :

- physical

- additive

 

I would like to get very close to Maxwell for surface / subsurface logic

but get closer to PBR generic term for the BSDF control.

[lisux]

If I would you guys, I will wait for H14.5

[up4]

lol this is so cruel! y u do tis evritime, houdini. ;-)

 

i was working on understanding the fur system and scripting my own crowd system and then came H14. I know that they are working on shading and texturing this time, but what should I do now, hibernate until then H14.5/H15? Anyways, reading and researching is never lost.

 

Anyways... Back to you Emmanuel…

 

First, regarding CVEX, I'm not knowledgeable enough to know if it is really an alternative to writing VEX shaders. So, right now, I stick to VEX. Also, not bothering with Reyes/Raytracing/Micropolygons anymore and sticking with PBR.

 

Secondly, I think we are very aligned on the GLSL/VEX thing (aka Viewport/Mantra aka Realtime/Unbiased until they merge for good). And I think standardizing the shader interface (its parameters, which parameters can be maps, etc.) will come before standardizing the shaders themselves. Just everybody is pushing in this direction and the two big trends I see are 1) measured reflectances/brdf and 2) human skin is approached separately from everything else in the (then not so-) universal shading architecture.

 

And really if we should wait for H14.5 maybe more details are in order, no?

[sebkaine]

@Pablo

Thanks for the hint that's cool to know that something is gonna happen soon in shading workflow.

Cause Mantra Material is really not a good proof of Mantra beauty.

 

@Vincent

Well after playing a little i think both solution offer by dany and jim contain nearly all the code stuff we need. if you add on top of that some mario code on glass / dispersion / sss

we have all we need to build a cool shader. I will try to start something while waiting for sesi new implementation.

 

But for the moment jim approach looks to be the closest to what i have in mind

 

Code 7 basic node in pure CVEX that can be call in the Mantra Material Builder context (like jim exemple)

- 1 Core BSDF with as less parameter as possible like the disney one

- 1 Coating Node that can be added on top of BSDF

- 1 Emission Node that can be added to BSDF or use as a simple constant shader

- 1 displacement node

- 1 BSDF combiner with Physical or Additive mode

- 1 Texture node with as less parameter as possible , the Arnold one is sexy in this regards

- 1 Texture Combiner for multiple map compositing

 

here is an empty box that i send to next limit for maxwell plugin, but it was never use.

i find the atomic node layout pretty cool.

 

the thing that need to be modify is the BSDF logic to match something closer from standard PBR names.

a la disney / unreal / substance.

 

what do you think of the layout ?

you can see that all work is done on a sub level, but it is far more simple and concise than the mantra material mess imo.

 

The first thing to code is the core BSDF so let's start by this i guess ...

I will try to reorganise the current BSDF to give it a more standard taste.

mantra_material.hip

Edited May 2, 2015 by sebkaine

[pezetko]

Just something :

https://vimeo.com/123865793#t=9m40s

[up4]

@pezetko: I see a (VERY crude) viewport shader implementation, but is there a Mantra one as well? and will they be configurable because nobody uses the GLSL shaders bundled in the Algorithmic products (they dont support a fraction of what the Substance engine offers), for example as of a couple of weeks ago, I still had to implement opacity myself… there is no refraction, no sss emulation, etc.

 

@sebkaine : the other nice thing about VEX is that you don't need a license to open it ;-) can you post your thing in an Apprentice HIP, please ;-) also, are you talking about Dany's 2 PBR shaders on Orbolt : the "skin" one and the MERL PBR Layered one? I have purchased both of them, the code is in the OTL, but I think we should involve him or at least ask for his permission before repackaging his thing. Otherwise, I agree that Jim and Dany's shaders. I have no experience with Roman's PhyShader, but is there a reason why you are discarding his work? I'm just saying this because his code is available on Github whereas neither Jim nor Dany have open sourced theirs. And also, I think the reason why Jim wrote his F in CVEX is that GGX was not implemented in VEX at the time. I think that unless you have a good reason to discard SESI's GGX implementation, maybe we should stick with it (it's the default specular "mode" in the mantra surface shader now).

[sebkaine]

@Vincent.

I've already contact Dany to ask him what he think about the fact that i use his code as a reference / learning material for a free shader, and he kindly answer me :

 

Hi Emmanuel

 

It's not like I invented shader writing. ;-)

Lot's of code, I found around the web, understand, implement the way I see fit.

The only thing that is truly unique is probably all the Presets, the way one can control the falloff (with my own bsdf), the way the layers are mixed. The fresnel of metals. And the SSS in the skin shader. If you strip those away, it's not much different than Mantra Surface. So feel free to learn from the shader.

I think most people get my shader, because they either want something simple and complete (artists) and don't want to deal with VOPs at all. Or they are like you and inspect the Code ;-)

 

So, for people that want something more customizable your VOP - exbandable shader will be embraced.

 

By the way, if I were you, I'd build it around the BSDF GGX, which seems to be included in H14. (Search for ggx in the help files). Unfortunately I couldn't find the actual node.. 

You might also want better support for Substance Painter and DDO maps.

 

Looking forward to your shader.

 

Cheers

Dany

 

I have not discard roman work at all i just haven't study his code yet. but it looks excellent at first sight, and will be definitly a reference for me.

I have try SESI GGX on 2 shows and each time i have some noise / fireflies artefact that i can't correct. Blinn always work like a charm so for the moment i stick with it.

But chance are that i am the problem ...

 

for vex / cvex, i don't know why but i have the impression that using cvex_bsdf() is the best choice for long term ... but again i have no valid argument to support that.

 

i have some reading to do

http://renderwonk.com/publications/s2010-shading-course/

https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf

http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_notes_v2.pdf

https://www.solidangle.com/research/physically_based_shader_design_in_arnold.pdf

http://www.frostbite.com/wp-content/uploads/2014/11/course_notes_moving_frostbite_to_pbr.pdf

 

all the code needed is free and accessible , like dany said we are not inventing anything here ...

i have a strong interest in UE4 shader, the source is accessible you just have to subscribe. they use a modify GGX

this article is very interesting

 

http://graphicrants.blogspot.fr/2013/08/specular-brdf-reference.html

 

again mixing UE4 BSDF Material and Maxwell BSDF Material by keeping

- simplicity very high => you just keep what is absolutely necessary

- only pick for each component ONE shading model that gives the best ratio beetween Physically Correct Quality result / Best Performance

- stacking BSDF

 

the arnold paper is really interesting when describing +/- of UBER vs STACK

 

Cheers

 

E

 

 

Edited May 3, 2015 by sebkaine

[up4]

Thanks for contacting Dany. It had to be done, I think.

 

I would like to investigate SESI's Fs and especially GGX more thoroughly before going with custom CVEX. What do you think?

 

Re: UE4: me too. Actually, I want to know if it is better to use the Unreal Editor with the Houdini Engine with their shader or port it to Houdini and work in Houdini natively. What is your take on that? I mean for previz and all, not just for making real-time versions of assets for games.

 

Also, do you have a deadline right now for this? What is your time frame?

 

Take care!

[sebkaine]

I would like to investigate SESI's Fs and especially GGX more thoroughly before going with custom CVEX. What do you think?

 

well from what i have in mind it would be cool to have like i said :

- very few atomic nodes that will allow to keep the shading tree simple / consice / powerfull (avoid the mantra shader mess ...)

- code those nodes in CVEX in plain external code, that is accessible to anybody

- no black box / no offuscated code

 

the problem by using sesi default implementation is that we can't optimise things.

for ex the GGX formula use in UE4, is 90% accurate but a lot faster so if this one is good enough i don't care about the last 10% if i have a 35% gain in speed for ex.

 

Re: UE4: me too. Actually, I want to know if it is better to use the Unreal Editor with the Houdini Engine with their shader or port it to Houdini and work in Houdini natively. What is your take on that? I mean for previz and all, not just for making real-time versions of assets for games.

well i would say it depend on your goal.

- if you want to Light in RT for VFX / animation movies, there is actually no way to export an UE4 lighting to H

- that would be cool in theory to light RT in UE4 and then export light + shaders to H , but it's challenging

- UE4 is cool if your outpout is RT High End app

 

from what i have in mind RT and OpenGL are use for 2 main purpose :

- have an accurate RT preview of what you mantra render will look like

- have an accurate RT preview of what your scene will look like in a RT canvas with restriction like WebGL / OpenGL ES

 

UE4 is fantastic but you are looking at what is the best rendering you can have in RT, if you push DX12+HLSL to the limit, with a high end GPU.

WebGL for ex is not in the same level ... you are more watching PS1 graphics ...  (Ridge Racer ... anyone ? )

 

Also, do you have a deadline right now for this? What is your time frame?

 

Well i am still working in VFX but have high interest in this , so i would say that 6 month / 1 year would be realistic considering my disastrous math skills !

 

Cheers

 

E

Edited May 3, 2015 by sebkaine

[up4]

Hi,

 

I give myself one or 2 weeks to investigate custom CVEX vs SESI VEX Fs. I will report here. But I agree with you on all principles. Just in case, I asked the UE shader author if there is any update on his article.

 

I have 2 more questions for you:

1. how to you plan to incorporate general SSS / human skin shading in all of this if ever? 
2. will you look at measured Fs (MERL, Marmoset & al)? because I really like the idea of measured presets as a starting point.

[sebkaine]

1. how to you plan to incorporate general SSS / human skin shading in all of this if ever? 
2. will you look at measured Fs (MERL, Marmoset & al)? because I really like the idea of measured presets as a starting point.

 

 

 

well for human skin i see 2 possibilities.

 

The best imo would be to only use atomic BSDF to build the layer of human skin so i guess a combination of 5 BSDF if we respect the classical approach.

 

The second possibility would be to create a dedicated BSSRDF that handle multiple layer of sss in a very optimised way, so it would be an independant component like

- the coating component

- the emission component

 

That you would combine with 2 traditional BSDF for specular.

 

But having a combination of 5 atomic BSDF would be my first choice. Only if we can gain huge render time i would be ok to switch to a dedicated component. because while coating and emission justify to be separated from the BSDF , i see no objective reason to create a dedicated component for skin sss.

 

The UE4 source code is free you just have to register and get full access.

Here is the HLSL code for their BRDF they give you the link of their source.

 

for being as physical as possible i absolutely agree so sticking as much as possible to those

http://www.merl.com/brdf/

http://refractiveindex.info/

is a great idea and that's exactly what i like in maxwell approach

http://support.nextlimit.com/display/mxdocsv3/Index+of+Refraction+-+ND+and+K

http://support.nextlimit.com/display/mxdocsv3/IOR+files

 

I would say that befor attacking sss a good startup would be to choose the best shading models for

- Diffuse model

- Microfacet distribution

- Geometric attenuation

- Fresnel

 

By picking for each one of them

- the best ratio beetween Physicall accuracy / Speed in VEX and GLSL

- the one that give all the needed control but without adding extra complexity for the users

 

This is also a good link to investigate BRDF

https://trac.solidangle.com/arnoldpedia/chrome/site/Arnold-4.0.14.0/doc/api/group__ai__shader__brdf.html

http://igorsklyar.com/main/developments?locale=en

ue4.txt

Edited May 3, 2015 by sebkaine

[up4]

Re: skin, human character shading is the ultimate test for a shader I think. I test mine on clothing, props, eyes, nails, hair and skin. I have never been satisfied (æsthetically) with generic articulations of SSS for human skin and I have seen that most treat human skin as a special case. I'd still want to include it in this shader because ideally for me it should be able to handle all the surfaces in the scene. MERL has a measured reflectance database only for human skin, Arnold has a shader dedicated to human skin, Dany made a PBR shader for human skin separate from his general PBR one. So: I would like our shader to be able to shade state of the art human skin and I think the best way is to address it specifically.

 

I will include human skin models in my 2-week study of Fs and reflectance measurements. I am really surprised nobody has yet said anything on shading human skin over at Wikihuman (formerly known as The Digital Human League).

 

But I will use the same strategy: look at both the GPU/RT and the unbiased strategies and frankenstein one up.

[sebkaine]

well i see no objection for a dedicated shading components for skin sss.

 

it looks to be the chosen path here and this guy look to seriously know his subject on mantra shaders ...

http://igorsklyar.com/main/development_description/25?locale=en

 

so :

 

1 - Core BSDF

1 - Coating component to blend with core BSDF

1 - Skin SSS component to blend with core BSDF

1 - Emission component to blend with core BSDF or use as constant shader

 

1 - BSDF combiner with Physical / Additive mode

 

1 - Texture loader where you can access user data / texture map

1 - Procedural noise generator where you can acces easily all type of patterns

 

1 - Texture combiner where you can mix various texture easily

 

1 - Utility swiss army knife node that can do basic OP

- clamp

- remap

- facing ratio

- color correct

 

So basically your shaders are created with those 9 CVEX atomic nodes.

The full code is included in each nodes ...

 

That sound like we have a plan  ...

Edited May 3, 2015 by sebkaine

[Guest mantragora]

Check also papers from Activision R&D:

1. http://www.iryoku.com/next-generation-life

2. http://www.iryoku.com/stare-into-the-future

 

in second link there is PowerPoint file where they talk about their approaches to skin shading.

 

Also worth mentioning, AxisAnimation started using UE4 for cinematics and from looking at their site it looks they also aim to use it for commercial projects as e normal renderer too. They are a Houdini house so maybe worth to look who is in charge of UE4 team and make some contacts.

 

BTW. Jorge Jimenez also have Github account where he shares some code => https://github.com/iryoku?tab=repositories

Edited May 3, 2015 by mantragora

[up4]

Browsing on the Activision guy's website, I found this. I contacted him to know more about the paper and its open source implementation. Will look into AxisAnimation later and maybe contact them too.

 

Thanks, mantragora.

[eetu]

Great initiative!

 

A couple of quickie comments. You can't just pick'n'choose the D, F and G from UE sources and run with it, the bulk of the work is getting the respective sampling functions for MIS. You could do a naive illuminance loop version of the shading model for learning/reference, which would be pretty much just implementing the game shaders, but it would be very inefficient (I have and it was:). A proper BRDF is a must. I would try to use existing BRDF implementations where possible, and concentrate efforts on the higher level design/modularity of the material. Of course if you really want to learn everything and do it all, the more power to you!

Also, as far as I understood, the SESI GGX _is_ Jim's GGX, with some modifications. (?)

[up4]

Hello eetu!

 

I'm glad that you came by to spill some wisdom beans! ;-)

 

So you wrote realtime-inspired cvex_bsdf and you didn't tell anybody? Naughty. What do you mean by inefficient? Writing eval functions is hard? I'm asking because one of the reason why I said I'd rather stick with the SESI implementations is that I could not find anything about importance evaluation (and a sh**load about sampling). BUT as Emmanuel said, and I agree, it is also because the importance evaluation functions are blackboxes (more so than the sampling functions, or maybe I overlooked something?) that we should write our own(s?) if you know what I mean. Is it possible (and I know I'm stretching) to use SESI's evaluation functions (how to call them, then?) independently with our own sampling functions?

 

Just my shitty theory that (as per your signature) is better than no (publicly available) theory at all.

 

And since you asked, I shall insist: SESI GGX ~= Jim's GGX? If so what are the modifications and why? In the sampling function itself or in the eval?

 

And since you are here (bis), tell me please on a scale of 1 to 10 how crazy this sounds: dump all the reflectance measurements I can find into a VEX header in some kind with a standardized static data structure (with the new H14 VEX array manipulation functions AND CVEX support for array binding, arrays are sexy again) and use them as the basis for presets (I looooooove presets) or, even better as material parameters.

 

I'm going for a walk to calm down now lol.