Show more

Thursday's performance at Art Futura London went well.

I uploaded the diff-cast (with pure-digital recording, no audience/room sound) here:

More at:

preparing my in the language - next performance this Thursday 22nd November 2018 at Stour Space Hackney Wick UK, doors 7:30pm, part of London 3 day festival which includes talks and film screenings as well as performances.

Tickets and more info:

Some slight glitches in my first practice set due to extreme CPU near-overload, which scared me until I fixed the bug (don't reinitialize the reverb every sample, it's expensive). Fine now, I hope...

(see earlier in this thread for license details)

added vignette to my virtual pinhole camera model, using the formula for S(a) at (about half way down the page) licence CC-BY-SA by Alexandre Duret-Lutz

a little bit noisy, only 128 subframes

sense of scale is a bit strange because the background is modelled (conceptually) as a sphere at infinity, while the bubble has radius 1m in world units so would probably be resting on the ground...

vec3 glitch(vec2 pos) { if (length(pos) < 0.1) return fract(pos.xyy) / 0.1; else 0.0; }
vec3 color(vec2 pos) { return glitch(pos); }
// note no return in else branch - > undefined behaviour, surprised it even compiles...

"A bubble in Berlin" using this CC-BY-SA (DE) image by Ansgar Koreng, thus my video attached is also licensed CC-BY-SA (DE), if redistributing you may attribute me as @mathr or my full name, whichever makes sense in the context. Attribute Ansgar too of course (who has other nice panoramas on wikicommons)!

I managed to convert "sRGB image" to "intensity at a wavelength" (needed for my raytracer) by emulating a CRT monitor. That's why the colours are off, the I think the blue is too bright. Reference: figure 2

Looking again at the figure, the peaks of Blue and Green in the White image are at roughly 0.5, while the first Red peak is at 1.0 - this should allow me to make the colours more accurate (just make Blue and Green half as bright). I'm emulating the spectral peaks as simple humps: y=1/(1+((x-x0)/w)^2)

I wrote a bit about the algorithms I worked on recently, mainly to make the inflated Mandelbrot image a reality. I do intend to explain that in a future blog post, but here are two about Newton's method:

I'm very surprised amps weren't defined in terms of electron charge already. Makes much more sense.

brexit Show more

these soap bubbles have a constant thickness of 1000nm, my earlier soap bubble render varied the thickness from top to bottom which looked better. need to find research on how the thickness of soap bubbles changes with height, found one paper but that was for hemispherical bubbles resting on a surface...

long render finished! here's a preview

has some glitches at the soap bubble / glass intersections, presumably I need to do better CSG operations with difference or so:

Solids = Union(CheckerSphere Glass, Fringe)
Scene = Union(Solids, Subtract(SoapBubbles, Solids))

aaargh. went to bed with a render running, hoped it would be done by the time I work up. no! the lock screen kicked in, which paused the render, so now I have to wait some more while not sleeping :(

my mantra for rendering is now:

xset s off
xset -dpms
killall light-locker

stochastic tricks look bad, so I'm intersecting each atom domain with an inside out virtual surface just inside (a % size difference) that transmits rays through unchanged. very slow though. the edge that is done so far looks pretty good, a few hours until it is all done.

Refactored some code, now just have to write 2 "scene()" functions (one for DE only, one for DE plus Surface + next Ray output). Broke the existing examples, but made the Mandelbrot feasible. Attached is with "maxPeriod = 12; maxIters = 100;". Maybe the normals are wrong, because the edges of the cardioid look a bit odd. Could also be down to ray depth limited to 3, though. 32 subframes.

I think I'll have to do stochastic tricks to get the soap bubbles working, because I don't know how to do distance estimate based rendering with nested objects (atom domains are not disjoint...)

Soap bubble rendering works, but Raymond is way too slow for the Mandelbrot stuff, locked up my machine pegging the GPU, had to SysRq reboot.

I know why it is slow (it does full lighting calculations at every ray step instead of only after finding an intersection, and it does the maximum number of ray steps each time instead of stopping if it is close), but fixing it requires a lot of rewriting, and will probably require the top level user-written scene descriptions to be repeated three times (once for DE, once for DE plus normal vector, once for that plus material properties) because GLSL is insufficiently polymorphic to be able to write it just once. Maybe preprocessor macros? shudder....



This one is rendered with Fragmentarium's default distance estimation-based raytracer, I want to port my code to my own Raymond raytracer for spectral rendering of glass and soap bubbles but I fear it will be too slow, as Raymond is a few of orders of magnitude slower, and the image attached took already 10 mins to render as it is (so guesstimating at a whole day to render 1 image).

my inflated mandelbrot has 2 flaws

1. a straight line to the nucleus doesn't meet the surface at the nearest point (this flaw may be fatal, back to the drawing board...)

2. when checking if a point is exterior to a period P component, need to check that it is not interior to any component of lower period Q dividing P (I think this is why there is a "collar")

I just installed and used `debsums` to check for any other corruption of my system files, no issues found. There remains the many GB of /home that could have been affected, hopefully only files that were accessed in the time period would be affected (but with SSD wear levelling, who knows...).

I booted 4.19.1 and 4.18.18 too, so it could be those at fault and not 4.20-rc2. Or it could be impending hardware failure, or cosmic rays, or something else I haven't thought of.

Just had a scary issue with :

$ sudo cp -avi /lib/x86_64-linux-gnu/
cp: error while loading shared libraries: /lib/x86_64-linux-gnu/ unexpected PLT reloc type 0x00000107

Not many internet hits for PLT reloc type errors.

Managed to repair it with

$ sudo su -
# cat < > /lib/x86_64-linux-gnu/

I had to use a network connection to my rpi to extract the file from the libattr deb downloaded from the Debian archive, and copy back over network, because tar invoked by dpkg wouldn't launch (same error, noticed it first from sed failing noisily on terminal launch, probably bash completions or something).

This happened shortly after testing linux-4.20~rc2 this evening, maybe it has a bug in its ext4 filesystem? I will report it, just in case.

Show more

Welcome to, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that. This is part of a family of services that include mailing lists, group chat, and XMPP.