P3D performance with 62500 boxes

Any chance this will be fixed any time soon ??? Thanks.

i just downloaded 3.5.2 but i still have the same bottleneck with shapes[i].translate where shapes.length = 62500 (cubes). it drops from 120fps to 16fps when i add shapes[i].translate

shapes = thisModel.getChildren();

for (int i = 0; i < shapes.length; i++) {
shapes[i].resetMatrix();
shapes[i].translate(m.x, m.y, m.z);
}

shape(thisModel);

anyone for a fix ?
thanks

Has anyone
else run into this problem. I’m still stuck !!!

I tried the 3.5.3 version but same bottleneck.
it is definitely the shapes[i].translate line that slows everything way down.

for (int i = 0; i < shapes.length; i++) {
shapes[i].resetMatrix();
shapes[i].translate(m.x, m.y, m.z);
}
it is so frustrating because i don’t know what to do to move forward. I absolutely need to port my very long 151 + GLGraphics program to P3 very soon. any suggestions, anyone ? help !

1 Like

Hey There!

When I get home happy to help. Leaving this comment here to push this topic up so I don’t lose it and others may see it!

Instead of moving each bit individually, why not use translate (pure translate without shapes…) before shape and kill the for loop??

Great !!! Thanks because it still hasn’t been fixed.

Because I need to move them individually, they all go to different places

Actually you move them all the same way nvm

Try get rid of resetMatrix

Instead try translate… display… translate (-m.x,-m.y…

Hey There!

So I had a go at improving performance at @hamoid sketch and the sketch with 15000 objects I was able to go from 17 FPS to an average 40 FPS by pulling the translate on a separate thread and just simple variable calling improvements such as not loading an array everytime inside draw() aswell as not translating all the time but every 2 frames.( You can set this to whatever you want). I have no other ideas on what to do different. ( I also added the reset matrix to mousePressed to offLoad their positions to get a nice FPS spike )

Giving processing more access to memory from file -> preferences could also help.

Best of Luck ( Tried on a laptop: Pentium N3310 x 4C x 4T with 512 MB Ram set for Processing ).


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

I fail to see how breaking the code and misusing threads is helpful! It’s highly likely you’re not actually measuring what you think you are here.

1 Like

Pulling on a separate thread I believe allows to offload the main animation thread so simultaneous work can be done. Comment out the thread and you can see that the fps drops drastically ! Also I didn’t not break up the code but modified it in a way I thought could be helpful. With the previous code that was available @hamoid

Potentially multithreading this correctly would help, but without guarantees when that offloaded work completes the code is broken, if not risking crashing.

1 Like

But the program keeps drawing so I do not see any potential for breaking. Maybe it would be important to prevent from a Lock. But I think for the sake of simplicity no bad deed will occur.

1 Like

The code is broken. It doesn’t do the same thing and is now indeterminate. It might be safe from crashing, but you’re assuming no thread unsafe structural changes are happening in PShape - you might just be lucky for a few hours or days! :wink:

1 Like

Yes, the code doesn’t do the same action as the translations are not complete on the same thread as the drawing. But this deed doesn’t I think cross it off as broken, the way I see it is that if translating slows down we can still keep drawing the shapes and not sacrifice the FPS so drastically. But you could be right that unsafe things could be happening in PShape ! I guess I just wanted to demonstrate a possibility that maybe Multi-Threading could be a potential answer to the slow performance of translation. But as it seems for me we are only translating the shapes. I don’t feel it a highly ground-breaking procedure which is being pulled on a thread. :smiley: .

1 Like

Thanks for your suggestions. I think there is something wrong with the source code that needs to be corrected concerning PShape and translations. I’m hoping that your messages and mine will make this fix more urgent.

You got one shape with children shapes

In my experience this structure is slow.

Did you try to work with single shapes or boxes instead of using a big shape with children?

1 Like

It is definitely faster than doing a
Single objects each. Having each shape as a single object. Is ambiguously slow. Maybe load each shape as an image to be honest. Maybe that can help

This is only true as of 3.5+ if you’re doing any sort of matrix transformations on the child shapes. It is better than it was, but still not as good as the claim for the performance with GLGraphics in 1.5.

Incidentally, I can get exactly the same reported framerate from your example above whether I thread the shape transformation, or just run it in the same thread every other frame.