Michael Carroll

> homebrew is not happy? there're quite a few test failures. I'm assuming this is also because it's targeting main? I will change this to draft until I can confirm...

So not something that needs to be addressed here, but I believe that adding and removing components is relatively expensive (compared to setting/unsetting them) as they can incur allocation/deallocation as...

> That could make sense if it makes a significant performance improvement. I don't have a good gauge of the impact. I'm going to assume that not allocating/bookkeeping are always...

as a followup on the performance side of things, the concept of "optional components" was mostly added already: https://github.com/gazebosim/gz-sim/issues/1334#issuecomment-1036570727 So that is one less thing to worry about here.

In general, I believe that our sensor systems are guarded with logic like this: https://github.com/gazebosim/gz-sim/blob/c158287d6f8556112d86d6e4188c39784364bd40/src/systems/imu/Imu.cc#L154-L166 There has been discussion of a set of system callbacks that could fire at particular...

Good catch, I think your rewording makes sense. > What is "entity and component updates coming from the server"? In this case, the entity and component updates are coming from...

@mjcarroll to try to reproduce on linux

I'm not sure if this is gui or sim. @azeey additionally reports that this happens back to fortress.

> Also I think it would've been better if you had created the issue in the [gz-sensors](https://github.com/gazebosim/gz-sensors) project so that it would reach the experts for sensor implementations directly wink...

In addition to what @Bi0T1N said above, from a rendering perspective, the actual implementation changes that will be needed are: The underlying gz::rendering::Ogre2GpuRays sensor will need to be adjusted to...