Docs: fix some minor doxygen warnings

Components/Overlay/include/OgreOverlay.h

@@ -166,7 +166,7 @@ namespace Ogre {
             HUD, then you would create 2 overlays, one with a 3D object attached for the
             cockpit, and one with the HUD elements attached (the zorder of the HUD 
             overlay would be higher than the cockpit to ensure it was always on top).
-        @par    
+
             A SceneNode can have any number of 3D objects attached to it. SceneNodes
             are usually created using SceneManager::createSceneNode, but in this case
             you should create a standard SceneNode instance <b>manually</b>; this is

Docs/src/instancing.md

@@ -320,7 +320,7 @@ Do it sparingly and profile the optimal frequency of calling.
 @par Q: My mesh doesn't show up.
 A: Verify you're using the right material, the vertex shader is set correctly, and it matches the instancing technique being used.
 
-@par Q: My animation plays quite differently than when it is an Entity, or previewed in [Ogre Mesh Viewer](https://github.com/OGRECave/ogre-meshviewer).
+@par Q: My animation plays quite differently than when it is an Entity, or previewed in Ogre Mesh Viewer.
 A: Your rig animation must be using more than one weight per bone.
 You need to add support for it in the vertex shader, and make sure you didn't create the instance manager with the flags Ogre::IM_USEONEWEIGHT or Ogre::IM_FORCEONEWEIGHT.
 

Docs/src/manual.md

@@ -754,8 +754,6 @@ So clearly, when you use additive light masking as a shadow technique, you need
 
 Note that if you’re using texture shadows you have the additional option of using @ref Integrated-Texture-Shadows rather than being forced to use this explicit sequence - allowing you to compress the number of passes into a much smaller number at the expense of defining an upper number of shadow casting lights. In this case the ’additive’ aspect of the shadow technique just affects the colour of the shadow texture and it’s up to you to combine the shadow textures in your receivers however you like.
 
-<a name="Static-Lighting"></a>
-
 ## Static Lighting {#Static-Lighting}
 
 Despite their power, additive lighting techniques have an additional limitation; they do not combine well with pre-calculated static lighting in the scene. This is because they are based on the principle that shadow is an absence of light, but since static lighting in the scene already includes areas of light and shadow, additive lighting cannot remove light to create new shadows. Therefore, if you use the additive lighting technique you must either use it exclusively as your lighting solution (and you can combine it with per-pixel lighting to create a very impressive dynamic lighting solution), or you must use @ref Integrated-Texture-Shadows to combine the static lighting according to your chosen approach.

Docs/src/tutorials/deferred.md

@@ -129,7 +129,7 @@ Using tools like [RenderDoc](https://renderdoc.org/), we can see the texture bei
 
 Note that nothing has been written to the final output yet and that two output textures are being written to (see right hand side).
 
-# Lighting the scene {#lighting}
+# Lighting the scene
 In the GBuffer compositor, we built the G-Buffer for the current frame. It is now the time to use it to calculate the final lighting of the scene. This is what the compositor looks like :
 
 @snippet Samples/Media/DeferredShadingMedia/deferred.compositor showlit

OgreMain/include/OgreVertexIndexData.h

@@ -167,7 +167,7 @@ namespace Ogre {
             This 'w' component cannot be included in the original position buffer because
             DirectX does not allow 4-component positions in the fixed-function pipeline, and the original
             position buffer must still be usable for fixed-function rendering.
-        @par    
+
             Note that we don't store any vertex declaration or vertex buffer binding here because this
             can be reused in the shadow algorithm.
         */