[Bf-cycles] build with OSL support

storm kartochka22 at yandex.ru
Thu Nov 10 19:30:52 CET 2011


Wrong, Diffuse uses uniform sampler, you need patch to make it
importance sampling.

Patch just add function, you need to uncomment call to
sample_cos_hemisphere_importance() by hands in bsdf_diffuse.h to see
difference. No big changes on my test scenes, except it work worse in
the case distant light close to bumpy surface, long shadows from bumps
render with more noise, but it expected, as importance sampling fire
less rays in angles close to surface and more when we close to normal
direction. 


Index: intern/cycles/kernel/kernel_montecarlo.h
===================================================================
--- intern/cycles/kernel/kernel_montecarlo.h	(revision 41743)
+++ intern/cycles/kernel/kernel_montecarlo.h	(working copy)
@@ -85,7 +85,34 @@
 	*omega_in = randu * T + randv * B + costheta * N;
 	*pdf = costheta *M_1_PI_F;
 }
+/*
+ * from http://www.rorydriscoll.com/2009/01/07/better-sampling/
+Vector3 Sample::CosineSampleHemisphere(float u1, float u2)
+{
+    const float r = Sqrt(u1);
+    const float theta = 2 * kPi * u2;
+ 
+    const float x = r * Cos(theta);
+    const float y = r * Sin(theta);
+ 
+    return Vector3(x, y, Sqrt(Max(0.0f, 1 - u1)));
+}
+*/
+__device_inline void sample_cos_hemisphere_importance(const float3 N,
+	float randu, float randv, float3 *omega_in, float *pdf)
+{
+	float z = sqrtf(max(0.0f, 1-randu));
+	float r = sqrtf(randu);
+	float phi = 2.f * M_PI_F * randv;
+	float x = r * cosf(phi);
+	float y = r * sinf(phi);
 
+	float3 T, B;
+	make_orthonormals (N, &T, &B);
+	*omega_in = x * T + y * B + z * N;
+	*pdf = 0.5f * M_1_PI_F;
+}
+
 __device_inline void sample_uniform_hemisphere(const float3 N,
 											 float randu, float randv,
 											 float3 *omega_in, float *pdf)
Index: intern/cycles/kernel/svm/bsdf_diffuse.h
===================================================================
--- intern/cycles/kernel/svm/bsdf_diffuse.h	(revision 41743)
+++ intern/cycles/kernel/svm/bsdf_diffuse.h	(working copy)
@@ -76,6 +76,7 @@
 
 	// distribution over the hemisphere
 	sample_cos_hemisphere(m_N, randu, randv, omega_in, pdf);
+//	sample_cos_hemisphere_importance(m_N, randu, randv, omega_in, pdf);
 
 	if(dot(sd->Ng, *omega_in) > 0.0f) {
 		*eval = make_float3(*pdf, *pdf, *pdf);







В Чт., 10/11/2011 в 12:22 +0900, Yasuhiro Fujii пишет:
> Yes, they converge to the same value. however, difffuse() uses
> cosine-weighted importance sampler while my oren_nayar() currently
> uses uniform sampler, they have different variances. (Sorry for my
> poor English skill...)
> 
> After night's sleep, I started to think that it is a technical detail,
> it can be resolved later when it becomes a problem.
> OK, I will change the patch to unify diffuse() and oren_nayar().
> 
> 
> On Thu, Nov 10, 2011 at 2:23 AM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
> > I think it should converge to the same result when roughness is zero?
> > At least in blender internal this seems to be the case. Also, looking
> > at your code: when sigma = 0, we get m_a = 1 and m_b = 0. As a result,
> > all that is left is nl/M_PI, i.e. a regular diffuse BSDF?
> >
> > Brecht.
> >
> > On Wed, Nov 9, 2011 at 4:27 PM, Yasuhiro Fujii
> > <y-fujii at mimosa-pudica.net> wrote:
> >> pros:
> >> + Simplify the UI.
> >> + Simplify the code.
> >>
> >> cons:
> >> + oren_nayar() and diffuse() have different convergence behavior even
> >> if roughness == 0.0, yield very different looks if convergence is not
> >> sufficient. In some scene, designers may want to choose oren_nayar()
> >> even if roughness == 0.0.
> >> + Thus users must know roughness = 0.0 is specialized.
> >>
> >> I can't decide it because of my poor experience, especially designer's side.
> >> What do you think about their cons?
> >>
> >>
> >> On Wed, Nov 9, 2011 at 11:37 PM, Brecht Van Lommel
> >> <brechtvanlommel at pandora.be> wrote:
> >>> Hi,
> >>>
> >>> What do you think about implement this as a Roughness input for the
> >>> Diffuse BSDF node, instead of a separate one? Internally it can still
> >>> be a separate closure/BSDF, but it could just check if(roughness ==
> >>> 0.0) diffuse() else oren_nayar().
> >>>
> >>> Brecht.
> >>>
> >>> On Wed, Nov 9, 2011 at 6:55 AM, Yasuhiro Fujii
> >>> <y-fujii at mimosa-pudica.net> wrote:
> >>>> The O-N patch must be updated, however, the compile errors don't seem
> >>>> to be caused by this patch. I guess that they are due to tomato branch
> >>>> merged.
> >>>>
> >>>> Blender's source (including cycles) will be changed a lot this week,
> >>>> due to a Branch Merger hurricane week:
> >>>> http://www.blendernation.com/2011/11/07/developer-meeting-notes-november-6-2011/
> >>>>
> >>>> I will update the patch when cycles get to be able to compile again.
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Bf-cycles mailing list
> >>> Bf-cycles at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-cycles
> >>>
> >> _______________________________________________
> >> Bf-cycles mailing list
> >> Bf-cycles at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-cycles
> >>
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles




More information about the Bf-cycles mailing list