add Lua function image:drawverts(), initial version

[fgenesis]

Right now the API for sending actual vertex data is very lacking. Last year I was able to get 3D boxes working using image:draw() and a bit of matrix trickery (https://github.com/spreadspace/info-beamer-e18-bg for reference), but it's not enough for what's planned this time.

Unless it's intentional that only an API for drawing 2D rectangles projected into 3D space is exposed I'd like to suggest adding a bunch more functions.

This PR adds one for supplying vertex data from 2 Lua tables. I'm not entirely happy with it as it's probably very slow to extract floats from Lua tables each frame, but it requires no other changes elsewhere (like API for VBOs etc)

I plan to add some other things like this but I'd like to (1) get an OK first to go ahead with this and possibly add some more API that will likely get in; and (2) we'd need those changes also in the RPi version (since the whole setup is going to run via the managed service), and when we can't get that there's no reason to even start working on the planned effects.

The WIP effect stuff is in https://github.com/spreadspace/info-beamer-e19-bg.

There are some more things like an actual depth buffer and GL antialiasing that would be nice to have but I'd take care of that once it becomes an issue.

Thoughts/Comments?

[dividuum]

Neat. If I understand this correctly, this code allows you to reuse the same texture multiple times and place each vertex and texture coordinate individually? The problem with the current approach is that this won't work on the Pi as it is: The Pi uses OpenGLES and doesn't support immediate mode (glBegin(), glEnd()). I'm also not sure if all the drawtypes are possible with OpenGLES.

What would be your use case for the API? Would all the input values change every frame or do you expect them to be constant across a number of frames? In that case, it might be possible to wrap this into some kind of internal object that holds a buffer and then renders it with by calling a single glDrawArrays call.

Regarding depth buffer: I think I played around with it a bit, but IIRC it had a rather big impact on performance. Same with AA. You can play around with it by setting the undocumented INFOBEAMER_EXPERIMENTAL_AA=1 env variable.

[fgenesis]

If I understand this correctly, this code allows you to reuse the same texture multiple times and place each vertex and texture coordinate individually?

Yes.

The Pi uses OpenGLES and doesn't support immediate mode

I never understood why you started using immediate mode in the first place. There's enough of a common subset between GL2 and GLES2 (coughWebGLcough) to use the same code on both RPi and the desktop.

Been doing enough OpenGL lately, i know the differences and imho anything less than 4.5 is a disgrace, but can't choose on the RPi, unfortunately :)

I'm also not sure if all the drawtypes are possible with OpenGLES.

This: http://docs.gl/es2/glDrawArrays -- Minus deprecated features like polygons and quads. But those can be replaced by triangles so no big deal.

But as I said a better solution would be to make VBOs explicit (as a class with accessors, __gc, etc that modify memory locations, like a table but for arrays of floats). That would add a bit of code but I if it has a chance of going in i might hack something up that's also GLES2 compatible (and possibly replace some of the immediate mode cruft in the process)

Would all the input values change every frame or do you expect them to be constant across a number of frames?

In my case those values change every frame but a VBO is the better solution in any case, given dynamic data or not.

Regarding depth buffer: I think I played around with it a bit, but IIRC it had a rather big impact on performance. Same with AA. You can play around with it by setting the undocumented INFOBEAMER_EXPERIMENTAL_AA=1 env variable.

Cool, thanks for that env var. Then I guess enabling the depth buffer should be optional (and explicit, like render a few things that need it, with depth buffer, then turn it off and render overlays on top). That will work with no perf impact as long as it isn't enabled.

[dividuum]

I never understood why you started using immediate mode in the first place. There's enough of a common subset between GL2 and GLES2 (coughWebGLcough) to use the same code on both RPi and the desktop.

Easy. Never had any performance critical application or motivation to learn the more complex GLES when immediate mode worked perfectly fine for what I was doing up till then. Remember: info-beamer started as a for-fun project and I wanted to get "shit done". I had no idea I'd still work on this 7 years later. In hindsight, starting with GLES would have been better but I might not have finished the project in time for it's very first intended use and if I had missed that and nobody saw a working version, who knows if the project would still exist today.

As much as I'd like to add this feature properly, I'm not sure I have enough time to do this right now. There's a lot of tasks already on the todo list. I'm also not sure about contributions. I also would love to run info-beamer on the Pi as an open source project, but that would give away one of the major unique selling points of the service and you can bet that all other Pi based services would love to add info-beamer to replace their duct-taped pile of omxplayer and image viewers. So that's not going to happen.

Given this new stupid law proposal I'm not sure about accepting any outside contributions either without consulting a lawyer.

Are you at congress?

[fgenesis]

[...] but that would give away one of the major unique selling points of the service [...]

I fully understand and respect this. I'm still hoping the code bases aren't too different and you could easily drop in new GLES2-compatible code, but I can't know how things really are. So i'll leave this to you.

Given this new stupid law proposal I'm not sure about accepting any outside contributions either without consulting a lawyer.

For the record, and if it helps: Any contributions I make to projects are WTFPL or whatever works in a given case. I really don't care as long as shit gets done (tm). Up to you. Take it and run, no bullshit.

Are you at congress?

Nope. Also not planning to go there anytime soon. http://under-construction.tum-party.net/ works for me. :D

[equinox0815]

Hi, i'm working since 2009 for the Elevate Festival - for which the packages that @fgenesis mentioned are used. For several years now i wanted to use info-beamer at the Elevate and 2018 was the first year i actually had time to put together a basic package that does extract the info to be displayed from the event management software the festival is using. Thankfully @fgenesis helped me out with creating a neat little background animation as well with some other stuff.

The next Elevate will take place between February 27th and March 3rd 2019 and at the moment we are at the point where we need to decide how this years animation should look like and whether the RPi will be able to render it in realtime. Using a video of a pre-computed animation is always an option as well but of course an animation the runs natively on the RPi is much nicer.

For 2019 we would very much like to use your hosted service again. Therefore any animation we build must be running smoothly on the RPi. We don't need this to be working promptly but what we would like to know, within the next month or so, whether you think that the feature will be available in your hosted service in time for Elevate 2019. It is of course totally fine if this doesn't get merged until then. In this case we will be working on a different approach. We might still work on getting this in so we can potentially use this for Elevate 2020 ;)

Thanks in advance!