Pi3D transparent background on Pi4

[Gavinmc42]

Broke another Gentoo64 uSD.

Anyway I have Raspberry Rain working on a Raspbian Buster Pi4.
But it is not transparent, was it supposed to be?

Have not test everything but most Pi3D demos seem to work.

Edit My Python shader examples run fine too on Buster.
Which makes sense, the GPU does not care if it is talking to arm32 or arm64.

[paddyg]

Getting the transparent background looks tricky http://forums.libsdl.org/viewtopic.php?p=44939 is only explicit ref I can find.

PS I've tried testing for availability of pysdl2 on init of pi3d and defaulting to that unless explicitly set use_sdl2=False That might be a nicer approach but will see how it works on all the different platforms.

[Gavinmc42]

glClearColor( 0.7, 0.7, 0.7, 0.7) ; // light gray bg

Interesting, I have the same line in my cloud shader code trying to do a blue sky.
I only get black. Tested on mesa 19.1.0 and 19.2.3
It might not be SDL issue, probably OpenGL?

Perhaps a mesa issue?
New versions are out, time to update.
Gentoo might get 19.3-rc?
It is going to 19.3 soon?

Rebuilding some new OS's now, my Buster is old and broken.
Looking for shader code that does not need x11 or SDL etc.
OpenGL or SDL2? Will look in the mesa demo code first.

[Gavinmc42]

Made another Buster OS, has the new DVFS.
So used to 55C temps 43C is making me think something is wrong.
Just in time for summer downunder.

Trying to get transparency to work while my Gentoo64 is genuping(update/upgrade).
`My OpenGl testing has been on Gentoo64, so I am installing most of those tools on Buster.

My Python shaders from Blakkis use pygame.
https://github.com/Blakkis/GLSL_Python

These don't seem to do anything

Code: Select all

glClearColor(0.0, 0.0, 0.0, 1.0)
glClear(GL_COLOR_BUFFER_BIT)

The NOFRAME option works

Code: Select all

 pygame.display.set_mode(self.resolution, DOUBLEBUF | OPENGL | NOFRAME)

Does glClearColor(0.0, 0.0, 1.0, 0.0) work on PC's?

Ouch, Rustc and Pi3drust install issues, broken my new Buster?
"Aw, snap" yikes, lots of OS breaking this week.
To be continued...

[paddyg]

Does glClearColor(0.0, 0.0, 1.0, 0.0) work on PC's?

Yes, but only using the mechanism discussed at the start of this thread (glx and X extension) I've not got it working with the sdl2 branch or on Windows (can't get the sdl2 window to work at all on Windows yet)

[Gavinmc42]

Have not looked at how to use extensions yet.
Got my free Pascal OpenGL up and running on Buster now.
GL, GLX, GLU, GLEXT, GLUT are options for that.

Google time-
It looks like I need to use glext for Pascal to access the extensions.
https://wiki.lazarus.freepascal.org/OpenGL

There is also a web page on Free Pascal with SDL2, but I will skip that for the moment.

I guess these are the extensions? Probably accessible to that python example code too.

Code: Select all

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.2.0-rc1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
    GL_APPLE_texture_max_level, GL_EXT_base_instance, GL_EXT_blend_minmax, 
    GL_EXT_color_buffer_float, GL_EXT_compressed_ETC1_RGB8_sub_texture, 
    GL_EXT_discard_framebuffer, GL_EXT_draw_buffers, 
    GL_EXT_draw_elements_base_vertex, GL_EXT_float_blend, GL_EXT_frag_depth, 
    GL_EXT_map_buffer_range, GL_EXT_multi_draw_arrays, 
    GL_EXT_occlusion_query_boolean, GL_EXT_read_format_bgra, 
    GL_EXT_sRGB_write_control, GL_EXT_separate_shader_objects, 
    GL_EXT_shader_integer_mix, GL_EXT_texture_border_clamp, 
    GL_EXT_texture_format_BGRA8888, GL_EXT_texture_query_lod, 
    GL_EXT_texture_rg, GL_EXT_texture_sRGB_decode, 
    GL_EXT_texture_type_2_10_10_10_REV, GL_EXT_unpack_subimage, 
    GL_KHR_context_flush_control, GL_KHR_debug, GL_KHR_no_error, 
    GL_KHR_parallel_shader_compile, GL_KHR_texture_compression_astc_ldr, 
    GL_KHR_texture_compression_astc_sliced_3d, 
    GL_MESA_shader_integer_functions, GL_NV_draw_buffers, 
    GL_NV_fbo_color_attachments, GL_NV_read_buffer, GL_NV_read_depth, 
    GL_NV_read_depth_stencil, GL_NV_read_stencil, GL_OES_EGL_image, 
    GL_OES_EGL_image_external, GL_OES_EGL_image_external_essl3, 
    GL_OES_EGL_sync, GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, 
    GL_OES_depth_texture, GL_OES_depth_texture_cube_map, 
    GL_OES_draw_elements_base_vertex, GL_OES_element_index_uint, 
    GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, 
    GL_OES_packed_depth_stencil, GL_OES_required_internalformat, 
    GL_OES_rgb8_rgba8, GL_OES_standard_derivatives, GL_OES_stencil8, 
    GL_OES_surfaceless_context, GL_OES_texture_3D, 
    GL_OES_texture_border_clamp, GL_OES_texture_float, 
    GL_OES_texture_half_float, GL_OES_texture_half_float_linear, 
    GL_OES_texture_npot, GL_OES_texture_stencil8, GL_OES_vertex_array_object, 
    GL_OES_vertex_half_float

[paddyg]

The transparent background uses libGLX and an X extension libXrender. Which seems to be already available on raspbian and ubuntu but may be harder to find elsewhere.

[Gavinmc42]

Tried the raymarch shader code on Windows, same result, black background.
Pygame does not do transparency?
It could just be a simple mode setting?

Now have a PC to test the Pi code against.
Wish I knew what I was doing
Blakkis's minimal.py GLSL does 2000fps, that's a bit faster than the Pi4.
Tested OpenGL 3.3 and 4.6.

[Gavinmc42]

Finally got my Gentoo64 OS's up and running with the new 1.5.2 release.
While playing with the python shader code I just grabbed a window to move it and noticed it went a bit transparent.

What is happening with the window compositing that does that?
Is it usable in the OpenGL shader code.

[paddyg]

Yes (and no, it's X11 window related rather than OpenGL). With the compositor running (it's turned off by default in raspbian buster but you can start it with ``xcompmgr``, already on in ubuntu or gentoo64) you can adjust the opacity of the X11 window. See the discussion on the first page of this thread.

In SDL2 it's very easy. The rust code I added to do it is a one line function. The xlib code is a bit messier with xatoms etc. It also probably depends on a later X extension being available, but that seems to be the case where I've tested it.

[Gavinmc42]

With the compositor running (it's turned off by default in raspbian buster but you can start it with ``xcompmgr``, already on in ubuntu or gentoo64)

I never even noticed it was on in Gentoo64..
I can remember when compositors first came out on Linux, slowed things down, I used to turn them off.

Too many layers, time to go headless, without x11?
Is pygame using SDL?
Need to get RustPi3D working on the new 1.5.2 Gentoo's