P3D performance with 62500 boxes

When I thread my example I got an increase of fps on the animation thread. And yes the child grouping works better but when I tried to make an array of PShapes and just displaying them not even talking about translating. It was only 2 FPS average.

Is this good enough?
(my noise sucks do)

PShape group;



void setup() {  
  size(600, 600, P3D);
  noStroke();
  group = createShape(GROUP);
  for (int i = 0; i < 65; i++) {
    PShape s = createShape(BOX, 5);
    s.translate(random(-width, width)/2, random(-height, height)/2, random(-height, height)/2);
    group.addChild(s);
  }
}


void draw() {
  background(0);
  PShape[] shapes = group.getChildren(); 
  
  pointLight(51, 102, 126, -100, 40, 36);
  pointLight(200, 50, 80, width + 100, 40, 36);
  pointLight(200, 200, 80, width/2, height, 0);
  
  translate(width/2, height/2);
  
  float t = frameCount * 0.001;
  
  
  for (int i = 0; i < 1000; i++) {
    pushMatrix();
    rotate(noise(i * i, t) * TWO_PI);
    translate(nnoise(i * i, t) * width, nnoise(0, i * i, t) * height, nnoise(i * i, i * i, t) * height);
    shape(group);
    popMatrix();
  }
  
 
  surface.setTitle(nfc(frameRate, 0));
}


float nnoise(float x) {
  return noise(x) * 2 - 1;
}

float nnoise(float x, float y) {
  return noise(x, y) * 2 - 1;
}

float nnoise(float x, float y, float z) {
  return noise(x, y, z) * 2 - 1;
}
4 Likes

The cheating approach?! :laughing: I haven’t had a chance to have a play with this yet, but interested in how much you played around with different sizings of the different groupings, and what you can get away with before you can notice correlation in movement?

1 Like

Yeah it looks like a work-around since you only have 64 items in the group shape

Why?

So cool!

I changed quantities around a bit; just experimenting to see what it would do.
I also modulated the Z- axis for a very cool effect.
I get a rock solid 60 fps.

You can see the shapes (group of 1024 cubes in my edit) move together when you zoom the Z-axis; maybe less is more in this case.

Thanks for sharing!

PShape group;

float th2;

void setup() {  
  size(600, 600, P3D);
  noStroke();
  group = createShape(GROUP);
  for (int i = 0; i < 1024; i++) {
    PShape s = createShape(BOX, 5);
    s.translate(random(-width, width)/2, random(-height, height)/2, random(-height, height)/2);
    group.addChild(s);
  //ortho();  
}
}


void draw() {
  background(0);
  PShape[] shapes = group.getChildren(); 
  
  pointLight(51, 102, 126, -100, 40, 36);
  pointLight(200, 50, 80, width + 100, 40, 36);
  pointLight(200, 200, 80, width/2, height, 0);
  
  th2+= TAU/1000;
  float z = 1000*sin(th2)-500;
  
  translate(width/2, height/2, z);
  
  float t = frameCount * 0.001;
  
  
  for (int i = 0; i < 256; i++) {
    pushMatrix();
    rotate(noise(i * i, t) * TWO_PI);
    translate(nnoise(i * i, t) * width, nnoise(0, i * i, t) * height, nnoise(i * i, i * i, t) * height);
    shape(group);
    popMatrix();
  }
  
 
  surface.setTitle(nfc(frameRate, 0));
}


float nnoise(float x) {
  return noise(x) * 2 - 1;
}

float nnoise(float x, float y) {
  return noise(x, y) * 2 - 1;
}

float nnoise(float x, float y, float z) {
  return noise(x, y, z) * 2 - 1;
}

@glv I would create the boxes inside a sphere if you zoom that far out:

 PVector v = new PVector();
    float r = width/2;
    v.set(random(-1, 1), random(-1, 1), random(-1, 1));
    v.normalize();
    v.mult(r);
    v.mult(random(1));
    s.translate(v.x, v.y, v.z);

Also maybe less translation when the zooming out is quite far, to hide that we are cheating :smiley: .

@Chrisir If you really wan’t to move 65000 boxes with a good framerate I guess you have to use compute shaders.

1 Like

Could you please elaborate?

What are these?

@clankill3r “move 65000 boxes with a good framerate” - yes, this is exactly what i’m trying to do. i’m curious about the shader approach !

A Compute Shader is a Shader Stage that is used entirely for computing arbitrary information. While it can do rendering, it is generally used for tasks not directly related to drawing triangles and pixels.

Unfortunately my macbook from early 2013 does not support this, since it needs a opengl version a bit higher then my graphic card supports.

The thing is that communication over the bus is slow, so if you update 65000 boxes on the cpu and need to inform the gpu about those new positions to render them, then your slow…
So ideally you don’t want to leave the gpu for those operations (except sending a seed and time for example).

Unfortunately I think the current state of processing on the GPU is terrible anyway. OpenCL support is dropped by apple. CUDA is Nvidia only. Compute shaders are both their for OpenGL and DirectX so you need to write them twice. It would be so nice if computing on the GPU would become non vendor specific and cross platform.

Could also possibly just use vertex shaders here? I tried adding in the tweening shaders from the MeshTweening example into the CubicGridRetained example. Adding custom position attributes on to each cube works fine and solid 60fps with individually moving cubes. However, finding the right collection of attributes and calculations in the vertex shader might take a bit more time! :smile:

I really appreciate all of these solutions. It seems like there is just a problem with Shapes and the way they calculate transformations. Hopefully one day the Processing gods will find this bug. In the meantime I managed to get Java 6 and Processing 151 + GLGraphics to run well on Mojave but as time moves forward this becomes more and more precarious.

1 Like

I just downloaded the 3.5.4 version but i still have the same problem. Any chance this might be resolved soon ? Thanks !!

Sorry to bring this up yet again but I’m still, after all this time, trying to figure out why this snippit (a part of a much larger program) is so slow (15 fps on a new MBP) with 62500 PShapes whereas in Processing 151 using GLGRAPHICS I’m easily at 60 fps.

I desperately need to move from Java 6 to Java 8 !!!
Could anyone point me in the right direction !!!
Thanks a million !!!

PShape group;

void setup() {  
  size(600, 600, P3D);
  noStroke();
  group = createShape(GROUP);
  for (int i = 0; i < 62500; i++) {
    PShape s = createShape(BOX, 2);
    s.translate(random(width), random(height));
    group.addChild(s);
  }
}
void draw() {
  background(0);
  PShape[] shapes = group.getChildren(); 
  for (int i = 0; i < shapes.length; i++) {
    //shapes[i].resetMatrix();
    shapes[i].translate(random(-1, 1), random(-1, 1));
  }
  shape(group);
  if(frameCount % 60 == 0) {
    println(frameRate);
  }
}

I just realized this might be the solution. I’ve been trying to do the same but can’t figure it out. Any help would be appreciated !

1 Like

I am following with interest… any updates?

:)

I followed your discussion with interest. What brought me here was google and my quest search for “box performance in processing”. I had a long break from processing, and now I got back to 4.0b2. A couple of years back, when I ran my processing experiments, I could swear that I had much better framerates in 3D for thousands of “boxes.” At some point in time, I thought it was only my imagination, but going through this thread, I see I was right. COCO code is similar to what I was using (i don’t have my codebase anymore).

Guys, I’m using OpenJDK at this moment for windows - maybe it has something to do with JVM?

Any feedback on this topic would be highly appreciated. A lot of people will benefit from this.

Thank you :slight_smile:

Highly unlikely, OpenJDK and Oracle JDK are the same code. Just built and supported by different people. Well, unless you’ve picked up one with OpenJ9, but that performs pretty well too.

The major factor is how Processing interacts with the GPU (and how much it’s not doing on the GPU for “accuracy”)