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:

https://mathr.co.uk/blog/2018-11-18_newtons_method_for_periodic_cycles.html

https://mathr.co.uk/blog/2018-11-17_newtons_method_for_periodic_points.html

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

https://www.theregister.co.uk/2018/11/17/amp_kelvin_kilogram/

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... https://www.physics.mun.ca/~yakov/paperADA_soap_bubbles_AJP_2011.pdf

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 #filesystem #corruption :

$ sudo cp -avi libattr.so.1.1.0 /lib/x86_64-linux-gnu/libattr.so.1.1.0

cp: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107

Not many internet hits for PLT reloc type errors.

Managed to repair it with

$ sudo su -

# cat < libattr.so.1.1.0 > /lib/x86_64-linux-gnu/libattr.so.1.1.0

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.

I'm probably preaching to the choir here, but there absolutely _needs_ to be a federated version of GitHub/GitLab.

Let me host my projects' critical infrastructure (issue tracker, PRs, private repos etc) on my own servers, while also being able to interact and socialize with the rest of the open source world.

I'll keep saying this until someone builds it - I would do it myself if I had enough time on my hands right now.

This one binary searches for the surface of each component from its nucleus to far exterior in the direction of the target point. Finding the distance estimate in this solution is easy (just `length(point - nucleus) - length(surface - nucleus)`).

Finding the surface normal is harder: for circle-like components that become sphere-like the binary search ray direction is a close approximation, but cardioids are not sphere-like. One tangent is `i d/dz` at the boundary, but in the wrong frame...

Distance estimates for height fields only work if the height field is well-behaved (eg: height is a constant factor times 2D exterior distance estimate of Mandelbrot set) so you can bound the distance to the surface from a point by a constant factor times the vertical distance from the surface.

My desired height field for interior as solid balls is not well-behaved (in fact the magnitude of the gradient tends to infinity at the boundaries), so the height field approach is doomed to fail.

english ambiguity Show more

Atom domain coordinates can be calculated to construct a height field too, but I think a "distance estimate to nearest atom domain boundary" algorithm will work out to be an O(N^2), where N is the maximum iteration count, because you need to check all the other periods for each period.

The interior is easier because all the components are disjoint (except at single points). Atom domains overlap.

So it remains a concept for now, too hard for me...

The height of the interior components could be computed using the size estimate for the atom and the interior coordinate (multiplier map). Maybe |size| sqrt(1-|d/dz|^2)?

A distance estimate for this height field could be found for disc-like components by assuming the nearest point on the surface of the component is on the ray to the nucleus of the component, not sure how it would work for cardioid-like components...