visualizer: adopt backend-neutral cScene3DNode (OSG+VSG coexistence)

[tabgab]

What

Companion to omnetpp/omnetpp-dev topic/VSG (backend-neutral cScene3DNode, PR omnetpp/omnetpp-dev#5). Updates INET's OSG and VSG visualizers to the renderer-neutral scene-handle API so INET builds and runs against an OMNeT++ that contains both 3-D backends, with the renderer chosen per simulation.

How

• Wrap OSG scene roots with omnetpp::createScene3DNode() when calling cOsgCanvas::setScene().
• Recover the typed root via getOsgRoot() / getVsgRoot() instead of casting cScene3DNode directly to a scene-graph type.
• Updated both visualizer trees:
  • OSG: SceneOsgVisualizer, SceneOsgEarthVisualizer, SceneOsgVisualizerBase, OsgScene, GeographicCoordinateSystem
  • VSG: SceneVsgVisualizer, VsgScene

Verified

Built against an OMNeT++ with both backends. From the same build: INET OSG showcase (showcases/visualizer/osg/networknode, oppqtenv-osg) and VSG showcases (vsgsignal, vsgsignal3d, vsglidar, vsgsignalwave, oppqtenv-vsg) each render on the correct backend.

Requires the omnetpp-dev topic/VSG change (PR omnetpp/omnetpp-dev#5) to build.

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 potential issue.

[tabgab]

Thanks for the analysis — went through all four findings. Summary: one real bug (now fixed + verified), three not actionable. Details below.

1. OSG-only build failure (missing include path) — fixed in 6d3244880e

Confirmed and correct. The five OSG source files adopted in this PR now #include "qtenv/osg/osgscenehandle.h" (which lives under $(OMNETPP_ROOT)/src), but that include path was only added by the VisualizationVsg makefrag block (src/makefrag:81), not the VisualizationOsg block. So an OSG-only build (VisualizationOsg enabled, VisualizationVsg disabled — the common existing configuration) could not find the header.

Fix: add CFLAGS += -I$(OMNETPP_ROOT)/src to the VisualizationOsg block, mirroring the VSG one.

Verified with an actual OSG-only build from a clean checkout (VisualizationOsg enabled, VisualizationVsg disabled): make MODE=release completes with exit 0, all OSG scene visualizers compile (including the five that include the header), libINET.dylib links, and there are no osgscenehandle.h not-found errors. My earlier verification missed this because it was built with both features enabled, where the VSG block's -I masked the gap.

2. Null-safety at SceneVsgVisualizer.cc:42 — verified safe (see resolved thread)

omnetpp::getVsgRoot() (omnetpp-dev src/qtenv/vsg/vsgscenehandle.h) is:

return (node && node->getBackendType() == cScene3DNode::BACKEND_VSG)
           ? static_cast<VsgScene3DNode *>(node)->getRoot()
           : vsg::ref_ptr<vsg::Group>{};

The node && short-circuit returns an empty ref_ptr for a null (or wrong-backend) argument, so it never dereferences null. The null path ends in the existing if (topLevelScene == nullptr) throw cRuntimeError(...) — a clean error, not a crash. It is also stricter than the pre-PR code, which had no backend-type check.

3. OsgGeographicCoordinateSystem reads the scene at INITSTAGE_LOCAL — not a regression

The pre-PR code read the scene at the same stage; the getOsgRoot indirection does not change initialization order. No change needed. (A null scene here would surface as the existing "Could not find map node in the scene" cRuntimeError, same as before.)

4. getOsgRoot must return the full scene-graph root for findMapNode — correct by design

createScene3DNode(node) wraps node in OsgScene3DNode, which stores it verbatim, and getOsgRoot() returns that same pointer. So getOsgRoot(getOsgCanvas()->getScene()) yields the identical TopLevelScene root that SceneOsgEarthVisualizer::initializeScene() attaches the map scene to — findMapNode traverses the correct subtree, and no wrapper node is interposed.