Animations are very dim due to illumination not changing

[PeterJCLaw]

One option might be to change the way we do the fade-up at the start.

Here's some fudging I applied for SR2023 which makes the animations more usable:

sed -i "s/exposure='1'/exposure='5'/" match-*.x3d
sed -i "s/intensity='0.2'/intensity='0.8'/" match-*.x3d
sed -i "s/luminosity='0.05'/luminosity='0.25'/" match-*.x3d

sed -i 's/"1 1 1"/"50 50 50"/g' match-*.json

[PeterJCLaw]

Looking at the animation from the PR which moves to 2023b (https://github.com/srobo/competition-simulator/pull/401) https://github.com/srobo/competition-simulator/actions/runs/6059019794 this may no longer be an issue. Needs validating with a full length match and on hardware closer to what we'll use for the virtual competition.

[PeterJCLaw]

When I tested Webots 2023b (#401) I didn't actually hit this, so they may have fixed the issue. We should validate whether this is present in animations produced on any platform.

[PeterJCLaw]

Testing the animation files produced during testing for SR2024 (see #410) suggests that the only fix we need this year is:

sed -i "s/luminosity='0.05'/luminosity='1'/" match-*.x3d

I'm unclear whether this is due to changes made in our simulation, in Webots or something else.

While I'm happy that this is now simpler, it suggests that there isn't a simple solution we can just add to our match-running scripts to always have this work. Instead I think we may need to always consider this during manual testing & preparation for a virtual competition. Having a post-processing step for the animations files is obvious not as good as not having such a step, though while it's this simple to apply (i.e: a sed one-liner) it feels like there is little value in trying to fully automate it.