Today I'm mostly working on 'nnirror', my art project about training neural networks to recognize themselves.

The ego network is trained using a generative adversarial network against the id network. Ego aims to recognize its own weights (output 1) vs everything else (output 0 for id's attempts to fool ego, output 0 for random input too).

The network weights are visualized at the top left of the first image, below is the normalized change since the previous epoch.

The second image plots the parameters (learning rates, momementa, etc), on the left if the ego network failed to achieve enlightenment after 1000 epochs, on the right if it managed to score above 4.5 in that time. The total score is twice the top graph minus the two lower graphs.

strobing gif Show more

stroboscopic gif Show more

stroboscopic gif Show more

. - training neural networks

o - training generative adversarial neural networks

O - training generative adversarial neural networks to recognize their own weights

medication Show more

Added compile-time control to set the preferred distance between nodes of different colours, relative to the average distance between nodes evenly spaced on the sphere. At 2.0 the structure is more uniform, at 0.5 it is more clustered with patches of high and low density.

However the mesh breaks more often when setting the distance too low, and the sound is too loud (and overloading CPU) when setting the distance too high.

With 4000 nodes I needed to increase the neighbourhood from 8 (this image is with 16) to avoid the breaking/overlap as described in the blog post. I suspect an alternative solution is to reduce the node movement speed when I increase the node count, so that it is relative to the cell size.

With this high node count and speed there are interesting emergent dynamics with locally-dense pockets between less-dense regions.

But it doesn't run at a realtime framerate any more, my CPU takes 1m15s to simulate 1min at 60fps, before even doing any rendering. With rendering:
512x256: 47fps
1024x512: 46fps
2048x1024: 32fps
4096x2048: 8fps
8192x4096: 2fps

Reducing the neighbourhood count speeds simulation up enough to be realtime, but rendering is the bottleneck.

(see earlier in this thread for license details)

added vignette to my virtual pinhole camera model, using the formula for S(a) at galerie-photo.com/stenope-cerc (about half way down the page)

commons.wikimedia.org/wiki/Fil licence CC-BY-SA by Alexandre Duret-Lutz flickr.com/photos/gadl/4561856

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...

"2D.frag"
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"

commons.wikimedia.org/wiki/Fil 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:
marcelpatek.com/LCD.html 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)

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))

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")

Show more
lurk.org

Welcome to post.lurk.org, 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.