Show more

I resumed work recently on my reaction-diffusion explorer stuff (project started 2008 or so).

Minor improvements to the code, mainly using texture arrays instead of separate textures or atlases, which as a bonus allows mipmaps to be used too for much smoother appearance.

I also added an backend to the code, because really dislikes my laptop's onboard sound card, xruns all over. OSS works fine at similar latencies.

Next steps include getting the rdex-server side of things running again (probably need to port from 2 to Python 3, and has been replaced by in I think).

Followed by setting up a WIFI hotspot from the machine's card with captive portal to the rdex-server website, and an Android app to access it in fullscreen (because the browser UI adds unsightly scrollbars that aren't necessary if the address bar is hidden).

rdex.mathr.co.uk
code.mathr.co.uk/rdex-client/s

Using and commands to make a out of image thumbnails sorted by average level:

```
montage -tile ${COLUMNS}x${ROWS} -geometry ${TILEWIDTH}x${TILEHEIGHT}+0+0 $( identify -colorspace RGB -format "%[fx:mean] %[filename]\n" in-*.png | sort -nr | cut -d\ -f 2 ) out.png &&
convert tmp.png -colorspace RGB -geometry ${WIDTH}x${HEIGHT} -colorspace sRGB out.png
```

I didn't yet figure out how to get the -correct colour space conversion to happen inside the montage's own rescaling, so I render at natural size and with convert afterwards.

The last image is the good result, the other two are gamma-incorrect, thus they appear too dark on screen (and presumably print too).

Another good iteration loop formula is:

```
z := z^p + c
z := (|x| + i |y|)^p + c
z := (|x| + i |y|)^p + c
z := z^p + c
```

(p = 2)

Over 2 minutes to build each time I make a typo :(

Fixed them now though, PNG comment metadata loading works in the GTK GUI.

No more copy/pasting values from various windows into text files to save my explorations!

Implemented PNG comment metadata saving. Still working on PNG comment metadata loading. Nearly there I think. The build times with are killing me though.

I re-enabled "ignore isolated glitches" for non-progressive rendering (as used in the CLI renderer, but not the GTK GUI). This speeds up high resolution perturbation rendering at the cost of inaccuracy (hopefully invisible after downscaling).

Theoretical worst case is 1/4 of pixels being wrong, but that is highly unlikely in practice.

Added a new feature to et-gtk: quick image saving. The time of program launch is stored, and pressing 's' saves an image with this timestamp and a sequence number in the filename. Uses the 'xdg-userdirs' (to find "~/Pictures" regardless of language) and 'time' packages (to get the time and format it).

Eventually the PNG files will contain metadata (formula, coordinates, etc) that can be reloaded into the et GTK GUI, and I want to add a batch mode to the CLI renderer so I can point it at a bunch of such PNGS with options like "re-render all of these at higher resolution".

Even later I want to add an 'r' shortcut to add to a render queue, so I don't need to launch the CLI renderer manually.

Working on 'et' (my escape-time program) this morning.

I added presets from 1x1 through 8x8, selectable by keypress. It already did supersampling but you had to enter 3 numbers in a modal dialog.

The calculations of the array used for progressive image rendering were annoyingly slow, so I'm now caching them on disk using the xdg-basedir and vector-mmap packages (et is written in ). I also need the directory and filepath packages for this part.

The arrays get quite big, almost 700MB total for all supersampling sizes with a base resolution of 1024x576 pixels (it takes up 6 bytes per pixel). Changing the base resolution size means recalculating and storing another set of arrays. Cache will bloat!

So I'm thinking there might be a better procedural way to do what the arrays do, which is style interlacing (coarse pixels getting gradually finer in a multipass rendering) with the pixels in each pass ordered so that the center gets rendered first and it spreads out towards the edges.

So in short I need a cheap function from (ImageWidth, ImageHeight, PixelIndex) to (PixelX, PixelY, PixelWidth, PixelHeight), because using anything other than to increment PixelIndex is much too slow in Haskell.

An excerpt from the parameter plane of this formula iterated in a loop (p = 2):

````
z := z^p + c
z := (|x| - i y)^p + c
z := (x - i |y|)^p + c
```

got sRGB gamma-correct scaling working in et, is a bit blurry because it uses mipmaps instead of more advanced (slower) algorithms like GIMP does, but the brightness is good.

before today's coding, the output in the et window was too dark (saved PNGs were brighter when downscaled by GIMP)

key things were: GL_SRGB8_ALPHA8 instead of GL_RGBA in texture specification; glEnable(GL_FRAMEBUFFER_SRGB) to do gamma-correct blending, and manual linear->sRGB in the final "display texture to screen" fragment shader because GtkGLArea does not expose a way to get an sRGB default framebuffer (yet; I filed a ticket)

claude boosted

Sonic Electronics Festival @ IKLECTIK London Thursday 30 May - Sunday 02 June Workshops Talks Concerts with London artists & International line-up Lucia Farinati @ninapower Laura Netz Isn'tses Tim Drage Lisa McKendrick Blanca Regina Chris Speed SLOW SLOW LORIS @alessandraeramo Bioni Samp Vera Bremerton Tony Morton + more TBC
Supported by Arts Council England

I added light sampling to Raymond: for diffuse opaque surfaces it is vastly more efficient (less noise for given rendering time) than random sampling, at the cost of double the number of rays to trace (an additional one from each surface hit directly towards a light).

Not so beneficial for shiny opaque surfaces in one test. And it breaks rendering of transparent objects (refractive caustics disappear).

code.mathr.co.uk/raymond/commi

spoiler 

for viewing

depth map exported from (one of the examples that comes with it)

horizontally repeating fractal texture made with (modulusx final transform).

combined with homemade software. final image had autolevels applied to brighten it up before downscaling to 1920x1080@100dpi

I think this one turned out ok despite the depth discontinuities.

June 20th

facebook.com/events/3318283907
tickets.partyforthepeople.org/
residentadvisor.net/events/126

> Algorave+friends return to Corsica Studios for a two room featuring: Lil Data (PC Music) // Heavy lifting (Pickled Discs) x Graham Dunning (Fractal Meat) // Miri Kat (Establishment) // Deerful // Hard On Yarn Sourdonk Communion (Hmurd x peb) // Class Compliant Audio Interfaces x Hellocatfood (Computer Club/Keysound) // Digital Selves // Mathr // xname // BITPRINT // Deep Vain // Hortense // Tsun Winston Yeung // +777000 // Coral Manton // Rumblesan + more TBA

spoiler 

claude boosted

The final ROM of What Remains is out! 🎉🎊

What Remains is an 8-bit interactive fiction and adventure video game for the about environmental issues, the manipulation of public opinion, and whistleblowing.

iodinedynamics.com/whatremains

for viewing

map exported to from my "raymond" thingy implemented in inside , converted to using . EXR data must be in [0..1] for GIMP to understand it (otherwise it clips, not sure if it's clipped by FragM or GIMP). Not sure if sRGB non-linear response curve is mangling my data.

texture from a photo I took, cropped into a narrow vertical strip and made in

depth and texture combined with . took many iterations to get something that didn't make my eyes hurt too much. depth is jarring, too-small texture detail is distracting.

Refs:
- paulbourke.net/dataformats/pbm for PFM file format (like PGM/PPM but float32 data)

get 1.2 on with :

- make sure your system is up to date github.com/RadeonOpenCompute/R

- add the rocm apt repository github.com/RadeonOpenCompute/R

- install rocm-opencl-dev (using upstream kernel drivers) github.com/RadeonOpenCompute/R

- do NOT try to mess with anything dkms, it won't work

- purge mesa-opencl-icd and pocl-opencl-icd, they get in the way and stop the amdgpu icd from loading correctly(*)

implementation doesn't go as high as OpenCL version 1.2, and is only, thus usually slower. There was a proprietary CPU-based OpenCL implementation that I found in some random backports repository once, but in my test it was very slow, and it got uninstalled during my tinkering

tested on RX 580 GPU with Ryzen 2700X CPU, don't know about other hardware, maybe check for support online or just try it

I used Fractorium for testing, it needs OpenCL >= 1.2.

(*) works for me, your mileage may vary

render a vertical strip that repeats horizontally in (possibly also other software like or ). possible use case: texture for generation.

0. start with some flame
1. add a Final transform with linear variation weight 0 and modulusx weight 1. its affine transform should be reset to identity.
2. set flame Width to 256px, and Scale to 128.0 (presumably half the width works in all cases).
3. make sure camera rotation and offset are 0.0
4. render!

Problems:

- a small seam is still visible in Firefox when zooming in, possible workaround is to render bigger, tile in , then downscale and crop, to make the seam as (subpixel) small as desired

- "overlaps" in the fractal structure, but I don't care about that (yet)

Example:

- mathr.co.uk/tmp/Flame_2019-05-:

- mathr.co.uk/tmp/Flame_2019-05-

Show more
post.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.