functor

[stasis-field]

[stasis-field]

I’m getting close to the end of my masters now (a month or so to go). I still have quite a bit of writing to do, but I have a home-page for the project now.

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.

Maybe once this is all out the way I’ll get back to doing gifs... idk tho

[stasis-field]

The real miracle of modern computing is that I can force my wireless mouse to stop responding to movement (clicks work fine of course), with 100% reproducibility, by quitting Chrome.

Explain that one, atheists. 

[stasis-field]

From Xcode 8. If only there were room for that extra ‘e’.

[stasis-field]

Russian Roulette:

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

Then just keep hitting :bw until you see something which literally kills you from shame.

[stasis-field]

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.

While the waveguide model can be applied to arbitrary rooms, the image-source model used here can only be applied to cuboid rooms, so now I have to replace it with the proper raytracing method, which can also cope with arbitrary rooms.

[stasis-field]

Been using git submodules for ages, and never been entirely happy with the workflow (git clone, forget to use --recursive, google ‘git check out submodules’, git submodule init && git submodule update)... getting a working copy of the repo should just require a ‘git clone’, which isn’t true with submodules. Plus, using submodules puts dependencies within your source tree, which I don’t really like.

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.

It’s still not a perfect system - in particular, I’d like a way of using find_package on ExternalProjects, so that I can use the library/include paths that the externals export, rather than hard-coding library names to use. Unfortunately I haven’t been able to configure the dependencies in a way that allows this (yet).

[stasis-field]

Wrote my first iterator adapter today. I think I understand why Boost has a library dedicated to this stuff now.

(code review plox if you’re feeling nice :3 )

[stasis-field]

foldingcookie2 replied to your post: This week on ‘developing for OpenCL really...

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.

I'm also really excited to see how portable this is. The appeal of OpenCL over CUDA was that my code could run in more places, but given how rubbish the support for my system is, I wouldn't be surprised if the version that works for me fails completely on any other machine...

[stasis-field]

This week on 'developing for OpenCL really sucks':

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; }

If anyone knows why this might be the case, please (please) let me know.

[stasis-field]

The raytracer I’m writing uses voxelised geometry to speed up raycasting - the scene is split up into boxes, where each box stores a list of the triangles that intersect with it. When you shoot a ray, you can walk along the voxels that the ray hits very quickly, and then you only need to check for ray-triangle intersections with the triangles contained by those voxels (rather than checking against all the triangles in the scene). This is pretty standard for most forms of raytracing.

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.

Here's the problem: That's all C++14, and I need to do the traversal in OpenCL C which doesn't even have function pointers. I'm not sure how to simulate passing in a callback, but I really don't want to duplicate the traversal algorithm for each operation I might need it for. Macros to the rescue?

[stasis-field]

Animated rayfronts.

Not sure how to tie this in with the waveguide view - maybe I’ll just show a few planes from the mesh, rather than the whole thing.

[stasis-field]

I need a name for this app that’s better than ‘wayverb’

[stasis-field]

There’s a small chance I just found my first second compiler bug wooooo

please send help

[stasis-field]

No apparently I’m just dumb and using aligned types in stl containers isn’t guaranteed to be safe.

[stasis-field]

There’s a small chance I just found my first second compiler bug wooooo

please send help

[commodorez]

reuben-thomas answered your question:Question Time:

Didn’t have the turtle robot but I played with the logo language a bit when I was 13 or 14. There was a demo where it would switch into 3D mode and draw a wireframe space-shuttle which blew my mind. I was hopeless at writing my own stuff though.

That sounds awesome!  I’ve never heard of a 3D version of LOGO, but now I want to play with that.

[stasis-field]

donning rose-tinted nostalgia-goggles:

[stasis-field]

Me: ok, simple feature this one

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*

Me: it happened again