Structural cleanup

Author: jankrassnigg

pages/docs/custom-code/visual-script/visual-script-class-asset.md

@@ -133,7 +133,7 @@ Loops are often used together with arrays. Various array operations such as `Pus
 
 ## Node Types
 
-Visual scripts provide a wide variety of node types for different operations. For detailed documentation on each node category, see the [Visual Script Node Reference](nodes/index.md).
+Visual scripts provide a wide variety of node types for different operations. For detailed documentation on each node category, see the [Visual Script Node Reference](nodes/vscript-node-reference.md).
 
 ### Quick Reference
 

pages/docs/effects/decals/decals-overview.md

@@ -0,0 +1,14 @@
+# Decals Overview
+
+Decals are a way to project textures onto surfaces in your scene. They're useful for adding detail like dirt, scratches, bullet holes, or other surface imperfections without modifying the underlying geometry.
+
+## Decal Types
+
+EZ provides different types of decals for various use cases:
+
+* **[Decals](decals.md)** - Standard projected decals
+* **[Mesh Decals](mesh-decals.md)** - Decals that use mesh geometry
+
+## See Also
+
+* [Render Pipeline](../../graphics/render-pipeline/render-pipeline-overview.md)

pages/docs/effects/decals.md pages/docs/effects/decals/decals.mdpages/docs/effects/decals.md renamed to pages/docs/effects/decals/decals.md

@@ -1,6 +1,6 @@
 # Decals
 
-![Decals](media/decals-overview.jpg)
+![Decals](../media/decals-overview.jpg)
 
 *Decals* are textures that are projected onto the underlying geometry. Decals can be used to to apply text and other signs to geometry. The most common use-case, though, is to make scenes look more natural by simulating wear and tear, such as dirt and scratches. Decals can also be used to simulate dynamic surface imperfections like bullet holes, soot and blood spatters.
 
@@ -10,7 +10,7 @@
 
 ## Decal Asset
 
-Before being able to place a *decal component*, you must create a decal [asset](../assets/assets-overview.md).
+Before being able to place a *decal component*, you must create a decal [asset](../../assets/assets-overview.md).
 
 ### Decal Asset Properties
 
@@ -38,7 +38,7 @@ Each *decal component* represents a single instance of a decal. Its position, ro
 
 **Extents:** The size of the decal along each axis.
 
-**SizeVariance:** If this value is non-zero, the decal's *Extents* will be randomized between `Extents - Extents*Variance` and `Extents + Extents*Variance` using a Normal Distribution. See [Variance Values](particle-effects/particle-effects-overview.md#variance-values).
+**SizeVariance:** If this value is non-zero, the decal's *Extents* will be randomized between `Extents - Extents*Variance` and `Extents + Extents*Variance` using a Normal Distribution. See [Variance Values](../particle-effects/particle-effects-overview.md#variance-values).
 
 **Color:** A tint color for the decal.
 
@@ -65,4 +65,4 @@ In addition to projected decals, there are also [mesh decals](mesh-decals.md). M
 
 ## See Also
 
-* [Particle Effects](particle-effects/particle-effects-overview.md)
+* [Particle Effects](../particle-effects/particle-effects-overview.md)

pages/docs/effects/mesh-decals.md pages/docs/effects/decals/mesh-decals.mdpages/docs/effects/mesh-decals.md renamed to pages/docs/effects/decals/mesh-decals.md

@@ -2,7 +2,7 @@
 
 *Mesh decals* (also called *floaters*) are a different approach to decals where the decal texture is mapped directly onto mesh geometry rather than being projected. This technique is useful for adding surface detail to meshes like dirt, scratches, or markings that need to follow the mesh topology precisely.
 
-![Mesh Decals](media/mesh-decals.jpg)
+![Mesh Decals](../media/mesh-decals.jpg)
 
 Unlike regular [decals](decals.md) which project a texture onto geometry, mesh decals:
 
@@ -12,7 +12,7 @@ Unlike regular [decals](decals.md) which project a texture onto geometry, mesh d
 
 ## Mesh Decal Component
 
-Add a *Mesh Decal Component* to a game object that has a [mesh component](../graphics/meshes/mesh-component.md). The component manages decal textures and communicates with the runtime decal atlas.
+Add a *Mesh Decal Component* to a game object that has a [mesh component](../../graphics/meshes/mesh-component.md). The component manages decal textures and communicates with the runtime decal atlas.
 
 ### Component Properties
 
@@ -44,4 +44,4 @@ The `DepthBias` material parameter (default: 1.0) controls how far the decal geo
 ## See Also
 
 * [Decals](decals.md)
-* [Meshes](../graphics/meshes/meshes-overview.md)
+* [Meshes](../../graphics/meshes/meshes-overview.md)

pages/docs/effects/particle-effects/behaviors/pb-bounds.md

@@ -7,7 +7,7 @@ This behavior can be used for atmospheric effects that should be centered around
 **OutOfBoundsMode:** Defines what happens for particles that leave the bounding area.
 
 * **Die:** Particles outside the area will be killed right away.
-* **Teleport:** Particles leaving one side of the bounding box will be teleported to the other end of the box. This allows the effect to keep a constant density of particles and is therefore useful for effects that should happen around a player, without being simulated completely in the local space of the player, which would prevent things like using the [raycast behavior](pb-raycast.md). Instead, particles can simulate in global space, and only be teleported on demand. Be aware that this teleportation can still break the effect in various ways, because only the *position* and *last position* of each particle is relocated. Behaviors and [particle renderers](../../particle-renderers.md) that use additional positional data may not work well with this. For example, the [trail renderer's](../particle-renderers.md#trail-renderer) position history is not relocated and therefore trails will suddenly stretch through the entire bounding area after a relocation.
+* **Teleport:** Particles leaving one side of the bounding box will be teleported to the other end of the box. This allows the effect to keep a constant density of particles and is therefore useful for effects that should happen around a player, without being simulated completely in the local space of the player, which would prevent things like using the [raycast behavior](pb-raycast.md). Instead, particles can simulate in global space, and only be teleported on demand. Be aware that this teleportation can still break the effect in various ways, because only the *position* and *last position* of each particle is relocated. Behaviors and [particle renderers](../particle-renderers.md) that use additional positional data may not work well with this. For example, the [trail renderer's](../particle-renderers.md#trail-renderer) position history is not relocated and therefore trails will suddenly stretch through the entire bounding area after a relocation.
 Similarly, an effect that uses the [raycast behavior](pb-raycast.md) to prevent tunneling through geometry, may be able to tunnel through walls, if it is being relocated from an unobstructed area to a position where it should not have been able to get to without the teleportation.
 
 ## See Also

pages/docs/effects/particle-effects/behaviors/pb-velocity.md

@@ -1,6 +1,6 @@
 # Velocity Behavior
 
-This behavior affects particle position and velocity. It can be used to gradually dampen the starting velocity through 'friction' and it may apply a constant upwards movement. If a scene contains [wind](../wind/wind.md), this behavior can also apply a fraction of the wind force to the particle's position.
+This behavior affects particle position and velocity. It can be used to gradually dampen the starting velocity through 'friction' and it may apply a constant upwards movement. If a scene contains [wind](../../wind/wind-overview.md), this behavior can also apply a fraction of the wind force to the particle's position.
 
 **RiseSpeed:** If non-zero, the particles will move upwards with at least this constant speed. This is added to the particle position independent from its velocity, so if the current velocity points downward, the two may cancel each other out.
 

pages/docs/effects/particle-effects/particle-effect-component.md

@@ -17,7 +17,7 @@ The *particle effect component* is used to instantiate and control particle effe
 
 **RandomSeed:** If set to zero, the effect will use random values and look slightly different every time. If set to any other value, the effect will look identical every time it is restarted.
 
-**SpawnDirection:** The direction along which the effect should be spawned (in local space). The default is 'positive Z' which means 'up', but to align this with other things, such as [decals](../decals.md) or [lights](../../graphics/lighting/lighting-overview.md), it can be useful to use a different axis. Note that interactions with [surfaces](../../materials/surfaces.md) (e.g. an impact effect that is spawned when a bullet hits a wall) are always spawned such that the spawned prefab's positive X axis aligns with the surface interaction axis (e.g. it's normal). For such cases it therefore makes sense to spawn a particle effect along 'positive X'.
+**SpawnDirection:** The direction along which the effect should be spawned (in local space). The default is 'positive Z' which means 'up', but to align this with other things, such as [decals](../decals/decals.md) or [lights](../../graphics/lighting/lighting-overview.md), it can be useful to use a different axis. Note that interactions with [surfaces](../../materials/surfaces.md) (e.g. an impact effect that is spawned when a bullet hits a wall) are always spawned such that the spawned prefab's positive X axis aligns with the surface interaction axis (e.g. it's normal). For such cases it therefore makes sense to spawn a particle effect along 'positive X'.
 
 **IgnoreOwnerRotation:** By default the *SpawnDirection* is local to the owning game object, meaning when the owning object is tipped over, the effect will also spawn sideways. For some effects it can be desireable to ignore the rotation of the owner, and always spawn in *global space*, though. For instance, when an effect has a strong directionality, such as debris flying away in a cone, it may look best when it is always spawned upwards.
 

pages/docs/effects/particle-effects/particle-effects-overview.md

@@ -88,7 +88,7 @@ You can use this in a static way, as a means to add more variety to multiple ins
 
 ## Events and Event Reactions
 
-Particles may raise *events*. The most common one is when a particle dies, but different particle behaviors can raise other events as well. For example when a particle collides with the environment (see [raycast behavior](particle-behaviors.md#raycast-behavior)).
+Particles may raise *events*. The most common one is when a particle dies, but different particle behaviors can raise other events as well. For example when a particle collides with the environment (see [raycast behavior](behaviors/pb-raycast.md)).
 
 The **Event Reactions** tab allows you to configure what happens for a specific event. This is mostly used to chain effects. For example the fireworks effect below has particles that represent the rockets flying up, and when one 'dies', an explosion is spawned at that position, using event reactions.
 
@@ -130,19 +130,19 @@ When enabling **SimulateInLocalSpace** in the *Effect tab*, the effect is simula
 
 <video src="media/sim-local-space.webm" width="500" height="500" autoplay loop></video>
 
-Some behaviors won't properly work for effects that are simulated in local space. For example the [raycast behavior](particle-behaviors.md#raycast-behavior) will do it's raycasts at the origin of the scene, rendering it pointless.
+Some behaviors won't properly work for effects that are simulated in local space. For example the [raycast behavior](behaviors/pb-raycast.md) will do it's raycasts at the origin of the scene, rendering it pointless.
 
 There is no performance benefit to using local space simulation. However, when using [shared effects](#shared-effects), the shared state must be simulated in local space.
 
-Other options to keep particles closer to the owning object are to use the [pull along behavior](particle-behaviors.md#pull-along-behavior) or to [inherit the owner velocity](#owner-velocity-inheritance).
+Other options to keep particles closer to the owning object are to use the [pull along behavior](behaviors/pb-pull-along.md) or to [inherit the owner velocity](#owner-velocity-inheritance).
 
 ### Owner Velocity Inheritance
 
 In the *Effect tab* there is a property **ApplyOwnerVelocity** which is a value between `0` and `1`. By default the value is zero, which means that all particles are initialized with either a zero velocity or with whatever some [initializer](particle-initializers.md) decided. In that case, particles will fly away from the emitter position unaffected by the velocity of the effect object itself. However, if the value is set to non-zero, a part of the velocity of the owning game object will be added to newly spawned particles.
 
-This can be used for effects that may be spawned from moving objects and that shall retain some of that momentum. However, unless you additionally configure the effect to have some velocity damping (ie. using the *friction* property of the [velocity behavior](particle-behaviors.md#velocity-behavior)), the particles will fly into that direction continuously, which may look weird, especially when the owner object changes direction or brakes, and the spawned particles overtake it.
+This can be used for effects that may be spawned from moving objects and that shall retain some of that momentum. However, unless you additionally configure the effect to have some velocity damping (ie. using the *friction* property of the [velocity behavior](behaviors/pb-velocity.md)), the particles will fly into that direction continuously, which may look weird, especially when the owner object changes direction or brakes, and the spawned particles overtake it.
 
-Other options to keep particles closer to the owning object are to use the [pull along behavior](particle-behaviors.md#pull-along-behavior) or to fully [simulate in local space](#local-space-simulation).
+Other options to keep particles closer to the owning object are to use the [pull along behavior](behaviors/pb-pull-along.md) or to fully [simulate in local space](#local-space-simulation).
 
 ### Shared Effects
 

pages/docs/effects/particle-effects/particle-emitters.md

@@ -52,7 +52,7 @@ This emitter type spawns new particles whenever a specific [event](particle-effe
 
 **SpawnCountScaleParam:** See the [burst emitter](#burst-emitter).
 
-In the animation below, the blue particles use a [raycast behavior](particle-behaviors.md#raycast-behavior) to get removed when a collision is detected. The behavior also sends an *event*. This is picked up by a second particle system, which then spawns a number of red particles.
+In the animation below, the blue particles use a [raycast behavior](behaviors/pb-raycast.md) to get removed when a collision is detected. The behavior also sends an *event*. This is picked up by a second particle system, which then spawns a number of red particles.
 
 <video src="media/onevent-emitter.webm" width="500" height="500" autoplay loop></video>
 

pages/docs/materials/surfaces.md

@@ -38,7 +38,7 @@ Interactions are triggered by different systems. The [physics engine](../physics
 
 ### Spawning Prefabs
 
-All surface interactions ultimately spawn [prefabs](../prefabs/prefabs-overview.md). So if you want to have different footstep sounds when walking over stone, sand and mud, you need three prefabs, each playing a different sound. However, since they are prefabs, your creativity is not limited to playing a sound. Your "sand footstep effect" may contain spawning a small dust [particle effect](../effects/particle-effects/particle-effects-overview.md). And the "mud footstep effect" could additionally spawn a footprint [decal](../effects/decals.md).
+All surface interactions ultimately spawn [prefabs](../prefabs/prefabs-overview.md). So if you want to have different footstep sounds when walking over stone, sand and mud, you need three prefabs, each playing a different sound. However, since they are prefabs, your creativity is not limited to playing a sound. Your "sand footstep effect" may contain spawning a small dust [particle effect](../effects/particle-effects/particle-effects-overview.md). And the "mud footstep effect" could additionally spawn a footprint [decal](../effects/decals/decals.md).
 
 The following options allow you to adjust how prefabs are spawned: