Wireframe meshes are black in software-rendering mode (BrainVISA 5.0.0)

[ylep]

Textured wireframe meshes (e.g. DISCO sulcal imprints) appear all black when using software OpenGL rendering (opengl=software).

This can be worked around: open Settings / Anatomist Preferences, go to the OpenGL tab and uncheck Enable OpenGL shaders. Strangely, even if that box is already unchecked when you open the mesh, it may still appear black: you may have to check then uncheck the box to fix it.

[denisri]

I can't reproduce the problem in any situation (I've tried casa-distro on a machine with a nvidia GPU, on another one with an Intel GPU, and remotely through ssh, all display correctly with opengl=software).
However I can investigate if shaders are enabled when they should not.

[denisri]

I tried using x2go and I could not reproduce the problem either, in casa-distro or outside of it. Maybe I should use one of your meshes ?
Otherwise, I have run glxinfo:

• outside of the container (in x2go):
  name of display: :50
  display: :50 screen: 0
  direct rendering: Yes
  server glx vendor string: SGI
  server glx version string: 1.2
  server glx extensions:
  GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info,
  GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample,
  GLX_SGIX_fbconfig, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier,
  GLX_SGI_make_current_read
  client glx vendor string: Mesa Project and SGI
  client glx version string: 1.4

(same as you have)

• inside the container with opengl=software:
  name of display: :50
  display: :50 screen: 0
  direct rendering: Yes
  server glx vendor string: Brian Paul
  server glx version string: 1.4 Mesa 17.0.0
  server glx extensions:
  GLX_ARB_create_context, GLX_ARB_get_proc_address,
  GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
  GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
  GLX_MESA_release_buffers, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
  client glx vendor string: Brian Paul
  client glx version string: 1.4 Mesa 17.0.0

(something different, thus)

[ylep]

Try this command in NeuroSpin to reproduce the bug:

bv opengl=software brainvisa -s /neurospin/tmp/yleprince/partage/black_mesh_bug.bvproc

I can reproduce the bug every time with these two versions of software-rendering:

• MESA GLX with opengl=software

  OpenGL vendor string: Brian Paul
  OpenGL renderer string: Mesa X11
  OpenGL version string: 2.1 Mesa 17.0.0
  OpenGL shading language version string: 1.20
  

• llvmpipe renderer inside of X2Go

  OpenGL vendor string: VMware, Inc.
  OpenGL renderer string: llvmpipe (LLVM 10.0.0, 256 bits)
  OpenGL version string: 3.1 Mesa 20.0.8
  OpenGL shading language version string: 1.40
  

The bug never appears with opengl=nv:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro K620/PCIe/SSE2
[...]
OpenGL version string: 4.6.0 NVIDIA 390.141
OpenGL shading language version string: 4.60 NVIDIA

In case this is related to the data or the way that I am calling the Anatomist API for displaying the mesh, here is the relevant code of the view_sulcal_imprint_mesh process:

def execution(self, context):
    a = anatomist.Anatomist()
    aobj_mesh = a.loadObject(self.imprint_mesh)

    if self.imprint_texture is not None:
        aobj_tex = a.loadObject(self.imprint_texture)
        aobj = a.fusionObjects([aobj_mesh, aobj_tex], method='FusionTexSurfMethod')
    else:
        aobj = aobj_mesh

    aobj.setMaterial(line_width=self.line_width)

    window = a.createWindow('3D')
    window.assignReferential(aobj.referential)
    window.addObjects([aobj])

    return {'object': aobj, 'window': window}

[denisri]

OK I can reproduce the problem now !
The situation is a bit different from what I was trying because rendering properties (line width, here) are set not directly on the mesh, but on a textured mesh object (fusion). There must be a bug in this object properties propagation to the mesh (or in its initialization, I'm not sure). Anyway as this property actually belongs to the mesh, it's more natural to set it on the mesh, and doing it fixes the problem (well, it's a workaround: the way it is done in this process should work either so there is definitely a bug).

[ylep]

Anyway as this property actually belongs to the mesh, it's more natural to set it on the mesh, and doing it fixes the problem

Okay thanks! I will change the DISCO code to set the property on the mesh then.

[denisri]

What happens is that the mesh (a wireframe mesh) has normals in it, which is unusual for a wireframe mesh (and probably a bug here), and normals are all set to (0, 0, 0) (which is kind of illegal since they should be of length 1.0). In this situation Anatomist assumes that normals represent a direction that can me mapped on vertices as a RGB color (black here since they are all 0), and activates shaders by default to render it. There was a bug in Anatomist because this was bypassing the config option to disable all shaders. This is fixed now in 5.0.2 so it should not happen if the config is set to disable shaders.
However there seems to remain 2 problems:

• shaders are not working as expected in this software rendering mode
• rendering properties set to a textured mesh object (a fusion) don't "completely" propagate to the mesh (actually: they propagate but the mesh doesn't notify changes to its observers), so there are some behaviour differences between setting the rendering properties on the mesh or on the textured mesh (which should be exactly the same). This is not so obvious to solve in anatomist internal notification system, unfortunately, and I'm not sure it's worth the effort right now.

Anyway now this issue can be solved in 3 ways:

• disable shaders in Anatomist config
• don't set normals on these meshes
• set rendering properties on the mesh instead of the textured mesh