fix links

docs/modules/contributions/pages/ai/jme3_ai.adoc

@@ -33,7 +33,7 @@ The jme3 Artificial Intelligence Library contains:
 
 [NOTE]
 ====
-This scope of this tutorial is restricted to the NavMesh part of the library and expands upon the lessons taught in the xref:jme3#tutorials-for-beginners,tutorials]. It demonstrates the use of some classes and methods found in the Medium and Advanced topics of the wiki as well. You can find the source code for this tutorial in the  link:https://github.com/jMonkeyEngine/doc-examples/tree/master/src/com/jme3/examples/jme3ai[jMonkeyEngine/docs-examples] repository.
+This scope of this tutorial is restricted to the NavMesh part of the library and expands upon the lessons taught in the xref:tutorials:beginner/beginner.adoc[tutorials]. It demonstrates the use of some classes and methods found in the Medium and Advanced topics of the wiki as well. You can find the source code for this tutorial in the  link:https://github.com/jMonkeyEngine/doc-examples/tree/master/src/com/jme3/examples/jme3ai[jMonkeyEngine/docs-examples] repository.
 ====
 
 Moving a character through your scene requires three things.

docs/modules/contributions/pages/lanscapes/vegetationsystem/grass.adoc

@@ -40,7 +40,7 @@ There is a tutorial on how to work with alpha textures and transparency here: xr
 
 Materials have something called additional renderstate options. They can be found in the material editor. When rendering grass, you usually want to look at these settings:
 
-*FaceCull:* When using fixed quads it should be set to “Off. This means both sides of the quads will be rendered. When using billboarded grass, you can cull the back side, because it never faces the camera.
+*FaceCull:* When using fixed quads it should be set to "`Off`". This means both sides of the quads will be rendered. When using billboarded grass, you can cull the back side, because it never faces the camera.
 
 *Blending mode:* With grass you'd normally be using *Alpha*. The *AlphaTestFallof* parameter should also be set, but the value to use depends a lot on the texture. It may be worth trying a few different values.
 
@@ -62,6 +62,6 @@ renderer.setAlphaToCoverage(true);
 
 There's an example in the Forester test project that shows how you enable it, and how you use it in Forester.
 
-Alpha to coverage works through multi-sampling, and you have to use 4xMSAA in order for it to work. It is a fairly new technique and may not be supported on older graphics-cards. It is also implemented differently by different vendors, and while some cards “technically support it, it may not work as intended. This means it's always a good idea to provide an alternative to AtoC in your apps/games.
+Alpha to coverage works through multi-sampling, and you have to use 4xMSAA in order for it to work. It is a fairly new technique and may not be supported on older graphics-cards. It is also implemented differently by different vendors, and while some cards "`technically`" support it, it may not work as intended. This means it's always a good idea to provide an alternative to AtoC in your apps/games.
 
 link:http://en.wikipedia.org/wiki/Alpha_to_coverage[http://en.wikipedia.org/wiki/Alpha_to_coverage]

docs/modules/contributions/pages/lanscapes/vegetationsystem/trees.adoc

@@ -44,13 +44,13 @@ When a model is supplied to a tree-layer, and physics is enabled, the model will
 
 The reason for this is that the trees are lumped together in a process called geometry-batching. It is commonly used to reduce the number of drawing-calls for groups of objects that are very similar.
 
-What this means in practice is that your model is not just duplicated and spread out across the scene, they are in fact baked together into one single mesh (per “block). This process is also used for collision shapes. They are all compounded into one large collision shape, then added to this newly created clump of vertices. Basically.
+What this means in practice is that your model is not just duplicated and spread out across the scene, they are in fact baked together into one single mesh (per "`block`"). This process is also used for collision shapes. They are all compounded into one large collision shape, then added to this newly created clump of vertices. Basically.
 
 *In short* - there are a couple of instances when the collision physics system may fail:
 
 - If you do not supply a physics space to the forester, no physics will be enabled.
 
-- If you do not check “true for enable physics when creating the tree-layer.
+- If you do not check "`true`" for enable physics when creating the tree-layer.
 
 - If you do not supply a collision mesh to the model.
 

docs/modules/contributions/pages/lanscapes/vegetationsystem/vegetationsystem.adoc

@@ -1,10 +1,6 @@
 = The Forester
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
+:revnumber: 2.0
+:revdate: 2020/07/25
 
 
 This is the wiki page for the Forester grass/tree loading system. It contains information on how to add vegetation to a scene, and how to manage it. Grass and trees are treated differently, but the approaches are very similar.
@@ -15,19 +11,19 @@ The library can be found in the Github link:https://github.com/jMonkeyEngine-Con
 
 == The Forester (Basic)
 
-The Forester class is the root class of this lib. You can use it to create grass/treeloaders, and a few other things. It also manages random number tables and a few other things. 
+The Forester class is the root class of this lib. You can use it to create grass/treeloaders, and a few other things. It also manages random number tables and a few other things.
 
 It is a singleton class, so it can be used anywhere for easy access to Forester data.
 
 
 == The grass
 
-Proceed to the grass section: <<jme3/contributions/vegetationsystem/grass#,jme3:contributions:vegetationsystem:grass>>
+Proceed to the grass section: xref:lanscapes/vegetationsystem/grass.adoc[contributions:vegetationsystem:grass]
 
 
 == The trees
 
-Proceed to the tree section: <<jme3/contributions/vegetationsystem/trees#,jme3:contributions:vegetationsystem:trees>>
+Proceed to the tree section: xref:lanscapes/vegetationsystem/trees.adoc[contributions:vegetationsystem:trees]
 
 
 == Tuning the paging engine (Advanced)
@@ -37,9 +33,9 @@ All tree/grassloaders use a paging engine to load/unload data. There are some th
 
 === Manipulating the cache
 
-The cache saves expired tiles for some time before disposing of them. This makes it possible for the engine to re-use pages instead of having to load and prepare them again. 
+The cache saves expired tiles for some time before disposing of them. This makes it possible for the engine to re-use pages instead of having to load and prepare them again.
 
-An example: Lets say you walk across the border between two tiles. Passing the border between two tiles prompts the engine to load new tiles in the direction you are moving, and toss old ones away. Lets say you then walk back directly. Or keep walking back and forth across that border. Without the cache, you'd be loading and unloading tiles all the time. 
+An example: Lets say you walk across the border between two tiles. Passing the border between two tiles prompts the engine to load new tiles in the direction you are moving, and toss old ones away. Lets say you then walk back directly. Or keep walking back and forth across that border. Without the cache, you'd be loading and unloading tiles all the time.
 
 There is no point in turning it off, unless maybe if you use extremely small tiles. You can change the cache timer however. Default time is 2 seconds (2000 ms actually, the value is in ms). After 2 seconds the tiles are dropped from the cache.
 
@@ -64,7 +60,7 @@ Having few but large geometries is more efficient when rendering, however. That
 
 Having many geometries, on the other side, ensures more geometry is culled on average. If you use one mega-block of 512x512 square units, you'd have to render the entire block even if you can only see a tiny fraction of it. Also, when massive blocks are pushed in and out of the rendering queue you might get noticeable increases/drops in frame-rate.
 
-It is very hard to say what is the correct resolution in an application, because it depends on very much, but it is possible to try a few different settings and see which is best. This may have an effect on performance; particularly if you're using massive amounts of grass. 
+It is very hard to say what is the correct resolution in an application, because it depends on very much, but it is possible to try a few different settings and see which is best. This may have an effect on performance; particularly if you're using massive amounts of grass.
 
 
 [TIP]

docs/modules/contributions/pages/tools/charts.adoc

@@ -4,13 +4,13 @@
 :revdate: 2020/07/15
 
 
-Previous: xref:jme3/tools/navigation.adoc[Navigation]
+Previous: xref:tools/navigation.adoc[Navigation]
 
 In this tutorial we will have a look at creating a simple 3D cartography application that allows you to display 3D charts at different zoom levels.
 
 This tutorial assumes that you know:
 
-*  About the xref:jme3/tools/navigation.adoc[Navigation package].
+*  About the xref:tools/navigation.adoc[Navigation package].
 *  How to create a xref:tutorials:beginner/hello_terrain.adoc[3D landscape] using image-based heightmaps.
 
 image:tools/mercator_grid_3d_small.png[mercator_grid_3d_small.png,width="",height=""]
@@ -37,9 +37,9 @@ applyDefaultTexture();
 
 image:tools/globe.png[A 256x256 mercator projection of planet earth.,width="",height=""]
 
-In essence, 3D chart visualization is achieved by converting the polygons composing planet earth's landmass into float matrices whereby each value within the matrix represents a specific terrain height. For example, given a terrain of 100 x 100 world units, we construct a heightmap by creating a 100 x 100 matrix. Each cell within the matrix corresponds to a terrain coordinate; each cell’s value to that coordinate’s desired height. But you already knew that, so where's the tricky part? Well, when visualizing a chart an accurate projection requires a translation of latitude/longitude coordinates into their equivalent world unit (x,y,z) counterparts. This translation however is not a straight forward mapping of one coordinate system into the other due to the distortion arising from projecting an oblate spheroid onto a flat surface (see my previous wiki article xref:jme3/tools/navigation.adoc[here]). This means that if one would adhere to a linear scale, the Mercator projection would distort the size and shape of objects as the object distances itself from the equator, eventually resulting in infinite scaling as the pole is reached. So the first task at hand, is to construct accurate 2D projections of planet earth which we can then use as heightmaps. We can achieve this using the jme3.tools.navigation package and co-ordinate sets available at link:https://maps.ngdc.noaa.gov/viewers/geophysics/[noaa.gov].
+In essence, 3D chart visualization is achieved by converting the polygons composing planet earth's landmass into float matrices whereby each value within the matrix represents a specific terrain height. For example, given a terrain of 100 x 100 world units, we construct a heightmap by creating a 100 x 100 matrix. Each cell within the matrix corresponds to a terrain coordinate; each cell’s value to that coordinate’s desired height. But you already knew that, so where's the tricky part? Well, when visualizing a chart an accurate projection requires a translation of latitude/longitude coordinates into their equivalent world unit (x,y,z) counterparts. This translation however is not a straight forward mapping of one coordinate system into the other due to the distortion arising from projecting an oblate spheroid onto a flat surface (see my previous wiki article xref:tools/navigation.adoc[here]). This means that if one would adhere to a linear scale, the Mercator projection would distort the size and shape of objects as the object distances itself from the equator, eventually resulting in infinite scaling as the pole is reached. So the first task at hand, is to construct accurate 2D projections of planet earth which we can then use as heightmaps. We can achieve this using the jme3.tools.navigation package and co-ordinate sets available at link:https://maps.ngdc.noaa.gov/viewers/geophysics/[noaa.gov].
 
-As xref:jme3/tools/navigation.adoc[previously discussed], the distortion in latitude is derived by using the difference in meridional parts between the chart’s centre and the current position as a baseline; through converting the difference to world units by dividing it by the number of world units contained within one minute, a latitude’s y-coordinate can be obtained. Calculating a position’s x-coordinate is somewhat easier as the distortion only applies to latitude, not longitude. Therefore x merely equals the sum or difference between itself and the viewport’s centre coordinate, depending on the relative location of the position itself and the chart’s centre. Despite being able to convert between the two coordinate systems, slight precision problems remain once the chart projection is scaled down past a level of 6 meters. This is caused by the pixel referencing system of modern displays being integer based; once the ratio of minutes to pixels exceeds the aforementioned threshold, slight inaccuracies are introduced into the display. However this is of little relevance to most GIS (such as Debrief) as a) the inaccuracies are a matter of meters (or even centimetres) and b) it is impossible to notice this variation as GPS exposes a much higher inaccuracy (between 10 - 100 meters).
+As xref:tools/navigation.adoc[previously discussed], the distortion in latitude is derived by using the difference in meridional parts between the chart’s centre and the current position as a baseline; through converting the difference to world units by dividing it by the number of world units contained within one minute, a latitude’s y-coordinate can be obtained. Calculating a position’s x-coordinate is somewhat easier as the distortion only applies to latitude, not longitude. Therefore x merely equals the sum or difference between itself and the viewport’s centre coordinate, depending on the relative location of the position itself and the chart’s centre. Despite being able to convert between the two coordinate systems, slight precision problems remain once the chart projection is scaled down past a level of 6 meters. This is caused by the pixel referencing system of modern displays being integer based; once the ratio of minutes to pixels exceeds the aforementioned threshold, slight inaccuracies are introduced into the display. However this is of little relevance to most GIS (such as Debrief) as a) the inaccuracies are a matter of meters (or even centimetres) and b) it is impossible to notice this variation as GPS exposes a much higher inaccuracy (between 10 - 100 meters).
 
 
 [TIP]

docs/modules/core/pages/effect/effects_overview.adoc

@@ -124,7 +124,7 @@ image:effect/light-scattering-filter.png[light-scattering-filter.png,width="150"
 
 === Vegetation
 
-*  Contribution: xref:jme3/contributions/vegetationsystem/grass.adoc[Grass System]
+*  Contribution: xref:contributions:lanscapes/vegetationsystem/grass.adoc[Grass System]
 *  Contribution: {uri-forum}t/generating-vegetation-paged-geometry-style/18928[Trees (WIP)]
 
 

docs/modules/tutorials/pages/beginner/hello_collision.adoc

@@ -554,6 +554,6 @@ You learned to speed up the physics calculations by using the CollisionShapeFact
 *See also:*
 
 *  How to load models and scenes: xref:beginner/hello_asset.adoc[Hello Asset], xref:sdk:scene_explorer.adoc[Scene Explorer], xref:sdk:scene_composer.adoc[Scene Composer].
-*  xref:ROOT:jme3/advanced/terrain_collision.adoc[Terrain Collision]
+*  xref:core:collision/terrain_collision.adoc[Terrain Collision]
 *  To learn more about complex physics scenes, where several mobile physical objects bump into each other, read xref:beginner/hello_physics.adoc[Hello Physics].
 *  FYI, there are simpler collision detection solutions without physics, too. Have a look at link:https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-examples/src/main/java/jme3test/collision/TestTriangleCollision.java[jme3test.collision.TestTriangleCollision.java].

docs/modules/tutorials/pages/beginner/hello_physics.adoc

@@ -1,7 +1,6 @@
 = jMonkeyEngine 3 Tutorial (13) - Hello Physics
-:author:
-:revnumber:
-:revdate: 2020/07/06
+:revnumber: 2.0
+:revdate: 2020/07/24
 :keywords: beginner, intro, physics, documentation, input, model, control
 
 
@@ -513,5 +512,5 @@ You have learned how to activate the jBullet PhysicsSpace in an application by a
 
 [TIP]
 ====
-Congratulations! – You have completed the last beginner tutorial. Now you are ready to start xref:ROOT:jme3.adoc[combining what you have learned], to create a cool 3D game of your own. Show us what you can do, and feel free to share your demos, game videos, and screenshots on the link:http://hub.jmonkeyengine.org/c/user-code-projects[User Code & Projects Forum]!
+Congratulations! – You have completed the last beginner tutorial. Now you are ready to start combining what you have learned, to create a cool 3D game of your own. Show us what you can do, and feel free to share your demos, game videos, and screenshots on the link:http://hub.jmonkeyengine.org/c/user-code-projects[User Code & Projects Forum]!
 ====

docs/modules/tutorials/pages/beginner/hello_terrain.adoc

@@ -408,7 +408,7 @@ For this exercise, you can keep using the splat Material from the sample code ab
 
 === Exercise 3: Solid Terrains
 
-Can you combine what you learned here and in xref:beginner/hello_collision.adoc[Hello Collision], and xref:ROOT:jme3/advanced/terrain_collision.adoc[make the terrain solid]?
+Can you combine what you learned here and in xref:beginner/hello_collision.adoc[Hello Collision], and xref:core:collision/terrain_collision.adoc[make the terrain solid]?
 
 
 == Conclusion
@@ -417,5 +417,5 @@ You have learned how to create terrains that are more efficient than loading one
 
 *See also:*
 
-*  xref:ROOT:jme3/advanced/terrain_collision.adoc[Terrain Collision]
+*  xref:core:collision/terrain_collision.adoc[Terrain Collision]
 *  xref:core:terrain/terrain.adoc[Advanced Terrain]

docs/modules/tutorials/pages/concepts/the_scene_graph.adoc

@@ -145,8 +145,6 @@ a| The rootNode, the guiNode, an audioNode, a custom grouping node for a vehicle
 
 Before you start creating your game, you should plan your scene graph: Which Nodes and Geometries will you need? Complete the xref:tutorials:beginner/beginner.adoc[Beginner tutorials] to learn how to load and create Spatials, how to lay out a scene by attaching, detaching, and transforming Spatials, and how to add interaction and effects to a game.
 
-//The <<jme3#documentation-for-intermediate-users#,intermediate and advanced documentation>> gives you more details on how to put all the parts together to create an awesome 3D game in Java!
-
 
 == See also