MERL BRDF Database

[Annon]

Before I go messing around, has anyone looked into implementing some of these BRDF functions into SHOPs?

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

[dulo]

Looks quite interesting. Houdini lacks some proper Drag and Drop Material Collection ..

[Macha]

Interesting, but copyright wouldn't allow us to use this in production.

[Erik_JE]

I think I read somewhere on the SESI boards that it is not yet possible to implement your own BRDFs.

[Annon]

That does ring a bell actually. Ohh well

[Macha]

Nono, I think you can still do it, sort of. If all you want to know is how the light is reflected from various angles, then you can do that in a normal micropoly or raytrace.

[exu]

also, you can use this one...

http://www.disneyanimation.com/technology/brdf.html

cheers!

[Annon]

Yeah, this morning is a vague memory for me atm, but I think that was what made me end up on the mitsubishi site.

I'll look properly into it in a few weeks when I'm not as busy. I really only ever mess with shaders at last minute making them on the fly to look how I think they should look before the deadline crushes me, but I'd like to get into shader writing more.

I'll report back with my findings just if there is any.

C

[stevegh]

Checking in several weeks later.

I find myself wanting more options than the BSDFs that ship with Houdini but I am unable to find where these functions are located. After much scouring through the source files and headers, I probably should have come here sooner to ask if someone knows where these are?

[Annon]

I think you can now code your own BRDFs in 12.5, I don't believe you could do it before hand.

[Annon]

http://www.sidefx.com/docs/houdini12.5/vex/functions/cvex_bsdf

[stevegh]

Oh duh! Thanks Christian.

Edit :: Ignorance Question::

So trying to follow the docs and I'm not quite sure where/how to compile those diffuse_eval and diffuse_sample shaders. I tried including it in my shader just editing the type properties code tab which is how I've been doing everything so far. I also tried compiling to separate OTLs but I continually get this error:

mantra: VEX error: Unable to load file diffuse_sample.vex
mantra: VEX error: Could not find shader 'diffuse_sample'
mantra: VEX error: Unable to load file diffuse_eval.vex
mantra: VEX error: Could not find shader 'diffuse_eval'
[/CODE]

when trying to call the shaders. Any tips here would be much appreciated.

Edited May 7, 2013 by stevegh

[danylyon]

Hi guys.

I've looked into the MERL database some time ago.

Well you really don't want to use them (apart from license).. because. One BRDF is around 33 MB. Imagine having a 33MB texture lookup on every sample (not shading point but actual sample!).. so way way to slow. Also you couldn't change anything about the BRDF. Plug in a "blue paint" and you couldn't even change the color of the blue. because it's baked into the BRDF.

That being said, it can actually be useful to be able to see how the BRDF looks. Not on a surface but as a graph. That way you can try matching mathematical BRDF's (like the ashikminh, phong..) to the data. You will end up using several mathematical BRDFs in combination to try to match it.. and even then it's hard... probably ending up with not as intuitive parameters anymore aswell. Balancing artist friendly.. mathematical correctnes.. and physical "likeliness" to the data.

The only thing I found, that's really cool is just getting "inspiration" for writing your shaders.

I can post the file that's importing and displaying the BRDF. Will have to dig it up, don't expect too much from it, though ;-)

[danylyon]

Stephan: look at http://forums.odforce.net/index.php?/topic/17326-new-pbr-shader-features-in-h125/

I briefly explain how to install it. (took my quite long to figure out aswell ;-)

Don't use the bsdf I post.. it's not working correctly!

[danylyon]

Here's the file.

There's a note in the file how to use it.
It's probably not in the most efficient way done.. but it's really just for visualization.
Unfortunatly I don't know, how the MERL values are normalized. Some materials seem to be too bright / too dark.

Things I've discovered.
- Forget IOR values for fresnel, anything other than really reflective / refractive surfaces.. as soon as the surface gets more complex, a lot more happens
- Specular peaks (especially on metals) have a very strong peak and soften slowely. Phong etc. are way too soft.
- Specualr highlights are indeed often slightly colored, especially if the surface is rough.
- darkening at the edges in the diffuse, only happens on few materials..
- many materials have a little bit of SSS.

BRDF_load.zip

Edited October 3, 2014 by danylyon

[stevegh]

Awesome Dany! I will definitely be checking this out today. The Lafortune BRDF seems like it might be worth investigation. Or perhaps some Cook-Torrence / Lafortune Hybrid. Hell it would be really nice to throw toggles for known BRDF's into the shader itself. I know what I'll be doing this weekend! :sad nerd face:

[danylyon]

You'll have to decide early on if you want to go PBR.

As far as I know only really Phong or Ashikhmin have PDF functions (basically a function which describes how to shoot samples). Which is needed with PBR.

To do that for, say Cook is nearly impossible. Involves some serious Math and hasn't been done yet (well as far as I know anyway).

Lafortune is a different beast, as far as I know it's "just" a combination of phong BRDFs. Which is a good thing, because you can already do that with PBR.

The amazing thing about PBR, you can take as many BSDF functions weight and combine them and THEY GET SAMPLED ALL TOGETHER!!.. so no speed hike with many combinations of BSDFs! I tell you that right there is a killer feature, which almost nobody knows about!

(Vray, Arnold, MRay all would slow down considerable..)

So PBR is in my opinion the best way to go!

I don't think the big thing is triing to find the better BSDF or code it yourself.. but to make a shader wich makes a good combination of the already built in once.

Btw, you can use

vector eval_bsdf(bsdf b, vector viewer, vector light, int mask)

Inside geometry context, so you can quite easely show the build in BSDF's along with the MERL Data :-)

And please have a look at my code.. I really hope I didn't mess something up, which would be a shame if you (we :-) want to build upon it.

[stevegh]

The small amount of testing I've done with Mantra leads me to believe PBR is a much nicer solution in terms of reducing the need to 'chase' noise. Coming from V-Ray and Arnold this is a pretty big deal since I am very used to being able to control the noise level in one place. I am in the process of converting the V-Ray Materials .de site's shader ball over to mantra so we have a decent shader testing environment (no offense meant to the creator of the other one I've seen/used floating around).

One thing in particular I noticed was that when I had a shader with just a diffuse component it rendered extremely fast, as well just a reflection component very fast, but when I went to add them together (non-PBR mainly) the render time went up a good bit. I am assuming this is caused by a multiplication of samples based on ray depth. So for example if I had 3 diffuse bounces, and 3 reflection bounces, there would effectively be 9 maximum bounces per pixel, multiplying that by the number of diffuse samples (lights, shading quality) and reflection samples (glossy or not). Is this accurate? Are you saying PBR evaluates them all simultaneously at the given depth and sample rate? This confuses me because doesn't PBR look for BSDF ray types as well?

Sorry for all the questions, I am really trying to move over to Mantra and having used V-Ray for so long I really need to know what's going on under the hood here.

[danylyon]

Hi Stephen

PBR and non PBR work very different in the way samples are shoot. If (non PBR) you have 128 samples for diffuse and 64 samples for reflections you're going to sample 184 per pixel.. there are some little optimizations but as far as I know thats essentially it. Then shadow rays I think get added aswell.. and so on

With PBR you just define a Diffuse BSDF and a Specular BSDF add them together and assign to F. You might have defined a Fresnel.. so some part is more or less reflective. PBR will essentially take all informations (including lights) and try to figure out the best way to shoot samples.

So for example.. it will shoot less samples if diffuse is darker. Or if the reflection is less blurry and so on. That's why PBR will get very slow if you have 100% diffuse PLUS 100% reflection.

Diffuse bounces and reflection bounces don't add up. When you write a shader, you "label" the different BSDFs. That's also how you split them up into different AOV's. Only a few predefined label's are allowed though.

All in all PBR gives you less control when you write your shader. You can't do per light or sample stuff easy (you'll have to do your own BSDF for that). But it's also much easier to write shader.

essentially all you really do is:

F = diffuse() + phong(100) * Fresnel + phong(500) * Variable .. etc.

look at: http://localhost:48626/vex/pbr

Edited May 9, 2013 by danylyon

[rendertan]

Some time ago i tried http://brdflab.sourceforge.net/, it allows you to load MERL and iirc NEF data and do the data fitting for any number of lobes. The problem was that for quite some time only the (windows) binary was made available at sourceforge. They seem to have added the source finally, but i haven't tried building it (depends on OGRE and Qt).

Another alternative is well, the MERL format is described, you could try loading the data in Fytik and do the data fitting there.

http://fityk.nieto.pl/

just my .02c

Edited May 12, 2013 by rendertan