Show contour maps in 3D views via an in-view contour map collection

[magnesj]

Implementation plan for #1043.

Description

What

Make contour maps available inside normal 3D views. A new in-view mirror collection on RimGridView lists every contour map in the project; a per-view wrapper object points at an existing contour map view and renders its geometry in the 3D scene at a controllable elevation, with an option to drape the contour lines onto the visible grid geometry.

Why

Contour maps today can only be seen in their own dedicated 2D view. RimEclipseContourMapView derives from RimEclipseView but locks the camera top-down (sm_defaultViewMatrix, navigation rotation disabled, orthographic projection), and the projection geometry is generated in a flat local coordinate space with z = 0 that the part manager lifts to RigContourMapGrid::origin3d() — the minimum z of the expanded bounding box, i.e. below the reservoir.

The result is that a contour map cannot be correlated visually with the 3D model it was computed from. Users want to overlay a contour map (including ensemble statistics maps) on a normal 3D view: see the aggregated values as a coloured plane above the grid, see the contour lines, and optionally drape those lines onto the visible grid geometry so they read as isolines on the reservoir surface.

How

Mirror, don't duplicate. RimContourMapInView holds a caf::PdmPtrField<RimEclipseContourMapView*> and renders that view's already-computed trianglesWithVertexValues(), contourPolygons() and legendConfig(). No second projection, no second result computation, no duplicated result/aggregation/resolution UI. The wrapper owns only presentation state: where the map sits in z, whether the surface and lines are drawn, and whether lines are draped.

This follows the established in-view collection pattern used by RimSurfaceInViewCollection and RimPolygonInViewCollection: project-level master data under RimOilField, a caf::PdmChildField mirror on the view, thin wrapper objects with a PdmPtrField back to the master item, and a sync routine that orphan-sweeps, find-or-creates and reorders.

Scope

Eclipse contour maps and ensemble statistics contour maps. RimStatisticsContourMapView derives from RimEclipseContourMapView, so a single pointer type covers both.

GeoMech contour maps are deliberately out of scope: their collection lives per-case on RimGeoMechCase rather than on RimOilField, and there is no common view base type across the two families.

Key design decisions

Decision	Choice	Rationale
What the wrapper holds	Pointer to an existing contour map view	Reuses the computed projection, triangles, contour polygons and legend. RimContourMapProjection::baseView() already assumes a contour-map-view ancestor, so owning an independent projection would require reworking that.
Vertical placement	MapPosition enum (Top of case / Bottom of case / User defined depth) + Depth Offset	Default TOP_OF_CASE puts the map above the reservoir instead of underneath it. TOP_OF_CASE uses expandedBoundingBox().max().z(), the same value RicCreateContourMapPolygonTools uses for contour-map-derived polygons.
Which maps are mirrored	All of them, unchecked by default	A 3D view of one realization may legitimately want to overlay an ensemble statistics map whose primary case is a different one. Filtering by case would exclude exactly that.
Scene model	Per-frame named cvf::ModelBasicList, not a static viz model	Contour map data is time-step dependent. Follows the pattern already in RimEclipseContourMapView::appendContourMapProjectionToModel.
Contour labels	Not drawn in 3D for this iteration	Label placement is camera-dependent; the 2D view only keeps them correct via onViewNavigationChanged().

Prerequisites

None. All work is inside ApplicationLibCode; no external resources or configuration changes are needed.

Steps

1. Elevation control in the part manager

Every consumer of contour map geometry repeats the same conversion in four places — createProjectionMapPart (~line 245), createContourPolygons (~line 304), createContourLabels, and createPickPointVisDrawable (~line 552):

cvf::Vec3d globalVertex  = localVertex + contourMapGrid.origin3d();
cvf::Vec3d displayVertex = displayCoordTransform->transformToDisplayCoord( globalVertex );

Introduce an elevation provider so the z component can be replaced without touching geometry generation.

• Add ApplicationLibCode/ModelVisualization/RivContourMapElevationProvider.{h,cpp} with an abstract provider and two implementations:

  class RivContourMapElevationProvider
  {
  public:
      virtual ~RivContourMapElevationProvider();
      // localPos2d is relative to RigContourMapGrid::origin2d().
      // Returns the domain z to use, or nullopt where no elevation is defined.
      virtual std::optional<double> domainElevation( const cvf::Vec2d& localPos2d ) const = 0;
  };
  
  class RivContourMapFlatElevation : public RivContourMapElevationProvider { /* constant z */ };
  class RivContourMapTopographyElevation : public RivContourMapElevationProvider { /* backed by RigContourMapTopography */ };

• Centralise the coordinate conversion in RivContourMapProjectionPartMgr behind a private helper:

  std::optional<cvf::Vec3d> toDisplayCoord( const cvf::Vec3d&                     localVertex,
                                            const RigContourMapGrid&              contourMapGrid,
                                            const caf::DisplayCoordTransform*     displayCoordTransform,
                                            const RivContourMapElevationProvider* elevationProvider ) const;

  With elevationProvider == nullptr it must return exactly today's value (+ origin3d()) and never nullopt, so existing 2D contour map views are byte-for-byte unchanged.
• Add a trailing const RivContourMapElevationProvider* elevationProvider = nullptr parameter to appendProjectionToModel and appendContourLinesToModel. Existing call sites in RimEclipseContourMapView.cpp and RimGeoMechContourMapView.cpp need no edit.
• Handle gaps in createContourPolygons: when toDisplayCoord returns nullopt for either end of a segment, skip that segment. Dropping segments naturally splits a draped polyline wherever the grid is not visible below it — the same gap handling RivSeismicSectionPartMgr::projectPolyLineOntoSurface uses.
• Fix the discarded polygon offset. At RivContourMapProjectionPartMgr.cpp:174 (and :92) the return value of caf::MeshEffectGenerator::createAndConfigurePolygonOffsetRenderState( caf::PO_1 ) is discarded and never assigned to the effect, so contour lines get no polygon offset at all. In the 2D view the lines are coplanar with the map so nothing shows; draped onto grid geometry they will z-fight badly. Assign the render state to an un-cached effect (generateUnCachedEffect(), otherwise the shared cached effect is polluted), using the recipe already established in RivSurfaceIntersectionCurveTools::createCurvePart (factor = -5, units = -1000). This is required for the feature, not a drive-by cleanup.

2. Top-elevation lookup over the contour map grid

Nothing in the repo does "drape onto grid topography" today (grep -i drape returns nothing), and RigMainGrid has no topZAtXY()-style helper. Rather than ray-casting per polygon vertex, precompute a raster once over the contour map grid's vertices and bilinearly interpolate — the same shape as RigContourMapProjection::interpolateValue. The vertex count is the same order as the map itself (a 100×100 map is ~10k rays, computed once per display model rebuild).

• Add ApplicationLibCode/ReservoirDataModel/ContourMap/RigContourMapTopography.{h,cpp}:

  class RigContourMapTopography
  {
  public:
      RigContourMapTopography( const RigContourMapGrid& contourMapGrid,
                               const RigMainGrid&       mainGrid,
                               const cvf::UByteArray*   cellVisibility );
  
      std::optional<double> elevationAtLocalPos( const cvf::Vec2d& localPos2d ) const;
  
  private:
      std::vector<double> m_vertexElevations; // infinity marks undefined
      cvf::Vec2ui         m_vertexCount;
  };

• Implement the per-vertex ray drop using the idiom already present at RigContourMapCalculator.cpp:450: build a thin vertical cvf::BoundingBox at the vertex x/y spanning the grid's z range → RigMainGrid::findIntersectingCells( bbox ) → for each cell set in cellVisibility, RigHexIntersectionTools::lineHexCellIntersection with a vertical segment top→bottom → keep the maximum hit z. Use #pragma omp parallel for over vertices, matching the surrounding contour map code.
• Implement bilinear interpolation in elevationAtLocalPos, returning nullopt when any contributing vertex is undefined.

cellVisibility is the host view's RimGridView::currentTotalCellVisibility(), so the drape follows the 3D view's cell filters and property filters — this is what "project onto the visible geometry" means.

3. The in-view wrapper

• Add ApplicationLibCode/ProjectDataModel/ContourMap/RimContourMapInView.{h,cpp}, deriving from RimCheckableNamedObject:

  using SourceItemT = RimEclipseContourMapView;   // matches the in-view wrapper convention
  RimEclipseContourMapView* sourceItem() const;
  
  enum class MapPosition { TOP_OF_CASE, BOTTOM_OF_CASE, USER_DEFINED_DEPTH };

  Field	Purpose
  caf::PdmPtrField<RimEclipseContourMapView*> m_contourMapView	the mirrored source
  caf::PdmProxyValueField<QString> m_nameProxy	tracks the source view's name; nameField() uiHidden
  caf::PdmField<caf::AppEnum<MapPosition>> m_mapPosition	default TOP_OF_CASE
  caf::PdmField<double> m_depthOffset	applied in all modes, default 0
  caf::PdmField<double> m_userDefinedDepth	positive downwards (z = -depth), as RimPolygonAppearance does with m_polygonPlaneDepth
  caf::PdmField<bool> m_showMapSurface	the coloured plane, default true
  caf::PdmField<bool> m_showContourLines	default true
  caf::PdmField<bool> m_projectLinesOnGeometry	drape lines onto visible grid geometry, default false

  Non-PDM members: cvf::ref<RivContourMapProjectionPartMgr> m_partMgr (lazily created, exactly as RimSurfaceInView::surfacePartMgr() does) and a cached std::shared_ptr<RigContourMapTopography> cleared by clearGeometry().

• Implement appendPartsToModel( cvf::ModelBasicList*, const caf::DisplayCoordTransform*, const cvf::Camera*, int hostTimeStep ):

  1. Guard: source view non-null, its case has loaded data, isChecked().
  2. auto* proj = m_contourMapView->contourMapProjection(); then proj->generateResultsIfNecessary( timeStep ); proj->generateGeometryIfNecessary(); — clamp timeStep to the source case's time step count, since the host view and the contour map's case need not have the same number of steps.
  3. Build a RivContourMapFlatElevation from mapElevation() and call appendProjectionToModel(...) when m_showMapSurface.
  4. Build either the flat provider or a RivContourMapTopographyElevation and call appendContourLinesToModel(..., showContourLines = m_showContourLines, showContourLabels = false, ...). Passing showContourLabels = false already short-circuits createContourLabels (RivContourMapProjectionPartMgr.cpp:149).

• Implement double mapElevation() const:

  • TOP_OF_CASE → proj->mapGrid()->expandedBoundingBox().max().z()
  • BOTTOM_OF_CASE → proj->mapGrid()->origin3d().z() (today's 2D behaviour)
  • USER_DEFINED_DEPTH → -m_userDefinedDepth()

  m_depthOffset() is added in all three cases.

• Implement legend forwarding: legendConfig() returns m_contourMapView->contourMapProjection()->legendConfig(), and updateLegendRangesTextAndVisibility( RiuViewer*, bool ) calls the source projection's updateLegend() (which sets ranges and title) then addColorLegendToBottomLeftCorner( legendConfig()->titledOverlayFrame(), ... ), mirroring RimSurfaceInView::updateLegendRangesTextAndVisibility (RimSurfaceInView.cpp:269).

• Implement fieldChangedByUi: clearGeometry() for m_projectLinesOnGeometry (invalidates the topography cache), then firstAncestorOfType<Rim3dView>()->scheduleCreateDisplayModelAndRedraw().

4. The in-view collection

The master collection RimEclipseContourMapViewCollection is a flat caf::PdmObjectCollection<RimEclipseContourMapView>, not a caf::PdmNestedCollection, so the CRTP template RimNestedMirrorCollectionInView (used by RimPolygonInViewCollection) does not apply. Model the sync on the flat half of RimSurfaceInViewCollection::syncSurfacesWithView().

• Add ApplicationLibCode/ProjectDataModel/ContourMap/RimContourMapInViewCollection.{h,cpp}, deriving from RimCheckableNamedObject:

  caf::PdmChildArrayField<RimContourMapInView*>         m_contourMapsInView;
  caf::PdmPtrField<RimEclipseContourMapViewCollection*> m_sourceCollection;   // uiHidden
  
  void updateFromContourMapCollection();        // sync entry, resolves the source via RimProject
  std::vector<RimContourMapInView*>    visibleContourMapsInView() const;      // {} when !isChecked()
  void appendPartsToModel( cvf::ModelBasicList*, const caf::DisplayCoordTransform*, const cvf::Camera*, int timeStep );
  std::vector<RimRegularLegendConfig*> legendConfigs() const;
  void updateLegendRangesTextAndVisibility( RiuViewer*, bool );
  void clearGeometry();
  void appendMenuItems( caf::CmdFeatureMenuBuilder& ) const override;         // "RicNewContourMapViewFeature"

• Implement the sync in updateFromContourMapCollection(): orphan-sweep children whose PdmPtrField has been auto-nulled by PDM, find-or-create a wrapper per source view, then clearWithoutDelete() and push back in source order. Every new wrapper starts unchecked.

5. Wiring into the views

• Extend the bitmask at ApplicationLibCode/Application/RiaDefines.h:269:

  enum class ItemIn3dView { NONE = 0b00000000, SURFACE = 0b00000001, POLYGON = 0b00000010,
                            CONTOUR_MAP = 0b00000100, ALL = 0b00000111 };

• RimGridView.{h,cpp}: add caf::PdmChildField<RimContourMapInViewCollection*> m_contourMapInViewCollection plus accessor, created eagerly in the constructor next to m_polygonInViewCollection (RimGridView.cpp:106). Handle ItemIn3dView::CONTOUR_MAP in updateViewTreeItems (RimGridView.cpp:533) by calling updateFromContourMapCollection().
• RimEclipseView.cpp — scene assembly in onUpdateDisplayModelForCurrentTimeStep(), using the per-frame named-model pattern from RimEclipseContourMapView.cpp:333 (not a static viz model, because the data is time-step dependent):

  cvf::Scene* frameScene = nativeOrOverrideViewer()->frame( m_currentTimeStep, isUsingOverrideViewer() );
  Rim3dView::removeModelByName( frameScene, "ContourMapsInView" );
  cvf::ref<cvf::ModelBasicList> model = new cvf::ModelBasicList;
  model->setName( "ContourMapsInView" );
  m_contourMapInViewCollection->appendPartsToModel( model.p(), displayCoordTransform().p(),
                                                    viewer()->mainCamera(), m_currentTimeStep() );
  model->updateBoundingBoxesRecursive();
  frameScene->addModel( model.p() );

• RimEclipseView.cpp — tree and legends: uiTreeOrdering.add( contourMapInViewCollection() ) in defineUiTreeOrdering (~line 2141); append the collection's legend configs in legendConfigs() (~line 2536); call updateLegendRangesTextAndVisibility(...) in onUpdateLegends() (~line 1674) when checked.
• RimEclipseContourMapView.cpp: suppress the collection inside contour map views themselves (they derive from RimEclipseView), the same way surfaceInViewCollection() returns nullptr there (RimEclipseContourMapView.cpp:641) — don't add it to the tree and skip the append. Otherwise every contour map view would offer to render every other contour map.

6. Change notification

• RimEclipseContourMapViewCollection.cpp: after addView, removeChild and in onChildDeleted, broadcast to all views, following RimPolygonCollection::updateViewTreeItems() (RimPolygonCollection.cpp:203):

  for ( auto view : RimProject::current()->allViews() )
  {
      view->updateViewTreeItems( RiaDefines::ItemIn3dView::CONTOUR_MAP );
      view->scheduleCreateDisplayModelAndRedraw();
  }

• RicNewContourMapViewFeature.cpp: trigger the same broadcast after creating a map, so it appears in already-open 3D views without a reload.

7. Build files

Headers are not listed in this project's cmake fragments — only .cpp files.

• ApplicationLibCode/ProjectDataModel/ContourMap/CMakeLists_files.cmake — add RimContourMapInView.cpp, RimContourMapInViewCollection.cpp
• ApplicationLibCode/ReservoirDataModel/ContourMap/CMakeLists_files.cmake — add RigContourMapTopography.cpp
• ApplicationLibCode/ModelVisualization/CMakeLists_files.cmake — add RivContourMapElevationProvider.cpp
• New files get a Copyright (C) 2026- Equinor ASA header (current year, per docs/agents/coding-style.md)

8. Verification

• Build and run unit tests

  cmake --build --preset x64-relwithdebinfo --target ResInsight
  ctest -R "UnitTests" -C RelWithDebInfo

• Regression check on the 2D view: create a contour map (New Contour Map from a 3D view) and confirm the 2D view is visually unchanged. This validates the toDisplayCoord refactor and the polygon offset fix.
• Basic overlay: open a normal 3D view. Contour Maps appears in the tree with the map listed and unchecked. Check it — the coloured plane renders above the grid (TOP_OF_CASE) with contour lines, and its legend appears in the bottom-left corner.
• Placement: switch Map Position through Bottom of Case and User Defined Depth, and vary Depth Offset. The plane moves accordingly.
• Visibility toggles: toggle Show Map Surface and Show Contour Lines independently.
• Draping: enable Project Lines on Geometry. Lines follow the grid topography and are cut where no cell is visible. Apply a cell filter or property filter in the 3D view and confirm the drape follows the new visibility and does not z-fight.
• Time steps: step through time steps in the 3D view and confirm the map updates.
• Ensemble: create an ensemble statistics contour map and confirm it also appears and renders.
• Deletion: delete the contour map view and confirm the wrapper disappears from every 3D view without a crash.
• Project round-trip: save the project, reopen it, and confirm check state, map position, offset and drape flag all persist.

Files touched

New (8 files)

File	Purpose
ProjectDataModel/ContourMap/RimContourMapInView.{h,cpp}	per-view wrapper around a contour map view
ProjectDataModel/ContourMap/RimContourMapInViewCollection.{h,cpp}	in-view mirror collection
ReservoirDataModel/ContourMap/RigContourMapTopography.{h,cpp}	top-elevation raster over the contour map grid
ModelVisualization/RivContourMapElevationProvider.{h,cpp}	elevation provider interface + flat/topography implementations

Modified (~9 files)

ModelVisualization/RivContourMapProjectionPartMgr.{h,cpp}, ProjectDataModel/RimGridView.{h,cpp}, ProjectDataModel/RimEclipseView.cpp, ProjectDataModel/ContourMap/RimEclipseContourMapView.cpp, ProjectDataModel/ContourMap/RimEclipseContourMapViewCollection.cpp, Commands/RicNewContourMapViewFeature.cpp, Application/RiaDefines.h, plus 3 CMakeLists_files.cmake.

Known limitations (documented, not fixed here)

• Contour labels are not drawn in the 3D view. They are camera-dependent and would need an onViewNavigationChanged() hook in RimEclipseView to stay correct while rotating.
• The map surface is always flat; only the contour lines can be draped.
• If both the 2D contour map view and a 3D view showing it are open on different time steps, the shared projection cache (m_currentResultTimestep) will recompute on each redraw. Correct, but it costs time; worth revisiting if it proves annoying.
• GeoMech contour maps are not covered.

Links

Issue

• Make contour maps available in 3D view #1043 — Make contour maps available in 3D view

Contour map implementation (to reuse)

• RivContourMapProjectionPartMgr.h — already decoupled from the projection object; takes vertices, grid, background colour and scalar mapper as arguments
• RimContourMapProjection.h — generateResultsIfNecessary, generateGeometryIfNecessary, trianglesWithVertexValues, contourPolygons, mapGrid
• RimEclipseContourMapView.cpp — updateGeometry() and the three append*ToModel() methods are the template for scene assembly
• RigContourMapGrid.h — origin3d(), expandedBoundingBox(), generateVertices() (local, z = 0)

In-view collection pattern (to follow)

• RimSurfaceInViewCollection.cpp — hand-rolled flat + nested sync, legend handling
• RimPolygonInViewCollection.h — the modern CRTP variant (not directly applicable here, the master collection is flat)
• RimNestedMirrorCollectionInView.h — the CRTP template and its documented contract

Draping / z-fighting prior art

• RivSeismicSectionPartMgr.cpp — projectPolyLineOntoSurface, the only per-point projection in the repo
• RivSurfaceIntersectionCurveTools.cpp — the canonical polygon-offset recipe for lines on a surface
• RigHexIntersectionTools.h — lineHexCellIntersection
• RicCreateContourMapPolygonTools.cpp — existing local-to-domain conversion using topDepthBoundingBox()

Project conventions

• docs/agents/coding-style.md
• docs/agents/build.md

[magnesj]

The project-level contour map collection stays the single owner of contour map views and their computed projections; each 3D view gets a mirror collection of thin wrappers that point back at those views. At render time the wrapper pulls the already-computed triangles and contour polygons from the source projection and passes them to the part manager together with an elevation provider, which is the only thing that decides where the geometry lands in z.

graph TD
    subgraph project["RimOilField (project level)"]
        MC["RimEclipseContourMapViewCollection"]
        CMV["RimEclipseContourMapView<br/>RimStatisticsContourMapView"]
        PROJ["RimContourMapProjection<br/>triangles + contour polygons + legend"]
        MC --> CMV
        CMV --> PROJ
    end

    subgraph view["RimEclipseView (3D view)"]
        IVC["RimContourMapInViewCollection<br/><i>new</i>"]
        IV["RimContourMapInView<br/><i>new</i><br/>map position, offset,<br/>show surface / lines, drape"]
        IVC --> IV
    end

    subgraph render["Rendering"]
        PM["RivContourMapProjectionPartMgr<br/><i>+ elevation provider param</i>"]
        FLAT["RivContourMapFlatElevation<br/><i>new</i>"]
        TOPO["RivContourMapTopographyElevation<br/><i>new</i>"]
        RIG["RigContourMapTopography<br/><i>new</i><br/>top z of topmost visible cell"]
        MODEL["cvf::ModelBasicList<br/>'ContourMapsInView'"]
        PM --> MODEL
        FLAT --> PM
        TOPO --> PM
        RIG --> TOPO
    end

    MC -. "mirrored by<br/>updateFromContourMapCollection()" .-> IVC
    IV -- "PdmPtrField" --> CMV
    IV -- "reads geometry + legend" --> PROJ
    IV --> PM
    VIS["RimGridView::currentTotalCellVisibility()<br/>host view cell + property filters"] --> RIG

Loading

[magnesj]

Steps 1 to 7 are implemented on branch 1044-contour-maps-in-3d-view, seven commits, one per step.

Automated verification done

• cmake --build build --target ResInsight — clean build, no warnings introduced.
• ResInsight-tests.exe — 1023 tests from 173 suites, all passing. (ctest finds nothing in this build directory because BUILD_TESTING is OFF; the ResInsight-tests target is built and run directly instead.)
• Smoke test: ResInsight.exe --case TEST10K_FLT_LGR_NNC.EGRID --savesnapshots views loads the case, builds the display model through the new appendContourMapsToModel and legend hooks with an empty collection, writes the snapshot and exits with code 0. The rendered view is unchanged.

Still open

The nine remaining checkboxes under step 8 are visual checks that need a case with an actual contour map, and are left for manual review.

Deviations from the plan

• The conversion helper is a pair, toDomainCoord plus toDisplayCoord, rather than toDisplayCoord alone. The label code needs domain coordinates to derive the text orientation vector, so collapsing everything into a display-coordinate helper would not have covered that call site.
• contourMapInViewCollection() was made virtual on RimGridView so RimEclipseContourMapView can return null, mirroring surfaceInViewCollection(). The 2d contour map views already fully override defineUiTreeOrdering and onUpdateDisplayModelForCurrentTimeStep, so this only stops the empty collection being synced and serialized for them.
• No change was needed in RicNewContourMapViewFeature. Every creation path goes through RimEclipseContourMapViewCollection::addView, so putting the notification there covers the new contour map feature, paste, and the case migration path alike.
• The discarded createAndConfigurePolygonOffsetRenderState( caf::PO_2 ) call for the pick point marker at RivContourMapProjectionPartMgr.cpp:92 was left alone. It is the same latent bug, but the pick point is only drawn in the 2d views where it is coplanar with the map, so applying an offset there would change existing rendering for no benefit to this feature.

[magnesj]

Added visualization control for contour line color and thickness in the 3d view, beyond the original plan.

The contour lines were drawn as hairlines colored to contrast the map level underneath them, which is computed per level from the scalar mapper. That reads well on the flat 2d map, but poorly in a 3d view where the lines are draped on grid geometry of arbitrary color.

New fields on RimContourMapInView

Field	Values	Default
Line Color Mode	Contrast to Map / Single Color	Contrast to Map
Line Color	color picker, shown only for Single Color	Black
Line Thickness	1 to 10	1

The Project Lines on Geometry, color and thickness fields moved into their own Contour Lines group, made read only when Show Contour Lines is off.

Rendering

RivContourMapProjectionPartMgr::appendContourLinesToModel takes a new trailing RivContourLineAppearance parameter holding an optional color and a line width. An unset color keeps the per level contrast behaviour, and the defaults reproduce the current appearance exactly, so the 2d contour map views, which pass no appearance at all, are unaffected.

Verification

Clean build, 1023 unit tests passing, and the snapshot smoke test still loads a case and exits with code 0.

[magnesj]

Two reported defects fixed, plus surface draping added.

Empty collection name in the project tree

RimNamedObject::userDescriptionField() returns the name field, and that is what the tree label is read from. The collection never set it, so the node rendered without text. Now set to Contour Maps in the constructor.

Contour lines hidden below the map surface

The root cause is not what the earlier commit assumed. Polygon offset applies to polygon primitives only, and the FILL / LINE / POINT enable flags select which polygon mode is offset, not which primitive type. The contour lines are PT_LINES, so no polygon offset can ever reach them, and the render state added earlier was inert. The map surface, being a triangle drawable, already carries caf::PO_1 from the cached scalar mapper effect, which is enough in the flat top down 2d view but not in an oblique 3d view.

The fix is geometric: the lines are lifted above the surface they follow by 0.02 * sampleSpacing, so the lift scales with the model and stays invisible at any reasonable zoom. The dead render state is removed and the line effect goes back to a cached effect.

Project Surface on Geometry

New field on RimContourMapInView, alongside the existing option for the lines. The map surface follows the top of the visible geometry instead of the map plane. Triangles with no visible cell underneath are dropped, which createProjectionMapPart already handled. The property panel is now grouped as Position, Map Surface and Contour Lines.

Topography cache invalidation

Found while implementing the above. The raster was built once and kept forever, so a drape would not follow a cell or property filter change. It is now rebuilt when the host view produces a new cell visibility array or the projection a new map grid. Both are replaced as new objects by their owners, so comparing identity is sufficient.

Clean build, 1023 unit tests passing, snapshot smoke test exits 0.

[magnesj]

Added Show Contour Labels to RimContourMapInView, off by default, in the Contour Lines group and read only when Show Contour Lines is off.

Revising an earlier decision

Labels were originally left out as a known limitation, on the assumption that they would not survive navigation in a 3d view. That assumption was wrong. cvf::DrawableText::renderText projects every anchor position to window coordinates each frame and hands the result to TextDrawer as screen aligned text, so a label keeps its position on the contour line and stays readable whatever the camera does.

What is still camera dependent

Only the layout, decided once from the camera as it is when the display model is built:

• which labels are dropped because they overlapped another label, computed in window space in createContourLabels
• the in plane rotation of the text, taken from the contour segment direction

Rotating the view can therefore leave labels overlapping, or turned at an angle that suited the previous camera. The 2d contour map views avoid this by rebuilding on a camera z change above five percent, through onViewNavigationChanged. The same hook could be added to RimEclipseView, but it would rebuild the whole contour map model on navigation, so it is left out until the layout drift proves annoying in practice.

Labels use the same elevation provider as the lines, so they are lifted clear of the map surface along with them, and they drive the gaps cut in the lines exactly as in the 2d views.

Verification

ResInsight.exe could not be relinked, a running instance is holding the file, so this is not build verified end to end yet. The code does compile and link: ApplicationLibCode is up to date and ResInsight-tests links against it and runs, 1023 tests passing.

[magnesj]

Contour lines are now resampled before being elevated, so a draped line follows the geometry along its whole length instead of only at the polygon vertices.

Why the lines did not look draped

RigContourMapTrianglesGenerator simplifies every contour polygon with Douglas-Peucker, at an epsilon of 5.0e-2 * sampleSpacing for smoothed lines, doubled or quadrupled for the coarser resolutions, so up to a fifth of the sample spacing. A straight stretch of a contour line therefore collapses to a single segment that can span a large part of the map. Elevating only its two end points leaves the segment cutting straight through everything between them.

Sampling density is a property of the elevation provider

RivContourMapElevationProvider gained resamplingDistance(), defaulting to zero, meaning the elevation does not vary and the end points are enough. RivContourMapFlatElevation keeps the default, so flat lines generate exactly the geometry they did before and the 2d contour map views are untouched. RivContourMapTopographyElevation returns sampleSpacing / 8, eight samples per raster cell of the topography.

That keeps the decision where the knowledge is. The provider knows whether and at what scale its elevation varies; the part manager only asks.

Side benefit

A sample with no elevation still leaves a gap, so a draped line is now cut at the true edge of the visible geometry rather than at the nearest polygon vertex. Gaps used to be quantised to the simplified polygon.

The per segment sample count is capped at 200 so a pathologically long segment cannot generate unbounded geometry.

Verification

Clean build, 1023 unit tests passing, snapshot smoke test exits 0. Whether eight samples per raster cell is the right density is a judgement call best settled by looking at it on a real model.

[magnesj]

Contour map geometry now drapes on surfaces as well as grid cells.

Why nothing was drawn

RimEclipseView::calculateCurrentTotalCellVisibility starts with setAll( false ) and only ORs in visibility for the grids returned by indicesToVisibleGrids(). Hiding the grid cells leaves that array all false. RigContourMapTopography searched grid cells only, so it hit nothing anywhere, every elevation came back undefined, and the gap handling that splits a draped line at the edge of the visible geometry removed the entire line.

What it does now

At every raster vertex the highest of two candidates is kept:

• the top of the highest visible grid cell, as before
• the top of the highest visible surface

So a view with only the grid shown behaves exactly as it did, a view with only a surface shown drapes on the surface, and a view with both drapes on whichever is on top. Nothing visible under a vertex still leaves it undefined, so lines are still cut at the edge of the geometry rather than floating.

Each surface gets a ray range computed from its own vertices, with a small margin, since a surface can sit well outside the depth range of the case. Using a fixed span would have been unit dependent.

Supporting change

RimSurfaceInViewCollection::visibleSurfacesInView() returns the surfaces the collection contributes to the scene, recursing the checked sub collections exactly as the existing appendPartsToModel and legendConfigs do. There was no such accessor; the collection only knew how to append its own parts.

The cached raster now also keys on the surface set, so checking a surface on or off rebuilds the drape.

Verification

Clean build, 1023 unit tests passing, snapshot smoke test exits 0. The surface drape itself needs a model with a surface to confirm visually.

[magnesj]

Branch pushed and PR opened: #1045, targeting dev in the fork.

All 14 commits are included. The nine manual verification items in step 8 of this plan are still open and are called out in the PR description as not verified end to end.