Applying EasyBlend files to slaves takes too long

[Amerio.Stephane]

Hello,

Contrary to previous 2.16 version, the 2.20 easyblend files are now deployed to slaves by the master. But I found this step to consume way too much time, as it can 'pause' the IG for up to 5s (while it was almost immediate in 2.16). Maybe I'm doing something wrong, so...

Here is part of the code used, in a World::update() when the user has requested to change the position of the pilot's eye (pilot<->copilot for example):

	SpiderVision::DisplaysConfig* c = spider->getConfig();
	for (int index = 0; index < c->getNumViewports(); ++index) {
		auto v = c->getViewportByIndex(index);
		const int id = v->getID();
		if (!v->getName().startsWith("OTW")) //< Out The Window, ie the dome
			continue;
		String ext = v->getName().extension(); // ext now contains the ID (1,2,..) of the mesh OL file for this viewport
		String easyBlendSettings = String::format("%s/%s/mesh%s.ol", _calibrationPath.get(), eyeName.get(), ext.get());

		if (FileSystem::isFileExist(easyBlendSettings)) {
			Log::message("Calibration EasyBlend Settings %s\n", easyBlendSettings.get());

			v->setType(SpiderVision::ViewportData::DISPLAY_TRANSFORM_TYPE_PROJECTOR);
			v->loadEasyBlendSettings(easyBlendSettings);
			v->setProjectionEnabled(true);
			v->getEasyblendData()->setEnabled(calib_enabled.get());
		}
		else {
			Log::error("Calibration EasyBlend Settings not found: %s\n", easyBlendSettings.get());
		}
	}

Is this the correct way to do it? (in the update). Is it possible to do this in a non-blocking way?

Is there any way to accelerate this (preloading?). The files are not expected to change during a session.

Context: the pilot & copilot need to change the eye position quite frequently because they need to calibrate their helmet HUD, and in 2.20 this step has become too slow.

Thanks!

[silent]

Hi Stephane,

Just to understand the procedure of applying easyblend files:

• You have set of the .ol files for the left position (let's say 18 .ol files and each file ~1MB on disk)
• You have set of the .ol files for the right position (again 18.ol files, each 1MB on disk)
• All the files are available locally on each PC (18 PCs, 36 files)
• On master you run the code that updates SpiderVision config (attached code from your 1st post)

Is that correct assumptions? We would need to do some tests to find out what is happening here.

Thanks!

[Amerio.Stephane]

All OL files are currently only on the master in 2.20, as Spider is the one sending this data. If needed, we can of course copy them to the slaves at the same location as it was done in 2.16.

The code presented previously is only ran on the master in 2.20 (in 2.16, master and slaves had to run the OL loading code).

[silent]

Thanks for the update, now it's more clear.

But amount of PCs are still not 1-2, but rather 15-20?

[Amerio.Stephane]

more like 6 to 12 PC depending on dome.

[silent]

Thanks for the clarifications.

Could you let us know how critical this is for your workflow?

If a ~5-second delay during projection changes is acceptable for now, we can defer the work, invest more time in profiling and optimizations, and include the improvements in the 2.21 release. If it’s blocking, we’ll prioritize an earlier fix.

So far, I'm afraid there is no easy ways exists (or any other ways) to improve current the projection applying timings. But if anything we can find quickly to improve the situation, we surely let you know. Your code looks completely valid and simple, so it should perform better once we’re able to optimize this path.

Thank you!

[Amerio.Stephane]

Our target time for switching eye is "less than 1s" (as it was in 2.16). This is because pilots and copilot need to work collaboratively to calibrate both their helmet "as the same time", so the switching must be as fast as possible. Note: while it's critical during this calibration phase, pilot and copilot have the possibility - on a button pressed - to switch to their own eye during a flight, so it's not a one-time per flight need!

With this target in mind: it's not blocking at this time, as 2.16 is still installed and working and can be used for now (it just lacks performance and quality-wise when compared to 2.20). So we can wait 2.21 (ETA?).

Understand also that the visual system starts in central eye by default and design (so 5 sec lag) and right after the simulator host sends the correct eye (wich may be pilot or copilot, depending on the scenario) (so 5 more sec => 10 wasted seconds with a frozen screen and no feedback possible).

Thanks!

[silent]

Version 2.21 is tentatively planned for late November to early December.

Because 2.20 and 2.21 are quite close code-wise (especially around SpiderVision) there’s a good chance we can backport the relevant 2.21 changes to 2.20.