Ian Chen

The implementation of gpu_lidar with the default render engine in gz-sim (`ogre2`) is slightly different from gazebo-classic. The `` parameter plays a more important role in the accuracy of the...

> it appears that I can't switch the rendering engine for just this specific sensor - only for all sensors at once. Is that correct? yes that's correct > Suppose...

sure please go ahead!

that section of the code is located [here](https://github.com/gazebosim/gz-cmake/blob/3509305eadb60b9fc78e91595d9adafa18d525fc/doc/doxygen/header.html#L37-L46) in gz-cmake. Every gz packages runs gz-cmake's [gz_create_docs](https://github.com/gazebosim/gz-cmake/blob/3509305eadb60b9fc78e91595d9adafa18d525fc/cmake/GzCreateDocs.cmake#L25) cmake function to create these doc pages, e.g. gz-sensors [gz_create_docs](https://github.com/gazebosim/gz-sensors/blob/810409d5fdcfc0cb0bf80f1188c6c7ba1db8eccc/CMakeLists.txt#L107-L110) call. To locally test...

yep that sounds good. Since this changes the return type, I think it may not be trivial to deprecate the existing `Subscribe` functions and go through a tick-tock cycle. So...

for me, I would expect 2. to happen. The functionality of `Node::Unsubscribe(const std::string &_topic)` will remain the same, which is that it will remove all subscriptions, use cases: ```cpp bool...

Ran into a long start up time issue with the Jetty demo world and narrowed it down to model sdf deserialization: https://github.com/gazebosim/jetty_demo/issues/3 This issue pretty much sums up the problem.

> We should really skip serializing models altogether. I tested this and the jetty demo world load time reduced from 55s to 42s on my (old) machine. Most importantly, hitting...

here's a draft PR for testing: https://github.com/gazebosim/gz-sim/pull/3070

https://github.com/gazebosim/gz-rendering/pull/1126 disables a couple of tests on `main` for now