Merge pull request #70 from Vulwsztyn/amount_2_number

nitpick: change 'amount' to 'number' when thing is countable & some trailing spaces removed

src/beginning/assets.md

@@ -42,7 +42,7 @@ you'll also see a preview of the model.
 
 ![preview](preview.gif)
 
-The maximum amount of asset instances is not limited by the engine but it is by the memory and CPU resources of your PC. 
+The maximum number of asset instances is not limited by the engine but it is by the memory and CPU resources of your PC. 
 Note that the engine does try to reuse data across instances as much as possible.
 
 You can also instantiate assets dynamically from your code. Here's an example of that for a Model:

src/beginning/editor_overview.md

@@ -8,7 +8,7 @@ This chapter will guide you through the basics, advanced topics will be covered
 
 ## Windows
 
-When you open the editor for the first time you may be confused by the amount of windows, buttons, lists, etc. you'll be presented 
+When you open the editor for the first time you may be confused by the number of windows, buttons, lists, etc. you'll be presented 
 with. Each window serves a different purpose, but all of them work together to help you make your game. Let's take a look at a 
 screenshot of the editor and learn what each part of it is responsible for (please note that this can change over time, because
 development is quite fast and images can easily become outdated):

src/code/snippets/src/borrowck/mod.rs

@@ -32,7 +32,7 @@ impl ScriptTrait for MyScript {
         let some_other_node_ref = mbc.try_get_mut(self.some_other_node).unwrap();
         let yet_another_node_ref = mbc.try_get_mut(self.yet_another_node).unwrap();
 
-        // We can borrow the same node immutably pretty much infinite amount of times, if it wasn't
+        // We can borrow the same node immutably pretty much infinite number of times, if it wasn't
         // borrowed mutably.
         let some_node_ref_2 = mbc.try_get(self.some_node).unwrap();
     }

src/code/snippets/src/scene/mesh.rs

@@ -68,7 +68,7 @@ fn create_procedural_mesh(scene: &mut Scene, resource_manager: ResourceManager)
     .with_surfaces(vec![SurfaceBuilder::new(SurfaceResource::new_ok(
         ResourceKind::Embedded,
         // Our procedural mesh will have a form of squashed cube.
-        // A mesh can have unlimited amount of surfaces.
+        // A mesh can have unlimited number of surfaces.
         SurfaceData::make_cube(Matrix4::new_nonuniform_scaling(&Vector3::new(
             25.0, 0.25, 25.0,
         ))),

src/editor/plugins.md

@@ -78,7 +78,7 @@ approach for visualization is just a custom structure with a few methods:
 ```
 
 `sync_to_model` method can be called on every frame in `update` method of the interaction mode (see below) - it tracks 
-the amount of scene nodes representing points of the line and if there's mismatch, it recreates the entire set. 
+the number of scene nodes representing points of the line and if there's mismatch, it recreates the entire set. 
 `remove_points` should be used when the gizmo is about to be deleted (usually together with the interaction mode).
 
 All interaction with scene nodes should be performed using interaction modes. Interaction mode is a tiny abstraction layer,

src/editor/property_editors.md

@@ -42,7 +42,7 @@ following example shows a typical usage:
 {{#include ../code/snippets/src/editor/prop_editors.rs:add_enum_property_editor}}
 ```
 
-As you can see, your enumeration needs a decent amount of trait implementations, hopefully all of them can be derived.
+As you can see, your enumeration needs a decent number of trait implementations, hopefully all of them can be derived.
 
 ### Inheritable Properties
 

src/performance/index.md

@@ -8,7 +8,7 @@ For the vast majority of cases, standard engine approaches are perfectly fine.
 Theoretically, the ECS approach _can_ give you better performance, but lets at first see where ECS is beneficial,
 and why classic approach is still viable. The ECS is beneficial _only_ in cases where you have to process
 **ten or hundreds thousands** objects every frame, the performance gain of cache friendliness can be significant
-in such cases. But let's stop for a second and ask ourselves again: how _often_ games have such huge amount of objects
+in such cases. But let's stop for a second and ask ourselves again: how _often_ games have such huge number of objects
 that has to be processed every frame? There are very few examples of such games:
 
 - Strategy games - at some extent, because there are very few games that allows you to control tens of thousands
@@ -20,7 +20,7 @@ Note that the list does not include games with vast worlds, why so? The reason i
 process every tiny object in the world at once, instead they split the world in small chunks and process only
 few chunks at once, those where the player is present.
 
-The rest of genres operate on a tiny amount of object compared to those up above, maybe a few hundreds at max.
+The rest of genres operate on a tiny number of objects compared to those up above, maybe a few hundreds at max.
 One might say - hey, each object could contain lots of tiny "moving parts", what's about them? Usually each
 object contains up to 10-15 sub-parts, which leads us to few thousands of "atomic" object. Is it much? Not really.
 

src/physics/physics.md

@@ -19,6 +19,6 @@ rigid bodies in the world.
 
 There is a very few differences between 3D and 2D physics, the most obvious is that 2D physics does simulation only in 
 oXY plane (the plane of the screen). 2D physics has less collider shapes available since some 3D shapes degenerate in
-2D, for example cylinder 3D shape in 2D is just a rectangle. There is also lesser amount of joints available in 2D, 
+2D, for example cylinder 3D shape in 2D is just a rectangle. There is also lesser number of joints available in 2D, 
 there is no revolute joint for example. Unlike 3D physics entities, 2D physics entities exist in the separate
 `scene::dim2` module.

src/physics/ragdoll.md

@@ -36,7 +36,7 @@ scene nodes in the world viewer, located under a `Ragdoll` scene node:
 
 ![ragdoll result](ragdoll2.png)
 
-As you can see, the amount of entities you'd have to create and configure manually is quite high. Keep in mind, that 
+As you can see, the number of entities you'd have to create and configure manually is quite high. Keep in mind, that 
 ragdoll wizard can't generate perfect ragdoll, because of lack of information. The generated ragdoll will most likely
 require some minor tweaks (mostly joint angular limits).
 

src/physics/ray.md

@@ -26,8 +26,8 @@ the `collider` and fetch its `parent` field: `graph[collider].parent()`.
 - `normal` - a normal at the intersection position in world coordinates.
 - `position` - a position of the intersection in world coordinates.
 - `feature` - additional data that contains a kind of the feature with which intersection was detected as well as its
-index. FeatureId::Face might have index that is greater than amount of triangles in a triangle mesh, this means that 
-intersection was detected from "back" side of a face. To "fix" that index, simply subtract amount of triangles of a 
+index. FeatureId::Face might have index that is greater than number of triangles in a triangle mesh, this means that
+intersection was detected from "back" side of a face. To "fix" that index, simply subtract number of triangles of a
 triangle mesh from the value.
 - `toi` - (`time of impact`) a distance from ray's origin to `position`.
 
@@ -40,5 +40,5 @@ relatively slow and could be sped up a lot by using static array on stack:
 {{#include ../code/snippets/src/scene/ray.rs:do_static_ray_cast}}
 ```
 
-`usage_example` shows how to use the `do_static_ray_cast` function - all you need to do is to specify maximum amount of
-intersections you're interested in as a generic parameter.
+`usage_example` shows how to use the `do_static_ray_cast` function - all you need to do is to specify maximum number of
+intersections you're interested in as a generic parameter.

src/rendering/materials.md

@@ -4,8 +4,8 @@ Material defines a set of values for a shader. Materials usually contains textur
 textures. Each parameter can be changed in runtime giving you the ability to create animated materials. However,
 in practice, most materials are static, this means that once it's created, it won't be changed anymore.
 
-Please keep in mind that the actual "rules" of drawing an entity are stored in the shader, 
-**material is only a storage** for specific uses of the shader. 
+Please keep in mind that the actual "rules" of drawing an entity are stored in the shader,
+**material is only a storage** for specific uses of the shader.
 
 Multiple materials can share the same shader, for example standard shader covers 95% of most common use cases,
 and it is shared across multiple materials. The only difference are property values, for example you can draw
@@ -16,7 +16,7 @@ multiple objects with the same material efficiently.
 
 ## Performance
 
-It is very important re-use materials as much as possible, because the amount of materials used per frame
+It is very important re-use materials as much as possible, because the number of materials used per frame
 significantly correlates with performance. The more unique materials you have per frame, the more work
 the renderer and video driver need in order to render a frame and more time the frame will require for
 rendering, thus lowering your FPS.
@@ -27,7 +27,7 @@ The engine offers a standard PBR material, PBR stands for "Physically-Based Rend
 of shading which is very close to materials in real world (to some extent of course).
 
 The standard material can cover 95% of use cases, and it is suitable for almost any kind of game, except maybe
-some cartoon-ish or stylized games. 
+some cartoon-ish or stylized games.
 
 The standard material has quite a lot of properties that can be used to fully utilize the power of PBR rendering:
 
@@ -37,26 +37,26 @@ mesh ([see below](#transparency))
 - **diffuseTexture** - a 2D texture containing the unlit "basic" colors of your object, this is the most commonly
 used texture. For example, you can assign a brick wall texture to this property and your object will look like a brick
 wall.
-- **normalTexture** - a 2D texture containing per-pixel normal vectors. 
+- **normalTexture** - a 2D texture containing per-pixel normal vectors.
 - **metallicTexture** - a 2D texture containing per-pixel metallic factor, where 0 - dielectric, 1 - metal.
-In simple words it defines whether your object reflects (1.0) the environment or not (0.0). 
-- **roughnessTexture** - a 2D texture containing per-pixel roughness factor, where 0 - completely flat, 1 - 
+In simple words it defines whether your object reflects (1.0) the environment or not (0.0).
+- **roughnessTexture** - a 2D texture containing per-pixel roughness factor, where 0 - completely flat, 1 -
 very rough.
 - **heightTexture** - a 2D texture containing per-pixel displacement value, it is used with parallax mapping to
 crate an effect of volume on a flat surface.
 - **emissionTexture** - a 2D texture containing per-pixel emission lighting. You could use this to create emissive
-surfaces like small lamps on wall of sci-fi ship, or to create glowing eyes for your monsters that will scare 
+surfaces like small lamps on wall of sci-fi ship, or to create glowing eyes for your monsters that will scare
 the player.
 - **lightmapTexture** - a 2D texture containing per-pixel **static** lighting. It is used to apply precomputed
 light to your 3D models, and the most common use case is to lit a static object using a static light. Precomputed
 light is very cheap. The engine offers built-in lightmapper that can generate lightmaps for you.
 - **aoTexture** - a 2D texture containing per-pixel shading values, allows you to "bake" shadows in for your 3D
 object.
-- **texCoordScale** - a 2D vector that allows you to scale texture coordinates used to sample the textures 
+- **texCoordScale** - a 2D vector that allows you to scale texture coordinates used to sample the textures
 mentioned above (except lightmaps, they're using separate texture coordinates)
 - **layerIndex** - a natural number that is used for decals masking, a decal will only be applied to your mesh
-if and only if the decal has matching index. 
-- **emissionStrength** - a 3D vector that allows you to set the strength of emission per-channel (R, G, B) for 
+if and only if the decal has matching index.
+- **emissionStrength** - a 3D vector that allows you to set the strength of emission per-channel (R, G, B) for
 your `emissionTexture`
 
 ## Transparency
@@ -70,7 +70,7 @@ path on your mesh object. It could be done in this way:
 #     core::pool::Handle,
 #     scene::{mesh::RenderPath, node::Node, Scene},
 # };
-# 
+#
 # fn set_forward_render_path(scene: &mut Scene, mesh_handle: Handle<Node>) {
     scene.graph[mesh_handle]
         .as_mesh_mut()
@@ -85,16 +85,16 @@ if you need lighting, you will need to use custom shader for that!
 ## Material import
 
 When you're loading a 3D model in the engine, the engine tries to convert the materials stored inside to standard
-material. In most cases there is no way to create 100% matching material on the fly, instead the engine tries 
+material. In most cases there is no way to create 100% matching material on the fly, instead the engine tries
 to do its best to make sure the material will be imported as closely as possible to the original one. Various 3D modelling
 tools use different material system, but all of them allow you to export your 3D model in one of the commonly
 used formats (such as FBX).
 
 ### Blender
 
 When using Blender, make sure you are using **Principled BSDF** material, it is the closest material that can be converted
-to engine's standard material at almost 100% fidelity. 
+to engine's standard material at almost 100% fidelity.
 
 ### 3Ds max
 
-It highly depends on the version of the 3Ds max, but in general the default material should work fine.
+It highly depends on the version of the 3Ds max, but in general the default material should work fine.

src/rendering/shaders.md

@@ -2,19 +2,19 @@
 
 Shader is a set of programs that run directly on graphics adapter. Each program from the set is called
 _sub-shader_. Sub-shaders linked with render pass, each render pass defines "where" to draw an object.
-"where" means that you can set up your own render pass and the renderer will use the sub-shader with 
+"where" means that you can set up your own render pass and the renderer will use the sub-shader with
 your render pass. For the ease of use there are a number of [predefined render passes](#predefined-render-passes).
 
-Shaders have properties of various types that can be used together with materials to draw an object. 
+Shaders have properties of various types that can be used together with materials to draw an object.
 
 ## Shaders language
 
-The engine uses GLSL shading language for every sub-shader. There are numerous GLSL guides over the 
+The engine uses GLSL shading language for every sub-shader. There are numerous GLSL guides over the
 internet, so there is no need to "re-post" the well documented info again.
 
 There are very few differences:
 
-1) No need to define a version of the shader. Every shader source will be pre-processed, and it will 
+1) No need to define a version of the shader. Every shader source will be pre-processed, and it will
 get correct version automatically. Preprocessing is needed because the same shader could run on OpenGL
 and WebGL (OpenGL ES) which have some differences.
 2) There is a "standard" library of useful methods which is automatically included in every shader source
@@ -28,7 +28,7 @@ Shader has rigid structure that could be described in this code snippet:
 
 ```json
 (
-    // A set of properties, there could be any amount of properties.
+    // A set of properties, there could be any number of properties.
     properties: [
         (
             // Each property must have a name. This name must match with respective
@@ -128,7 +128,7 @@ This material instance can be used for rendering. For example, you can assign it
 
 Property is a named variable of some type. Properties are directly tied with the uniforms in the sub-shaders,
 for each you can have a property called `time`, and then you can define `uniform float time;` in your sub-shader
-and the engine will pass a property value to that uniform for you before drawing an object. Properties placed in 
+and the engine will pass a property value to that uniform for you before drawing an object. Properties placed in
 a "global namespace", which means that every sub-shader has "access" to the properties.
 
 ## Built-in properties
@@ -171,25 +171,25 @@ This list will be extended in future releases.
 
 ## Predefined render passes
 
-Predefined render passes helps you to create your own shader without a need to create your own render pass 
+Predefined render passes helps you to create your own shader without a need to create your own render pass
 and to quickly start writing your shaders.
 
-- **GBuffer** - A pass that fills a set with render target sized textures with various data about each rendered 
-object. These textures then are used for physically-based lighting. Use this pass when you want the standard 
+- **GBuffer** - A pass that fills a set with render target sized textures with various data about each rendered
+object. These textures then are used for physically-based lighting. Use this pass when you want the standard
 lighting to work with your objects.
-- **Forward** - A pass that draws an object directly in render target. This pass is very limiting, it does not 
+- **Forward** - A pass that draws an object directly in render target. This pass is very limiting, it does not
 support lighting, shadows, etc. It should be only used to render translucent objects.
 - **SpotShadow** - A pass that emits depth values for an object, later this depth map will be used to render shadows.
 - **PointShadow** - A pass that emits distance from a fragment to a point light, later this depth map will be used
 to render shadows.
-- **DirectionalShadow** - A pass that emits depth values for an object, later this depth map will be used to render 
+- **DirectionalShadow** - A pass that emits depth values for an object, later this depth map will be used to render
 shadows for directional light sources using cascaded shadow mapping.
 
 ## Drawing parameters
 
 Drawing parameters defines which GPU functions to use and at which state. For example, to render transparent
 objects you need to enable blending with specific blending rules. Or you need to disable culling to draw objects
-from both sides. This is when draw parameters come in handy. 
+from both sides. This is when draw parameters come in handy.
 
 There are relatively large list of drawing parameters, and it could confuse a person who didn't get
 used to work with graphics. The following list should help you to use drawing parameters correctly.