2.19: Syncker force load SpiderVision

[Amerio.Stephane]

Hello,

It looks like having Syncker loaded forcefully loads the SpiderVision plugin. Is it normal behavior? Am I missing something? Is there a way to prevent this?

[mifril]

Hello,

Yes this is normal behavior, since the functionality of the configurator and AppProjection plugin has now been transferred to SpiderVision, the Syncker now works together with the SpiderVision plugin, loading the plugin itself during initialization, if the plugin fails to load (the dynamic library will not be found) the Syncker will work but things related to projections will not work or will not be synchronized.

What problem did you encounter?

Why don't you want the SpiderVision plugin to not load?

[Amerio.Stephane]

There is nothing inherently wrong with forcefully loading SpiderVision, it's just that the doc/migration guide is not clear on this subject. So I'll simply adapt our workflow, but I needed to know first if this was the intended behavior.

I'm trying to migrate our 2.16 way-of-working to 2.19. Which, in insight, might need more tweaking or rethinking than I thought.

• Would having multiple PC in a cluster having the same "-computer_name X" pose any problem for Syncker for example? (eg PC A is master and have "-computer_name master", and PC B and C are slaves and both have "-computer_name slave")
• Would calling setComputerName() in code trigger a reload of the matching SpiderVision display settings? If not, how to trigger such a reload?

[mifril]

Yes, the presence of identical computer_name in the cluster can affect the correct working, since computer_name is a unique identifier of the computer on which the SpiderVision viewport should be created and processed. If you look at the viewport parameters in the SpiderVision configurator, you can find the computer_name parameter.
In this case, if we create two viewports that are supposed to be processed on different computers, the computer_name field should be different for them, otherwise these viewports will both be created on both computers.

No, changing computer_name at runtime will not cause a configuration reload. To do this manually, you can call the DisplaysConfig::loadConfig method, you can call it on any instance, Syncker should synchronize it.

[Amerio.Stephane]

Okay, thanks for the precisions.

Now, say I have a cluster of slaves in a dome each with an easyblend setup. I need to be able to change at runtime the eye position. In 2.16 this meant I loaded at runtime a mesh.ol corresponding to the correct eye (Pilot PEP or copilot CEP for eg., and on slave 2, this would mean mesh_pep.ol2 and mesh_cep.ol2). And I need to be able to switch from PEP to CEP to PEP, etc.

What would be the preferred way of doing this, now?

[mifril]

You can load .ol files in runtime in exactly the same way now, by getting the viewport you need via DisplaysConfig::getViewport, then calling the ViewportData::loadEasyBlendSettings method.
To change the position of the viewer relative to the setup, you can use the SpiderVision::Manager::setViewportViewOffset method, which works the same way as it did before in the Syncker.

[Amerio.Stephane]

Ok. Just to be clear:

• should I call loadEasyBlendSettings on the master, or only on the relevant slaves?
• If the call is on the master, then should the mesh.ol file exist only on the master (sync'ed by Syncker), or should they exist on all machine in the cluster with the same path?

[mifril]

You can call loadEasyBlendSettings anywhere where .ol files exist, they will then be synchronized by the Syncker.