mixed element braid example fails to render due to shape map entries

[mlohry]

Using the example mesh conduit::blueprint::mesh::examples::braid("mixed", 16, 16, 16, mesh);
and attempting to render results in the error:

message: 
Shape Map Entries do not match required VTK-m Shape Ids.
Passed Shape Map:

polyhedral: 42
tet: 10
hex: 12

Supported Shape Map:

tri: 5
quad: 9
tet: 10
hex: 12
point: 1
line: 3
wedge: 13
pyramid: 14

i.e. the polyhedral type looks unsupported, at least when mixed with standard shapes.

Exporting the HDF5 for this and trying to load in visit also hits an error when trying to load/render the mesh:

The compute engine running on lancer has exited abnormally.

Shortly thereafter, the following occured...

The Mesh plot of "mesh_mesh" for the file "all_output_braid.cycle_000100.root" could not be generated by the compute engine on host "localhost".

braid with all tets or other element types works as expected.

[JustinPrivitera]

I can't speak authoritatively on what the issue might be in Ascent, but in VisIt we added mixed element topology support to the Blueprint reader in our latest release, 3.4.2. Which version of VisIt were you using when you saw the error?

[mlohry]

Thanks @JustinPrivitera , visit 3.4.2 works; I was on 3.4.1 which didn't.

So the braid example containing polyhedra fails in the ascent render with the original error. A different mixed element mesh without polyhedra looks like it works correctly, except that sliced fields show blank images.

[JustinPrivitera]

I can confirm that we do not yet support polyhedral mixed topologies in Ascent. We may look to add that support in a future release, but not the most imminent release which is coming shortly.

[mlohry]

The main mixed element case I'm interested in doesn't have polyhedral elements. This example is comprised of tet, pyramid, and wedge. I can render a field on the full mesh correctly:

And I can show a mesh on a slice pipeline correctly:

but the same setup for the field renders a blank black screen (or the mesh+black if i also add the mesh)

[nicolemarsaglia]

Hmm odd. @mlohry could you share an extract and your actions file?

[mlohry]

out_hdf5.root.zip

-
  action: "add_pipelines"
  pipelines:
    pl1:
      f1:
        type: "slice"
        params:
          point:
            x: 0.0
            y: 468.75
            z: 0.0
          normal:
            x: 0.0
            y: 1.0
            z: 0.0
- 
  action: "add_scenes"
  scenes: 
    s1: 
      plots:
        p1: 
          type: "pseudocolor"
          field: "test_field"
      renders:
        default_view:
          image_width: 1024
          image_height: 1024
          image_prefix: "render_full_mesh"
    s2: 
      plots: 
        p1: 
          type: "mesh"
          pipeline: "pl1"
      renders:
        r1:
          image_width: 1024
          image_height: 1024
          image_prefix: "render_slice_mesh"
          world_annotations: "true"
          annotations: "true"
          camera:
            position: [1325.90, -700.0, 177.95]
            look_at: [1325.90, 468.75, 177.95]
            up: [0.0, 0.0, 1.0]
    s3: 
      plots: 
        p1: 
          type: "pseudocolor"
          pipeline: "pl1"
          field: "test_field"
      renders:
        r1:
          image_width: 1024
          image_height: 1024
          image_prefix: "render_slice_field"
          world_annotations: "true"
          annotations: "true"
          camera:
            position: [1325.90, -700.0, 177.95]
            look_at: [1325.90, 468.75, 177.95]
            up: [0.0, 0.0, 1.0]
- 
  action: "add_extracts"
  extracts:
    e1:
      type: "relay"
      params:
        path: "all_output"
        protocol: "blueprint/mesh/hdf5"

[nicolemarsaglia]

Thanks for the info @mlohry, I'm seeing what you're seeing. I will let you know what I find out.

[nicolemarsaglia]

Dumping a bunch of info as notes. This is definitely similar to the Rorschach-looking images we've experienced in the past.

dumped_rays_to_blueprint_python.txt
vtkm_rendering_raytracing_RayOperations_ray_dump_cxx.txt

Adding two text files: 1. the RayOperations.cxx file from vtkm/rendering/raytracing to dump rays to a txt file and 2. the python script to convert the dumped rays to a blueprint file to look at in Visit.

I've looked at the frustum output of the nonworking images, and it appears that the frustum is collapsing. For some reason, it believes that the scene is behind the chosen camera, even though the look_at is pointing at the data. Here is the line in VTK-m where it decides it is behind the scene based on the view and projection matrices: https://gitlab.kitware.com/vtk/vtk-m/-/blob/master/vtkm/rendering/raytracing/Camera.cxx#L864

I've also somehow recreated this error in the new uniform grid test that samples along the y axis in ascent/src/tests/ascent/t_ascent_uniform_grid.cpp MR #1499 . The elevation for the unit test is set to 30 because if it gets set to 90, it triggers the same result and thinks the scene is behind the camera, rendering a blank screen with a correct color bar.

[nicolemarsaglia]

Bug discovered: datasets with large z extents but a zoomed in camera can result in over culling of rays. Solution: remove z extents check from vtk-m/viskores.

Ascent/VTK-m: Resolved via a patch and PR #1561
Viskores: Merged in Viskores/viskores#109

Removing the check resulted in the test_field becoming visible: