gazebo-classic:scpeters/lens_flare_light_name

Last commit made on 2023-03-21
Get this branch:
git clone -b scpeters/lens_flare_light_name https://git.launchpad.net/gazebo-classic

Branch merges

Branch information

Name:
scpeters/lens_flare_light_name
Repository:
lp:gazebo-classic

Recent commits

4bf7d53... by Steve Peters <email address hidden>

Add spot light example to lensflare_plugin.world

Signed-off-by: Steve Peters <email address hidden>

ca6eedc... by Terry Welsh <email address hidden>

Only try to use the named lens flare light, if there is one. Otherwise, try to use the first directional light.

079fd3c... by Terry Welsh <email address hidden>

Allow user to name a specific light that will generate lens flare.

ba78508... by Silvio Traversaro <email address hidden>

Fix Instance() method of Singleton classes (#3269)

In particular, make sure that all the Instance() methods
of the same class always use the same instantiation.
Add detailed documentation on SingletonT.

e1f7f1f... by Terry Welsh <email address hidden>

Improvements to WideAngleCamera LensFlare bug fix (#3296)

* Reverse extraneous z-up to y-up transform that was corrupting
  WideAngleCamera LensFlare results. Fixed small related bugs.

* Use fisheye cameras in lensflare_wideangle_cam.world to
  improve testing of lens flare.

953badb... by Sanjuksha Nirgude <email address hidden>

Fix wide-angle camera lensflare occlusion (#3276)

* Fixing Z check in WideAngleCamera::Project3d

Signed-off-by: Sanjuksha Nirgude <email address hidden>

Added a test case for wideangle camera lensflare

Signed-off-by: Aditya <email address hidden>

Add extra model in test world

The pre-existing model in the test world exhibits
the lens flare rendering bug without the fix in
this branch, so I added an extra model at a different
pose that does not exhibit the bug. It makes it
easier to confirm that the bug is fixed.

* Add extra cameras with occluded views
* Add another camera with box to its side that
  is incorrectly occluded

Signed-off-by: Steve Peters <email address hidden>

08f01aa... by =?utf-8?q?Ond=C5=99ej_Svoboda?= <email address hidden>

Fix template specialization in constructors (#3295)

Fixes #3177.

86105ad... by Audrow Nash <email address hidden>

Set initial sim time from the command-line (#3294)

Signed-off-by: Audrow Nash <email address hidden>
Signed-off-by: Steve Peters <email address hidden>
Co-authored-by: Steve Peters <email address hidden>

cc87a67... by Silvio Traversaro <email address hidden>

Fix conda-forge GitHub Action CI by using mambaforge directly and by supporting graphviz >= 3 on Windows (#3287)

The fix is composed by two unrelated changes

### [Fix conda-forge GitHub Action CI by using mambaforge directly](https://github.com/gazebosim/gazebo-classic/commit/eea77c2d831763f6123b30e2b1a910b98205189a)

Currently the CI is failing on Linux and Windows with a weird conflict error. This is due to the fact that we are install mamba (from the conda-forge channel) on the top of miniconda3 (that by default install all the packages from the defaults channel). To make an analogy in apt world, this is like installing Debian, and then trying to install packages from the Ubuntu repo: something can go wrong.

To solve this problem, we install [mambaforge](https://github.com/conda-forge/miniforge) (a installer like miniconda3 but already using conda-forge packages) directly, so we always and only use packages from the conda-forge channel.

Similar to:
* https://github.com/robotology/robotology-superbuild/pull/840
* https://github.com/robotology/robometry/pull/141
* https://github.com/robotology-playground/yarp-devices-ros2/pull/44

### [Add support to use graphviz >= 3 on Windows](https://github.com/gazebosim/gazebo-classic/commit/15435b1520b7fbe041cb79c5f57829ab028eb5dc)

Since graphviz 3, any downstream library that on Windows links against a graphviz shared library needs to define the `GVDLL` preprocessor definition (see https://gitlab.com/graphviz/graphviz/-/blob/3.0.0/CHANGELOG.md#changed).

To deal with this, this PR adds the `GVDLL` definition for `gazebo_gui` when on Windows (on graphviz < 3 defining this definition will be harmless). As that prepocessor definition should not be set when linking static graphviz, and given that we can't detect in `FindGraphviz` if the linked graphviz is static or not, an ad-hoc CMake variable `GAZEBO_FINDGRAPHVIZ_USE_STATIC_GRAPHVIZ` is introduced in the case this definition needs to be disabled.

Similar to https://github.com/robotology/ycm/pull/414 .

c70761f... by Audrow Nash <email address hidden>

Fix typo in README (#3291)

Signed-off-by: Audrow Nash <email address hidden>