Right now the reflections field in RadarSensorView/Config and LidarSensorView/Config is an mixed up interface consisting of raytracer related fields and sensor principle related fields. Therefore to seperate the different sensor model approaches a new field RaytracerView/Config is necessary. Furthermore the OSI protobuf performance suffers because of data de-/serialization between GPU and CPU. Additionally the new RaytracerView/Config should be able to keep the raytracer output on the GPU and/or on the CPU..
Describe the solution you would like
A RaytracerView/Config is implemented and only pointers are exchanged via OSI messages.
Describe alternatives you have considered
Describe the backwards compatibility
The new feature is completly backward compatible, because a new field is introduced.
Describe the feature
Right now the reflections field in RadarSensorView/Config and LidarSensorView/Config is an mixed up interface consisting of raytracer related fields and sensor principle related fields. Therefore to seperate the different sensor model approaches a new field RaytracerView/Config is necessary. Furthermore the OSI protobuf performance suffers because of data de-/serialization between GPU and CPU. Additionally the new RaytracerView/Config should be able to keep the raytracer output on the GPU and/or on the CPU..
Describe the solution you would like
A RaytracerView/Config is implemented and only pointers are exchanged via OSI messages.
Describe alternatives you have considered
Describe the backwards compatibility
The new feature is completly backward compatible, because a new field is introduced.
Additional context