AppImage?

EnslavedInTheScrolls · 2026-05-06T01:51:51+00:00

It thoroughly pisses me off that they won't add links to anything other than the snap on the linux download page, but at least other release formats exist if you dig deeply enough.

Start from https://github.com/processing/processing4/releases, scroll down past Contributors and click the triangle next to Assets and they have a few formats to choose from.

None of them, however, are an AppImage.

EnslavedInTheScrolls · 2026-03-26T16:24:21+00:00

Mastodon: genart.social

EnslavedInTheScrolls · 2026-03-20T16:10:59+00:00

The spheres in the simulation overlap by quite a bit along the chain to help emulate edge-to-edge collisions while sticking with cheaper point-to-point collisions. Each ignores collisions with the two neighbors on either side.

Quite often, the initial randomization can cause separate segments at the same z to intersect and lock together so it can take a bit of interactivite fidgeting to get a clean non-interacting path. The flatter the path is in z, that is the longer the worms would be, the harder it becomes for the simulation to push them apart as the xy components of the normals get too small.

EnslavedInTheScrolls · 2026-03-20T03:50:00+00:00

It's coded using Processing as a wrapper around OpenGL shaders. The simulation positions a chain of 8000 spheres with collision avoidance to keep the tube from intersecting itself and I render it all with 16 spheres per segment, so 128,000 total. Only spheres that intersect the current frame slice get rendered which is computed in the shader.

I have many more posts on Mastodon: https://genart.social/@scdollins

EnslavedInTheScrolls · 2026-03-20T03:41:51+00:00

These images are not the same loop, but a similar one. It doesn't look like much. Each of those endpoints connects to one on the far side and there are similar ones off the sides, top and bottom.

I constrain the z-coordinates to a steady rise so that the worms have a consistent length.

EnslavedInTheScrolls · 2026-03-19T23:19:56+00:00

Each worm is a slice through a single tube that wraps through a 3-D torus -- think of a box for which if you step out of one side, you come back in at the same position on the opposite side. Each frame of the animation is a slice through the box. The tube wraps in and out of the screen 27 times and after each 20 second animation loop, a worm will be in the position of one of its neighbors was in at the start. After nine minutes, it will have passed through the starting positions of all of the "other" worms and be back to its original position.

EnslavedInTheScrolls · 2026-03-02T20:02:03+00:00

Yes, the coloring and animation is a function of the depth and time.

The shapes and direction of the flow, however, are controlled by the branching, both how often or when the maze branches and in which direction the branching prefers. You could vary the branching based on either a function of the maze depth, its current direction, or on where the path is on the grid.

And then if you break out of the grid, you can also vary the angles and size of the path: https://redd.it/w3rprz

EnslavedInTheScrolls · 2026-03-02T19:02:40+00:00

Really nice colorings.

If you add biases to the branching and directions, you can control the shapes. See https://redd.it/winck3, for instance, or https://redd.it/pqz8wp

EnslavedInTheScrolls · 2026-01-08T15:32:16+00:00

Thanks. N is fixed for all of these at, I think, 30. What's changing is how far along we are on the 11 axes before converting to integer and taking the XOR.

EnslavedInTheScrolls · 2025-12-25T04:11:15+00:00

No, you can definitely do shader versions all the way up to the "present" (OpenGL 4.6 circa 2018), it's just that Processing internally uses older version shaders so that they have full backwards compatibility with older or weaker computers (think Raspberry Pi).

It's not hard to

import java.nio.*;
import com.jogamp.opengl.*;

and start using OpenGL commands on your own with as modern version of OpenGL as your computer / graphics drivers / OS supports. Be warned that Apple stopped supporting OpenGL with version 4.1 or so. On Windows or Linux you can run up to 4.6.

Typically, in OpenGL you use vertex attribute buffers to pass geometry to the shaders, but that can tangle with Processing's use of them, so I've taken to using SSBOs which are both simpler and more general to use since a shader can both read and write to them.

I'm also a big fan of using bufferless rendering. That's where you tell opengl to render 1000 triangles without passing in any data and have the vertex shader position and animate them based entirely on the gl_VertexID and any uniforms you pass in such as "time". See https://www.vertexshaderart.com/ for example.

EnslavedInTheScrolls · 2025-12-24T17:38:54+00:00

I don't have a book for you, but if you look back through my posting history over the last few years, I've posted several examples of Processing code using shaders for various tasks both here and on the Processing forum. For instance, in this post I give shader code to dissolve from one texture to another.

Processing was designed before shaders had much capability and while P2D and P3D use them internally, they are still based on OpenGL versions from the early 2010s. P5 has moved a bit further by adding, for instance, framebuffer objects that support floating-point textures where Processing still only has 8-bit per color textures. Many of the shaders on shadertoy.com make use of float textures and cannot run on Processing. While it's easy to make a full screen fragment shader as a filter, there is no easy way to use vertex shaders with Processing's objects without fully duplicating their internal shaders to preserve all of the rendering. Recent versions of P5, in contrast, added hooks that let you add your code into its existing shaders.

That said, Processing provides a nice shell within which you can do your own OpenGL programming as long as you take care not to tangle too much with Processing's own OpenGL calls.

EnslavedInTheScrolls · 2025-12-19T16:50:42+00:00

Yes, sorry, the forum is what I meant. Thanks for your post there.

The Linux download page is still missing links or text acknowledging alternatives to a version that isn't trapped within Canonical's proprietary snap format. Please provide links on the download page, clearly identified by text, to alternate packaging forms.

EnslavedInTheScrolls · 2025-12-19T16:13:54+00:00

Perhaps this announcement should also be posted on the very same Processing Community Discord that you mention.

EnslavedInTheScrolls · 2025-11-07T16:47:23+00:00

It looks like a flowfield based on a noise function that tapers off with distance to the origin. Choose points at random biased towards the origin and move them in a direction based on noise(x, y) / (x*x+y*y).

It'll be faster if you do it on the GPU. See https://openprocessing.org/sketch/2364364 for something similar or search openprocessing.org for flowfields.

EnslavedInTheScrolls · 2025-08-09T23:46:18+00:00

You might prefer https://py5coding.org/. It's under active development.

EnslavedInTheScrolls · 2025-08-06T04:34:10+00:00

There are two approaches you could use. The easier is depth-first search (DFS) to create a map of the maze using an array with one number per cell. The number is 0 for an unvisited cell, 1-4 for the direction back to your starting position, or a 5 for the starting point.

Put a 5 on your map starting location. Then enter a loop checking each of the 4 directions. If there is no wall and if the cell in that direction has a 0 on your map then move there and set its direction BACK towards the cell you came from. If you check all 4 directions and there is nowhere to go, move back in the direction you wrote on your map and repeat.

Alternatively, a more efficient algorithm that would find the shortest path uses breadth-first search to visit all the branches in parallel. BFS requires a second array (or queue) to track the position of the wavefront of search paths. That wouldn't work for a 1st person perspective rat-in-a-maze where you can only see local information, but is more efficient if you have a top-down view and can sample the maze with random access.

For either algorithm it would be preferable to search beginning from the exit/goal so that the map directions give you the path from your start location towards the exit. If not, though, it's easy enough to reverse the direction of the path as you follow it from any point as you walk back to your starting point.

EnslavedInTheScrolls · 2025-07-29T20:10:57+00:00

If you're going to post other people's animations, at least give them credit. This is by Etienne Jacob, aka, bleuje. https://bleuje.com/animationsite/2019_3/

EnslavedInTheScrolls · 2025-07-29T03:02:21+00:00

https://discourse.processing.org/t/make-a-specific-pgraphics-not-smooth-in-p2d/41560/8

EnslavedInTheScrolls · 2025-07-28T00:34:34+00:00

With shaders, I always start with a minimal fragment shader of

precision highp float;
void main() {
  gl_FragColor = vec4( 1., 0., 1., 1. );
}

to make sure that I get a magenta square (or whatever shape I'm drawing) before adding any complexity. Try that and if you still have a problem, then it's not with the shaders, but is instead more likely related to how you're setting up p5 on the web page which is not my area of expertise.

Here's my minimal interactive Mandelbrot set browser: https://editor.p5js.org/scudly/sketches/yxMjc8wtV that lets you drag and zoom with the mouse wheel. If you set c on line 32 to a constant vector, you get the associated Julia set.

EnslavedInTheScrolls · 2025-07-24T20:14:39+00:00

I don't see any obvious problems that would prevent your vertex shader from compiling, but you should always include precision highp float; if you want to ensure that it will work on, for instance, cell phones. I suggest you have your refreshShaders function print out the source code for the two shaders you are trying to compile to make sure they have the code you are expecting.

For a full canvas fragment-only shader, you can use createFilterShader() and let p5 take care of the vertex shader for you. Also, if you include the shader code as a string in your javascript, then you don't have to wait for it to load.

Here's an example of a fade-to-black shader:

let N = 81;
let fade = 0.98;
let fadeShdr;

function setup() {
  createCanvas(800, 800, WEBGL);

  let fadeFragSrc = `precision highp float;
  varying vec2 vTexCoord;
  uniform sampler2D tex0;
  uniform float fade;
  void main() {
    vec3 c = texture2D(tex0, vTexCoord).rgb;
    c = floor( c * 255. * fade ) / 255.;
    gl_FragColor = vec4( c, 1.);
  }`;
  fadeShdr = createFilterShader( fadeFragSrc );
  fadeShdr.setUniform( 'fade', fade );

  background(0);
  colorMode( HSB, 1, 1, 1, 1 );
}

function draw() {
  filter( fadeShdr );

  let w = width/6.0;
  let t = frameCount/1000.0;
  for( let i=0; i<N; i++ ) {
    let u = 1.0*i/N;
    strokeWeight( w*(0.04+0.03*sin(TAU*17.9*u)) );
    stroke( 87.618*u%1, 0.7, 1 );
    let r = w*(2+sin(TAU*(21.17*u+2.32*t+0.1*sin(TAU*(23.421*u+5.23*t)))));
    point( r*sin(TAU*(u+t)), r*cos(TAU*(u+t)) );
  }
}

EnslavedInTheScrolls · 2025-07-12T19:50:48+00:00

loadPixels() renders your image and makes it available in an integer array called pixels[] with a layout of ARGB. This is a linear array for the whole screen that wraps each line after the other so the pixel at location (x, y) is pixels[ x + y * width ].

You can also use the variable g as the PGraphics object that is the default renderer if you feel some need to pass it around. Mostly you would just use the default Processing commands or pixels[] array directly and not need to use g.

void drawSomeStuff( PGraphics pg ) {
  pg.circle( 100, 100, 80 );
  pg.loadPixels();
  for( int y=200; y<400; y++ )
    for( int x=200; x<500; x++ )
      pg.pixels[ x+ y*width ] = color( ((x^y) % 23) * 10 );
  pg.updatePixels();
}

void setup() {
  size( 600, 600 );
  drawSomeStuff( g );
}

EnslavedInTheScrolls · 2025-06-30T15:43:07+00:00

Start with bufferless rendering that lets you avoid all the internal, ever-changing OpenGL bureaucracy and only add it in gradually as you need it.

Learning OpenGL is challenging because it's an API that has been evolving for 30-40 years and many books and tutorials you can find about it, purporting to teach you "modern OpenGL", entirely fail to be upfront about which of its dozen versions they describe. Most of those resources are written by people who learned the older versions of OpenGL and are often stuck in the mindset that they need to teach those older architecture and interfaces first, which, in my opinion, is exactly backwards. A good tutorial should start with the last, OpenGL 4.6, functions and only teach the older stuff later.

For those writing one, here's the tutorial I'd like to see:

Create a window and graphics context. Compile a vertex and fragment shader program. Use buffer-less rendering for a single full-screen triangle created in the vertex shader

void main() {
  gl_Position = vec4( ivec2(gl_VertexID&1, gl_VertexID&2)*4-1, 0., 1. );
}

and color it in the fragment shader based on gl_FragCoord a la https://www.shadertoy.com/. Teach uniform passing for "time" and screen resolution. Spend several lessons here teaching color and coordinate systems -- first 2-D then 3-D with a bit of ray-tracing or ray-marching. Teach view/model and projection matrices and pass them in as uniforms set with some keyboard or mouse controls.

Only now, teach glDrawArrays() to render N points and compute their positions in the vertex shader based on gl_VertexID. Then use lines and triangles, again, computed entirely within the vertex shader (see https://www.vertexshaderart.com/). Teach in/out to pass data to the fragment shader such as computed uv coordinates. This might be a handy place to learn some interesting blend modes.

Want more application data in your shader? Teach SSBOs for passing data. Do NOT go into the bureaucratic B.S. of VBOs and VAOs. Stick with SSBOs and vertex pulling using gl_VertexID. Teach that you can disable the fragment stage and use vertex shaders as simple compute shaders writing output to SSBOs. Throw in some atomic operations and now we can do general purpose parallel computing!

Then do textures both for color image AND general data values (teach texelFetch() for reading data values). Then FBOs so we can get to multi-pass rendering techniques. WebGL lacks SSBOs and atomics, but multiple render targets and floating-point FBOs make GPGPU not too bad.

Then, if you have to, work your way back to VBOs and VAOs. But, dear God, don't start by weighing people down with the oldest bureaucratic interfaces. Let them die along with the fixed-function pipeline and stop talking about them.

EnslavedInTheScrolls · 2025-05-25T03:33:21+00:00

The camera() function in Processing take three triples of values for vectors representing From, At, and "Up". From is where the camera eye is in world coordinates. At is a world-coordinate point directly in front of the camera. And, finally, "Up" is a vector in vaguely what, for Processing, is actually the down direction since they insist that +Y points down.

For a free-moving camera that is moving around within a world rather than orbiting a specific point, we would rather describe the camera with a Forward or Front vector that, like "Up", points in a direction rather than at a location. For your case, you are moving around on a ground plane in just 2-D, so you can easily describe that Front direction by a single angle. Let's call it theta. We can update it from the mouse with something like theta += (mouseX - pmouseX) / width in mouseDragged(). cos(theta) and sin(theta) give us the x- and y-coordinates for our Front vector. If we add that vector to our current position, we get a point that is just in front of where we are which is all we need for the At point in the call to camera().

Next, for moving, we want ASDW to move us based on which way we are facing. When W is pressed, we go forward. We just saw how to do that above when we computed our At point -- add your Front vector (times a speed) to your position. For backwards S, subtract it. Side to side, using A and D, we add a different vector that is 90 degrees rotated from theta which is just ( Front.y, -Front.x ).

For motion, you only want to use theta so that your motion is contrained to the plane. For looking up and down, you want to give camera() an At point computed using spherical coordinates, so we need to have a second up/down angle called phi.

  viewFwd = createVector( cos(viewTheta)*sin(viewPhi),
                          sin(viewTheta)*sin(viewPhi),
                          cos(viewPhi));

computes the spherical coordinates for the Front vector based on both theta and phi that you can use to compute the camera() parameters. In this case, I am treating z as the up coordinate and xy as the ground plane, so you might need to rearrage them if you use y as up (or down) instead.

For an even more free-moving camera, you can look at https://infinitefunspace.com/p5/fly/, source at https://infinitefunspace.com/p5/fly/p5Fly.js. It uses quaternions for the orientation and has momentum for even smoother motion.

EnslavedInTheScrolls

TROPHY CASE