glShadeModel: invalid operation -> no 3d #97
Comments
|
#92 : midyukov-anton is hitting the same issue. |
|
It seems to be some kind of linker-issue ... as if the python wrapper for opengl knows about symbols but can not find a single one. And each time such a symbol is used it throws errors like "invalid operation" "invalid enumerant" instead. |
|
Did you try to run the previous state (e.g. commit 77dd887) with python3 (e.g. From a distance, this feels like a local library issue. Even though I would not expect this with a Debian system (I hardly ever encountered this). Maybe you are using external repositories (e.g. deb-multimedia)? Regarding #92: the submitter of that bug report noticed a difference between libglut (works) and libfreeglut (fails). Did you try this, as well? |
|
77dd887 with |
|
After fiddling some more with the code , by redoing the imports stumbled on something weird: The python code referenced |
|
Regardless of how you/we sort this out, I think it would be a good idea
to post a report upstream.
…On Dec 24 2017 9:54 AM, FDePourcq wrote:
After fiddling some more with the code , by redoing the imports
stumbled on something weird:
```
Traceback (most recent call last):
File "/home/donf/src_other/pycam/pycam/Plugins/OpenGLWindow.py",
line 740, in paint
self.glsetup()
File "/home/donf/src_other/pycam/pycam/Plugins/OpenGLWindow.py",
line 514, in glsetup
| GLUT.GLUT_MULTISAMPLE | GLUT.GLUT_ALPHA | GLUT.GLUT_ACCUM)
File "/usr/lib/python3.6/ctypes/__init__.py", line 361, in
__getattr__
func = self.__getitem__(name)
File "/usr/lib/python3.6/ctypes/__init__.py", line 366, in
__getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/x86_64-linux-gnu/libglut.so.3: undefined
symbol: GLUT_RGBA
Font directory: /home/donf/src_other/pycam/share/fonts
```
The python code referenced `GLUT.GLUT_RGBA` and this value is defined
with a preprocessor #define in glut, so it should not result in
compiled code, it should not be present as a symbol in the dynamic
library (.so).
And indeed I see in PyOpenGl in raw/GLUT/constants.py the thing
explicitly redefined for python:
`GLUT_RGBA = Constant( 'GLUT_RGBA', 0)` ... but still for unknown
reason ... that constant is being searched in the dynamic library ...
I suspect that the root-cause of that problem will be really close to
the root-cause of the other problems here.
|
I used this approach in order to avoid rather complicated (and repetitive) conditional imports (since OpenGL is not strictly required). I doubt, that this import-once approach could change the behaviour of the OpenGL libraries - but of course, there could be magic involved :) I still find it a bit puzzling, that you could encounter such issues with a clean Debian installation without external repositories. I am also using Debian "testing" (just for i386 instead of amd64). If your local installation is fine, then I agree with ebo, that an upstream bug report could be the way to proceed. |
|
It is not a clean installation in the sense that it has gone through several upgrades already. So a completely clean installation might not have these problems. I will give it some more time and if that does not work ... will look into that mysterious upstream. (Whatever that means: i don't see a debian package for pycam, i can't say if it is an issue with python3 or with pyopengl or with debian packaging or with some extra layer i don't know about yet.) |
I did not want to appear so picky :) An upgraded installation is perfectly fine. Maybe you can use |
|
Debian 9.3: $ ./run_gui.py (run_gui.py:1172): Gtk-CRITICAL **: gtk_box_pack: assertion '_gtk_widget_get_parent (child) == NULL' failed (run_gui.py:1172): Gtk-CRITICAL **: gtk_box_pack: assertion '_gtk_widget_get_parent (child) == NULL' failed |
Also, i rebooted the same machine to a ubuntu (which also never saw sources.list-modifications and even less upgrades):
|
|
from https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glShadeModel.xml GL_INVALID_OPERATION is generated if glShadeModel is executed between the execution of glBegin and the corresponding execution of glEnd. |
|
I have the same issue using this commit: Probably, the problem was introduced in 3p dependency. It's sad, there are no unit tests. |
|
@valeriob01: the error handling while loading the workspace file is improved now. Thus the one error (due to OpenGL) will not be mangled with unrelated error output anymore. @FDePourcq: thank you for taking the time to try it in a clear environment. What a pity, that this did not offer any new clues to us (as far as I understood). @unrealsolver: yes, frozen requirements would prevent a certain class of problems with the cost of introducing another one. Personally I prefer non-versioned dependencies. @ all: could you please try if the same error happens with commit 77dd887 - either with python2 or python3? I am wondering if this is a python3-opengl-specific issue (but I have no idea at all). |
|
Now there is a blank 3d model window
but still: |
under which circumstances? |
|
python3 pycam/run_gui.py |
|
The error is still the same on my non-debian os. |
|
@valeriob01 & @unrealsolver : did you use the current master for your test? Did you also try the commit 77dd887 with python2 and python3? What exactly was the behaviour of these three situations? Thank you! |
|
The output for python3 and master / 77dd887 are same (the OpenGL error part is exact same). I haven't installed python2 deps yet and couln't test it yet. |
|
not getting very far. I figured that if you put But the demo-scripts in pyopengl seem to work (after converting them from python2 to python3 using the script 2to3-3.6 )... of course those demo-scripts have no gtkglarea... |
|
I think i know what is going on: --> ... even if i figure out how to build it for python3 ... ... is it possible to resurrect the living dead debian package maintainers? |
|
@FDePourcq: almost :) PyCAM switched from GTK2 to GTK3 and from Python2 to Python3. This also included the switch from gtkglext (gtk2/python2) to gtk.GLArea (GTK3). Thus gtkglext is finally not an issue anymore. I am very confused, that the current state is not working for the three of you. With the libraries above, the current master works with Python3 and 77dd887 work with Python2 and Python3 on my system. Please make sure that you do not use manually compiled libraries (e.g. via virtualenv), when checking the same on your systems. |
|
|
|
$ dpkg -l |grep -E "(glut|python3?-opengl|gir1.2-gtk-3.0|libglu?1)" |
|
|
Just a guess, probably GL.glShadeModel is a deprecated function ? |
|
no, because the other gl-calls have it too and they do work after glut.createwindow. My guess is that the implementation of gtk.glarea does not succeed in making itself the "current opengl context" -> the subsequent opengl-calls are no valid operations on a non-existing context. |
|
Which other gl-calls ? |
|
@FDePourcq it would suffice to emit a render signal https://developer.gnome.org/gtk3/stable/GtkGLArea.html#GtkGLArea-render, that would make the GLArea the current context.??? |
|
i tried things like |
|
I am amazed, that you were (probably painfully) digging deeper! I am still confused, that everything is working fine for me - while you are having issues. This should indicate that it is indeed not a high-level problem (e.g. caused by the way the PyCAM code handles GLArea). Or what do you think? I will ask on the pycam-devel mailinglist if it works for them. Maybe this will give us a better feeling for the source of the problem. |
|
So I gave it one more try: "maybe my system does not have that specific extension??" It has it but ... not in the list directly beneath the opengl 4.50 ... it is only mentioned in the list beneath So ... either ... my opengl 4.50 should have that Anyway ... getting closer. |
|
WAAAA IT WOOOORKSS but it looks horrible :( Downgrading all mesa 17.2.5 to 13.0.6 did not help with that. https://www.khronos.org/opengl/wiki/GL_EXT_framebuffer_object --> this is indeed the stuff gtkglarea in gtk+3 is build upon. |
|
Woo Hoo! Congrats ;-)
…On Dec 27 2017 2:07 PM, FDePourcq wrote:
WAAAA IT WOOOORKSS
```
MESA_GL_VERSION_OVERRIDE="3.0 Mesa 17.2.5" python3
./pycam/run_gui.py
```
|
|
oh wait it is no solution yet, the different mesa-version offers a useless gui, i am figuring out if i can't get different graphics-drivers. -> nvidia driver is the latest already :( (nvidia-driver-bin 384.98-3) |
|
I will still give you a "Woo Hoo"... we need to celibate our successes
from time to time, even when they are small ;-)
…On Dec 27 2017 3:17 PM, FDePourcq wrote:
oh wait it is no solution yet, the different mesa-version offers a
useless gui, i am figuring out if i can't get different
graphics-drivers.
|
|
SBANG !!! Good! $ MESA_GL_VERSION_OVERRIDE="3.0 Mesa 17.2.5" python3 pycam/run_gui.py (run_gui.py:1328): Gtk-CRITICAL **: gtk_box_pack: assertion '_gtk_widget_get_parent (child) == NULL' failed (run_gui.py:1328): Gtk-CRITICAL **: gtk_box_pack: assertion '_gtk_widget_get_parent (child) == NULL' failed (run_gui.py:1328): Gtk-WARNING **: Allocating size to GtkBox 0x56312da33170 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? (run_gui.py:1328): Gtk-WARNING **: Allocating size to GtkWindow 0x56312dc1a2a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? (run_gui.py:1328): Gtk-WARNING **: Allocating size to GtkBox 0x56312da33170 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? (run_gui.py:1328): Gtk-WARNING **: Allocating size to GtkWindow 0x56312dc1a2a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
|
|
Mesa override trick does not work for me either. In addition, have following error: |
fixed now - see 40dc12f |
|
@FDePourcq, @valeriob01, @unrealsolver: what is the current status of this bug? |
|
I just did a git pull and ./pycam/run_gui.py --> still the same. I ... moved on ... by writing my own script for getting that drill perfect the way i wanted it ... i should still upload that script to github. (Also i got myself a 4th axis -> pycam would not have helped me there anyway.) |
|
Hi - I am having exactly same issue. When running with Any help would be appreciated! |
|
@tracek: I took a look at the code that could lead to the error thrown above by Here on my system (Debian testing, i386, python3-openg==3.1.0+dfsg-1), the above error cannot be thrown, as far as I can tell (all types are properly handled in that function). Which version of python3-opengl do you use? |
|
@sumpfralle Thanks for checking it. I am on 3.0.2-1 (latest in the stable repo), Xubuntu 16.04. |
|
Hi. Same here with 0.7.0~pre0.480.gd0d0091.dirty, Ubuntu Mate 18.04, Nvidia GeForce GTX 750 Ti, Driver 396.24.02: OpenGL.error.GLError: GLError( To verify my driver setup i tried this example: I don't know if this is enough to verify that the drivers works. Because my python skills are not so good yet the code is not easy to debug for me. |
|
My OpenGL understand is quite minimal.
|
|
A few comments:
|
|
FYI, I am having this issue on Ubuntu 16.04.5 LTS on a set-up with two graphic adapters: an Intel Xeon E3-1200 (i915 kernel module) and an AMD Radeon HD 7770/8760 (radeon kernel module), kernel 4.4.0-137-generic, python3 (3.5.2), pyopengl (3.0.2-1). The MESA_GL_VERSION_OVERRIDE trick does not work for me. It shows "Unable to create GL context" or something similar where the visualisation should show. |
|
I think, the issue is caused by #134. |
|
Problem still present. Debian testing, mesa 18.3.2 mesa info: MESA_GL_VERSION_OVERRIDE="3.0" fixes the problem |
|
After running with gl override, I started without it, and now 3d was working, but errors were present |
Hi,
when trying out the master branch ( 23 dec 2017 ) I get no opengl rendering and lots of errors are thrown:
I am running debian:
In pycam version 6.2 the opengl-part works fine on my system. I might dig in to it because I want good toolpaths. :)
The text was updated successfully, but these errors were encountered: