The waves visual plugin is sensitive to the plugin load order when running on an arm64 mac. It is not clear why the issue is not present on an amd64 mac or linux, but the same issue is potentially present.
The problem is that the ogre2 render engine plugin must be loaded and initialised before the waves visual plugin is loaded for the model. The waves visual plugin links directly against the ogre2 render engine plugin library. This library (libgz-rendering7-ogre2.dylib) is installed into two locations (./install/lib and ./install/lib/gz-rendering-7/engine-plugins).
On arm64 macs the libraries are loaded twice, once from each location. The library linked to the visual plugin is loaded first and the render engine is initialised second. This appears to cause dynamic casts of the scene pointer to fail when the scene is being initialised.
Suggested fix
A fix requires better control over the order in which the extensions to the ogre2 render engine that are embedded in the waves visual plugin are loaded.
Currently there is no mechanism in gz-rendering to define custom extensions to the render engine interface and implement these for specific render systems. The waves visual plugin (a system plugin) works around this by defining the extensions directly and hoping that the render engine is available at the point the visual is initialised. This is not robust.
The proposal is add a class for render engine extensions and a manager to load and store them, analogous to the classes for the main render engine. This will allow the loader to check the base render engine plugin is present before loading the extension.
The visual plugin should be written in terms of render engine extension interface classes - rather than depending directly on a specific render engine. This allows the direct linkage to specific render engines to be broken.
srmainwaring
commented
2 years ago
The waves visual plugin is sensitive to the plugin load order when running on an arm64 mac. It is not clear why the issue is not present on an amd64 mac or linux, but the same issue is potentially present.
The problem is that the ogre2 render engine plugin must be loaded and initialised before the waves visual plugin is loaded for the model. The waves visual plugin links directly against the ogre2 render engine plugin library. This library (
libgz-rendering7-ogre2.dylib) is installed into two locations (./install/liband./install/lib/gz-rendering-7/engine-plugins).On arm64 macs the libraries are loaded twice, once from each location. The library linked to the visual plugin is loaded first and the render engine is initialised second. This appears to cause dynamic casts of the scene pointer to fail when the scene is being initialised.
Suggested fix
A fix requires better control over the order in which the extensions to the ogre2 render engine that are embedded in the waves visual plugin are loaded.
Currently there is no mechanism in
gz-renderingto define custom extensions to the render engine interface and implement these for specific render systems. The waves visual plugin (a system plugin) works around this by defining the extensions directly and hoping that the render engine is available at the point the visual is initialised. This is not robust.The proposal is add a class for render engine extensions and a manager to load and store them, analogous to the classes for the main render engine. This will allow the loader to check the base render engine plugin is present before loading the extension.
The visual plugin should be written in terms of render engine extension interface classes - rather than depending directly on a specific render engine. This allows the direct linkage to specific render engines to be broken.