Issues extending sample 6 to include constant medium geometry

[YayIguess]

I'm brand new to OWL and OptiX so forgive me if this is a very obvious question.

I'm trying to extend sample 6 to include volumes like how Ray Tracing The Next Week does them (see listing 68 for the code) and I'm having issues with my intersection program where nothing intersects and I'm pretty sure I'm just misunderstanding something in how Optix/OWL work but I'm having trouble figuring out what. I might be going about this in a completely wrong way.

__device__ void constantMediumSphereIntersectProg()
{
	const int primID = optixGetPrimitiveIndex();
	const auto& self = owl::getProgramData<ConstantMediumGeomType>().prims[primID];
	PerRayData& prd = owl::getPRD<PerRayData>();

	const vec3f org = optixGetWorldRayOrigin();
	const vec3f dir = optixGetWorldRayDirection();
	float hit1_t = optixGetRayTmax();
	float hit2_t = optixGetRayTmax();
	const float tmax = FLT_MAX;
	const float tmin = FLT_MIN;

	const vec3f oc = org - self.constantMediumSphere.sphere.center;

	const float a = dot(dir,dir);
	const float b = dot(oc, dir);
	const float c = dot(oc, oc) - self.constantMediumSphere.sphere.radius * self.constantMediumSphere.sphere.radius;
	const float discriminant = b * b - a * c;

	//	if (!boundary->hit(r, FLT_MIN, FLT_MAX, rec1, rand_state))
	//		return;
	if (discriminant < 0.0f)
		return;

	float temp;
	temp = (-b + sqrtf(discriminant)) / a;
	if (temp < tmax && temp > tmin)
		hit1_t = temp;
	else
	{
		temp = (-b - sqrtf(discriminant)) / a;
		if (temp < tmax && temp > tmin)
			hit1_t = temp;
		else
		{
			printf("WTF\n");
			return;
		}
	}

//	if (!boundary->hit(r, rec1.t+0.0001f, FLT_MAX, rec2, rand_state))
//		return false;
	float temp_tmin = hit1_t+0.0001f;
	temp = (-b + sqrtf(discriminant)) / a;
	if (temp < tmax && temp > temp_tmin)
		hit2_t = temp;
	else
	{
		temp = (-b - sqrtf(discriminant)) / a;
		if (temp < tmax && temp > temp_tmin)
			hit2_t = temp;
		else
			return;
	}

	if (hit1_t < tmin)
		hit1_t = tmin;
	if (hit2_t > tmax)
		hit2_t = tmax;

	if (hit1_t >= hit2_t)
		return;

	if (hit1_t < 0)
		hit1_t = 0;

	const auto distance_inside_boundary = (hit2_t - hit1_t) * optixGetRayTmax();
	const auto hit_distance = self.constantMediumSphere.neg_inv_density * log(prd.random());

	if (hit_distance > distance_inside_boundary)
		return;

	hit1_t = hit1_t + hit_distance / optixGetRayTmax();;

	optixReportIntersection(hit1_t, 0);
}

Any help is greatly appreciated!
Link to all of the optix code for reference

[ingowald]

Hey - debugging somebody else's code is always hard (hard enough to debug one's own code, right?), in particular by just looking at code snippets. But given your "am i going about this in the completely wrong way" comment you are well aware of that; and I think at least on that front I can tell you that no, you're not - at first glance that all looks pretty much the right way to go about it.

So, a few comments that may cause issues - or at least help in finding them:

• to get the ray origin and direction you use optixGetWorldRayXyz(); as long as you don't have any instances with non-unit transforms that shouldn't matter, but if you do: I think the intersection program is supposed to be executed in local space (optixGetObjectRayXyz()). Again i don't think that's causing the issue, but might be worth checking on.

• somewhat more suspicious: i think you're tyring to compute entry/exit into that sphere into hit_t0 and hit_t1 - but I'm not sure you're doing that right. One thing that struck me is that the first one (which i suppose to be the entry distance) is using "-b PLUS sqrtf", but if a is positive (as it will be) then that's the LARGER of the two roots. And I see you do have "some" check in there to try and catch that (love that "WTF" printf :-) ), but that won't actually get triggered if that larger root is inside the valid interval. Another reason I suspect this to be fishy is that if you look closely you'll see hit2_tmp is computed in the SAME way (with a PLUS).

• in general, a tip for debugging such code: a procedure i found useful for debuggin intersection, ch, ah, rg, etc programs is the following: first, use optixGetLaunchDimensoina dn optixGetLaunchIndex to compute wihch pixel you are in, and in particular, compute whether you are in the CENTER pixel of the screen. These values are all visible in all program. Then set a "bool dbg = ..." variable to true ONLY if you're in that center pixel. Then third, do some printf debugging wiht an "if (dbg) printf(...)" - now you know that those printouts will ONLY trigger for the center pixel, so you can more easily set up a situation where you have an expectation of what SHOLD happen, and can check with the outputs what DOES happen - without you getting overwhelmed with a deluge of printfs from millions of other pixels.

Hope that helps. Let me/us know how this goes please.

[YayIguess]

I think the second part of your suggestion did the trick! Thank you, that would have taken me way too long to catch on my own!

Now that that is solved I do have another question that isn't related to any changes I've made. Is there a reason the images generated by the sample program are so much darker than the book's code? Even trying to make a white Lambertian sphere using Lambertian{ vec3f(1.0f, 1.0f, 1.0f) } gives a sphere with a very distinct blue-ish hue to it while the code from the book does give a much more white sphere using the same colour values.

[ingowald]

"Probably" related to some light source settings, but honestly don't know. Another possible explanation (though tno sure it applies in this particular example): if it's a path tracer you may also get a blueish tint if there's lots of bluish stuff around it, or if there's a background env-map with an on-average blueish tint, etc. You can always use the printf-debugging tip from above to follow a given paths' individual steps. If you do the same "if (centerPixel) printf(...)" things in raygen, isec, CH, etc, then you'll get a constant stream of outputs for the center pixel only - if you then let that run for multiple frames (with different RNG values each frame) you should be able to see if any of these values tend towards blueishness. I'm sure there's better ways of doing that, but that's how I wold go about it :-)

[YayIguess]

Hmm, I'm trying that out but I'm actually not getting any output from printf. I have this at the top of the OPTIX_RAYGEN_PROGRAM(rayGen)() function.

	vec3i ld = optixGetLaunchDimensions();
	vec3i li = optixGetLaunchIndex();

	vec3i center = vec3i(ld.x/2, ld.y/2, ld.z/2);
	if(li == center)
		printf("Coordinates: %d %d\n", li.x, li.y);

even commenting out the if guard I don't get any output.

[YayIguess]

Actually was able to fix it without using printf(). Although I am still interested why it wasn't working...
But to fix the colour issue I just needed to gamma correct by changing
self.fbPtr[pixelIdx] = owl::make_rgba(color * (1.0f / self.samples));
to
self.fbPtr[pixelIdx] = owl::make_rgba(sqrt(color * (1.0f / self.samples)));