Steps to reproduce:

• open empty level
• add Entity and ROS2 Lidar Sensor
• switch from scene queries to RGL.
• Start GameLauncher (without autoexec.cfg)
• Reload level.

When building main branch against o3de and o3de-extras 2310.3 I can see the following warnings (Ubuntu 22.04, cmake 3.22.1):

[cmake] CMake Warning at /home/jhanca/devroot/o3de_main/o3de/cmake/LYWrappers.cmake:210 (add_library):
[cmake]   Cannot generate a safe runtime search path for target RGL because files in
[cmake]   some directories may conflict with libraries in implicit directories:
[cmake] 
[cmake]     runtime library [libpython3.10.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
[cmake]       /home/jhanca/devroot/projects/ProjectName/build/linux/bin/profile
[cmake] 
[cmake]   Some of these libraries may not be found correctly.
[cmake] Call Stack (most recent call first):
[cmake]   /home/jhanca/devroot/o3de-rgl-gem/Code/CMakeLists.txt:60 (ly_add_target)
[cmake] 
[cmake] 
[cmake] CMake Warning at /home/jhanca/devroot/o3de_main/o3de/cmake/LYWrappers.cmake:210 (add_library):
[cmake]   Cannot generate a safe runtime search path for target RGL.Editor because
[cmake]   files in some directories may conflict with libraries in implicit
[cmake]   directories:
[cmake] 
[cmake]     runtime library [libpython3.10.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
[cmake]       /home/jhanca/devroot/projects/ProjectName/build/linux/bin/profile
[cmake] 
[cmake]   Some of these libraries may not be found correctly.
[cmake] Call Stack (most recent call first):
[cmake]   /home/jhanca/devroot/o3de-rgl-gem/Code/CMakeLists.txt:100 (ly_add_target)

The current behavior seems to be that the entire scene is captured at once regardless of the sensor frequency. Real rotating lidar sensors collect points over time which causes distortion when objects are moving relative to the sensor.

Would it be possible to simulate distortions caused by movement? How big would the performance hit be? Would the limiting factor for "subsections" be the frame rate?
Point specific time stamps in the ROS message would be great with this feature.

Some strange scan artifacts are visible when RGL is used with height-mapped terrain (terrain gem):

• Scene queries
  

• RGL:
  

Currently (#33), the intensity textures are not calculated for the Actor Component. This component has been supported by the gem so far and support should (if possible) be kept by all newly added features.

The following error message appears when loading the main level of the agri demo:

[Error] (ErrorCheck) - RGL encountered an error in file /home/pawel/github/agri/o3de-rgl-gem/Code/Source/Entity/TerrainEntityManagerSystemComponent.cpp at line 208 with message: RGL API Error: Invalid argument, condition unsatisfied: mesh != nullptr

It doesn't seem to cause any issues, but the red error message may look alarming.

Spotted in: 7a61660

The gem's license has to be updated to a newer one. For now the one used by genai gems is planned.

The TerrainEntitManagerSystemComponent uses an identity transform for the terrain. This has to be evaluated and if this is not the case, modified.

We are currently adding support for Lidar 2D publishing LaserScan messages to ROS2 gem and would like to have it supported by RGL gem. New API that needs to be implemented is publishing topic with array of ranges as well as 3D point coordinates for visualisation purposes.

It would be beneficial for high frequency 2D lidars and cases with multiple lidar instances

Existing issue: o3de/o3de-extras#247
PR current state: o3de/o3de-extras#255

Adding a model in a run-time, in already existing Entity results in triggering an assert in MeshEntityManager::OnModelReady.

Code: MeshEntityManager::OnModelReady:L42

It is possible that on the very same entity, there will be multiple OnModelReady calls and the number of entities might not be zero. Therefore, most probably the assert is unnecessary.

I created two PRs to fix missing dependency versions:

1. PR #42 targeting the development branch, which sets the requirement for RGL to use development branch of O3DE
2. PR #43 targeting the main branch, which sets the requirement for RGL to use stable O3DE or the next stable (in development, but feature-locked already).

My second PR #43 was force-pushed and modified (!?) to link main version of RGL with main version of O3DE. As a result is it IMPOSSIBLE to use RGL with the stabilization branch of O3DE. Please note, that O3DE is to be released within a month, the stabilization branch is feature-locked and many developers use it on a daily basis.

1. Change vector to vector
2. Add validation

I'm opening it here as our fork of o3de-extras doesn't have github issues.

The non-uniform scale component is omitted when running RGL - the uniform scale is always used.

Bug description:
Current terrain mesh does not seem to reflect the terrain generated by the Terrain Gem.

In some configurations it works fine but in others, either the mesh gridsize is too large (first picture) or the grid is offset (second picture).

After changing the level from the one with terrain to some new one (without restarting o3de editor) I got strange visualization - it looks like rgl somehow remember the old terrain and "draw" it above the current one. Everything works fine when I close O3DE and rerun it with new level. Hopefully the screenshot says more than this description.

What is the problem

I was able to build O3DE project that utilizes ROS 2 Gem and RGL Gem as monolithic game launcher with instruction that instruction:
https://github.com/o3de/o3de.org/pull/2520/files.
However the shared library libRobotecGPULidar.so is missing.

Steps to reproduce

0. Setup all repos to the latest release (2310.1)
1. Create a project from a template with some name ${PROJECT_NAME} at path ${PROJECT_PATH}
2. Enable RGL Gem (if it is not already enabled in the template)
3. Build toolset (with PhysX 4.0):

cmake -B build/linux -G "Ninja Multi-Config" -DLY_DISABLE_TEST_MODULES=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DLY_STRIP_DEBUG_SYMBOLS=ON
cmake --build build/linux --config profile --target ${PROJECT_NAME} ${PROJECT_NAME}.Assets

4. Deploy monolithic build

cmake -B build/linux_mono -S . -G "Ninja Multi-Config" -DLY_3RDPARTY_PATH=${HOME}/o3de-packages -DLY_MONOLITHIC_GAME=1
cmake --build build/linux_mono --target install --config release

5. Run GameLauncher in ${PROJECT_PATH}/install/bin/Linux/release/Monolithic/`

./${PROJECT_NAME}.GameLauncher

6. Experience missing dynamic library:

./ROSCon2023Demo.GameLauncher: error while loading shared libraries: libRobotecGPULidar.so: cannot open shared object file: No such file or directory

Expected behavior

Since libRobotecGPULidar.so is a shared library the o3de build system should copy it for us into the install directory (like libVkLayer_khronos_validation.so).

Proposed solution

Modify https://github.com/RobotecAI/o3de-rgl-gem/blob/development/Code/FindRGL.cmake to copy the above-mentioned shared library to install space when install target is being built.
Alternatively, consider static linking.

Current walk-around

Copy libRobotecGPULidar.so .