'assert r' error due to old API usage and advice on latest API usage

[WayneKeenan]

Hi,

Just for background, I can install Pi3d v2.41 and run demos ok on a Pi4.

The issue I have is my own, as I'm uplifting my VRZero project to the latest Pi3d release on a Pi4.

I pinned my usage to Pi3d version 2.23, 3 years ago... things have moved on...

I'm going to start to dig into it but I was wondering if there was something you might know of already?

I've recored the exception in my issue here: https://github.com/WayneKeenan/python-vrzero/issues/12#issuecomment-769410900

[WayneKeenan]

small update: switching from use_pygame=True to use_glx=True stops the crash, but I get a black screen only.

[WayneKeenan]

ok, somethings changed in, or related to the use of, pi3d.StereoCam as if I revert to pi3d.Camera I see rendering.

[paddywwoof]

OK Wayne, I will have a look at that. I'm pretty sure that the https://github.com/pi3d/pi3d_demos/blob/master/ForestStereo.py works as that's one of the 'unit tests' in RunTests.py.

There have been some changes in the way the offscreen textures work. I will have a look at the way your code is set up c.f. ForestStereo and get back.

Paddy

PS these https://github.com/pi3d/pi3d_demos/commits/master/ForestStereo.py are the changes I've made to ForestStereo, does anything jump out at you? I will have a look at your setup too.

[WayneKeenan]

Hi Paddy, thanks for looking at this, I will take a look see too.

[WayneKeenan]

Just as a quick heads up, if I don't specify the shader then it renders side by side. I'll dig a bit more.

[paddywwoof]

Ah, that sounds very significant, and rings a bell at the back of my mind!

[WayneKeenan]

I don't get any shader compilation errors from Pi3d, even if I put gibberish in the shader source.

[paddywwoof]

Wayne, I know, it's very frustrating. Over the years I tried to get the log to work but never really managed to https://github.com/tipam/pi3d/blob/master/pi3d/Shader.py#L163 (it looks like you have to set logging level to debug LOGGER = pi3d.Log(level='DEBUG', format='%(message)s') beforehand. It's a bit of a nightmare getting info between python and C, when I was getting pi3d to work on the RPi4 I basically got the Rust version working first then worked my back to python! Often when developing shaders, because there aren't really any run-time errors, I comment out the whole file and reveal it variable by variable until I can pin down the cause of the crash!

And I remember one significant breaking change (sorry not to remember it Yesterday): In order to get the different versions of OpenGL and OpenGLES, that the new graphics driver ran, all working I had to build in a shader 'parser' https://github.com/tipam/pi3d/blob/master/pi3d/Shader.py#L200

This means that I added

#version 120
//precision mediump float;
...
//fragcolor //only in fs

to the two shader files Hopefully this is the issue with your barrel shader. Let me know how you get on.

Paddy PS I will add something to the pi3d FAQ on this topic now. Even if it doesn't turn out to be your problem.

[paddywwoof]

Ha, it looks like I beat myself to it http://pi3d.github.io/html/FAQ.html#diy-shaders

[WayneKeenan]

No worries, thanks again for your help.
Ooo a rust version, interesting, I'm going to have a play with that at some point.

[WayneKeenan]

The barrel shader is back up and running, many thanks Paddy!

[paddywwoof]

Good, glad you fixed it (and sorry it took me so long to remember).

w.r.t rust. I know it gets some bad press due to being hard but actually a lot of the python stuff translated quite easily. The critical rethinks were where things like Texture or Shader objects were created then needed to be dished out to various other objects or where inheritance had been used as in Plane, Cuboid etc being descended from Shape. In fact there is often a simple way to do things differently: passing objects to other object just for the duration they are needed (i.e. as a draw() argument) or making the Plane struct contain a Shape struct. And when it just doesn't seem to work there is always the reference counting wrapper.

Generally speaking I have to say that I really like rust!

Paddy

[WayneKeenan]

I’ve had some fun with the borrow checker too.

Separate question, have you looked at the Vulkan API on the Pi at all?

[paddywwoof]

Not yet but it is on the list. Being a little bit cautious because when I tried setting up 'bevy' (rust game engine) on my laptop it proved pretty difficult to get the required drivers.

I suspect using vulkan would need a big rewrite of OpenGL based code.

[WayneKeenan]

I did mean it as a completely separate question, it would have to be a greenfield experiment for Python or Rust.

The reason I ask is that I was kinda expecting OpenGL ES to be inherently quicker on the Pi4, no criticism of Pi3D, as I thought Pi3D would inherent from a system performance boost. I’m revisiting this world after a big gap, but it seems to me, on the surface, that desktop GL has taken a hit.

I’m rusty and I never optimised my stuff, so am way behind the curve, just seems that way.

[paddywwoof]

I think the GPU is pretty much the same but the broadcom display surface has disappeared or changed and maybe a few other things so the new open source driver was seen as an opportunity to add GL compatibility. I think the machine code (or whatever basic GPU instructions are called) is pretty much the same. Vulkan, as I understand it, can utilize more of the parallel processing capacity of the GPU to do some of the jobs otherwise given to the CPU. But that requires a bit of a rethink in terms of program structure.

At one point I thought about making all the Shapes in a pi3d scene use a single buffer array to allow numpy to do matrix multiplication etc very quickly. This turns out to be the way games are made nowadays, a kind of entity component system. But it's quite alien if you are used to thinking of objects with properties etc. TLDR; vulkan is good if you structure your code the 'modern' way.