STEP reader improvement (Pass 4): Moving to OpenGL 3.2

[vejmarie]

maybe off topic but what would be a reason not to upgrade to a higher version of OpenGL?

OpenGL is exposing different level of functions depending on the hardware it is running on and the release of the library it is used. It's implementation is device driver and O/S dependant, and most of the time even if new extension are implemented in software they are not back ported on old hardware. This means that if we use a too recent OpenGL version we might not be able to run properly on old hardware unfortunatly.

[vejmarie]

For the one who want test I have pushed my first patches on my FreeCAD github repo (branch step) github.com/vejmarie/FreeCAD

I still need to fix a few things like Color management (currently everything is a single color), and Part update (aka when a recompute call is performed we need to update the VBO content).

Up to now I have a massive rendering improvement with this patch even if it has broken the color, and is not fully functional, I think this is definitly something we should finish and integrate.

[triplus]

I tried but on Linux first i had to use #include <GL/gl.h> in SoBrepFaceSet.h instead of #include <OpenGL/gl.h> and after i had to put #include <GL/glew.h> at the top of SoBrepFaceSet.cpp and install libglew-dev package to get around:

Code: Select all

SoBrepFaceSet.cpp:100:43: error: ‘glGetStringi’ was not declared in this scope

But still the compile failed after at things like:

Code: Select all

SoBrepFaceSet.cpp:97:74: error: no matching function for call to

Therefore i give up for today.

[vejmarie]

I tried but on Linux first i had to use #include <GL/gl.h> in SoBrepFaceSet.h instead of #include <OpenGL/gl.h> and after i had to put #include <GL/glew.h> at the top of SoBrepFaceSet.cpp and install libglew-dev package to get around:

Code: Select all

SoBrepFaceSet.cpp:100:43: error: ‘glGetStringi’ was not declared in this scope

But still the compile failed after at things like:

Code: Select all

SoBrepFaceSet.cpp:97:74: error: no matching function for call to

Therefore i give up for today.

Thanks for the try. I can't test this part of the code related to GL 3.0 detection. I will do it another way and push it right now as you can test it by tomorrow .

This is still really buggy (you can't select a face anymore with that rendering approach and that is something I need to understand why), you can select whole elements only, and I still need to find a way to render the color, but Coin3d / Inventor material management is a bit complex to me right now.

[triplus]

Just wondering as you said OpenGL 1.4+ should support VBO. Do we need to bother with detecting the OpenGL version at all?

P.S. Reading this:

https://en.wikipedia.org/wiki/Vertex_Buffer_Object

I guess code implementation is different between OpenGL versions and therefore you plan to tackle OpenGL 3+ for now. Well i guess no performance boost on my old pre OpenGL 3 hardware then but on the hardware i have OpenGL 3+ there VBO should be used if this effort gets through.

[vejmarie]

Just wondering as you said OpenGL 1.4+ should support VBO. Do we need to bother with detecting the OpenGL version at all?

P.S. Reading this:

https://en.wikipedia.org/wiki/Vertex_Buffer_Object

I guess code implementation is different between OpenGL versions and therefore you plan to tackle OpenGL 3+ for now. Well i guess no performance boost on my old pre OpenGL 3 hardware then but on the hardware i have OpenGL 3+ there VBO should be used if this effort gets through.

You are right I don't think we need the detection. I just made it in a quick and dirty mode, we probably can assume it is available everywhere at least on the platform we compile currently.

I think the code implementation I am currently using shall work even with old stuff. I am using the ARB extension

If somebody knows how to get RGB value from a SoMaterialBundle index, I am really really interested ! I believe wmayer remark was a good one. The key issue I am facing right now is that Coin doesn't support VBO it does support Vertex Array which are not cached at the GPU level. So I really would like to see if we could make work the VBO stuff, I am getting at least x3 FPS improvement. Hope you can compile my mockup and test it with some big step file.

[triplus]

You are right I don't think we need the detection. I just made it in a quick and dirty mode, we probably can assume it is available everywhere at least on the platform we compile currently.

I think the code implementation I am currently using shall work even with old stuff. I am using the ARB extension

Sounds good. And likely some new dependencies could be avoided (on Linux). And to be honest especially on the older hardware i use (OpenGL 2.1) the performance boost for such use cases would really be nice.

If somebody knows how to get RGB value from a SoMaterialBundle index, I am really really interested ! I believe wmayer remark was a good one. The key issue I am facing right now is that Coin doesn't support VBO it does support Vertex Array which are not cached at the GPU level. So I really would like to see if we could make work the VBO stuff, I am getting at least x3 FPS improvement. Hope you can compile my mockup and test it with some big step file.

Hope you will be able to figure it out and to get proper advice from other developers.

[NormandC]

what would be a reason not to upgrade to a higher version of OpenGL?

AFAIK Intel graphics chipsets notoriously lagged behind in OpenGL versions. I don't know if it's still the case. Not everybody has a discrete graphics card.

Even among those who do (like me), do their drivers allow a recent OpenGL version? I have a pretty decent Nvidia GeForce card from 2012, but because of issues with Nvidia's proprietary driver I (privately) lifted the same finger Linus Torvalds did and switched to the open source "nouveau" driver.

Apparently my OpenGL version used is only 3.0. But the following commands seem to be contradictory. On talks of v3.0, the other of 4.1.

Code: Select all

$ /usr/lib/nux/unity_support_test -p
OpenGL vendor string:   nouveau
OpenGL renderer string: Gallium 0.4 on NVE6
OpenGL version string:  3.0 Mesa 11.0.4

Not software rendered:    yes
Not blacklisted:          yes
GLX fbconfig:             yes
GLX texture from pixmap:  yes
GL npot or rect textures: yes
GL vertex program:        yes
GL fragment program:      yes
GL vertex buffer object:  yes
GL framebuffer object:    yes
GL version is 1.4+:       yes

Unity 3D supported:       yes

Code: Select all

$ glxinfo | grep "OpenGL"
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVE6
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.4
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

Mesa 11.0.0 Release Notes
Mesa 11.0.0 implements the OpenGL 4.1 API, but the version reported by glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. Some drivers don't support all the features required in OpenGL 4.1. OpenGL 4.1 is only available if requested at context creation because compatibility contexts are not supported.

[ickby]

The key issue I am facing right now is that Coin doesn't support VBO it does support Vertex Array which are not cached at the GPU level.

I wouldn't be that sure. Have a look at the shapes base class, SoShape, and the respective startVertexArray/finishVertexArray functions: https://bitbucket.org/Coin3D/coin/src/1 ... e.cpp-1556
If VBO's are supportet by the platform coin uses them, if not the fallback are vertex arrays. So I think the whole infrastructure is there. But if I read it correctly quite a few conditions need to be meet regarding the scene setup if VBO's should kick in.

On a first look it seems SoFaceSet does not use the mentioned functions and hence no VBO's, but SoIndexedFaceSet does use them. So if one wants to achieve a good coin compatibility SoIndexedFaceSet may be a good place to steal some ideas from.

[vejmarie]

The key issue I am facing right now is that Coin doesn't support VBO it does support Vertex Array which are not cached at the GPU level.

I wouldn't be that sure. Have a look at the shapes base class, SoShape, and the respective startVertexArray/finishVertexArray functions: https://bitbucket.org/Coin3D/coin/src/1 ... e.cpp-1556
If VBO's are supportet by the platform coin uses them, if not the fallback are vertex arrays. So I think the whole infrastructure is there. But if I read it correctly quite a few conditions need to be meet regarding the scene setup if VBO's should kick in.

On a first look it seems SoFaceSet does not use the mentioned functions and hence no VBO's, but SoIndexedFaceSet does use them. So if one wants to achieve a good coin compatibility SoIndexedFaceSet may be a good place to steal some ideas from.

You are right and this seems promising. Now how can we re-implement the SoBRepFaceSet::renderShape with it. This is where I am a little bit lost now. Can you have a look to my code ? I think we are not far away from a big performance improvement and this will be great if we could achieve it.