makehumancommunity / makehuman

This is the main repository for the MakeHuman application as such.
http://www.makehumancommunity.org
Other
1.22k stars 250 forks source link

Render plugin generates an exception ( when used with older version of GL (2.1 vs 3.0 and higher) #62

Closed afarlie closed 4 years ago

afarlie commented 4 years ago

Version: 1.2.0 alpha3 Component:
plugins/4_rendering_openGL lib/glmodule.py pkgs/OpenGl

Short summary: Rendering generates an exception leaving the program effectively crippled. This issue does not occur with 1.1.x stable version.

Observed behaviour:-

Started MakeHuman 1.2.0 alpha3

Changed NO settings, go to Render with default resolution given.

Rather than the expected behaviour of an image being rendered I get this:

" Exception during event onClicked Traceback (most recent call last): File "C:\Program Files\makehuman-community\pkgs\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 "C:\Program Files\makehuman-community\pkgs\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 "./core\events3d.py", line 211, in callEvent method(event) File "C:\Program Files\makehuman-community\makehuman\plugins\4_rendering_opengl__init.py", line 125, in onClicked mh2opengl.Render(settings) File "C:\Program Files\makehuman-community\makehuman\plugins\4_rendering_opengl\mh2opengl.py", line 104, in Render img = mh.renderToBuffer(width, height) File "./lib\glmodule.py", line 901, in renderToBuffer glDeleteFramebuffers(np.array([framebuffer])) File "C:\Program Files\makehuman-community\pkgs\OpenGL\latebind.py", line 45, in call return self._finalCall( *args, *named ) File "C:\Program Files\makehuman-community\pkgs\OpenGL\latebind.py", line 61, in call return self.wrapperFunction( self.baseFunction, args, **named ) File "C:\Program Files\makehuman-community\pkgs\OpenGL\GL\ARB\framebuffer_object.py", line 328, in glDeleteFramebuffers return baseOperation( n, framebuffers ) File "C:\Program Files\makehuman-community\pkgs\OpenGL\latebind.py", line 45, in call__ return self._finalCall( *args, *named ) File "C:\Program Files\makehuman-community\pkgs\OpenGL\wrapper.py", line 679, in wrapperCall result = wrappedOperation( cArguments ) File "C:\Program Files\makehuman-community\pkgs\OpenGL\platform\baseplatform.py", line 407, in call self.name, self.name, OpenGL.error.NullFunctionError: Attempt to call an undefined function glDeleteFramebuffers, check for bool(glDeleteFramebuffers) before calling"

Expected behaviour:

Rendering of image per settings and textures set up in program, and GUI presented by the plugin.

mdamonconnolly commented 4 years ago

Does the problem persist with alpha4?

afarlie commented 4 years ago

Where do I grab a windows build of alpha4?

afarlie commented 4 years ago

As a quick test I took the Render code from the 1.1.x series, and I still get the same problem, of a near identical exception. The problem isn't the plugin, but it WOULD seem to be an issue with the underlying GL support module.

afarlie commented 4 years ago

I don't think this issue will be solved by using alpha4 as the underlying causes are a little more interesting.

The problem I think I've encountered is that Make Human's GL support isn't apparently checking what version of Open GL is being used by the underlying OS/Grpahics chipset, as robustly as it could be.

The exception above would appear to occur because the GL support module is trying to make a call that is only supported in Open GL 3.0 and higher. Naturally this call will fail when the underlying graphics drivers claim to only support 2.1 (as would be the case with drivers that have not been updated in some time.)

Would it be possible to provide some kind of version check in the code, implementing a fall-back rendering support method, for older chipsets that don't fully support more recent versions of the OpenGL specification (given that there was render code in the 1.1.x and older series of releases, which would have been written for older versions of the GL spec?

Aranuvir commented 4 years ago

@afarlie: Thanks for your input. MakeHuman makes use of OpenGL 2.0/2.1. When it comes to these bugs the situation is weird. Sometimes things work and with update of drivers they stop to work. We planed to update the code to something like OpenGL 3.0 or higher. But following a developer blog of Blender about graphics card issues, I'm not too positive we'll get all bugs fixed...

afarlie commented 4 years ago

The problematic call in the exception is to glDeleteFrameBuffers call (nominally in lib/glmodule.py) I think..

According to https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDeleteFramebuffers.xhtml

The call isn't actually supported until GL 3.0 according to the box at the bottom....

It's not unexpected that the developers would use Gl 3.0 functionality. However, some kind of version/feature check in the code as opposed to a silent failure would as I say be a better way of handling this. If Make Human was essentially going to be Gl 3.0 (or higher) moving forward then doing this version check would be highly recommended. Of course providing a fall-back to use an older GL 2.0/2.1 way of doing the same function would also be appreciated for those of with 'real user' budgets for hardware :laughing:

Unless this was actually a typo for a different call entirely given that the parameter count doesn't seem to match up given the context...

(In 1.1.x the Render plugin works, provided that no materials are used, because for me it doesn't seem to handle the shading properly. If it's trying to use a litsphere texture defined as such as a diffuse texture, there's something wrong in the code..)

Blender 3.8.0 is GL 3.0 and higher, (I asked on their freenode IRC channel explicitly) So Make Human also going for this wouldn't be unexpected. (I clearly need new hardware...)

mdamonconnolly commented 4 years ago

@afarlie, Can you clone the version from my fork of this and try it and see if it fixes your problem?

afarlie commented 4 years ago

Do you have a link for the fork (alternatively do you have a diff for the changes needed?)

I'll ceratainly be testing your 'legacy compatiable' module in the next few days, Perhaps a comment about this could also be fed back to the upstream maintainers of the PyOpenGl bindings?

mdamonconnolly commented 4 years ago

https://github.com/mdamonconnolly/makehuman

It's just the simple function name changes now but if they work for you i'll add it in as a fallback or whatever seems best.

afarlie commented 4 years ago

Changes worked, but it was a bit of work around to install it manually, putting it into a formal patch as a fallback legacy mode would be advised.

(Aside: Can someone consider making an Alpha 4 build/distro for Win32 thanks? )

afarlie commented 4 years ago

Based on the above identification of the issue and the intended patch I am suggesting this issues can now be closed this as "fix or workaround available" . Any objections?

Aranuvir commented 4 years ago

I'd suggest to leave that task open. The fix deserves an evaluation, if it could go into the official repo, perhaps in an separate branch at first...

mdamonconnolly commented 4 years ago

My fix can't go into the master branch. It uses fallback versions of the openGL functions that aren't compatible with 2.1, but it compromises stability for users with more up-to-date hardware.

I'm not sure about the performance impact of constantly branching or using try/except every time one of these functions is used but I'll profile some of the fixes I have locally and see how much it affects the performance and try to find something more permanent.

joepal1976 commented 4 years ago

I'm following this with great interest. We certainly need stability/fallback fixes. The number one issue which we have is the depressingly large number of graphics cards that fail to run makehuman.

I think we're perfecly willing to accept a reasonable performance hit if it means that a larger number of graphics cards will work.

mdamonconnolly commented 4 years ago

@afarlie (or anyone with the hardware to test), my fork now has an update for this, if you want to test that. If you want a build, let me know your preferred delivery method and I'll build and send it to you.

Aranuvir commented 4 years ago

Seems to be fixed.