Issue with Windows

[Simon Harwood]

Hi All,

I'm evaluating various options to display a 3D Heightmap with Python and came across Pi3D (which I know is mainly for the RPi), which looks really interesting.

I have installed everything as per the instructions and I know that PyGame works fine on my laptop (I have run several PyGame scripts successfully), however every time I run one of the Pi3D demos the PyGame window pops up and then just sits there doing nothing except showing a coloured background. Very occasionally I can see one of the Sprites/Models for a split second, so it looks like either the render order is screwed up, or PyGame is not being refreshed correctly?

I'm running Pi3D on a Windows 10 Laptop with an i7 CPU, 16GB RAM and a GTX770M GPU. I have also tried the integrated GPU with no success.

If anyone has any thoughts on how to fix this I would be extremely grateful, as I would really like to test how well Pi3D works.

Regards

Shando

[Paddy]

Hi, that does sound odd, and definitely needs to be sorted out. I wouldn't have thought you would ever see anything unless you had the right libglesv2.dll and libegl.dll library files (though I notice that there have been some updates to github.com/google/angle so maybe I should recompile them and update my repo.) It sounds like it might be a stencil or depth testing issue, or else the screen is getting overwritten by the background for some reason.

What versions of pygame and python are you using (32/64 2.7/3.4 etc)?

If you load a demo like ForestWalk.py and move the mouse around do you see the whole scene for a fraction of a second, do you only see single shapes (all the trees are one shape) or do you only see parts of shapes i.e. just a few vertices or triangles? Do you not see anything with some demos whatever you do.

If you screen capture every frame or even between some of the draw() calls do the images look like the correct scene or like the view you see on the pygame drawing surface? Use a little function like this

def scrcap():

  global scshots

  pi3d.screenshot('pic{:04d}.jpg'.format(scshots))

  scshots += 1

Don't leave it running too long!

[Paddy]

Actually now I look there are three Shape object, one for each type of tree.

[Paddy]

Also what do you get for

import pi3d

import pygame

print(pi3d.__version__, pygame.__version__)

[Simon Harwood]

Hi Paddy,

Thanks for the reply.

When I take the automated screenshots, the first image shows a black 'w' on its side towards the middle right of the canvas and then just a blue background for each of the other images (I had about 50).

Also, when I run the code for checking versions, it errors with AttributeError: 'module' object has no attribute '__version__' and PyCharm highlights the __version__ for Pi3D.

Finally, this is a list of all of my installed modules in Python 2.7.9 (64bit):

apptools==4.4.0

configobj=-5.0.6

configparser==3.3.0.post2

cx-Freeze==4.3.4

Cython==0.23.4

enum34==1.1.3

fs==0.5.4

GDAL==1.11.3

h5py==2.5.0

Jinja2==2.8

MarkupSafe==0.23

noise==1.2.2

numpy==1.11.0

packaging==16.5

pathlib==1.0.1

pi3d==2.10

Pillow==2.5.1

protobuf==3.0.0a3

pyface==5.0.0

pygame==1.9.2a0

pyglfw==0.2.2

Pygments==2.1.3

PyInstaller==3.1.1

pynsist==1.6

PyOpenGL==3.1.0

PyOpenGL-accelerate==3.1.1

pyparsing==2.1.0

pypiwin32==219

PyPlatec==1.4.0

pypng==0.0.18

Python-Ogre==1.7.1

pywin32==220

requests==2.9.1

six==1.10.0

traits==4.5.0

traitsui==5.0.0

Regards

Shando

PS: ALL demos are blank screens except for maybe a very quick flash of an image on startup (seems to me that the background is being drawn in front of the rest of the models etc.? but I don't know enough about Pi3D/OpenGL to know what to change to test :( )

[Shando]

I managed to get the Pi3D version using:

print(pi3d.constants.__version__)

which gave me 2.10

[Paddy]

Yes, I realized after I posted it that the 'alias' to constants.__version__ was only fixed in v2.11 (live as of Yestday! There shouldn't be anything relevant so no need to upgrade)

I've compared my modules and upgraded all to the latest (32 bit versions) Also added PyOpenGL and PyOpenGL-accelerate as they looked possible interfeerers. However everything still works fine on this machine.

You have a lot more modules installed than I do on this (on windows anyway) so maybe it's one of the other ones. six looks to be a possibility as we included a modified version in pi3d (with the benefit of hindsight not a good idea!) and I'm not sure what python will import. On my machine if I

import six

print(six.__version__)

I get 1.3.0 Except that I have just renamed the file that was c:\python27\lib\site-packages\six.py to six_mod.py and gone through the pi3d files and changed references to six to six_mod this was a bit messy, and I will fix the version in the repository. These were the files I modified, all paths rel to c:\python27\lib\site-packages\

pi3d\Buffer.py

pi3d\Display.py

pi3d\Mouse.py

pi3d\Shader.py

pi3d\Texture.py

pi3d\util\TkWin.py

pi3d\util\DisplayOpenGL.py

pi3d\util\Scenery.py

pi3d\util\Gui.py

pi3d\util\ClashTest.py

pi3d\loader\LoaderEgg.py

pi3d\event\Event.py

pi3d\event\EventStream.py

pi3d\shape\ElevationMap.py

pyxlib\xlib.py

Most of these are probably not relevant, in fact six is imported and not used in quite a few which also needs tidying up, but it might be something like this that breaks a process once it's started to render things which prevents anything else appearing. Are you running the demos from a terminal? If so do you get any messages?

Paddy

[Shando]

Hi Paddy,

I made the changes to six, but still no joy :(

I tried to run "blur.py" from both the command line and from within PyCharm and got an empty blue window both times. There are no error messages in the console, though it does print the FPS etc. so seems like everything is running OK except for the display?

Thanks

Shando

[Paddy]

@Shando, Sorry about that, It's quite tricky to figure out what's happening but the fact that you got a 'w' shape on its side on the first draw is crucially important. Just need to find out exactly what the 'w' was and when and why it stopped rendering after that! When I load textures on this window laptop I get a warning message trying to run glGenTextures() do you get that? If not then maybe there's some difference between the graphics card drivers. I've seen people fix OpenGL issues on forums by reloading graphics drivers so that may be worth looking into. Meanwhile it might be worth trying the little script below to see a) what happens if no textures are loaded b) what the 'w' looks like for a known simple shape. c) are we getting the background we specify rather than a random colour.

The other thing (for me) to think about is whether I've broken something specific to 64bit window. Maybe I should set this laptop up using 64bit python to test that.

def scrcap():
  global scshots
  pi3d.screenshot('pic{:04d}.jpg'.format(scshots))
  scshots += 1

DISPLAY = pi3d.Display.create(w=200, h=200, background=(0.8,0.2,0.8,1.0))
tet = pi3d.Tetrahedron(z=3.0)
tet.set_material((0.2, 0.8, 0.2))
scshots = 0
while DISPLAY.loop_running() and scshots < 10:
  scrcap()
  tet.draw()
  scrcap()
  tet.rotateIncY(10)

[Shando]

@Paddy, no worries, I know from experience that these sort of things can be frustrating at best...

I get no errors/warnings (that I can see) relating to glGenTextures.

I also ran your script, and got the 10 screenshots. The first one and the last eight were all just blank purple squares, but the second one had a black triangle in the middle.

HTH

Shando

[Paddy]

So that's some progress! If you start the rotation at 50deg then there are two triangles visible to the camera. It would be interesting to see if rendering stops after just one triangle has been rendered or if all the vertices get processed. The fact that the triangle was black means that the fragment shader isn't working properly - i.e. not just a texture sampler issue. It might be possible to figure out a little more where the rendering process breaks by doing

DISPLAY = pi3d.Display.create(w=200, h=200, background=(0.8,0.2,0.8,1.0))

tet = pi3d.Tetrahedron(ry=50)

tet.set_material((0.2, 0.8, 0.2))
scshots = 0

while DISPLAY.loop_running() and scshots < 4:
  for x in [-0.5, 0.5, 1.5]:
    tet.position(x=x, y=0.0, z=4.0)
    tet.draw()
    scrcap()
  tet.rotateIncY(10)

The first two images should look like this.

I will see if I can write a little program to extract a bit more info about the egl and opengles systems.

Thanks for helping sort the problem out.

Paddy

[Shando]

Hi Paddy,

OK, so now I get the first 3 screenshots showing a black pyramid to the left of the screen (which is exactly the same in each image) and the remaining images as purple squares with no pyramid.

Regards

Shando 

[Paddy]

OK, so if it looks like a pyramid (i.e. kite shaped rather than just a triangle) that sound like it's drawing all the vertices for that shape but the process of running the fragment shader, or whatever opengles functions get called along with Buffer.draw() or Shape.draw() break something. One the difficulties is that there isn't much (or any) output from runtime errors that happen in the GPU. All trial and error

[Shando]

Hi Paddy,

Just tried a quick test using pyglet and that works fine, which is a bit annoying as I would really like to try Pi3D :(

Regards

Shando

[Paddy]

Shando, that's also good info but I suppose pyglet uses opgl directly on windows and has to patch stuff (misa etc) to get it to work on other platforms such as the RaspberryPi.

Meanwhile I've updated the google/angle repository from github and recompiled. It seems to work ok on this laptop but it did previously! For some reason I had patched the code to not default to d3d11 renerer (not entirely sure what that is) on the previous compile so I have made two versions with it on an with it off. I've pushed it up to https://github.com/paddywwoof/pi3d_windll If you get a chance I would be interested to see if this has made any difference.

[Shando]

Hi Paddy,

I bit the bullet and installed 32bit Python and now everything works fine ;) So, it's either a major issue with 64 bit (still doesn't work even with the new DLLs) or it's one of my installed packages interfering with Pi3D?

If I get a chance, I might try to uninstall everything in my 64 bit installation and see if that helps at all.

Regards

Shando

PS: Thanks for all your help on this

[Shando]

OK, so uninstalled everything from 64bit Python and re-installed to match the working 32bit..... exactly the same issues (i.e. light blue screen), so I think I'll just stick to 32bit for now.

Regards

Shando

[Paddy]

I am really grateful for the time and effort that you have spent helping to track down the problem. Both Chrome and Firefox stick to 32 bits, at least for the OpenGL functionality so maybe there is more checking for driver clashes and built-in procedures to sort them out.

I've used pi3d ok on 64bit windows 7 python2.7 on my son's laptop (which is away at uni at the moment) but two other laptops here that I will fix up with 64bit python and do more experiments. The fact that you've had these problems means that there's something that needs to be sorted out for anyone trying to install on the same setup.

[Shando]

Hi Paddy,

Just wondering if you got anywhere with the 64bit issues?

The only reason I ask is that I'm now at the stage where I am trying to integrate pi3d into Worldengine and my version of Worldengine is all 64bit.

Thanks in advance

On Friday, April 29, 2016 at 5:31:27 PM UTC+8, Paddy wrote:

[Paddy]

Hi, I've put off un-installing and re-installing everything... but started to do that now. I will let you know how I get on.

[Shando]

Hi Paddy,

Sorry to bother you again but I was wondering if there is any update on 64 bit?

Thanks

Shando

On Friday, June 10, 2016 at 11:16:41 PM UTC+8, Paddy wrote:

[Paddy]

@Shando,

Frustratingly I can't get even as far as you managed. I tried recompiling the ANGLE libraries in different forms an un-installed an re-installed various types of python but with 64 bits it always fails after eglInitialize() returns EGL_FALSE. I presume that other people are managing to use ANGLE libEGL.dll on 64 bit systems as I can't find any reports of a similar issue.

I feel that it must be something to do with pointer sizes and maybe ctypes but I can't figure out what. It's also strange that you managed to initialize the egl display but had problems with the rendering.

(After your last post today I dug out a different laptop and un-installed and re-installed everything on that and got the same result)

[Paddy]

A few hours after resorting to stackoverflow the problem is fixed! I will push the modifications up to the develop branch and test on other machines, then pretty soon move the master branch to v2.13. Thanks for your persistence and help getting this sorted.