functor

Having a website is difficult, because I spend a lot of my time fixing up the page layout instead of actually working on content, which is the really critical thing at the moment. Every time I think “that was the last website change ever,” I end up thinking of something I’ve forgotten. Oh well.

Check it out, let me know what you think. There’s still no binary release, but that should be up in the next few weeks.

cd my/current/project vim src/**/*.(h|cpp)

Comparison of the frequency responses of a simplified image-source model and a waveguide model in a cuboid room. The levels and modal responses seem to match. Whoop.

Today, I switched my current project to use cmake’s ExternalProject facilities, and I’m pretty happy with how it turned out. ExternalProject can download stuff from everywhere, so although most of the libraries I depend on are on GitHub, it can also fetch things like FFTW which distribute a source tarball from their own website. It runs as part of the cmake/configure stage of the build, and it stores the dependencies in the build tree rather than the source tree. This means that for the most part, the process of downloading, building, and linking against external projects is completely transparent, which is really cool. You invoke make, it gathers and builds all the bits-and-pieces you’ve specified, and then your code is free to link against the results.

I also cleaned up the build in general, so now it’s about as self-contained as possible, and should work immediately on any reasonably modern macOS, regardless of which libraries are already installed on the system.

does “Intersection ret = {};” necessarily initialize ret to something sane (.intersects=false)? I’d pass the accumulator a simple float distance (potentially inf) rather than an Intersection just to decrease # of moving parts

Yeah no it definitely zeroes all the bits, which sets .intersects to false by virtue of ‘false’ and ‘no bits set’ being the same thing in C. The idea of getting rid of the .intersects field is good though, I’ll probably do that.

I tried changing things one-at-a-time until it worked again - my working version looks like this now:

#define INTERSECTION_ACCUMULATOR \ const Triangle tri = triangles[triangle_index]; \ const float distance = triangle_intersection(tri, vertices, ray); \ if (EPSILON < distance && (!ret.intersects || distance < ret.distance)) { \ ret.primitive = triangle_index; \ ret.distance = distance; \ ret.intersects = true; \ } Intersection ray_triangle_intersection(Ray ray, const global Triangle * triangles, ulong numtriangles, const global float3 * vertices) { Intersection ret = {}; for (ulong i = 0; i != numtriangles; ++i) { const ulong triangle_index = i; INTERSECTION_ACCUMULATOR } return ret; }

The thing that 'fixed' it was moving the triangles[triangle_index] lookup to its own line. I can only assume the AMD OpenCL compiler has taken some artistic liberties with the sequence point rules.

The following code comes from my OpenCL kernel, and is designed to find the intersection between a ray and a set of triangles, which has the smallest distance along said ray. triangle_intersection is a function which takes a specific triangle and a ray, and returns the distance to the triangle if there is an intersection, or 0 otherwise.

The 'fun' bit is that this code works properly when compiled for CPU, but gives garbage results when compiled for GPU. Why? No idea.

Intersection intersection_accumulator(Ray ray, ulong triangle_index, const global Triangle* triangle, const global float3* vertices, Intersection current) { const float distance = triangle_intersection(triangle[triangle_index], vertices, ray); if (EPSILON < distance && (!current.intersects || distance < current.distance)) { return (Intersection){triangle_index, distance, true}; } return current; } Intersection ray_triangle_intersection(Ray ray, const global Triangle * triangles, ulong numtriangles, const global float3 * vertices) { Intersection ret = {}; for (ulong i = 0; i != numtriangles; ++i) { ret = intersection_accumulator(ray, i, triangles, vertices, ret); } return ret; }

You might want to use voxel traversal for operations other than just ‘finding the closest intersection’ - for example, you can do a fast inside/outside check by counting the number of intersections along a ray (the starting point of the ray is inside the geometry if the number of intersections is odd).

In terms of implementation, it might look like this:

using traversal_callback = std::function<bool( const geo::ray&, const aligned::vector<size_t>&, float)>; void traverse(const voxel_collection& voxels, const ray& the_ray, const traversal_callback& fun);

The callback takes a ray, and a vector of primitives inside the current voxel, and returns whether or not the traversal should continue. In the callback, you can either ask to quit as soon as you find an intersection, or you can ask to keep going, storing some count of intersections. Pretty flexible.

Animated rayfronts.

Me: just need to update the UI and add a couple of loops to the engine so it handles multiple inputs rather than single ones

Me: *rewrites entire multithreaded interface to the engine*