Can we get new light engine?

Processing Development
1

Hi all!
I’m new to the forum but not new to processing, in fact a long time user.
I’m calling out to you devs who are doing an astonishing work with Processing!

I was coding a project the other night and was playing around with lights when I ran in to the long known limitation of only 8 simultaneous light sources. That got me thinking.

Todays computers are far more capable than what they used to be, Processing shouldn’t be limited by hard limits but rather the amount of processing power your computer has, and it would be great if we could finally get a light engine that doesn’t limit what you can do. If I want a thousand lights, well then I should be able to put a thousand lights in there even though I would only get 5 fps. It should be up to the user.

I think I read somewhere a few years ago that the limit has to do with OpenGL rather than Processing, but I think it’s about time to re-visit the light engine and make it less limiting. And also while you’re at it, modernise the syntax and allow lights to take parameters like falloff, accept Color datatype to mention a couple of things.

Seriously, please consider upgrading the lights engine :grin:

Best /William

2 Likes
2

Hi,

Welcome to the forum then! :wink:

Actually rendering a lot of lights is not a limitation of OpenGL but rather two different methods when doing real time graphics : Forward rendering (classic one) and Deferred Rendering. It’s really well explained on this thread :

If you go on the GitHub repo of Processing 4 (the next release which is in alpha), they say this in the changes.md file :

Processing 4.0 alpha 2

Revision 1271 - 15 September 2020

Several fixes for this round, plus working on the guts quite a bit to prepare for newer/faster/better rendering methods.

So hopefully they are going to change that!

And when you look at the GLSL code for the basic shading, you see that it’s forward rendering limited to 8 lights :

// processing4/core/src/processing/opengl/shaders/LightVert.glsl

for (int i = 0; i < 8; i++) { // <<= HERE
  if (lightCount == i) break;
    
  vec3 lightPos = lightPosition[i].xyz;
  bool isDir = lightPosition[i].w < one_float;
  float spotCos = lightSpot[i].x;
  float spotExp = lightSpot[i].y;
    
  vec3 lightDir;
  float falloff;    
  float spotf;
      
  if (isDir) {
    falloff = one_float;
    lightDir = -one_float * lightNormal[i];
  } else {
    falloff = falloffFactor(lightPos, ecVertex, lightFalloff[i]);  
    lightDir = normalize(lightPos - ecVertex);
  }

//... they compute basic phong lighting
}

(processing4/core/src/processing/opengl/shaders/LightVert.glsl at main · benfry/processing4 · GitHub)

I did a test by changing the 8 value in this shader and modifying the MAX_LIGHTS variable inside the processing4/core/src/processing/opengl/PGL.java source file to 32 and compiled processing4 with ant. With this program I was able to have more than 8 lights :

ArrayList<PVector> lights;
float range = 500;
float r = 0;
float lightsIntensity = 10;

float rRange(float range) {
  return random(-range, range);
}

void setup() {
  size(500, 500, P3D);
  
  lights = new ArrayList<PVector>();
  
  for (int i = 0; i < 32; i++) {
    lights.add(new PVector(rRange(range), rRange(range), rRange(range)));
  }
}

void draw() {
  background(0);
  
  for (int i = 0; i < 32; i++) {
    PVector light = lights.get(i);
    pointLight(lightsIntensity, lightsIntensity, lightsIntensity, light.x, light.y, light.z);
    
    // Visualize light
    stroke(255);
    point(light.x, light.y, light.z);
  }
  
  camera(cos(r) * 500, 100, sin(r) * 500, 0, 0, 0, 0, 1, 0);
  
  // shininess(10.0);
  fill(255);
  noStroke();
  sphere(100);
  
  r += 0.01;
}

Screenshot from 2020-12-03 17-45-45

But as you noticed, we get wrong results because the light calculation doens’t handle too much lights and the colors overflow or something :wink:

Anyway fun experiment!

1 Like