Bug: Graphic setZIndex on polyline / polygon causes crash in Scene View

[radimbachb]

I've stumbled upon a bug (Using the most recent ArcGIS SDK 200.5) which is very easy to reproduce.

Create a polyline / polygon, add it to a graphics overlay. After a few seconds, change the graphic's zIndex -> Crash.

// Add Scene
m_sceneView = findChild<SceneQuickView*>("sceneView");
Scene* scene = new Scene(BasemapStyle::ArcGISTopographic, this);
m_sceneView->setArcGISScene(scene);

// Add Graphics Overlay
auto graphicsOverlay = new GraphicsOverlay(this);
LayerSceneProperties props{SurfacePlacement::DrapedFlat};
graphicsOverlay->setSceneProperties(props);
m_sceneView->graphicsOverlays()->append(graphicsOverlay);

// Add Simple Polyline
SimpleLineSymbol* simpleLineSymbol = new SimpleLineSymbol(SimpleLineSymbolStyle::Solid, QColor("blue"), 3.0f, this);

const SpatialReference spatialRef(SpatialReference::wgs84());
PolylineBuilder polylineBuilder(spatialRef);
polylineBuilder.addPoint(8.5417, 47.3769);
polylineBuilder.addPoint(8.4920, 47.3495);
auto line = new Graphic(polylineBuilder.toGeometry(), simpleLineSymbol, this);
graphicsOverlay->graphics()->append(line);

// After some seconds set Z Index of graphic
QTimer::singleShot(5000, this, [line]() {
	line->setZIndex(1);
	// EXCEPTION
});

The call stack of the exception (Polyline):

runtimecore.dll!esri::map_renderer_3d::Polyline_sequence3d::update_vertex_origin(class std::shared_ptr<class esri::hal_3d::Vertex_datastore> const &,class osg::Vector3d const &,class osg::Vector3d const &)
runtimecore.dll!esri::map_renderer_3d::Sequence3d_group::finalize(void)
runtimecore.dll!std::_Func_impl_no_alloc<<lambda_2dee8c25f9c57f9a5ef5822a08bc3cf4>,void>::_Do_call()
runtimecore.dll!std::_Func_impl_no_alloc<<lambda_3fd62d7055a6d88d598cbfa1725bfcb4>,unsigned char,unsigned char>::_Do_call()
runtimecore.dll!pplx::details::_PPLTaskHandle<unsigned char,pplx::task<unsigned char>::_InitialTaskHandle<void,<lambda_2dee8c25f9c57f9a5ef5822a08bc3cf4>,pplx::details::_TypeSelectorNoAsync>,pplx::details::_TaskProcHandle>::invoke()
runtimecore.dll!pplx::details::_TaskProcHandle::_RunChoreBridge(void *)
runtimecore.dll!esri::common::concurrency::Core_scheduler::invoke_(struct esri::common::concurrency::Core_scheduler::Queued_proc *)
runtimecore.dll!esri::common::concurrency::Core_scheduler::bridge_proc_(void *)
runtimecore.dll!esri::common::concurrency::`anonymous namespace'::Scheduler_param::work_callback()
ntdll.dll!00007ff90f473730()
ntdll.dll!00007ff90f45d79a()
kernel32.dll!00007ff90e317344()
ntdll.dll!00007ff90f45cc91()

 The call stack of the exception (Polygon)

runtimecore.dll!esri::map_renderer_3d::Polygon_base_sequence3d::update_vertex_origin(class std::shared_ptr<class esri::hal_3d::Vertex_datastore> const &,class osg::Vector3d const &,class osg::Vector3d const &)
runtimecore.dll!esri::map_renderer_3d::Sequence3d_group::finalize(void)
runtimecore.dll!std::_Func_impl_no_alloc<<lambda_2dee8c25f9c57f9a5ef5822a08bc3cf4>,void>::_Do_call()
runtimecore.dll!std::_Func_impl_no_alloc<<lambda_3fd62d7055a6d88d598cbfa1725bfcb4>,unsigned char,unsigned char>::_Do_call()
runtimecore.dll!pplx::details::_PPLTaskHandle<unsigned char,pplx::task<unsigned char>::_InitialTaskHandle<void,<lambda_2dee8c25f9c57f9a5ef5822a08bc3cf4>,pplx::details::_TypeSelectorNoAsync>,pplx::details::_TaskProcHandle>::invoke()
runtimecore.dll!pplx::details::_TaskProcHandle::_RunChoreBridge(void *)
runtimecore.dll!esri::common::concurrency::Core_scheduler::invoke_(struct esri::common::concurrency::Core_scheduler::Queued_proc *)
runtimecore.dll!esri::common::concurrency::Core_scheduler::bridge_proc_(void *)
runtimecore.dll!esri::common::concurrency::`anonymous namespace'::Scheduler_param::work_callback()
ntdll.dll!00007ff90f473730()
ntdll.dll!00007ff90f45d79a()
kernel32.dll!00007ff90e317344()
ntdll.dll!00007ff90f45cc91()

[Tanner_Yould]

Hey, thanks for bringing this to our attention!

I've been able to recreate your crash and found that using void Graphic::setZIndex(int value) on a GraphicsOverlay in a SceneView with SurfacePlacement::DrapedBillboarded or SurfacePlacement::DrapedFlat will cause a crash. All other surface placements are okay (Absolute, Relative, RelativeToScene).

I'll open an issue on our end to investigate further and prevent this crash from happening. In the meantime however, can you explain what you're trying to do? Setting a Z-index on a graphic in a 3D scene view is a little unconventional as noted in the api ref. However, you're explicitly setting the surface placement to "draped" so I'm guessing you maybe have some overlapping lines and you want control over which are displayed on top? Otherwise, if you're trying to extrude the line above the ground, you may want to look at our Extrude Graphics sample code for reference. With a bit more information, maybe we can help you find a workaround to this bug while we sort it out!

In any case, this crash should definitely not be happening, so thank you for bringing it to our attention!

[radimbachb]

Great, thanks for looking into this!

In our application we have a 3D and a 2D view that the user can switch between. When the user switches from 3D to 2D or vice versa we move the graphic overlays from scene view to map view, or vice versa. Users may select certain graphics which then get a high z-index. This improves the visibility of the selected graphic if there are multiple graphics overlapping each other. This is mostly important for 2D, and much less important for 3D where things like labels are billboraded and the distance from camera decides what is rendered in front of each other...
Our "SelectionController" logic doesn't know whether the map view or scene view is active and sets a high z index on the selected graphic either way when a graphic is selected.