Jump to content

Wolfwood

Members
  • Posts

    688
  • Joined

  • Last visited

  • Days Won

    3

Wolfwood last won the day on August 23 2014

Wolfwood had the most liked content!

About Wolfwood

  • Birthday 05/11/1978

Contact Methods

  • Website URL
    http://www.mrxfx.com

Personal Information

  • Name
    jim
  • Location
    near coffee
  • Interests
    Anything with a XYZ-axis...preferably in a left-handed coordinate system.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Wolfwood's Achievements

Newbie

Newbie (1/14)

37

Reputation

  1. Yulp yulp. I just meant when you were solving for the D()'s normalization factor you need to solve for Int[D]==2*pi instead of Int[D]==1. (Papers generally use ==1 where as mantra ==2pi)
  2. The interplay between the eval/sample is a massive pain and instead of having a straight forward sample(), pdf() and eval() functions like in Arnold or PBRT, you have these inner dependent variables. (For example, from what I can tell the eval export in the sample function is used for indirect bounces while the eval in the eval shader is used for direct.) The stock Houdini BSDFs (phong, blinn, etc) use unnormalized distributions then outside of the bsdf use 1/luminance(albedo) to normalize the BSDF. This has been the standard pattern I've seen in almost all shader setups and it works if your BSDF is a straight distribution (D). It kind of falls apart though when doing a full microfacet model, which is what my note in the known issues eludes to. Basically what I'd like to do is normalize the D inside the BSDF, then have the albedo function return exactly what its suppose to, the average reflectance over the surface. But that would mean you shouldn't divide by luminance(albedo) as the BSDF would now be taking care of it. (I had it setup this way originally but since it was a slight departure from the standard BSDFs I changed it to its current form and its been bugging me ever since.) The pdf is divided by rho (aka albedo aka refl) in the sample function because that's the way mantra expects it. "note that this differs from the pdf produced by the evaluation function by a factor of refl" As for the Pi factor, the PBR engine is taking care of this for you indirectly. (PDF values by definition should integrate to 1, not 2*PI which Mantra expects, so there is some definitely some trickery going on behind the scenes.) While Mantra's end result is the same, the implementation is a bit different from other renderers so various factors need to be taken into account when porting from one to another. For example, the diffuse eval() function in PBRT just returns your diffuse reflectance divided by Pi. In Mantra's eval(), the Pi is left out and there is an additional cos() factor tossed in for good measure. I think this is because the light transport equation is Lo = Li * fr * cos(theta_wi). Where fr is your BSDF. Mantra doesn't have that cos factor in pathtracing code so its up to you to do it inside the BSDF. It doesn't mean Mantra is wrong since multiplication is associative but it does make porting harder as you have to understand the intent. If you are inspecting the code to see how everything relates the microfacet_eval and microfacet_sample might be a bit better as the distribution aspects have been abstracted out and the bulk of the code is just handling the expectations of Mantra. Ultimately I could be wrong and if there is a convincing argument to how something should be implemented I'm all ears. Effectively I had an initial explanation from Mario, the cvex_bsdf help, and then a lot of trial and error and comparisons to other renderers.
  3. Difference with between the remapped roughness in v1.1 (top) and the unmapped version in 1.2 (bottom). Added link to the first post.
  4. The Disney BSDF has an intentional remapping of the Masking-Shadowing roughness term that prevents full reflectivity at the grazing angles so I mimicked that. HOWEVER, just last week Bruce amended the implementation details to say that may have not been a good idea. I've already removed this restriction from our internal version and I'll push out a 1.2 shortly. Its a noticeable difference. (For the better IMHO)
  5. First post has been updated with 1.1.1 versions of the OTL that works around the VEX bug.
  6. Just as a heads up we've come across a Houdini (LLVM) bug when using the Disney mixer with varying values. If you see a crash that looks like- VEX_LLowering::createInputRegister(llvm::MachineFunction&, llvm::MachineBasicBlock&, UT_AssocArray<llvm::Value const*, unsigned int>&, llvm::Value const*) <libHoudiniUT.so> VEX_LLowering::lowerToMachineCode(llvm::MachineFunction&) <libHoudiniUT.so> VEX_LLowering::runOnMachineFunction(llvm::MachineFunction&) <libHoudiniUT.so> llvm::FPPassManager::runOnFunction(llvm::Function&) <libHoudiniUT.so> llvm::FunctionPassManagerImpl::run(llvm::Function&) <libHoudiniUT.so> llvm::FunctionPassManager::run(llvm::Function&) <libHoudiniUT.so> VEX_LModule::codeGen(VEX_SymbolTable&, UT_Array<VEX_Word>&, UT_StringArray&, VEX_SymbolTable const&, VEX_NativeModule*, _IO_FILE*, int) const <libHoudiniUT.so> VEX_Code::codeGen(VEX_LModule const&, VEX_SymbolTable const&, VEX_ErrorLog&) <libHoudiniUT.so> VEX_Assemble::getAutoFoldedCode(VEX_SymbolTable const&, VEX_AssembleParms const&, VEX_ErrorLog&, bool) <libHoudiniUT.so> VEX_Assemble::getAutoFoldedCode(int, char const* const*, VEX_AssembleParms const&, VEX_ErrorLog&, bool) <libHoudiniUT.so> it's probably the same one. I've tracked down exactly what part of the source is causing the crash and have a workaround that I'll push out tonight or tomorrow. The bug has been reported to SESI and hopefully they'll fix it on their end too.
  7. Ya I do, I just stripped it out of the release cause I needed to make some examples for it first. I'll try to update the OTL tonight with a couple of mods based on the above comments.
  8. Indeed. From a pure physical pov it doesn't make sense but from a artistic or approximation pov it makes perfect sense. The disney brdf is a reference implementation of what was described in the paper. There are some aspects I love very much about it. Parameter values between 0 and 1 but unclamped, along with having a small number of parameters. Its obvious that a lot of time and thought went into its design. But of course there are also some things I don't, for example I dislike the remapping of the roughness masking term that happens under the hood. If nothing else it serves as a wonderful starting place for discussions about PBR shader interfaces. Internally we'll definitely be making some modifications.
  9. I actually have this tagged as issue #17.Currently when in microfacet mode (ggx or gtr) F0 isn't taken into account when fetching the albedo. I actually have a fresnel aware diffuse bsdf where you wire in F0 and the diffuse takes the reflexivity of the microfacets. PBRT takes the easy way out and instead of having an analytical solution just takes a bunch of samples of the BSDF and returns the albedo of your parameters settings.
  10. You get kudos too! All our discussions about stupid "refl" kept me digging deeper.
  11. I should mention, one thing that doesn't blend well is the metallic parameter. If you have two objects one a metal the other a plastic and you do a 50% blend you are going to get some funky results. (Not sure what a 50% metallic object even is.) However, completely masking (100% blend) is perfectly legal. The reason why its a float instead of a dielectric/conductor toggle is so that maps can be painted and you don't get aliasing due to the discontinuities of int 0 and int 1.
  12. Correct, currently the disney_struct has no concept of any of those geometry terms and they can only be set on the final Vop. Was a design decision but an easily changeable one. (I had considered anisoAngle a geometric term, but I am easily swayed.)
  13. Ha. I was debating whether or not that parm should be mixable just the other day. Guess that answers that. I'll have it updated in a few hours. (And I'm looking forward to the "I told you so" from one of my coworkers )Fyi- currently none of the geometric parameters blend, like nN or the tangent directions.
  14. There isn't a "clean" way to do it currently. If using the distribution only (and not the microfacet model) you can flip the normals and do it similar to how the Mantra surface works (fresnel blend), but ultimately support should be built in. I already have logged an issue (#19) for this. So far only the BRDF has been implemented from Walter's 2007 paper, issue #19 is to implement the BTDF too (making the full BSDF). It shouldn't be too difficult, and is high up on my TODO list once I'm back from Siggraph.
×
×
  • Create New...