UnrealEngine/Plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

minor markdown formatting fixes

Browse Source
This commit is contained in:
Mamadou Babaei
2026-07-13 20:21:07 +02:00
parent 9e67ea83d1
commit c860f3380e
1 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Handbook/src/getting-started/sensecom/fakeshm-tuning/README.md
+6 -6
View File
@@ -2,7 +2,7 @@
Starting with **SenseGlove Libraries `v2.400.0-023e6b23c`**, which is at the heart of **SenseCom v1.10.x** and the **SenseGlove Unreal Engine Plugin v2.9.x**, SenseGlove has introduced a completely new communication backend called **`SGFakeShm`**.
Despite its name, `SGFakeShm` is **not** another shared memory implementation. Instead, it is a modern communication layer that supports multiple transports to imitate the legacy SharedMem behavior using alternative transports and mechanisms on both Microsoft Windows and GNU/Linux, while retaining full compatibility with the existing Shared Memory implementation.
Despite its name, `SGFakeShm` is **not** another shared memory implementation. Instead, it is a modern communication layer that supports multiple transports to imitate the legacy `SharedMem` behavior using alternative transports and mechanisms on both Microsoft Windows and GNU/Linux, while retaining full compatibility with the existing Shared Memory implementation.
The new module was designed to significantly improve latency, throughput, and frame rate stability while maintaining backward and forward compatibility with previous or future releases of SenseCom or the UE plugin.
@@ -15,7 +15,7 @@ While the legacy Shared Memory provides good performance, it has several drawbac
- Communication is fundamentally blocking.
- Enterprise security software frequently interferes with Shared Memory.
- Multiple applications competing for Shared Memory can negatively impact performance.
- Due to its blocking/synchronous nature of the legacy SharedMem implementation, rendering and communication become more tightly coupled, potentially reducing frame rate where Boost SharedMem becomes the bottleneck.
- Due to its blocking/synchronous nature of the legacy `SharedMem` implementation, rendering and communication become more tightly coupled, potentially reducing frame rate where Boost `SharedMem` becomes the bottleneck.
The new `SGFakeShm` backend addresses these limitations by introducing two additional communication mechanisms/transports:
@@ -39,8 +39,8 @@ Even if your application is still using an **older Unreal Engine plugin**, simpl
> [!NOTE]
> If a new version of SenseCom or the UE plugin paired with a version that lacks
> support for `SGFakeShm`, using the default settings, it will always
> automatically fall back to the legacy SharedMem. Thus, we recommend using the
> recent versions of both SenseCom and the UE plugin with support for
> automatically fall back to the legacy `SharedMem`. Thus, we recommend using
> the recent versions of both SenseCom and the UE plugin with support for
> `SGFakeShm` to be able to fully utilize the new capabilities and improvements
> including the new IPC and TCP transports. Otherwise, due to lack of support
> from one party in such setups where one side lacks `SGFakeShm` support, `IPC`
@@ -58,7 +58,7 @@ Although Shared Memory remains a blocking transport by design, it has received n
- Higher throughput.
- Various bug fixes.
In our benchmarking, we observed that the legacy SharedMem overhaul has dramatically improved its performance and stability, boosting throughput from only `a few KB/s` to roughly `7.5 GB/s` in certain configurations, compared to the previous implementation.
In our benchmarking, we observed that the legacy `SharedMem` overhaul has dramatically improved its performance and stability, boosting throughput from only `a few KB/s` to roughly `7.5 GB/s` in certain configurations, compared to the previous implementation.
Applications that still prefer to use `SharedMem` over `IPC` (**Named Pipes** on Microsoft Windows and **Unix Domain Sockets** on GNU/Linux), will therefore still benefit from upgrading SenseCom and the UE plugin, even without adopting the newer `IPC` or `TCP` transports.
@@ -154,7 +154,7 @@ The same benchmark via the `IPC` transport and using fine-tuned settings consist
> In this case, we recommend switching to `IPC` or `TCP` due to their low
> latency. Despite their lower throughput compared to Boost `SharedMem`, the
> latency of these alternative transports is in the realm of microseconds,
> making them significantly faster than Boost SharedMem, whose latency is
> making them significantly faster than Boost `SharedMem`, whose latency is
> measured in milliseconds.
### Benchmarking and Tuning Utilities