the most trivial way I'd come up with.

vec3 diffuse(float u,float v)
{
	float radius = 1.f-sqrt(v);
    u = u * 2.f * FLT_PI;
    return vec3(cosf(u)*radius,cosf(u)*radius,v);
}

You can google information about it using "uniform hemisphere sampling" or in particular for diffuse "cosine hemisphere sampling"

Brute-force path tracing using Cosine-Weighted Hemisphere Sampling applied to the Rendering Equation:

(P.S.: the title is in Dutch, since I need to teach this in a Dutch course, but is not really required to understand the big picture)

Once, you have sampled a vector over a standard hemisphere (e.g. hemisphere spanned about the z axis) using Cosine-Weighted Hemisphere Sampling, you need to construct an orthonormal base around the actual shading normal to transform your sampled vector from a standard hemisphere to the hemisphere spanned about the shading normal.

By including the cosine factor in the sampling strategy, you can completely eliminate noise caused by this factor. It is a common practice to include both the BRDF and cosine factor in the sampling strategy to reduce all noise caused by these factors, but that is a no-op for a Lambertian BRDF. Since, the cosine is part of the pdf, it cancels the cosine of the integrand. (You can even "cancel" the pi of your Lambertian BRDF. )

To construct the orthonormal base starting with just one basis vector (i.e. shading normal), you can use one of the methods in this repository.

To combine all of this in a path tracer, you can even take a look at this repository, pick a language you like, and you can easily find the few statements related to these topics.

1 hour ago, IsItSharp said:

Thanks for your reply!

I don't think that approach checks if the point is actually outside the intersected sphere?

What's about u and v? Wikipedia told me they are calculated like this:

    double u = p.x / length(p);
    double v = p.y / length(p);

But what is the intersected Sphere used for?

it generates a vector on the sphere, not inside, not outside, but exactly on a unit sphere.

u and v are two input seeds that you have to provide, to get the corresponding output vector. This values depend on your sampling approach, could be two fully random vectors, or maybe based on stratified sampling, could be a regular grid, some sequence (e.g. halton) or however you want to approach it.

It usually helps to split a big problem into smaller stages and get every step working individually.

From the image, it looks as if something with the first hit is wrong, aka camera rays, as there is some interlacing. (I would guess your "SetPixel" might be somehow wrong.) For debugging, you could try to just visualize the first hit and output the pure diffuse color. If that works, add some explicit tracing to a light source (e.g. point light), with old school lighting calculations.

make a 32x32 image and step with your debugger pixel by pixel, check why every 2nd line is black (or not written). (From a glance on it, your ray generation code looks fine. Maybe avoid doing halton for now, just to keep the count of possible error sources low.