Bug #1061

Debug opengl failure

Added by Aranuvir # over 2 years ago. Updated about 1 year ago.

Status:Fix exists, needs testingStart date:09/15/2016
Priority:HighDue date:
Assignee:Jonas Hauquier% Done:

90%

Category:OpenGL
Target version:MakeHuman 1.1.2

Description

Investigating on #1054, I tried to start MakeHuman with --debugopengl, receiving the following error message:

Failure on glGetUniformfv: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/OpenGL/logs.py", line 67, in __call__
    return function( *args, **named )
  File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 232, in glCheckError
    baseOperation = baseOperation,
GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glGetUniformfv,
        cArguments = (1L, 3, array([ 0.], dtype=float32))
)

Exception during event onStart
Traceback (most recent call last):
  File "./core/events3d.py", line 211, in callEvent
    method(event)
  File "./core/mhmain.py", line 806, in onStart
    self.startupSequence()
  File "./core/mhmain.py", line 728, in startupSequence
    self.loadHuman()
  File "./core/mhmain.py", line 383, in loadHuman
    self.selectedHuman = self.addObject(human.Human(files3d.loadMesh(mh.getSysDataPath("3dobjs/base.obj"), maxFaces = 5)))
  File "./apps/human.py", line 82, in __init__
    self.material = material.fromFile(getSysDataPath('skins/default.mhmat'))
  File "./shared/material.py", line 1372, in fromFile
    mat.fromFile(filename)
  File "./shared/material.py", line 476, in fromFile
    self.configureShading(diffuse=shaderConfig_diffuse, bump=shaderConfig_bump, normal=shaderConfig_normal, displacement=shaderConfig_displacement, spec=shaderConfig_spec, vertexColors=shaderConfig_vertexColors, transparency=shaderConfig_transparency, ambientOcclusion=shaderConfig_ambientOcclusion)
  File "./shared/material.py", line 913, in configureShading
    self._updateShaderConfig()
  File "./shared/material.py", line 950, in _updateShaderConfig
    bump = self._shaderConfig['bump'] and self.supportsBump()
  File "./shared/material.py", line 845, in supportsBump
    if self.shaderObj and result:
  File "./shared/material.py", line 1010, in shaderObj
    return self.getShaderObj()
  File "./shared/material.py", line 1006, in getShaderObj
    return shader.getShader(shaderPath, self.shaderDefines)
  File "./lib/shader.py", line 515, in getShader
    shader = Shader(path, defines)
  File "./lib/shader.py", line 306, in __init__
    self.initShader()
  File "./lib/shader.py", line 433, in initShader
    self.updateUniforms()
  File "./lib/shader.py", line 455, in updateUniforms
    for uniform in self.getUniforms():
  File "./lib/shader.py", line 449, in getUniforms
    uniform.update(self.shaderId)
  File "./lib/shader.py", line 134, in update
    self.glquery(pgm, self.index, values)
  File "/usr/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 402, in __call__
    return self( *args, **named )
  File "/usr/lib/python2.7/dist-packages/OpenGL/logs.py", line 67, in __call__
    return function( *args, **named )
  File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 232, in glCheckError
    baseOperation = baseOperation,
GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glGetUniformfv,
        cArguments = (1L, 3, array([ 0.], dtype=float32))
)

makehuman-debug.txt Magnifier (2.47 KB) Rob Baer, 10/14/2017 08:19 PM

makehuman.log (8.83 KB) Rob Baer, 10/14/2017 08:19 PM

image.png (408 KB) Rob Baer, 10/14/2017 10:42 PM

makehuman-debug.txt Magnifier (2.14 KB) Rob Baer, 10/14/2017 10:44 PM

makehuman.log (1.43 MB) Rob Baer, 10/14/2017 10:44 PM

makehuman.log (4.7 KB) Joel Palmius, 10/15/2017 11:39 AM

mhpy3qt5.PNG (122 KB) Joel Palmius, 10/15/2017 12:22 PM

py36_pyqt5_aranuvirqt5.png - Python 3.6.3, pyqt5, aranuvirqt5 branch (225 KB) Joel Palmius, 10/23/2017 02:51 PM

py34_pyside_master.png - Python 3.4.4, pyside, master branch (203 KB) Joel Palmius, 10/23/2017 02:51 PM

1416
1420
1426
1427

Related issues

Related to MakeHuman - Bug #1054: Ubuntu 16.04 and mesa drivers Fix exists, needs testing 09/02/2016
Related to MakeHuman - Bug #1144: openGL errors on startupof PPA MH1.1.1 New 03/05/2017
Related to MakeHuman - Bug #1208: Community AranuvirQt5 branch on MacOsx High Sierra New 10/23/2017
Related to MakeHuman - Bug #1209: Produce isolated test cases for opengl (with and without ... New 10/24/2017

History

#1 Updated by Rob Baer over 2 years ago

  • Related to Bug #1054: Ubuntu 16.04 and mesa drivers added

#2 Updated by Joel Palmius almost 2 years ago

  • Target version changed from MakeHuman 1.1.1 to MakeHuman 1.1.2

Since this bug doesn't have any impact on normal users and no solutions seems close, I'm moving to 1.1.2.

#3 Updated by Rob Baer almost 2 years ago

There is no reason to think this is related other than it's a change in openGL messaging appeared with a MH1.1.1 pre-release with no associated change in our own code that I know about. Just adding here in case it gets otherwise lost:


E:\MHPre2-\OpenGL\GL\VERSION\GL_2_0.py:374: Future Warning: comparison to `None` will result in an element wise object comparison in the future.

#4 Updated by Aranuvir # almost 2 years ago

I noticed this error message on my Linux system,too, and thought about writing a bug report. What puzzled me, was the fact, that the error message pointed to a library outside MakeHuman ($HOME/.local/lib/python2.7/...). So this isn't something we can fix, and will hopefully get solved by the distributor. But we should keep an eye on the problem, for not missing to eventually update the Windows build system. It might make sense to create a separate bug report for that issue.

#5 Updated by Rob Baer almost 2 years ago

I believe this reflects our upgrading dependencies openGL or pyOpenGL libraries. The reason it shows here is because Joel has built with a library that flags it.

You are probably correct that it deserves a separate issue tag.

#6 Updated by Joel Palmius almost 2 years ago

Rob Baer wrote:

I believe this reflects our upgrading dependencies openGL or pyOpenGL libraries. The reason it shows here is because Joel has built with a library that flags it.

This is correct. When pyinstaller refused to produce a runnable exe on the jenkins machine, I installed a clean instance with the latest everything and ran pyinstaller there.

#7 Updated by Aranuvir # almost 2 years ago

  • Related to Bug #1144: openGL errors on startupof PPA MH1.1.1 added

#8 Updated by Jonas Hauquier almost 2 years ago

My 5ct, good chance this is the cause of the rendering glitches with some openGL drivers:

Failure on glGetUniformfv: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/OpenGL/logs.py", line 67, in __call__
    return function( *args, **named )
  File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 232, in glCheckError
    baseOperation = baseOperation,
GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glGetUniformfv,
        cArguments = (1L, 3, array([ 0.], dtype=float32))
)

Exception during event onStart
Traceback (most recent call last):
  File "./core/events3d.py", line 211, in callEvent
    method(event)
  File "./core/mhmain.py", line 806, in onStart
    self.startupSequence()
  File "./core/mhmain.py", line 728, in startupSequence
    self.loadHuman()
  File "./core/mhmain.py", line 383, in loadHuman
    self.selectedHuman = self.addObject(human.Human(files3d.loadMesh(mh.getSysDataPath("3dobjs/base.obj"), maxFaces = 5)))
  File "./apps/human.py", line 82, in __init__
    self.material = material.fromFile(getSysDataPath('skins/default.mhmat'))
  File "./shared/material.py", line 1372, in fromFile
    mat.fromFile(filename)
  File "./shared/material.py", line 476, in fromFile
    self.configureShading(diffuse=shaderConfig_diffuse, bump=shaderConfig_bump, normal=shaderConfig_normal, displacement=shaderConfig_displacement, spec=shaderConfig_spec, vertexColors=shaderConfig_vertexColors, transparency=shaderConfig_transparency, ambientOcclusion=shaderConfig_ambientOcclusion)
  File "./shared/material.py", line 913, in configureShading
    self._updateShaderConfig()
  File "./shared/material.py", line 950, in _updateShaderConfig
    bump = self._shaderConfig['bump'] and self.supportsBump()
  File "./shared/material.py", line 845, in supportsBump
    if self.shaderObj and result:
  File "./shared/material.py", line 1010, in shaderObj
    return self.getShaderObj()
  File "./shared/material.py", line 1006, in getShaderObj
    return shader.getShader(shaderPath, self.shaderDefines)
  File "./lib/shader.py", line 515, in getShader
    shader = Shader(path, defines)
  File "./lib/shader.py", line 306, in __init__
    self.initShader()
  File "./lib/shader.py", line 433, in initShader
    self.updateUniforms()
  File "./lib/shader.py", line 455, in updateUniforms
    for uniform in self.getUniforms():
  File "./lib/shader.py", line 449, in getUniforms
    uniform.update(self.shaderId)
  File "./lib/shader.py", line 134, in update
    self.glquery(pgm, self.index, values)

GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glGetUniformfv,
        cArguments = (1L, 3, array([ 0.], dtype=float32))
)

What is happening is, debug opengl mode makes the error checking strict, instead of being permissive (but potentially having adverse effects). We have just been able to put our finger on a part of the implementation that is not respecting the OpenGL spec correctly. Some OpenGL driver implemenations might be more permissive and handle this case better than others. None the less, the behaviour should be considered undertermined.

File "./lib/shader.py", line 306, in __init__
    self.initShader()
  File "./lib/shader.py", line 433, in initShader
    self.updateUniforms()
  File "./lib/shader.py", line 455, in updateUniforms
    for uniform in self.getUniforms():
  File "./lib/shader.py", line 449, in getUniforms
    uniform.update(self.shaderId)
  File "./lib/shader.py", line 134, in update
    self.glquery(pgm, self.index, values)

#9 Updated by Aranuvir # over 1 year ago

  • Status changed from New to Accepted
  • % Done changed from 0 to 10

I did some further investigations, as this issue is now showing up every time I start MakeHuman without --noshaders.
From what I can tell, the invalid operation arises when self.glquery is glGetUniformfv. The function takes three variables program = 1, location = 3, and params = array([1.], float32).
Program = 1 and location = 3 seem to point to AdditiveShading which is declared in litsphere_fragment_shader.txt as a uniform float. Is there some type mismatch? Though being honest, I'm still struggling to understand the purpose of the glGetUniformfv function...

#10 Updated by Rob Baer over 1 year ago

Don't know if this helps:
http://manpages.ubuntu.com/manpages/zesty/man3/glGetUniformfv.3G.html

I wonder if we need to look especially at the error section of this description?

#11 Updated by Jonas Hauquier over 1 year ago

The function retrieves the current value of that shader parameter.
The third parameter of the function is a pointer to where the function can write the return value. Perhaps if that type is not correct (eg it expects a float64 instead of float32) then it's possible this could cause a crash.
However, we do not get a crash.

Rather, we should look at the return code.

GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glGetUniformfv,
        cArguments = (1L, 3, array([ 0.], dtype=float32))
)

Fron the documentation Rob referenced, I think we should investigate this possibility:
GL_INVALID_OPERATION is generated if program has not been successfully
linked.

Perhaps we should add more defensiveness and check whether the shader program was compiled (and linked?) succesfully. There's probably some glGet calls that will allow such testing.
In the end, we'd like to know exactly why it's failing.

What one could also try:
glGetActiveUniform() with arguments program and the index of an active
uniform variable
does this return a valid result?

glGetProgram() with arguments program and GL_ACTIVE_UNIFORMS or
GL_ACTIVE_UNIFORM_MAX_LENGTH
and this one?

#12 Updated by Aranuvir # over 1 year ago

  • % Done changed from 10 to 50

Well, the class Uniform stores the shader name (self.name) and the assumed shader location (self.index). The index is probably not the location. Changing the update function in the VectorUniform to something like

location = glGetUniformLocation(pgm, self.name)

and
self.glquery(pgm, location, values)

seems to fix the issue. Though, this is just a quick and dirty workaround. The whole update thingy looks odd to me and probably could need a rewrite ...

BTW, further bugs are waiting. To be continued ...

#13 Updated by Aranuvir # over 1 year ago

  • % Done changed from 50 to 80

OK, instead of creating further bug reports, let's generalize this problem a bit. If one defines a new self.location variable in the Uniform class, sets it to the result of glGetUniformlaction and replaces every occurrence of self.index with self.location the GL-bugs magically vanish and...

... this odd color thingy on Linux has disappeared! :D :D :D

I'd consider this more a workaround, rather than a bug fix, since it changes slightly the initial intention of the coders and probably introduces some additional redundancy. A rewrite of parts of the code is probably necessary.

#14 Updated by Aranuvir # over 1 year ago

  • Status changed from Accepted to Fix exists, needs testing
  • % Done changed from 80 to 90

Committed a fix to my github branch.

#15 Updated by Rob Baer over 1 year ago

ubuntu 16.04

I'm not clear exactly what I should be testing. Is this commit 6d6d205f161f51d5b661d07dad4f236f35ac64e2 ?

If so, it starts far enough to produce a splash screen with python34 but then hangs. There is a console error 1252.

...
Loading ASCII mesh data/3dobjs/base.obj.
Not writing compiled meshes to system paths (data/3dobjs/base.npz).
Loading material from file data/skins/default.mhmat
Shader: adding built-in uniform b'gl_ModelViewProjectionMatrixTranspose'
Shader: adding built-in uniform b'gl_NormalMatrix'
Exception during event onStart
Traceback (most recent call last):
  File "./core/events3d.py", line 211, in callEvent
    method(event)
  File "./core/mhmain.py", line 823, in onStart
    self.startupSequence()
  File "./core/mhmain.py", line 747, in startupSequence
    self.loadHuman()
  File "./core/mhmain.py", line 388, in loadHuman
    self.selectedHuman = self.addObject(human.Human(files3d.loadMesh(mh.getSysDataPath("3dobjs/base.obj"), maxFaces = 5)))
  File "./apps/human.py", line 83, in __init__
    self.material = material.fromFile(getSysDataPath('skins/default.mhmat'))
  File "./shared/material.py", line 1372, in fromFile
    mat.fromFile(filename)
  File "./shared/material.py", line 476, in fromFile
    self.configureShading(diffuse=shaderConfig_diffuse, bump=shaderConfig_bump, normal=shaderConfig_normal, displacement=shaderConfig_displacement, spec=shaderConfig_spec, vertexColors=shaderConfig_vertexColors, transparency=shaderConfig_transparency, ambientOcclusion=shaderConfig_ambientOcclusion)
  File "./shared/material.py", line 913, in configureShading
    self._updateShaderConfig()
  File "./shared/material.py", line 950, in _updateShaderConfig
    bump = self._shaderConfig['bump'] and self.supportsBump()
  File "./shared/material.py", line 845, in supportsBump
    if self.shaderObj and result:
  File "./shared/material.py", line 1010, in shaderObj
    return self.getShaderObj()
  File "./shared/material.py", line 1006, in getShaderObj
    return shader.getShader(shaderPath, self.shaderDefines)
  File "./lib/shader.py", line 522, in getShader
    shader = Shader(path, defines)
  File "./lib/shader.py", line 313, in __init__
    self.initShader()
  File "./lib/shader.py", line 440, in initShader
    self.updateUniforms()
  File "./lib/shader.py", line 462, in updateUniforms
    for uniform in self.getUniforms():
  File "./lib/shader.py", line 456, in getUniforms
    uniform.update(self.shaderId)
  File "./lib/shader.py", line 137, in update
    self.glquery(pgm, self.index, values)
  File "/home/rwbaer/anaconda3/envs/python34/lib/python3.4/site-packages/OpenGL/platform/baseplatform.py", line 402, in __call__
    return self( *args, **named )
  File "/home/rwbaer/anaconda3/envs/python34/lib/python3.4/site-packages/OpenGL/error.py", line 232, in glCheckError
    baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
    err = 1282,
    description = b'invalid operation',
    baseOperation = glGetUniformfv,
    cArguments = (1, 3, array([ 0.], dtype=float32))
)

If this is not the right thing to test, let me know how to get the right code. I'm attaching MakeHuman.log. I did not use any command line switches.

#16 Updated by Aranuvir # over 1 year ago

6d6d205f161f51d5b661d07dad4f236f35ac64e2 ? Something is telling me you're still on master. Perhaps try things like:

git checkout AranuvirQt5  :)

Here is my latest commit: https://github.com/makehumancommunity/makehuman/commit/084ec857d2c1bc004d90cbd4e21dd16b3c8a8469

#17 Updated by Rob Baer over 1 year ago

Yes, it was master indeed, but when I did git branch and I didn't see other branches I assumed there were none. Guess my git skills are sttill weak.

Your checkout seems to have gotten me the proper branch. This time it starts all the way up, but alas, no human.

EDIT: New logs uploaded. @Joel - if your following, pasting from clipboard is not in-lining the image anymore!

There are GL errors in the log. FWIW this computer has an Intel graphics card and hence the message when I clicked the render tab I suspect.

#18 Updated by Aranuvir # over 1 year ago

The next information after "QT.CONF: NOT PRESENT" (that's line 28 in your log file) is "PYOPENGL.VERSION: 3.1.0" on my system. Using a search tool on your log file I cannot find any pyopengl information. Do you have all dependencies?

 apt-get install python3-opengl, python3-qt5.qtopengl, python3-qt5.qtsvg ... ?

#19 Updated by Aranuvir # over 1 year ago

??? The edit obviously has happened 1 hour +- x after my last post.

"EDIT: New logs uploaded."

? The timestamps in both log files, which I have on my system, now, are exactly the same. So where are the differences?

Did you check ALL your dependencies, as suggested. And if it doesn't help, what happens when running MH outside this constrictor thingy?

#20 Updated by Joel Palmius over 1 year ago

This is aranuvirqt5 on windows 10 in virtualbox:

Traceback (most recent call last):
  File "C:\Python36\lib\site-packages\OpenGL\latebind.py", line 41, in __call__
    return self._finalCall( *args, **named )
TypeError: 'NoneType' object is not callable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./lib\qtui.py", line 291, in initializeGL
    gl.OnInit()
  File "./lib\glmodule.py", line 303, in OnInit
    glLightModelfv(GL_LIGHT_MODEL_AMBIENT, A(0.0, 0.0, 0.0, 1.0))
  File "C:\Python36\lib\site-packages\OpenGL\latebind.py", line 45, in __call__
    return self._finalCall( *args, **named )
  File "C:\Python36\lib\site-packages\OpenGL\wrapper.py", line 686, in wrapperCall
    raise err
  File "C:\Python36\lib\site-packages\OpenGL\wrapper.py", line 679, in wrapperCall
    result = wrappedOperation( *cArguments )
  File "C:\Python36\lib\site-packages\OpenGL\platform\baseplatform.py", line 402, in __call__
    return self( *args, **named )
  File "C:\Python36\lib\site-packages\OpenGL\error.py", line 232, in glCheckError
    baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
        err = 1282,
        description = b'invalid operation',
        baseOperation = glLightModelfv,
        pyArgs = (
                GL_LIGHT_MODEL_AMBIENT,
                array([ 0.,  0.,  0.,  1.], dtype=float32),
        ),
        cArgs = (
                GL_LIGHT_MODEL_AMBIENT,
                array([ 0.,  0.,  0.,  1.], dtype=float32),
        ),
        cArguments = (
                GL_LIGHT_MODEL_AMBIENT,
                array([ 0.,  0.,  0.,  1.], dtype=float32),
        )
)

Also attaching log.

MH on py2 and pyqt4 runs fine in the same environment, so obviously there's something different with qt5 here.

#21 Updated by Joel Palmius over 1 year ago

Oops. Now attaching log.

#22 Updated by Joel Palmius over 1 year ago

Exact dependency versions (according to pip)

numpy (1.12.1)
pip (9.0.1)
PyOpenGL (3.1.0)
PyQt5 (5.9)
setuptools (28.8.0)
sip (4.19.3)

python is official 3.6.3 32-bit.

#23 Updated by Joel Palmius over 1 year ago

#24 Updated by Joel Palmius over 1 year ago

Same test, same branch (aranuvirqt5), same dependencies, but repeated on native windows 10 with nvidia gtx 980:

... thus concluding it works per se. On pyqt4 with older opengl it seems the wrapper is much more forgiving if the underlying native layer doesn't support a particular feature/operation. On qt5 with modern gl it crashes horribly if something isn't supported.

#25 Updated by Aranuvir # over 1 year ago

IMHO we're currently going far beyond the initial bug and its fix, since I consider the qt5 branch highly experimental. Could you please check the fix from my qt4 branch? Though, this makes only sense if you have been affected by the bug before.

@Joel: taking a look at your log file, one gets the impression that even basic gl commands, like getting the vendor string do not work:

GLError(
    err = 1282,
    description = b'invalid operation',
    baseOperation = glGetString,
    cArguments = (GL_VENDOR,)
)

Not sure how to interpret this issue:

Traceback (most recent call last):
  File "C:\Python36\lib\site-packages\OpenGL\latebind.py", line 41, in __call__
    return self._finalCall( *args, **named )
TypeError: 'NoneType' object is not callable

Does opengl crash as a whole?

#26 Updated by Joel Palmius over 1 year ago

Aranuvir (Moderator) wrote:

IMHO we're currently going far beyond the initial bug and its fix, since I consider the qt5 branch highly experimental. Could you please check the fix from my qt4 branch? Though, this makes only sense if you have been affected by the bug before.

My situation is this:

  • Qt4 on virtualbox: works
  • Qt4 on native nvidia: works
  • Qt5 on virtualbox: crashes (as per above)
  • Qt5 on native nvidia: works

(qt4 = 1.1.1 release from tuxfamily, qt5 = aranuvirqt5 source with python 3.6.3)

So maybe this is a different error? Seeming as virtualbox (qt4) worked even without the fix?

Is the qt4 branch we're talking about "Aranuvir"?

Anyway, this reminds me I now have a spare machine which runs an intel card. It needs reinstallation though. Maybe I can get different crashes on that. What os + python combo would be most interesting to see on it?

@Joel: taking a look at your log file, one gets the impression that even basic gl commands, like getting the vendor string do not work:
[...]

Not sure how to interpret this issue:
[...]
Does opengl crash as a whole?

I don't know. :-)

Only the second error causes a python stack trace though.

#27 Updated by Rob Baer about 1 year ago

I will try the 'Aranuvir' branch, but I don't think there is one universal error and one universal fix. I think the error is situational and fundamental as exceptions are happening in libraries and not the MH code itself. MH error checking at each openGL call might help us, particularly when we compile shaders. I think specific behavior depends on operating system as well as graphics card.

I've gotten a little murky about the history, but I believe I had a single dual boot computer with an Intel card that worked when I direct booted into Windows, but did not work (failed) when I direct booted into Ubuntu 16.04 mesa drivers - this was before the fix -- all with qt4 and python 3.4

It may well be that Qt5 unmasks additional behaviors, and it is fine to deal with those separately. BUT, we need to be sure specify OS, graphics card, presence of virtual machine if relevant, and other test parameters as we work through this.

#28 Updated by Aranuvir # about 1 year ago

AWESOME! That's probably getting a nightmare! Got another one in my VBox-Vm (it's Linux, 3D-acceleration enabled, Python3, Qt5)

Loading material from file data/skins/default.mhmat
Error compiling shader: b'0:2(1): error: syntax error, unexpected NEW_IDENTIFIER\n'
Error loading shader /home/[...]/makehuman/makehuman/data/shaders/glsl/litsphere
Traceback (most recent call last):
  File "./lib/shader.py", line 525, in getShader
    shader = Shader(path, defines)
  File "./lib/shader.py", line 315, in __init__
    self.initShader()
  File "./lib/shader.py", line 417, in initShader
    raise RuntimeError("No vertex shader program compiled, cannot set vertex shader. (%s)" % vertexSource)
RuntimeError: No vertex shader program compiled, cannot set vertex shader. (/home/[...]/makehuman/makehuman/data/shaders/glsl/litsphere_vertex_shader.txt)

To fix the problem simply deactivate 3D-acceleration. I fear these issues happen outside MH and are probably outside our scope.

Here PyOpenGl-accelerate is installed and 3D-acceleration enabled:

OpenGL_accelerate module loaded
Traceback (most recent call last):
  File "makehuman.py", line 831, in <module>
    main()
  File "makehuman.py", line 821, in main
    from mhmain import MHApplication
  File "./core/mhmain.py", line 46, in <module>
    import mh
  File "./lib/mh.py", line 43, in <module>
    from glmodule import grabScreen, hasRenderSkin, renderSkin, getPickedColor, hasRenderToRenderbuffer, renderToBuffer, renderAlphaMask
  File "./lib/glmodule.py", line 45, in <module>
    import OpenGL.GLU
  File "/usr/lib/python3/dist-packages/OpenGL/GLU/__init__.py", line 3, in <module>
    from OpenGL.error import *
  File "/usr/lib/python3/dist-packages/OpenGL/error.py", line 224, in <module>
    ErrorChecker = _ErrorChecker( platform )
  File "errorchecker.pyx", line 17, in OpenGL_accelerate.errorchecker._ErrorChecker.__init__ (src/errorchecker.c:818)
TypeError: __init__() takes at least 2 positional arguments (1 given)

In this case enabling or disabling 3D-acceleration does not make a difference.

Conclusion: Do we really want to port to Qt5? I'd suggest to stick with Qt4 and drop Windows support ...

#29 Updated by Rob Baer about 1 year ago

Well, you won't catch me advocating dropping Windows ;-)

BTW, I have our Python 3 MH master working fine with python 3.4 and and QT4 on Windows (Intel and Nvidia graphics machines both work). It's just support for python 3.6 that is lacking and requires QT5.

On the other hand getting opengl support with my Intel graphics card on the Linux side has been quite difficult or virtually impossible with EITHER of the QTs. The very same machine (dual boot) with its intel graphics card runs MH on python3.4 with qt4 just fine under windows 10 but not ubuntu 16.04.

The issues with openGL are unlikely to be just about QT5. They predate QT5, and in fact have lurked since alpha days. We have just enough RIGHT in our code that everything works until the libraries change, or venders drivers change, or dark magic happens with some virtual machine.

Python 3 IS the future - we need to shallow that. QT4 is in essence gone with python 3 beyond python 3.4, and it makes no sense to develop towards QT4 in a python 3 version. pyside {4} is alive for now, but all serious development is pyside2. Pyside did not seem to work well for @Aranuvir on his system, although both @Joel and @Rob had it working on at least some platforms. I'm not sure I ever tried it with python 3.6 though. I may have though.

We could focus on pyside2, but I'm not sure it is far enough along that we even have the possibility to get it working in the PRESENT, but I don't know that for certain. Python 3.6 is where the present-day python work is happening, and it makes sense to do python 3.6 and QT5 to have a future-proof way to move forward.

As to acceleration, my widows machine logs have from the start not had support for the acceleration module. On occasion, I've pip installed and gotten the log to show support, but honestly it made no difference to performance. I wouldn't loose sleep over this in and of itself.

Of greater concern is the pyopengl binding to openGL. When we first worked on py3 port, Joel experience some problems on his Linux system that didn't exist on the Windows side. When we looked at the binding which had a slightly older version on the linux side, and contacted the maintainer, my memory was that it seemed like "no one was home",

If I understood the links Joel posted the other day, it seemed like the message might be that QT5 has intrinsic openGL support. How much it would impact the MH code to take advantage of that support is another question. If it were not too much infrastructure rebuilding, and my impression is correct, maybe replacing the pyopengl-binding dependency could solve many of these problems together.

Finally, although we are getting errors inside library code, Jonas has already suggested that we could protect ourselves better with some error checking in our own code. In theory this could at least prevent us from blowing up library code with bad input from a previous step.

#30 Updated by Rob Baer about 1 year ago

#31 Updated by Joel Palmius about 1 year ago

Also, let's not forget that the py3 + qt5 port actually works when on decent graphics hardware. It runs fine for me both on linux and on windows, when native on my nvidia machine.

In a side-by side comparison, I would be hard-pressed to say which was running py2 + qt4 and which was running py3 + qt5.

Pyside2 is most definitely not for the faint of heart presently. For example, there is no binary release for windows: You have to compile it yourself from source. Trying to use it now would introduce a whole host of new problems, although I think that in the long run it will be preferable to PyQt.

#32 Updated by Rob Baer about 1 year ago

  • Related to Bug #1208: Community AranuvirQt5 branch on MacOsx High Sierra added

#33 Updated by Joel Palmius about 1 year ago

Ok, I feel stupid. What am I doing wrong? I can't reproduce the crashes even on an intel card. I've tested both the master branch with python 3.4 + pyside, and the AranuvirQt5 branch with python 3.6 and pyqt5. It even looks as if the shaders are behaving properly. All this is on a clean install of windows 10.

Python 3.4.4, pyside, master branch

Python 3.6.3, pyqt5, aranuvirqt5 branch

#34 Updated by Joel Palmius about 1 year ago

It also works with the release (ie python 2.7 + pyqt4) on the same machine.

#35 Updated by Jonas Hauquier about 1 year ago

Keep up the great work! :)

#36 Updated by Aranuvir # about 1 year ago

Just some side notes: PyOpenGl-accelerate != 3D-acceleration. This 3D-acceleration thingy is a VirtualBox setting which does some magic with guests and hosts opengl libraries. The PyOpenGl-accelerate library was tested out of pure curiosity...
I'm not sure if VirtualBox should be considered a reliable testing environment for OpenGl. BTW, the OpenGl problems were/are not limited to Intel graphics cards, and I wouldn't affirme a statement that it's all an issue of bad Intel drivers...

#37 Updated by Jonas Hauquier about 1 year ago

There is a thing like OpenGL software renderer.
I believe there's some reference implementation of OpenGL on cpu.
It's also my guess that this is a good way of verifying your opengl code because it is quite strict and unforgiving.

#38 Updated by Joel Palmius about 1 year ago

  • Related to Bug #1209: Produce isolated test cases for opengl (with and without various version of qt) added

#39 Updated by Aranuvir # about 1 year ago

Current state on my Windows system, I get these interesting access violation errors:

Traceback (most recent call last):
  File "./lib\glmodule.py", line 231, in reshape
    updatePickingBuffer()
  File "./lib\glmodule.py", line 141, in updatePickingBuffer
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
OSError: exception: access violation reading 0x00000088

regardless of using the --noshaders option, or not.

Also available in: Atom