My vbos are invisible (probably because of a system update)

I believe a recent system upgrade broke my vbos. The code below doesn’t draw a triangle, unless I replace ofVboMesh with ofMesh. It was working about a week ago. I’m using OF 0.9.8 from December 30th, 2016.

How to debug this? Could it be the Mesa upgrade? The Intel driver? Is it something they have to fix? Or does OF need to be updated too?

ofVboMesh m;

void ofApp::setup() {
    vector<glm::vec3> vertices = {
        glm::vec3(0, 0, 0),
        glm::vec3(ofGetWidth(), ofGetHeight(), 0),
        glm::vec3(0, ofGetHeight(), 0)
    };

    vector<ofIndexType> indices = {
        0, 1, 2
    };
    vector<ofFloatColor> colors = {
        ofFloatColor::red,
        ofFloatColor::yellow,
        ofFloatColor::blue
    };

    m.addVertices(vertices);
    m.addIndices(indices);
    m.addColors(colors);
}
void ofApp::draw() {
    m.drawFaces();
    ofDrawCircle(0, 0, 100);
}

:deciduous_tree:

this is probably something related to the DSA extensions again. do the nightly builds work for you?

I tried the most recent nightly but it made no difference.

I forgot to mention that even my OF is from 29.12.2016, I did patch it with your commits for GL issues.

I suspect the issue is related to the Mesa upgrade (17.0.1-1 -> 17.0.1-2) and mesa-libgl becoming libglvnd. I see here people having issues with games that get solved when downgrading.

I was just wondering if this will be solved with future mesa or libgl updates, or if it will require changes in OF.

#not-urgent

it might be a bug but that’s strange i’ll take a look as soon as i can install mesa 17

Any updates or additional notes on this? I’m running into this problem currently. Appears that any project that contains a draw call to a ofVboMesh will fail (segfault). If I understand you’re nots on another thread correctly, ofxGui uses ofVboMesh to draw?

I’m suffering this problem with any attempts to draw a ofxPanel (part of ofxGui) and with attempts to draw ofVboMesh (i.e. running the vboExample).

Running Debian 9, Mesa 13.0.6.

Is this solved by updating to Mesa 17 or are there additional requirements to solve?

Thanks for any advice.

Hi! Which OF version? If you share a minimal example I can try run it and see if it works. My OF is from git master.

Using the nightly build on the OF website: of_v20180215_linux64gcc4_nightly.tar.gz

Neither guiExample nor vboExample will run. In my own code I’ve narrowed it down to gui.draw() call (gui == instance of ofxPanel).

Everything else works, builds fine and works perfectly on my Mac. If I comment out “gui.draw()” everything runs perfectly.

guiFromParametersExample works for me on ArchLinux and it calls gui.draw().

The thing that I have patched is ofBufferObject.cpp because of my Intel graphics.

if (false && GLEW_ARB_direct_state_access) {

I added false in 8 cases in that file, otherwise faces are invisible. But it does not crash.

Thank you. I’ll try that and doc.

I’m also running Intel graphics. Are you running Mesa? Which version?

You’re welcome :slight_smile: I see mesa-17.3.3-2-x86_64.pkg.tar.xz in my packages.

Just to update here in case it is helpful for anyone else:

I’m running Debian 9 Stretch, using the nightly build on the OF website:

of_v20180215_linux64gcc4_nightly.tar.gz

First, I installed Mesa 17.1.10 using the instructions found at this link: https://linuxconfig.org/how-to-install-the-latest-mesa-version-on-debian-9-stretch-linux

Once this is done, calling

glxinfo | grep “version”

returns the following:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.10 (git-60df95c6bd)
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 17.1.10 (git-60df95c6bd)
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.1.10 (git-60df95c6bd)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

When I ran the ofxGui example at this point, it compiles and runs successfully. The GUI Panel (ofxPanel) draws and doesn’t cause any crash. At this point, though, there is no text being drawn on the ofxPanel children. I’m seeing blank sliders with none of the text.

Next, I followed advice from @hamoid and when into ofBufferObject.cpp and modified any line that read

if(GLEW_ARB_direct_state_access) {

so that it now reads

if(false && GLEW_ARB_direct_state_access) {

Went back into my OF folder/scripts/linux and ran

./compileOF.sh

again.

ran

make clean && make

on the guiExample and then ran it. Everything works perfectly with the ofxPanel drawing along with the text.

Thanks for the help @hamoid

1 Like

Two years after the last post this issue still exists. Luckily, the solution by @hamoid also still works.

Is there any way I can help to fix it properly? (more info, certain logs, …).
To add some more info on my system:

uname -a:

Linux hostname 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux

glxinfo | grep “version”

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

yes i need to fix this before the next release but pretty much it means checking also if the opengl version is >= 3, then the check of DSA is correct and we know that DSA will work

Not necessarily the same topic, but related. I just moved over to Debian Testing (Buster) due to some issues with a WiFi device not being fully compatible with available drivers that are included repos on Debian 9 Stretch… as a result I’ve had to go thru the steps above to reinstall openFrameworks.

libgles1-mesa-dev is no longer available in Debian repos as of Debian Testing (Buster). I modified the install_dependencies.sh script found in scripts/linux/debian/, removing libgles1-mesa-dev from the packages to install on line 38. Ran script, everything else is found and installed on the repos.

Everything functions the same on Debian Buster in terms of installing and getting openFrameworks up and running (now running the nightly release: of_v20180321_linux64gcc6_release

It appears that libgles1-mesa-dev is available in the repos for Debian Sid (Unstable), although no longer for amd64 architecture. Perhaps this lib was incorporated into another that is already being installed under a different name now?

Looking here: https://packages.debian.org/search?keywords=libgles1-mesa-dev

just looked deeper… everything was superseded by libgles2-mesa-dev i’m assuming.