Port BxDF functions to HLSL

[Crisspl]

Description

I started from the state of this PR: #439 .
Im not intending to port anything besides bxdf/ (and stuff used by it).
Is there some issue/doc/anything with design for HLSL port? From the state of already done things in aforementioned PR, i see there was some design work done.

Testing

TODO list:

BRDF functions are done, BSDF not yet.
Everything touched by me is compiling fine, not tested in practice yet
@devshgraphicsprogramming Please look throughout the diff of my commit for TODO comments, maybe you can answer some questions

TODO:

• BRDF functions
• BSDF functions
• rename remainder_and_pdf functions and use quotient_and_pdf struct for them
• now doing concept stuff

[devshgraphicsprogramming]

@Crisspl can I get a DCO and statement you're not making this during work hours from you?

Also where do you work right now and is your employer ok with your after hours open source contributions?

Then I can get the review done right away

[Crisspl]

@devshgraphicsprogramming I'm not the only author of commits within this PR, so is it enough if I sign off just my commits?

Currently working in QLOC, I've asked personally and it's ok to contribute to opensource, my official agreement with QLOC also doesn't prohibit cooperation with others unless it's market competition

[devshgraphicsprogramming]

So this is the convention we want to keep

BxDFs

template<class IncomingRayDirInfo>
struct BxDFName
{
    // each BxDF can choose float, vec3, etc
    using spectrum_t = some_type;
    using pdf_t = float; // most of the time
    
    //
    using sample_t = LightSample<IncomingRayDirInfo>;
    using interaction_t = surface_interactions::Anisotropic<IncomingRayDirInfo>;
    using cache_t = AnisotropicMicrofacetCache;

    //! NOTE: now all the extra `...` parameters of the following functions ARE IN THE STRUCT AS MEMBERS!
    
    // if the BxDF is isotropic, then use isotropic types for the `interaction` and `_cache` inheritance will make it work nicely
    spectrum_t eval(in sample_t _sample, in interaction_t interaction, in cache_t _cache);
    
    sample_t generate(in interaction_t interaction, inout float3 u);
    
    quotient_and_pdf<spectrum_t> quotient_and_pdf(in sample_t _sample, in interaction_t interaction, in cache_t _cache);
};

the individual BxDF structs can obviously have "extra" functions to help us define the 3 cardinal ones that are needed.

So for example instead of having a diffuse namespace and prefixing all functions with lambertian_cos, you could just have

namespace brdf
{
struct Lambertian;
}
namespace bsdf
{
struct Lambertian;
}

[devshgraphicsprogramming]

Dielectrics

Could look like this

template<class fresnel_t>
struct /*Thin,Smooth*/Dielectric
{
using spectrum_t = fresnel_t::spectrum_t;

fresnel_t frensel;

// ... and all the functions required to conform to BXDF concept
};

Where fresnel_t is a struct functor implementing frensel;

Cook Torrance BxDFs

The NDF

We can define NDFs as struct concepts too

template<typename scalar_t=float>
struct NDF
{
    // generation is always anisotropic
    template <class IncomingRayDirInfo>
    float3 generateH(in surface_interactions::Anisotropic<IncomingRayDirInfo> interaction, inout float3 u, out AnisotropicMicrofacetCache _cache);
    
    // isotropic versions
    scalar_t D(in float NdotH2) const;
    scalar_t Lambda(in float NdotX2) const;
    
    // anisotropic version overloads
    scalar_t D(in float TdotH2, in float BdotH2, in float NdotH2) const;
    scalar_t Lambda(in float TdotX2, in float BdotX2, in float NdotX2) const;
};

all stuff like roughness will be stored as optional members

NDF Traits

Instead of providing G1, G2, and G2/G1 for every NDF, we can make a trait

namespace bxdf::cook_torrance
{
// forward declaration so we can explicitly specialize, e.g. for GGX where optimized forms of the functions provided by the trait exist
template<class ndf_t>
struct ndf_traits;

namspace impl
{
template<class ndf_t>
struct ndf_traits
{
    using scalar_t = ndf_t::scalar_t;

    scalar_t G1(in float NdotX2) const {return scalar_t(1)/(scalar_t(1)+ndf.Lambda(NdotX2));}
    scalar_t G2(in float NdotV2, in float NdotL2) const {return scalar_t(1)/(scalar_t(1)+ndf.Lambda(NdotV2)+ndf.Lambda(NdotL2));}
    
    scalar_t G2_over_G1(in float NdotV2, in float NdotL2) const
    {
        const scalar_t lambdaV_plus_one = ndf.Lambda(NdotV2)+scalar_t(1);
        return lambdaV_plus_one/(ndf.Lambda(NdotL2)+lambdaV_plus_one);
    }
    
    // bits from `ndf/common.glsl`
    scalar_t dHdL(NDFcos, in float_t maxNdotV);
    
    // bits from `geom/smith/common.glsl`
    scalar_t VNDF(...) // and variants
    
    //! anisotropic variants omitted for brevity
    
    ndf_t ndf;
};
}

// default specialization
template<class ndf_t>
struct ndf_traits : impl::ndf_traits<ndf_t> {};
}

The BxDFs

Instead of providing G1, G2, and G2/G1 for every NDF, we can make a trait

namespace bxdf::brdf
{
template<class fresnel_t, class ndf_t>
struct CookTorrance
{
   fresnel_t fresnel;
   ndf_traits<ndf_t> ndf;
};
}

Complex BxDFs

Since HLSL2021 doesn't yet support Variadic Templates (and therefore tuple not variant can be constructed) and IIRC not even unions

But its possible to create the structs on the fly and rely on inlining to clean it all up.

[devshgraphicsprogramming]

should probably make it

template<typename spectrum_t>
spectrum_t diffuseFresnelCorrectionFactor(in spectrum_t n, in spectrum_t n2)

[devshgraphicsprogramming]

why are we making Sample, Interaction and MicrofacetCache template parameters, I think only the RayDirDistribution ought to be one (which then goes into the interaction and sample)

[Crisspl]

but u dont know if u want isotropic or anisotropic interaction at this point

[devshgraphicsprogramming]

btw could we make the MicrofacetCache's have a using typedef for the surface_interaction (iso vs aniso) it wants?

[devshgraphicsprogramming]

Its a bit sad that HLSL202x doesn't have SFINAE, because we could have just made isotropic and anisotropic the same struct and enable_if-ed the anisotropic interaction overload

However we have inheritance, so we can make the base class Isotropic, and inherit to make the Anistropic and add that overload, not as clean but will do

[Crisspl]

but why? this completely messes up typedefs got from BxDFBase (always isotropic)

[devshgraphicsprogramming]

hmm, good observation.

The thing is that an anisotropic BxDF should always be usable as an isotropic one (thanks to inheritance).

Maybe the BxDFBase should be adjusted (sepearate typedefs for aniso and iso)?

[Crisspl]

The thing is that an anisotropic BxDF should always be usable as an isotropic one (thanks to inheritance).

it kinda is, just pass the same values to ax and ay, it's just going longer way to compute the result. Which should be assumed, since you've intentionally chosen anisotropic (more generic) variant

[devshgraphicsprogramming]

improve my quotient_and_pdf to take a pdf_t

[devshgraphicsprogramming]

sample should always be the same thing, cache should tell us the interaction (iso vs aniso)

using sample_t = LightSample<ray_distribution_t>;
using interaction_t = MicrofacetCache::interaction_t<ray_distribution_t>;
using cache_t = MicrofacetCache;

P.S. I'm not sure whether HLSL202x lets us define template aliases, please check add this into AnisotropicMicrofacetCache and see if DXC chokes on this when actually used:

public:

template<class ray_distribution_t>
using interaction_t = surface_interactions::Anisotropic<ray_distribution_t>;

if it doesn't then use similar trick on Isotropic

[Crisspl]

I'm not sure whether HLSL202x lets us define template aliases

i assumed it doesnt, i'll try to make sure
its a pity hlsl2021 has no spec XD the only way to check things is to write code and see what dxc spits out

[devshgraphicsprogramming]

Move fast, break things, no docs = the Nabla DirectX way.

[Crisspl]

yeah, HLSL supports templated using statements for typedefs/aliases

[devshgraphicsprogramming]

@sunho can you suggest some function signatures for AOVs, I'm thinking

using albedo_t = _albedo_t; // float3 default
using aov_transmittance_t = _aov_transmittance_t; // float3 default

[devshgraphicsprogramming]

just the angle between a surface and a ray cosTheta

all the other stuff like IoR and so on will be member variables (this is why lambdas rule!)

[Crisspl]

so F0 in case of schlick would be a member as well right?
btw do you remember what f0 actually was?

[devshgraphicsprogramming]

so F0 in case of schlick would be a member as well right? btw do you remember what f0 actually was?

Yes.

ofc i remember, F0 is reflectance when the angle is 0 (dot product is 1)

[devshgraphicsprogramming]

inline as much as possible and get rid of the forwarding

[Crisspl]

what do you mean by forwarding?

[devshgraphicsprogramming]

function with same parameters being called with no change just because its layering one API to another

[devshgraphicsprogramming]

if it makes sense, delcare parameter structs in the bxdf namespace for the ndf functions and gather some of these inputs together, right now its tedious to read and typo prone (many parameters have the same type, you'll die)

[devshgraphicsprogramming]

this header needs to be renamed to ndf.hlsl and be a level up, then in this very place you need to include all the other NDFs so their specializations have a chance to appear before the default one

[devshgraphicsprogramming]

how much of all this will the GGX specialization also use?

[devshgraphicsprogrammingjenkins]

[CI]: Can one of the admins verify this patch?