FBO and Polylines

#1

Howdy all!

Quick question for you guys… I posted here about a week ago asking about how I can manipulate the contour from OfxCV’s contourfinder. Y’all are amazing and answered my question, but now I am running into a performance issue. I know my solution is to use an FBO, but I am unsure of how to do so.

I have a vector of polyLines called ‘pp’. pp is instantiated in my update() function where I call pp = contourFinder.getPolylines(); After the instantiation, I then iterate through pp, which is usually 1-3 items at most, since there are usually no more than 1-3 contours in the picture at once. I call a nested for loop and iterate through that specific contour/polyline and then call the arc function to arc the polyline to that specific point, which goes through well over 5000-10000 iterations. This is where my program begins to break. I then iterate through my vectors of polylines (pp [like i said which is between 1-3] in my draw function, and draw every polyline, which is simultaneously being updated in my update function. I tried to declare an fbo and begin() and end() at my update function, but only a black box appeared in my sketch. How exactly do I “load” my sketch onto an FBO? Is that even the right terminology?

In essence, I would just like to run my sketch quicker. I know OpenFrameworks takes advantage of OpenGL, which streamlines processes like these, using classes such as FBO. Where exactly would I fit an FBO into my sketch?

update function:

fbo.begin();
    pp = contourFinder.getPolylines();
    // 1. We iterate through everything within pp (vector of polyLines)
    // 2. pp[i] represents the entire POLYLINE. IT IS WHAT YOU ARE LOOKING AT, ON THE SCREEN
    int sizz = pp.size(); //1 CONTOUR
    
    for(int i = 0; i < pp.size(); i++) {
        pp[i] = pp[i].getSmoothed(50); //this takes pp at position i, (there should only be 1 pp), and smooths out the ENTIRE polyline
        

        int polySize = pp[i].size() ; //this will be a large number, as it is the size of all the polylines within our main (1) poly. Polylines are objects consisting of smaller polylines
        for (int j = 0; j < polySize; j+=2){ //now we iterate through all the little polylines within our main pp
            


            ofPoint current = pp[i][j];
            pp[i].arc(current, 20, 200, 240, 120, 200);  //center, radius x, radius y, anglebegin, angle end, circle res
            cout <<  pp[i][j].x  << endl;
        }
     
    }
    for (int i =  0; i < pp.size(); i++){
        pp[i].draw();
    }
    
    fbo.end();

Draw function: So, when I iterate through the for loop, my current sketch draws in the background. When I call fbo.draw(), it just draws a black box on top of my current, running sketch. I just don’t know how I can load the current running sketch into the FBO.

 ofTranslate(100, 100, 0);
    for (int i =  0; i < pp.size(); i++){
        pp[i].draw();
    }

    fbo.draw(100, 100);
    

Thank you all so much for your time.

#2

A couple of questions:

  • Which performance issue are you having? how are you measuring it?
  • What do you want to draw on the screen? your polyline (pp) or your fbo?
  • From your sketch, it is not clear to me why do you want to use an FBO. Can you explain the reason behind it?
1 Like
#3

@armonnaeini have you allocated your fbo in the setup function? The usual way a fbo works is

  1. Declare it in the .h file
  2. Allocate it in the .cpp setup, with fbo.allocate(width, height, format). Also clear it once just for safety.
  3. In your update function, you begin the fbo, optionally clear it, put your draw code and then end it. Something like
fbo.begin();
fbo.clear(255, 255, 255, 0);
//draw code here
fbo.end();
  1. In your draw function, you only draw the fbo with a simple fbo.draw(0, 0) (or wherever else you need it to be). There doesn’t need to be any other .draw() inside the draw code.

Is your code following this? Are you still getting issues (if so, what?) For a sanity check, try setting the colours of the Polylines before you draw them into the fbo.

@edapx I believe @armonnaeini wants to leave some trails of the polylines based on the thread here, the fbo approach being something I pointed them towards.

I hope this clears up the FBO issue. For performance, I have the same question as Davide, what is the issue and how are you measuring it?

1 Like
#4

Thank you so much to the both of y’all for your responses. I am not at my computer, but I will try to implement your solution and will get back.

In regards I performance issues, my sketch just runs pretty slow. The frame rate is low and choppy and Xcode is showing me at around 110% cpu usage. I plan on setting up this sketch in an installation, hence why I was looking for a way to streamline the graphics. Pardon my knowledge regarding FBOs, as I’m still a novice, but to my understanding you can load graphics onto a buffer and then have the buffer drawn onto the screen, in order to have better performance. Is that correct? Does using an FBO mean that I’m running the graphics off my graphics card, rather than my actual CPU?

In essence, I don’t have an fbo in use and my sketch is pretty slow. Can I use an fbo to make it run faster?

#5

Polylines are still using the CPU for all the calculations, it’s only when it goes to drawing that it’s being sent to the GPU. So essentially, no, just because you’re using FBOs doesn’t mean your code will run faster. Your contour finders, smoothing, iterating through all the polylines, constructing the arcs, etc are all happening on the CPU side of things.

If you wanted to use the GPU for all your calculations, it would be doable, but unfortunately I’m not the right person to help you with regards to that. You’d need to either send off all your vertices or the image as a texture to the GPU and calculate the contours and all the likes through there, or use compute shaders, both beyond my skills to help you out with.

#6

Hi,
I think that your use of the polylines is kinda strange. inparticular puting an arc with its same vertices, as the arc will add more vertices, then it can grow in a sort of exponential way, leading you to have an excessive amount of vertices and then making the whole thing slow.

openFramewoks uses OpenGL to full extent, but it really depends a lot on what and how you code things if these are efficient or not. also I see a cout in the loop, which will certainly slow down the whole thing a lot. start by removing it. as for the fbo, at least in your case it will not produce any improvement on the performance as the polylines seem to get updated on each frame.