Browse Source

WIP: Updating & cleaning up framework docs

BearishSun 7 years ago
parent
commit
e71db9b4f9

+ 2 - 1
Documentation/Doxygen/NativeLayout.xml

@@ -3,7 +3,8 @@
   <!-- Navigation index tabs for HTML output -->
   <navindex>
     <tab type="mainpage" visible="yes" title=""/>
-	<tab type="user" url="manuals.html" title="Manuals"/>
+	<tab type="user" url="manuals.html" title="User manuals"/>
+	<tab type="user" url="devManuals.html" title="Dev. manuals"/>
     <tab type="user" url="group___layers.html" title="Core API"/>
 	<tab type="user" url="group___internals.html" title="Internals"/>
 	<tab type="user" url="group___plugins.html" title="Plugins"/>

+ 37 - 28
Documentation/Doxygen/doxystyle.css

@@ -1,6 +1,6 @@
 /* Global */
 body, table, div, p, dl {
-	font: 14px/22px Segoe UI,Roboto,sans-serif;
+	font: 16px/26px Segoe UI,Roboto,sans-serif;
 }
 
 h1, h2, h3, h4, h5, h6 {
@@ -44,48 +44,58 @@ a:visited {
 
 div.contents {
 	margin: auto;
-	width: 700px;
+	width: 800px;
 	padding-bottom: 170px;
 }
 
+div.line {
+	font-size: 15px;
+	line-height: 1.6;
+}
+
+div.fragment {
+	padding: 6px;
+}
+
 /* Nav bar */
-.tabs, .tabs2, .tabs3 {
+#main-menu {
 	background-color: rgba(0, 0, 0, 0.8);
 	background-image: none;
     font-family: Lato,'Lucida Grande',Geneva,Helvetica,Arial,sans-serif;
 	border-bottom: none;
-	width: 700px;
+	width: 800px;
 	margin: auto;
 }
 
-.tablist li {
+.sm-dox li {
     background-image: none;
 }
 
-.tablist a {
+.sm-dox a {
 	background-image: none;
 	color: rgba(255, 255, 255, 1.0);
 	background: transparent;
 	text-shadow: none;
-	font-weight: bold;
+	font-weight: normal;
+	font-family: Lato,sans-serif;
 }
 
-.tablist a:hover {
+.sm-dox a:hover {
     background-image: none;
 	color: rgba(255, 255, 255, 1.0);
 	text-shadow: none;
 }
 
-.tablist li.current a {
+.sm-dox li.current a {
     background-image: none;
 	text-shadow: none;
 }
 
-.tablist li:hover {
+.sm-dox li:hover {
 	background-color: rgba(255, 255, 255, 0.15);
 }
 
-.tablist li:last-child:hover {
+.sm-dox li:last-child:hover {
 	background-color: rgba(0, 0, 0, 0);
 }
 
@@ -94,7 +104,7 @@ div.contents {
 	background-color: rgba(222, 222, 222, 0.46);
 	background-image: none;
 	border: none;
-	width: 700px;
+	width: 800px;
 	margin: auto;
 }
 
@@ -127,7 +137,7 @@ div.contents {
 
 /* Page header */
 div.header {
-	width: 700px;
+	width: 800px;
 	margin: auto auto 15px auto;
 	background-image: none;
 	border-bottom: 1px solid rgba(89, 160, 195, 0.86);
@@ -140,7 +150,7 @@ div.headertitle {
 /* Members */
 .memproto, dl.reflist dt {
 	background-image: none;
-	background-color: #F9FAFB;
+	background-color: #b1cbe6;
 	color: #000000;
 	text-shadow: none;
 	padding: 2px 0px 4px 0px;
@@ -162,6 +172,10 @@ div.headertitle {
 	background-image: none;
 }
 
+.memtitle {
+	display: none;
+}
+
 /* TOC */
 
 div.toc li {
@@ -190,7 +204,6 @@ div.toc {
 	margin-top: none;
 	position: relative;
 	left: 470px;
-	top: 7px;
 }
 
 #MSearchBox .left {
@@ -210,17 +223,13 @@ div.toc {
 	border-right: 1px solid black;
 	position: relative;
 	left: 142px;
+	top: 0px;
 }
 
 #MSearchSelect {
 	left: 2px;
 }
 
-#MSearchResultsWindow {
-	margin-left: 85%;
-	margin-top: 100px;
-}
-
 /* Other */
 
 blockquote {
@@ -245,7 +254,7 @@ table.directory {
     font: 400 14px Segoe UI,Roboto,sans-serif;
 }
 
-table.doxtable {
+table.markdownTable {
 	border-radius: .28571429rem;
 	border-collapse: separate;
 	border: 1px solid rgba(34, 36, 38, .15);
@@ -253,34 +262,34 @@ table.doxtable {
 	background-color: #F9FAFB;
 }
 
-table.doxtable th {
+table.markdownTable th {
 	background-color: #F9FAFB;
 	color: rgba(0,0,0,.87);
 	border: none;
 }
 
-table.doxtable td {
+table.markdownTable td {
 	border: none;
 	border-left: 1px solid rgba(34, 36, 38, .1);
 }
 
-table.doxtable td:first-child {
+table.markdownTable td:first-child {
 	border-left: none;
 }
 
-table.doxtable tr {
+table.markdownTable tr {
 	border-left: 1px solid rgba(34, 36, 38, .1);
 }
 
-table.doxtable tr td {
+table.markdownTable tr td {
 	border-top: 1px solid rgba(34, 36, 38, .1);
 }
 
-table.doxtable tr:first-child td {
+table.markdownTable tr:first-child td {
 	border-top: 1px solid rgba(34, 36, 38, .1);
 }
 
-table.doxtable tbody tr:nth-child(2n) {
+table.markdownTable tbody tr:nth-child(2n) {
 	background-color: #FFFFFF;
 }
 

+ 1 - 1
Documentation/Doxygen/doxystyle_managed.css

@@ -1,3 +1,3 @@
 #MSearchBox {
-	left: 335px;
+	left: 0px;
 }

+ 1 - 1
Documentation/Doxygen/doxystyle_native.css

@@ -1,3 +1,3 @@
 #MSearchBox {
-	left: 65px;
+	left: 0px;
 }

+ 0 - 62
Documentation/Manuals/Native/User/advResources.md

@@ -1,62 +0,0 @@
-Advanced resources					{#advResources}
-===============
-
-We've covered basic resource operations already, and this manual will cover a more advanced topics that allow you to do more with resources.
-
-# Resource lifetime {#advResources_a}
-Whenever you load a resource, that resource will be kept loaded until all references to that resource are lost. Each resource handle (e.g. **HMesh**) that exists represents a single reference. By default an additional "internal" reference is also created and held by the system internally. This ensures the resource stays loaded even when all handles are destroyed.
-
-This internal reference must be released by calling @ref bs::Resources::release() "Resources::release()", as we mentioned when we talk about resources before.
-
-You can also force the system to not create the internal reference by passing a custom @ref bs::ResourceLoadFlag "ResourceLoadFlag" to the @ref bs::Resources::load() "Resources::load()" method. This flag should not include the @ref bs::ResourceLoadFlag::KeepInternalRef "ResourceLoadFlag::KeepInternalRef".
-
-~~~~~~~~~~~~~{.cpp}
-// The default load flag is a combination of ResourceLoadFlag::KeepInternalRef and
-// ResourceLoadFlag::LoadDependencies. We don't include the former to prevent the
-// internal reference from being created.
-HMesh mesh = gResources().load("myMesh.asset", ResourceLoadFlag::LoadDependencies);
-~~~~~~~~~~~~~ 
-
-## Weak handles {#advResources_a_a}
-In case you want to keep a reference to a resource without incrementing the reference count you can use a weak handle instead of a normal one. Weak handles are represented by the @ref bs::WeakResourceHandle<T> "WeakResourceHandle<T>" class and can be retrieved from normal handles by calling @ref bs::ResourceHandle<T>::getWeak "ResourceHandle<T>::getWeak()". Other than that they are accessed the same as normal handles.
-
-~~~~~~~~~~~~~{.cpp}
-// Load a mesh and store a handle as normal
-HMesh mesh = gResources().load("myMesh.asset");
-
-// Create a weak handle
-WeakResourceHandle<Mesh> weakMesh = mesh.getWeak();
-~~~~~~~~~~~~~ 
-
-# Resource dependencies {#advResources_b}
-Whenever you load a resource the system will automatically enumerate all dependencies of that resource and attempt to load them as well. For example when loading a **Material** it will automatically load its **Shader** and any referenced **Texture** resources.
-
-In case you wish to prevent that you can not provide the @ref bs::ResourceLoadFlag::LoadDependencies "ResourceLoadFlag::LoadDependencies" flag when calling **Resources::load()** (provided by default).
-
-~~~~~~~~~~~~~{.cpp}
-// Loads a resource without any dependencies, nor keeps an internal reference
-HMesh mesh = gResources().load("myMesh.asset", ResourceLoadFlag::None);
-~~~~~~~~~~~~~ 
-
-# Asynchronous loading {#advResources_c}
-Resources can be loaded asynchronously (in the background) by calling @ref bs::Resources::loadAsync "Resources::loadAsync()". The interface is identical to **Resources::load()**. The main difference is that the returned handle might will contain a reference to a resource that hasn't been loaded yet. 
-
-You can check if a resource handle is pointing to a loaded resource by calling @ref bs::ResourceHandle::isLoaded "ResourceHandle::isLoaded()".
-
-~~~~~~~~~~~~~{.cpp}
-HMesh mesh = gResources().loadAsync("myMesh.asset");
-
-if(mesh.isLoaded())
-{
-	// Check if loaded before doing something
-}
-~~~~~~~~~~~~~ 
-
-> Note that not-yet-loaded resource handles can be provided to some engine systems, but not all. Generally a system will note in its documentation if it works with such resource handles.
-
-You can block the current thread until a resource is loaded by calling @ref bs::ResourceHandle::blockUntilLoaded "ResourceHandle::blockUntilLoaded()".
-
-~~~~~~~~~~~~~{.cpp}
-mesh.blockUntilLoaded();
-// Makes sure the mesh is loaded at this point
-~~~~~~~~~~~~~ 

+ 1 - 1
Documentation/Manuals/Native/User/advancedTextures.md

@@ -1,4 +1,4 @@
-Manipulating textures				{#advancedTextures}
+Creating textures				{#advancedTextures}
 ===============
 
 In this manual we'll learn how to create textures manually, modify their contents and even read-back texture data.

+ 1 - 1
Documentation/Manuals/Native/User/bsl.md

@@ -610,7 +610,7 @@ technique MyShader
 
 Valid options are:
 Name                 | Valid values				   | Default value			| Description
----------------------|---------------------------- |------------------------|------------------
+---------------------|---------------------------- |------------------------|------------
 separable			 | true, false				   | false					| When true, tells the renderer that passes within the shader don't need to be renderered one straight after another. This allows the system to perform rendering more optimally, but can be unfeasible for most materials which will depend on exact rendering order. Only relevant if a technique has multiple passes.
 sort				 | none, backtofront, fronttoback | fronttoback			| Determines how does the renderer sort objects with this material before rendering. Most objects should be sorted front to back in order to avoid overdraw. Transparent (see below) objects will always be sorted back to front and this option is ignored. When no sorting is active the system will try to group objects based on the material alone, reducing material switching and potentially reducing CPU overhead, at the cost of overdraw.
 transparent			 | true, false				   | false					| Notifies the renderer that this object is see-through. This will force the renderer to the use back to front sorting mode, and likely employ a different rendering method. Attempting to render transparent geometry without this option set to true will likely result in graphical artifacts.

+ 7 - 5
Documentation/Manuals/Native/User/cameras.md

@@ -5,11 +5,11 @@ Cameras represent the user's view into the scene, and any graphical application
 
 They have parameters like position and orientation which define what part of the scene will the user see. Additionally, their parameters like field of view, projection mode and aspect ratio define how is the application scene transformed into the 2D output visible to the user. 
 
-Finally, everything that the camera sees is output to what we call a render target. Render targets can be windows, which we explained in the previous chapter, or off-screen surfaces, as we'll explain later.
+Finally, everything that the camera sees is output to what we call a render target. Render targets can be windows, like the one that was created when the application was started, or an off-screen surface, as we'll explain later.
 
 Cameras are represented by the @ref bs::CCamera "Camera" component, and they can be created as any other component. At minimum their constructor requires a render target onto which they will output their contents.
 
-Lets create a camera that renders to the primary render window:
+Lets create a camera that renders to the primary render window. The primary application window can be retrieved through @ref bs::Application::getPrimaryWindow "Application::getPrimaryWindow()".
 
 ~~~~~~~~~~~~~{.cpp}
 SPtr<RenderWindow> primaryWindow = gApplication().getPrimaryWindow();
@@ -18,10 +18,12 @@ HSceneObject cameraSO = SceneObject::create("Camera");
 HCamera camera = cameraSO->addComponent<CCamera>(primaryWindow);
 ~~~~~~~~~~~~~
 
+> **Application** is a singleton and its instance can be accessed through @ref bs::Application::instance() "Application::instance()", or the helper method @ref bs::gApplication() "gApplication()". All other singletons in the framework follow the same design.
+
 Once the camera has been created we can move and orient it using the **SceneObject** transform, as explained earlier. For example:
 ~~~~~~~~~~~~~{.cpp}
-// Move camera to 100 units high, and 500 units away from the center
-cameraSO->setPosition(Vector3(0f, 100f, 500f));
+// Move camera to 10 meters height, and 50 meters away from the center
+cameraSO->setPosition(Vector3(0f, 10f, 50f));
 
 // Orient the camera so it is looking at the center
 cameraSO->lookAt(Vector3(0f, 0f, 0f));
@@ -29,7 +31,7 @@ cameraSO->lookAt(Vector3(0f, 0f, 0f));
 
 Once set up, any rendered objects in the camera's view will be displayed on the selected render target, which is in this case the primary application window.
 
-However you might want to customize camera's parameters to get the exact feel you need. Lets cover some of the available parameters.
+You can also customize a variety of parameters that control how will the camera render the objects.
 
 # Projection type
 All cameras can be in two projection modes: *Perspective* and *Ortographic*. They can be changed by calling @ref bs::CCamera::setProjectionType "CCamera::setProjectionType()".

+ 1 - 1
Documentation/Manuals/Native/User/containers.md

@@ -1,7 +1,7 @@
 Containers 						{#containers}
 ===============
 
-Containers are data types that contain a set of elements. Banshee uses wrappers for C++ standard library containers like vector, set or map. Aside from different names Banshee containers act exactly like standard library containers.
+Containers are data types that contain a set of elements. bs::f uses wrappers for C++ standard library containers like vector, set or map. Aside from different names these containers act exactly like standard library containers.
 
 All available containers:
  - @ref bs::Vector "Vector" - A sequential list of elements. Fast iteration, slow lookup, slow insertion/deletion (except for the last element).

+ 14 - 18
Documentation/Manuals/Native/User/importingMeshes.md

@@ -1,13 +1,7 @@
-Importing meshes 						{#importingMeshes}
+Meshes 						{#importingMeshes}
 ===============
 
-Meshes are used for defining surfaces of 2D and 3D objects, and are the primary building blocks of the scene. They are represented with a set of vertices and triangles. Those vertices and triangles are then transformed by the graphics card when rendering, by converting them to pixels on the screen. 
-
-Each vertex can have one or multiple properties like texture coordinates (used for mapping textures onto mesh surface), normals, tangents, and at minimum, a position property. These properties are used by materials for customizing how a mesh is rendered (explained later).
-
-Vertices are connected into triangles via indices, where every three sequential indices specify which three vertices form a triangle. That information is then used by the graphics card for rendering.
-
-In Banshee meshes are represented with the @ref bs::Mesh "Mesh" class. A mesh is a resource, meaning it can be imported, saved and loaded as we described in the Resource manuals.
+Meshes are used for defining surfaces of 2D and 3D objects, and are the primary building blocks of the scene. In bs::f meshes are represented with the @ref bs::Mesh "Mesh" class. A mesh is a resource, meaning it can be imported, saved and loaded as any other resource.
 
 ![Wireframe mesh](DragonWireframe.png) 
 
@@ -24,6 +18,9 @@ Supported formats are:
  - DAE
  - OBJ
  
+# Creating a mesh
+Meshes can also be created manually, which we cover later in the [creating meshes](@ref creatingMeshes) manual.
+ 
 # Mesh properties
 Once a mesh has been imported, you can retrieve its properties like vertex & index counts, as well as its bounds by calling @ref bs::Mesh::getProperties "Mesh::getProperties()", which returns a @ref bs::MeshProperties "MeshProperties" object.
 
@@ -36,8 +33,7 @@ gDebug().logDebug("Num. indices: " + toString(props.getNumIndices()));
 gDebug().logDebug("Radius: " + toString(props.getBounds().getSphere().getRadius()));
 ~~~~~~~~~~~~~
 
-# Rendering meshes
-**Mesh** can be assigned to a **Renderable** component, along with a **Material** in order to be rendered. We'll cover rendering in a later chapter.
+> The debug logging functionality is explained in the [logging](@ref logging) manual.
 
 # Customizing import
 Mesh import can be customized by providing a @ref bs::MeshImportOptions "MeshImportOptions" object to the importer.
@@ -52,7 +48,7 @@ HMesh mesh = gImporter().import<Mesh>("dragon.fbx", importOptions);
 Lets see some of the options you can use for customizing import.
 
 ## Scale
-@ref bs::MeshImportOptions::setImportScale "MeshImportOptions::setImportScale" allows you to apply a uniform scale value to the mesh upon import. Although you can scale the size of a rendered mesh by adjusting the **SceneObject** transform when its placed in the scene, sometimes it is more useful to be able to do it once at import instead of every time you place it.
+@ref bs::MeshImportOptions::setImportScale "MeshImportOptions::setImportScale()" allows you to apply a uniform scale value to the mesh upon import. Although you can scale the size of a rendered mesh by adjusting the **SceneObject** transform when its placed in the scene, sometimes it is more useful to be able to do it once at import instead of every time you place it.
 
 ~~~~~~~~~~~~~{.cpp}
 // Reduce the size of the mesh to 10% of its original size
@@ -60,11 +56,11 @@ importOptions->setImportScale(0.1f);
 ~~~~~~~~~~~~~
 
 ## Normals
-@ref bs::MeshImportOptions::setImportNormals "MeshImportOptions::setImportNormals" controls whether normal vectors are imported from the mesh file. 
+@ref bs::MeshImportOptions::setImportNormals "MeshImportOptions::setImportNormals()" controls whether normal vectors are imported from the mesh file. 
 
 Normal vectors are used in lighting and are required for any meshes placed in the 3D scene (unless rendering them manually using some custom method). They allow the mesh to appear smooth even though its surface is made out of triangles.
 
-Most 3D authoring tools generate normals for their meshes, but if normals are not present in the mesh file, Banshee will attempt to generate normals automatically when this option is turned on.
+Most 3D authoring tools generate normals for their meshes, but if normals are not present in the mesh file, bs::f will attempt to generate normals automatically when this option is turned on.
 
 ~~~~~~~~~~~~~{.cpp}
 // Import or generate normals for the mesh
@@ -72,9 +68,9 @@ importOptions->setImportNormals(true);
 ~~~~~~~~~~~~~
 
 ## Tangent
-@ref bs::MeshImportOptions::setImportTangents "MeshImportOptions::setImportTangents" controls whether tangent vectors are imported from the mesh file. 
+@ref bs::MeshImportOptions::setImportTangents "MeshImportOptions::setImportTangents()" controls whether tangent vectors are imported from the mesh file. 
 
-Tangent vectors (along with normal vectors) are required if your rendering shader uses normal maps. Similar to normals, if tangents are not present in the mesh file, Banshee will attempt to generate them automatically.
+Tangent vectors (along with normal vectors) are required if your rendering shader uses normal maps. Similar to normals, if tangents are not present in the mesh file, bs::f will attempt to generate them automatically.
 
 ~~~~~~~~~~~~~{.cpp}
 // Import or generate normals for the mesh
@@ -82,9 +78,9 @@ importOptions->setImportTangents(true);
 ~~~~~~~~~~~~~
 
 ## Caching
-Similar as with textures, sometimes you need to import a mesh you don't want to only use for rendering, but rather for manually reading its contents. When that's the case you can enable the @ref bs::MeshImportOptions::setCPUCached "MeshImportOptions::setCPUCached" option.
+Sometimes you need to import a mesh you don't want to only use for rendering, but rather for manually reading its contents. When that's the case you can enable the @ref bs::MeshImportOptions::setCPUCached "MeshImportOptions::setCPUCached()" option.
 
-This will allow you to call @ref bs::Mesh::readCachedData "Mesh::readCachedData" and to manually read individual vertices and indices of the mesh.
+This will allow you to call @ref bs::Mesh::readCachedData "Mesh::readCachedData()" and to manually read individual vertices and indices of the mesh.
 
 Note that caching a mesh means its data will be available in system memory, essentially doubling its memory usage.
 
@@ -112,4 +108,4 @@ meshData->getVertexData(VES_POSITION, vertices.data(), vertices.size() * sizeof(
 ...
 ~~~~~~~~~~~~~
 
-> We will explain **MeshData** and mesh manipulation in detail, in a later chapter.
+> **MeshData** is explained later in the [creating meshes](@ref creatingMeshes) manual.

+ 10 - 14
Documentation/Manuals/Native/User/importingTextures.md

@@ -1,9 +1,7 @@
-Importing textures 						{#importingTextures}
+Textures 						{#importingTextures}
 ===============
 
-Textures are images that are applied to meshes in order to achieve greater surface detail. In Banshee they are represented with the @ref bs::Texture "Texture" class. A texture is a resource, meaning it can be imported, saved and loaded as we described in the Resource manuals.
-
-![Mesh without (left) and with (right) a texture](TexturedMesh.png)  
+Textures are images that are applied to meshes in order to achieve greater surface detail. In bs::f they are represented with the @ref bs::Texture "Texture" class. A texture is a resource, meaning it can be imported, saved and loaded as any other resource.
 
 # Importing a texture
 Textures can be imported from various third party formats, using the importer.
@@ -27,6 +25,9 @@ Supported formats are:
  - TARGA
  - TIFF
  
+# Creating a texture
+Textures can also be created manually, which we cover later in the [creating textures](@ref advancedTextures) manual.
+   
 # Texture properties
 Once a texture has been imported, you can retrieve its properties like width, height and format by calling @ref bs::Texture::getProperties "Texture::getProperties()", which returns a @ref bs::TextureProperties "TextureProperties" object.
 
@@ -40,9 +41,6 @@ gDebug().logDebug("Format: " + toString(props.getFormat()));
 gDebug().logDebug("Num. mip maps: " + toString(props.getNumMipmaps()));
 ~~~~~~~~~~~~~
 
-# Rendering using textures
-Once imported a texture can be assigned to a **Material** in order to be used for rendering. We will cover materials in a later chapter. 
- 
 # Customizing import
 Texture import can be customized by providing a @ref bs::TextureImportOptions "TextureImportOptions" object to the importer.
 
@@ -56,7 +54,7 @@ HTexture texture = gImporter().import<Texture>("myTexture.jpg", importOptions);
 A variety of properties can be customized on import, the most important of which being image format, mip-map generation, sRGB state and caching.
 
 ## Image format
-@ref bs::TextureImportOptions::setFormat "TextureImportOptions::setFormat" allows you to specify which format should the texture pixels be in after import. Any of the formats provided in @ref bs::PixelFormat "PixelFormat" are supported.
+@ref bs::TextureImportOptions::setFormat "TextureImportOptions::setFormat()" allows you to specify which format should the texture pixels be in after import. Any of the formats provided in @ref bs::PixelFormat "PixelFormat" are supported.
 
 ~~~~~~~~~~~~~{.cpp}
 // Set format as uncompressed RGB with an alpha channel
@@ -74,10 +72,8 @@ Some of most common formats are:
  - PF_BC3 - Compressed RGB data, with an alpha channel. 
  - PF_BC5 - Compressed 2-channel format. 
  
-> If importing normal maps, use the BF_BC5 format as other compression formats produce visible artifacts in the normal map. Optionally if memory is not a concern, use an uncompressed format.
- 
 ## Mip-maps
-@ref bs::TextureImportOptions::setGenerateMipmaps "TextureImportOptions::setGenerateMipmaps" allows you to specify should mip-maps for the texture be generated. Mipmaps ensure that textures applied to 3D surfaces look good when they're viewed from far away (i.e. when the pixel size they take up on screen is considerably less than the actual texture resolution).
+@ref bs::TextureImportOptions::setGenerateMipmaps "TextureImportOptions::setGenerateMipmaps()" allows you to specify should mip-maps for the texture be generated. Mipmaps ensure that textures applied to 3D surfaces look good when they're viewed from far away (i.e. when the pixel size they take up on screen is considerably less than the actual texture resolution).
 
 Enabling mip-maps will increase the memory use of the texture by 33%, but it is pretty much essential for any texture applied on a 3D object. It should not be enabled for textures used on 2D elements like GUI or sprites, as it will have no benefit.
 
@@ -91,7 +87,7 @@ Most images output by modern cameras and image editing software will be stored i
 
 However game engines don't like their data in gamma space, because it's not linear which means that all lighting and similar operations don't operate exactly as they should. Essentially the image ends up looking more "washed-out" than it should.
 
-For this reason Banshee provides @ref bs::TextureImportOptions::setSRGB "TextureImportOptions::setSRGB" toggle, which you can set for images in gamma (sRGB) space. The engine will then know to convert to linear space before performing any relevant operations, ensuring the final rendering looks good.
+For this reason bs::f provides @ref bs::TextureImportOptions::setSRGB "TextureImportOptions::setSRGB()" toggle, which you can set for images in gamma (sRGB) space. The engine will then know to convert to linear space before performing any relevant operations, ensuring the final rendering looks good.
 
 ~~~~~~~~~~~~~{.cpp}
 // Tell the engine this image is in gamma space
@@ -101,7 +97,7 @@ importOptions->setSRGB(true);
 > How do you know when an image is in gamma space and when in linear space? As a general rule an albedo (diffuse) images are in gamma space, and normal maps are in linear space. For other types of images you need to consult the tool you use to create/save them, but in most cases they will be in gamma space.
 
 ## Caching
-Sometimes you need to import a texture you don't want to only use for rendering, but rather for manually reading its contents. When that's the case you can enable the @ref bs::TextureImportOptions::setCPUCached "TextureImportOptions::setCPUCached" option.
+Sometimes you need to import a texture you don't want to only use for rendering, but rather for manually reading its contents. When that's the case you can enable the @ref bs::TextureImportOptions::setCPUCached "TextureImportOptions::setCPUCached()" option.
 
 This will allow you to call @ref bs::Texture::readCachedData "Texture::readCachedData()" and to manually read individual pixels of the texture.
 
@@ -125,4 +121,4 @@ Color color = pixelData->getColorAt(50, 50);
 ...
 ~~~~~~~~~~~~~
 
-> We will explain **PixelData** and texture manipulation in general, in a later chapter.
+> **PixelData** is explained later in the [creating textures](@ref advancedTextures) manual.

+ 2 - 0
Documentation/Manuals/Native/User/inputEvents.md

@@ -3,6 +3,8 @@ Input events						{#inputEvents}
 
 Events represent another way of handling user input. They are an alternative to input polling, and it's up to the developer to choose which way of handling input he prefers. These approaches aren't identical though, and events can provide more information than polling. Same as polling, events are also handled by the **Input** class.
 
+This approach uses the event system, on which you can read more on [here](@ref events).
+
 # Button presses
 You can subscribe to the following events that report when the user interacted with a button:
  - @ref bs::Input::onButtonDown "Input::onButtonDown" - Triggered whenever a button has been pressed.

+ 9 - 9
Documentation/Manuals/Native/User/inputPolling.md

@@ -3,13 +3,13 @@ Input polling						{#inputPolling}
 
 Input polling refers to the process of querying the input system to check if user interacted with a input device in some way. This may include checking if the user pressed a keyboard, mouse or a gamepad button or moved the mouse or an analog axis. 
 
-All the input in Banshee is handled though the @ref bs::Input "Input" class, which can always be accessed from the @ref bs::gInput "gInput" method.
+All the input in bs::f is handled though the @ref bs::Input "Input" class, which can be globally accessed through the @ref bs::gInput "gInput()" method.
 
 # Button presses
 Use the following methods to check if a button has been pressed, released or is currently being held down:
- - @ref bs::Input::isButtonDown "Input::isButtonDown" - Checks has the button been pressed this frame. Only valid for one frame.
- - @ref bs::Input::isButtonHeld "Input::isButtonHeld" - Checks is the button currently being held. This is valid for the first frame the button is pressed, and for any following frame until it is released.
- - @ref bs::Input::isButtonUp "Input::isButtonUp" - Checks has the button been released this frame. Only valid for one frame.
+ - @ref bs::Input::isButtonDown "Input::isButtonDown()" - Checks has the button been pressed this frame. Only valid for one frame.
+ - @ref bs::Input::isButtonHeld "Input::isButtonHeld()" - Checks is the button currently being held. This is valid for the first frame the button is pressed, and for any following frame until it is released.
+ - @ref bs::Input::isButtonUp "Input::isButtonUp()" - Checks has the button been released this frame. Only valid for one frame.
  
 These methods work on any kind of input device buttons, including keyboard, gamepad and mouse. Use @ref bs::ButtonCode "ButtonCode" to choose which button to query for.
 
@@ -22,9 +22,9 @@ if(gInput().isButtonHeld(BC_W))
 ~~~~~~~~~~~~~
 
 # Analog input
-Moving the mouse, gamepad sticks or triggers results in an analog input. While buttons can only be toggled on or off, analog input is received in a specific range (for example, anywhere between -1 and 1). This allows more precise input for games that require it.
+Moving the mouse, gamepad sticks or triggers results in an analog input. While buttons can only be toggled on or off, analog input is received in a specific range (for example, anywhere between -1 and 1). This allows more precise input for applications that require it.
 
-In Banshee analog input is represented through the concept of *axes*. Use @ref bs::Input::getAxisValue "Input::getAxisValue" to get a value for a specific axis. Check @ref bs::InputAxis "InputAxis" for a list of all supported axes.
+In bs::f analog input is represented through the concept of *axes*. Use @ref bs::Input::getAxisValue "Input::getAxisValue()" to get a value for a specific axis. Check @ref bs::InputAxis "InputAxis" for a list of all supported axes.
 
 ~~~~~~~~~~~~~{.cpp}
 Vector3 position(BsZero);
@@ -36,15 +36,15 @@ position.z += gInput().getAxisValue(InputAxis::LeftStickY);
 Most axes report their input in range [-1, 1], with the exception of mouse axes, which are unbound. 
 
 # Mouse input
-Often it is useful to receive mouse position directly, rather than dealing with raw mouse axis data. Use @ref bs::Input::getPointerPosition "Input::getPointerPosition" to retrieve the current position of the mouse cursor, in coordinates relative to the screen.
+Often it is useful to receive mouse position directly, rather than dealing with raw mouse axis data. Use @ref bs::Input::getPointerPosition "Input::getPointerPosition()" to retrieve the current position of the mouse cursor, in coordinates relative to the screen.
 
-Use @ref bs::Input::getPointerDelta "Input::getPointerDelta" to get the difference in coordinates between the position of the mouse on the previous and current frame.
+Use @ref bs::Input::getPointerDelta "Input::getPointerDelta()" to get the difference in coordinates between the position of the mouse on the previous and current frame.
 
 ~~~~~~~~~~~~~{.cpp}
 Vector2I screenPos = gInput().getPointerPosition();
 ~~~~~~~~~~~~~
 
-You can also check if the left mouse button has been double-clicked by checking @ref bs::Input::isPointerDoubleClicked "Input::isPointerDoubleClicked".
+You can also check if the left mouse button has been double-clicked by checking @ref bs::Input::isPointerDoubleClicked() "Input::isPointerDoubleClicked".
 
 ~~~~~~~~~~~~~{.cpp}
 if(gInput().isPointerDoubleClicked())

+ 13 - 3
Documentation/Manuals/Native/User/lights.md

@@ -1,7 +1,7 @@
 Lights						{#lights}
 ===============
 
-Lights control the rendering of the nearby **Renderable** objects, by attempting to simulate how a real light would affect them. They are represented by the @ref bs::CLight "Light" component.
+Lights control the rendering of the nearby **Renderable** objects, by attempting to simulate how a real light would affect them. They are represented by the @ref bs::CLight "Light" component. They are essential for creating a realistic 3D scene.
 
 # Creating a light
 **Light** is created as any component, and requires no additional parameters.
@@ -48,7 +48,7 @@ As the name implies, this controls what color light is being emitted from the so
 ## Attenuation radius
 Attenuation radius determines how far away does the light's influence reach. For radial lights this is the radius of the sphere of influence, and for spot lights this is the distance from the origin in the direction of the light. This property is not relevant for directional lights as their range is infinite. Use @ref bs::CLight::setAttenuationRadius "CLight::setAttenuationRadius()" to set the range.
 
-Note that the manually set range will only be used if automatic attenuation is disabled. You can toggle this by calling @ref bs::CLight::setUseAutoAttenuation "CLight::setUseAutoAttenuation()". When automatic attenuation is enabled the maximum range is calculated automatically based on the light intensity (described below). This automatic attenuation will smoothly cut off the light influence when it reaches roughly 10% of its intensity. Sometimes this is not wanted in which case you can turn this off and increase the range manually. Reducing the range manually will result in a non-physically realistic light attenuation.
+Note that the manually set range will only be used if automatic attenuation is disabled. You can toggle this by calling @ref bs::CLight::setUseAutoAttenuation "CLight::setUseAutoAttenuation()". When automatic attenuation is enabled the maximum range is calculated automatically based on the light intensity (described below). This automatic attenuation will smoothly cut off the light influence when it reaches roughly 10% of its intensity, but can result in very large attenuation radius, which can affect performance.
 
 ## Intensity
 This controls how strong is the light. Although you could technically control light intensity using the color property (by using a lighter or darker color), using the intensity allows the engine to simulate high-dynamic range. 
@@ -59,7 +59,7 @@ Banshee uses a HDR algorithm to try to approximate this adjustment, which result
 
 Use @ref bs::CLight::setIntensity "CLight::setIntensity()" to change the light intensity. 
 
-The specific units used for intensity (in case you want to look them up for actual light sources) are *luminous flux* for radial/spot lights, and *luminance* for directional lights.
+The specific units used for intensity (in case you want to look them up for actual light sources) are *luminous flux* for radial/spot lights, and *luminance* for directional lights. Generally this means directional light intensity should be much lower than for radial/spot lights.
 
 ## Source radius
 By default all lights are considered point (punctual) lights, meaning they have no surface area. In case you want to make an area light set the source radius of the light by calling @ref bs::CLight::setSourceRadius "CLight::setSourceRadius()". The value of this property is interpreted differently depending on light type:
@@ -72,6 +72,16 @@ Area light types are particulary important for physically based rendering, as th
 ## Shadows
 Lights may or may not cast shadows. For realism all lights should cast shadows, but that is not feasible due to the high performance costs of using shadows. Therefore you should enable shadows only for one, or a few important lights. Use @ref bs::CLight::setCastsShadow "CLight::setCastsShadow()" to enable or disable shadow casting.
 
+Casting shadows can cause artifacts called "shadow acne" in the scene. These artifacts occur due to an object casting a shadow on itself, caused limited precision of the calculations used. To combat this effect you can tweak the shadow bias property. Shadow bias moves the distance from which the shadow is cast, ensuring incorrect self-shadowing is avoided. Shadow bias can be tweaked by calling @ref bs::CLight::setShadowBias "CLight::setShadowBias()".
+
+@ref TODO_IMAGE
+
+Valid shadow bias values are from -1 to 1. When value is 0 no shadow bias will be applied, while positive shadow bias values will offset the shadow distance as described above. However offseting the shadow distance may cause the objects to appear like they are floating even if they are in contact with a surface.
+
+@ref TODO_IMAGE
+
+By setting the shadow bias to a negative value you move the shadow backwards, resolving both the shadow acne and the floating object issue. However this only works if your geometry has thickness, otherwise elements behind the object will be incorrectly shadowed. This is generally the best option as long as you can set up your geometry correctly.
+
 ## Spot angles
 Spot light have a property that defines at how wide an angle do they cast light in. Narrower angle means a more focused light beam, while wider angle means a weaker light covering a larger area. 
 

+ 44 - 0
Documentation/Manuals/Native/User/renderSettings.md

@@ -0,0 +1,44 @@
+Render settings						{#renderSettings}
+===============
+
+@ref bs::RenderSettings "RenderSettings" is an object present on every **Camera** object. It can be retrieved through @ref bs::CCamera::getRenderSettings() "Camera::getRenderSettings()" and allows you to customize what rendering effects are executed when rendering the scene through that view. 
+
+For complete list of tweakable properties check the API reference, and here we'll just cover the main points.
+
+# HDR and tonemapping
+HDR stands for high-dynamic range, and it allows the lights in the scene to use a large range of intensity values that can more closely approximate a real-world scene. Lighting information is first written to a floating point texture that can store a wider range of values than a normal RGB texture. These high range lighting values are then used throughout the calculations in the engine, ensuring a higher quality final result. You can toggle HDR rendering through @ref bs::RenderSettings::enableHDR "RenderSettings::enableHDR".
+
+Before the image is output to the screen it goes through the process called tonemapping, which converts the high range values into low range that a normal output device (like a monitor or a TV) can display. Tonemapping can be toggled through @ref bs::RenderSettings::enableTonemapping "RenderSettings::enableTonemapping", but this is generally something you always want to have on when HDR rendering is enabled.
+
+@ref bs::RenderSettings::tonemapping "RenderSettings::tonemapping" provides you with a variety of tweakable options on how is tonemapping performed. Tonemapping operators are a complex topic, but it's enough to know that these options affect the feel and tone of the final image, and it is generally something you will tweak to suit the best look for your project.
+
+HDR and tonemapping is also closely related to exposure, which we'll cover next.
+
+# Exposure
+Exposure determines which part of the high range image should be converted to low range (e.g. the very bright parts, the very dark parts, or somewhere in the middle). Generally this is a property you will only use when HDR is enabled, as LDR doesn't offer a high enough range for this property to be relevant.
+
+By default the system will calculate the exposure automatically, based on how the human eye determines exposure. Generally this means if you are in a very bright area, it will be hard to see into darker areas (imagine standing outside in sunlight and looking into house lit only by artifical light), or when in a very dark area the bright areas will be overexposed. As you move between areas of different light intensity the exposure will slowly adjust accordingly. You can tweak automatic exposure options through @ref bs::RenderSettings::autoExposure "RenderSettings::autoExposure".
+
+Automatic exposure can be disabled through @ref bs::RenderSettings::enableAutoExposure "RenderSettings::enableAutoExposure". In this case you will want to set the exposure manually through @ref bs::RenderSettings::exposureScale "RenderSettings::exposureScale"
+
+# Screen space reflections
+This effect provides high quality, real-time reflections at a fairly low performance impact. The main limitation effect is that it is performed in screen-space, and therefore cannot reflect an object that's not currently on the screen. When reflection cannot be found the system will fall back onto reflection probes for reflections. The effect is also generally not suitable for perfect mirror-like reflections due to limited precision.
+
+You can control, and well as toggle the effect through @ref bs::RenderSettings::screenSpaceReflections "RenderSettings::screenSpaceReflections".
+
+# Screen space ambient occlusion
+TODO
+
+
+Also: White balance, color grading, FXAA, depth of field
+
+
+
+# Gamma
+Tweaks the gamma value that's applied to the image before being sent to the output device. Mainly affects the brightness of the image.
+
+# Shadows
+Shadow rendering for a specific view can be completely disabled through @ref bs::RenderSettings::enableShadows "RenderSettings::enableShadows". Shadow options that are view-specific can be controlled through @ref bs::RenderSettings::shadowSettings "RenderSettings::shadowSettings".
+
+# Indirect lighting
+Indirect lighting provided by **LightProbeVolume** can be fully disabled for a view through @ref bs::RenderSettings::enableIndirectLighting "RenderSettings::enableIndirectLighting".

+ 8 - 10
Documentation/Manuals/Native/User/renderingObjects.md

@@ -1,7 +1,7 @@
-Rendering objects						{#renderingObjects}
+Renderable object						{#renderingObjects}
 ===============
 
-We are now finally ready to start displaying things on the screen. To render something you must create the @ref bs::CRenderable "Renderable" component.
+As the name implies, the renderable object allows you to display an object in the scene. It is represeted by the @ref bs::CRenderable "Renderable" component. The component requires you to assign a **Mesh** to render, as well as a **Material** to render the mesh with. Both of these are resources, and we'll explain them in the following chapters.
 
 # Creating a renderable
 **Renderable** is created as any component, and requires no additional parameters.
@@ -11,13 +11,11 @@ HSceneObject renderableSO = SceneObject::create("3D object");
 HRenderable renderable = renderableSO->addComponent<CRenderable>();
 ~~~~~~~~~~~~~
 
-# Rendering a mesh
-Once created you must assign it a **Mesh** to render, and a **Material** to render it with, both of which we have discussed in the previous chapters. Use @ref bs::CRenderable::setMesh "CRenderable::setMesh()" and @ref bs::CRenderable::setMaterial "CRenderable::setMaterial()".
+# Setting it up
+Once created you must assign it a **Mesh** to render, and a **Material** to render it with. Use @ref bs::CRenderable::setMesh "CRenderable::setMesh()" and @ref bs::CRenderable::setMaterial "CRenderable::setMaterial()".
 
 ~~~~~~~~~~~~~{.cpp}
-... set up a camera ...
-
-// Create a standard material as in the previous chapter
+// Create a standard PBR material
 HShader shader = gBuiltinResources().getBuiltinShader(BuiltinShader::Standard);
 HMaterial material = Material::create(shader);
 
@@ -40,11 +38,11 @@ renderable->setMaterial(material);
 renderableSO->setPosition(Vector3(0.0f, 15.0f, 30.0f));
 ~~~~~~~~~~~~~
 
-> Note that even though we always import resources in these examples, in production code you should load previously saved resources instead of importing them every time, as earlier described in the resource related chapters.
+> Note that even though we always import resources in these examples, in production code you should load previously saved resources instead of importing them every time.
 
-After the renderable has been set up, it will now be displayed in your camera view, if the camera is facing the direction of the renderable object. You are of course allowed to change the renderable mesh and material, as well as reposition, scale or orient the renderable during runtime.
+After the renderable has been set up, it will now be displayed in your camera view (if the camera is facing the direction of the renderable object).
 
-## Multiple materials
+# Multiple materials
 In the example above we use a single material for a single mesh, but it can sometimes be useful to use different materials for different parts of the mesh.
 
 It is up to the artist (creator of the mesh) to specify the regions of the mesh that will use separate materials. Upon mesh import those regions will be recognized as sub-meshes.

+ 57 - 6
Documentation/Manuals/Native/User/resourceSavingAndLoading.md

@@ -16,7 +16,7 @@ HTexture texture = gImporter().import<Texture>("myTexture.jpg");
 gResources().save(texture, "myTexture.asset");
 ~~~~~~~~~~~~~
 
-Note that resources can also be created within the engine, and don't necessarily have to be imported. e.g. you can populate texture pixels or mesh vertices manually, and then save the resource in this same manner. We will show later how to manually create resources.
+Note that resources can also be created within the engine, and don't necessarily have to be imported. e.g. you can populate texture pixels or mesh vertices programatically, and then save the resource in this same manner. We will show later how to manually create resources.
 
 # Loading
 Once a resource has been saved you can load it at any time using @ref bs::Resources::load "Resources::load()". Lets load the texture we just saved:
@@ -27,12 +27,63 @@ HTexture loadedTexture = gResources().load<Texture>("myTexture.asset");
 
 > If you attempt to load a resource that has already been loaded, the system will return the existing resource.
 
-# Unloading
-Note that the resource system by default never unloads a loaded resource, unless told explicitly. To unload a resource call @ref bs::Resources::release "Resources::release()".
+# Asynchronous loading
+Resources can be loaded asynchronously (in the background) by calling @ref bs::Resources::loadAsync "Resources::loadAsync()". The interface is identical to **Resources::load()**. The main difference is that the returned handle will contain a reference to a resource that hasn't been loaded yet. 
+
+You can check if a resource handle is pointing to a loaded resource by calling @ref bs::ResourceHandle::isLoaded "ResourceHandle::isLoaded()".
+
+~~~~~~~~~~~~~{.cpp}
+HMesh mesh = gResources().loadAsync("myMesh.asset");
+
+if(mesh.isLoaded())
+{
+	// Check if loaded before doing something
+}
+~~~~~~~~~~~~~ 
+
+> Note that not-yet-loaded resource handles can be provided to some engine systems, but not all. Generally a system will note in its documentation if it works with such resource handles.
+
+You can block the current thread until a resource is loaded by calling @ref bs::ResourceHandle::blockUntilLoaded "ResourceHandle::blockUntilLoaded()".
 
-To unload the texture we loaded previously:
 ~~~~~~~~~~~~~{.cpp}
-gResources().release(loadedTexture);
+mesh.blockUntilLoaded();
+// Makes sure the mesh is loaded at this point
+~~~~~~~~~~~~~ 
+
+# Resource lifetime
+Whenever you load a resource, that resource will be kept loaded until all references to that resource are lost. Each resource handle (e.g. **HMesh**) that exists represents a single reference. By default an additional "internal" reference is also created and held by the system internally. This ensures the resource stays loaded even when all handles are destroyed.
+
+This internal reference must be released by calling @ref bs::Resources::release() "Resources::release()".
+
+~~~~~~~~~~~~~{.cpp}
+gResources().release(mesh);
 ~~~~~~~~~~~~~
 
-> Note that if you called **Resources::load()** multiple times, you must also call **Resources::release** the same amount of times.
+> Note that if you called **Resources::load()** multiple times, you must also call **Resources::release()** the same amount of times.
+
+But you can also force the system to not create the internal reference by passing a custom @ref bs::ResourceLoadFlag "ResourceLoadFlag" to the @ref bs::Resources::load() "Resources::load()" method. This flag should not include the @ref bs::ResourceLoadFlag::KeepInternalRef "ResourceLoadFlag::KeepInternalRef".
+
+~~~~~~~~~~~~~{.cpp}
+HMesh mesh = gResources().load("myMesh.asset", ResourceLoadFlag::Default & ~ResourceLoadFlag::KeepInternalRef);
+~~~~~~~~~~~~~ 
+
+# Weak handles
+In case you want to keep a reference to a resource without incrementing the reference count you can use a weak handle instead of a normal one. Weak handles are represented by the @ref bs::WeakResourceHandle<T> "WeakResourceHandle<T>" class and can be retrieved from normal handles by calling @ref bs::ResourceHandle<T>::getWeak "ResourceHandle<T>::getWeak()". Other than that they are accessed the same as normal handles.
+
+~~~~~~~~~~~~~{.cpp}
+// Load a mesh and store a handle as normal
+HMesh mesh = gResources().load("myMesh.asset");
+
+// Create a weak handle
+WeakResourceHandle<Mesh> weakMesh = mesh.getWeak();
+~~~~~~~~~~~~~ 
+
+# Resource dependencies
+Whenever you load a resource the system will automatically enumerate all dependencies of that resource and attempt to load them as well. For example when loading a **Material** it will automatically load its **Shader** and any referenced **Texture** resources.
+
+In case you wish to prevent that you can not provide the @ref bs::ResourceLoadFlag::LoadDependencies "ResourceLoadFlag::LoadDependencies" flag when calling **Resources::load()** (provided by default).
+
+~~~~~~~~~~~~~{.cpp}
+// Loads a resource without any dependencies, nor keeps an internal reference
+HMesh mesh = gResources().load("myMesh.asset", ResourceLoadFlag::None);
+~~~~~~~~~~~~~ 

+ 16 - 14
Documentation/Manuals/Native/User/scenesAndComponents.md

@@ -1,13 +1,13 @@
 Scene objects and components					{#scenesAndComponents}
 ===============
 
-All scenes in Banshee are constructed from scene objects. Each scene object is a part of the scene hierarchy, and can have a parent scene object and zero or multiple child scene objects. Each scene object can also be positioned, oriented and scaled within the scene.
+All scenes in bs::f are constructed from scene objects. Each scene object is a part of the scene hierarchy, and can have a parent scene object and zero or multiple child scene objects. Each scene object can also be positioned, oriented and scaled within the scene.
 
 Components can be attached to scene objects - each scene object can have zero or multiple components attached to it. Components provide various functionality and contain the logic for your game. For example there is a **Camera** component that lets the user see into the scene, or a **Renderable** component that represents a single 3D mesh in the scene. 
 
 Once your scene has been set up the engine takes care of everything else, like rendering your meshes. You may also create your own components to put custom game logic in, receive events from the game, process input and manipulate the scene after initial set up. We will go into detail on how to create custom components later.
 
-Let see an example where we add a single scene object to the scene, position it, and attach to it a **Renderable** component. For now you do not need to know exactly how **Renderable** component works, as we will explain that later. Focus rather on how a scene object is set up and and how components are added to it.
+Let see an example where we add a single scene object to the scene, position it, and attach a **Renderable** component to it. For now you do not need to know exactly how **Renderable** component works, as we will explain that later. Focus rather on how a scene object is set up and and how components are added to it.
 
 ~~~~~~~~~~~~~{.cpp}
 // Create a brand new scene object named My Object. It is placed at the root 
@@ -21,19 +21,19 @@ so->setPosition(Vector3(0, 30, 0));
 HRenderable renderable = so->addComponent<CRenderable>();
 ~~~~~~~~~~~~~
 
-> Extra: As a convention, almost all complex Banshee classes use the static **create** method as a way to create new objects. More simple classes and structures, like **Vector3**, use the traditional constructors instead.
+> As a convention, almost all complex classes in bs::f use the static **create** method as a way to create new objects. More simple classes and structures, like **Vector3**, use the traditional constructors instead.
 
 # Handles {#a}
-Whenever you wish to keep a reference to a scene object or a component you must do so via a handle. They are represented with classes prefixed with an "H", as you might have noticed in the example above. 
+Whenever you wish to keep a reference to a scene object or a component you do so via a handle. They are represented with classes prefixed with an "H", as you might have noticed in the example above. 
 
 Scene objects are always referenced using the **HSceneObject** handle, while components have handles named with an "H" prefix, followed by the component name (e.g. **HRenderable** for the **Renderable** component).
 
 You may treat the handles as pointers, using "->" to access their members, comparing them for equality or with *nullptr* to check their validity. 
 
 # Scene object creation and destruction {#b}
-We have already shown how to use @ref bs::SceneObject::create "SceneObject::create" to create a new scene object. 
+We have already shown how to use @ref bs::SceneObject::create "SceneObject::create()" to create a new scene object. 
 
-If you wish to destroy a scene object call @ref bs::SceneObject::destroy "SceneObject::destroy". Note that destroying a scene object will destroy all of the components attached to it, as well as any child scene objects.
+If you wish to destroy a scene object call @ref bs::SceneObject::destroy "SceneObject::destroy()". Note that destroying a scene object will destroy all of the components attached to it, as well as any child scene objects.
 
 ~~~~~~~~~~~~~{.cpp}
 // Create a scene object
@@ -44,9 +44,9 @@ so->destroy();
 ~~~~~~~~~~~~~
 
 # Transforming scene objects {#c}
-You can change scene object position, orientation and scale using @ref bs::SceneObject::setPosition "SceneObject::setPosition", @ref bs::SceneObject::setRotation "SceneObject::setRotation" and @ref bs::SceneObject::setScale "SceneObject::setScale".
+You can change scene object position, orientation and scale using @ref bs::SceneObject::setPosition "SceneObject::setPosition()", @ref bs::SceneObject::setRotation "SceneObject::setRotation()" and @ref bs::SceneObject::setScale "SceneObject::setScale()".
 
-Components attached to scene objects will reflect the scene object transform. For example, moving a scene object with a **Renderable** component will make the 3D meshes referenced by **Renderable** display in a different location in the scene.
+Components attached to scene objects will reflect the scene object transform. For example, moving a scene object with a **Renderable** component will make the 3D mesh referenced by **Renderable** display in a different location in the scene.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject so = SceneObject::create("My object");
@@ -61,7 +61,9 @@ so->setRotation(Quaternion(Degree(0), Degree(90), Degree(0)));
 so->setScale(Vector3(2.0f, 2.0f, 2.0f));
 ~~~~~~~~~~~~~
 
-> Extra: There also other useful methods when it comes to dealing with scene object positions and orientations, like @ref bs::SceneObject::move "SceneObject::move", @ref bs::SceneObject::lookAt "SceneObject::lookAt" or @ref bs::SceneObject::getForward "SceneObject::getForward". See the @ref bs::SceneObject "SceneObject" API reference for a full overview.
+Internally these methods manipulate a @ref bs::Transform "Transform" object. You can also retrieve the transform from a scene object and manipulate it directly for greater control. To retrieve the world-space transform call @ref bs::SceneObject::getTransform() "SceneObject::getTransform()".
+
+There also other useful methods when it comes to dealing with scene object positions and orientations, like @ref bs::SceneObject::move "SceneObject::move()", @ref bs::SceneObject::lookAt "SceneObject::lookAt()". See the @ref bs::SceneObject "SceneObject" API reference for a full overview.
 
 # Scene object hierarchy {#d}
 As mentioned, scene objects can be arranged in a hierarchy. Hierarchies allow you to transform multiple scene objects at once, since any transforms applied to a parent will also be applied to a child.
@@ -94,14 +96,14 @@ childB->setParent(parent);
 parent->setPosition(Vector3(30, 0, 0));
 ~~~~~~~~~~~~~
 
-> Extra: You may query for parent and children of a scene object using methods like @ref bs::SceneObject::getParent "SceneObject::getParent", @ref bs::SceneObject::getNumChildren "SceneObject::getNumChildren", @ref bs::SceneObject::getChild "SceneObject::getChild" or @ref bs::SceneObject::findChild "SceneObject::findChild". See the @ref bs::SceneObject "SceneObject" API reference for a full overview.
+You may query for parent and children of a scene object using methods like @ref bs::SceneObject::getParent "SceneObject::getParent()", @ref bs::SceneObject::getNumChildren "SceneObject::getNumChildren()", @ref bs::SceneObject::getChild "SceneObject::getChild()" or @ref bs::SceneObject::findChild "SceneObject::findChild()". See the @ref bs::SceneObject "SceneObject" API reference for a full overview.
 
 # Components {#e}
-You may add components to a scene object using the @ref bs::SceneObject::addComponent<T, Args...> "SceneObject::addComponent<T>" method. 
+You may add components to a scene object using the @ref bs::SceneObject::addComponent<T, Args...> "SceneObject::addComponent<T>()" method. 
 
-You may retrieve existing components by calling @ref bs::SceneObject::getComponent<T> "SceneObject::getComponent<T>".
+You may retrieve existing components by calling @ref bs::SceneObject::getComponent<T> "SceneObject::getComponent<T>()".
 
-Components can be removed by calling the @ref bs::Component::destroy "Component::destroy" method on the component.
+Components can be removed by calling the @ref bs::Component::destroy "Component::destroy()" method on the component.
 
 ~~~~~~~~~~~~~{.cpp}
 HSceneObject so = SceneObject::create("My object");
@@ -116,4 +118,4 @@ HRenderable renderable = so->getComponent<CRenderable>();
 renderable->destroy();
 ~~~~~~~~~~~~~
 
-> Extra: As a convention, all component class names are prefixed with a "C".
+> As a convention, all component class names are prefixed with a "C".

+ 10 - 13
Documentation/Manuals/Native/User/simpleMaterial.md

@@ -1,25 +1,25 @@
 Materials 						{#simpleMaterial}
 ===============
 
-Materials are objects that control how are meshes rendered. They are represented using the @ref bs::Material "Material" class. Each material must have one @ref bs::Shader "Shader" object, and zero or more parameters.
+Materials are resources that control how are meshes rendered. They are represented using the @ref bs::Material "Material" class. Each material must have one @ref bs::Shader "Shader" object, and zero or more parameters.
 
-A shader is a set of GPU programs and render states that tell the GPU how is a mesh meant to be rendered. Most GPU programs in the shader have parameters that can be used for cutomizing the shader output. The primary use of the material is to allow the user to set those parameters. You can think of shaders as templates, and materials as instances of shaders - similar as you would think of a *class* vs. *object* relationship in a programming language.
+A shader is a set of GPU programs and render states that tell the GPU how is a mesh meant to be rendered. Generally these GPU programs have parameters that can control what they output (for example, which texture to use). A material allows you to set those parameters. You can think of shaders as templates, and materials as instances of shaders - similar as you would think of a *class* vs. *object* relationship in a programming language.
 
 # Retrieving a shader
-Before we can create a material we first need to pick a shader to use as a basis. Banshee allows you to create fully custom shaders, but this is an advanced topic and is left for a later chapter. For the majority of purposes when rendering 3D geometry you can use either of the following two shaders:
+Before we can create a material we first need to pick a shader to use as a basis. bs::f allows you to create fully custom shaders, but this is an advanced topic and is left for a later chapter. For the majority of purposes when rendering 3D geometry you can use either of the following two shaders:
  - Standard - Physically based shader for opaque 3D geometry
  - Transparent - Physically based shader for transparent 3D geometry
 
-Both of those shaders can be accessed through @ref bs::BuiltinResources::getBuiltinShader "BuiltinResources::getBuiltinShader()" using the values @ref bs::BuiltinShader::Standard "BuiltinShader::Standard" and @ref bs::BuiltinShader::Transparent "BuiltinShader::Transparent" respectively. @ref bs::BuiltinResources "BuiltinResources" can be globally accessed through @ref bs::BuiltinResources::instance() "BuiltinResources::instance()" and aside from shaders provides a variety of other resources that are always available.
+Both of those shaders can be accessed through @ref bs::BuiltinResources::getBuiltinShader "BuiltinResources::getBuiltinShader()" using the values @ref bs::BuiltinShader::Standard "BuiltinShader::Standard" and @ref bs::BuiltinShader::Transparent "BuiltinShader::Transparent" respectively.
 
 ~~~~~~~~~~~~~{.cpp}
-// Get the standard built-in shader
+// Get the standard PBR shader
 HShader shader = BuiltinResources::instance().getBuiltinShader(BuiltinShader::Standard);
 ~~~~~~~~~~~~~
 
 Both of these shaders provide physically based shading and expect four different parameters (see below on how to set parameters):
- - **gAlbedoTex** - RGBA texture representing the color of the object's surface. If using the transparent shader, alpha channels determines the amount of transparency.
- - **gNormalTex** - Normal map (texture containing surface normals)
+ - **gAlbedoTex** - RGBA texture representing the color of the object's surface. If using the transparent shader, alpha channel determines the amount of transparency.
+ - **gNormalTex** - Normal map (texture containing surface normals encoded into RGB channels)
  - **gRoughnessTex** - 1D texture that determines the roughness of the surface. Values closer to 1 mean a more rough (less reflective) surface, while values closer to 0 mean less rough (more reflective, mirror like) surface.
  - **gMetalnessTex** - 1D texture that determines if the part of the surface is a metal or a dieletric. This texture should only generally contain values 1 (metal) or 0 (dieletric). Metal surfaces are reflective reflective while dieletric ones are not.
 
@@ -56,9 +56,9 @@ material->setMat4("someTransform", Matrix4::IDENTITY);
 ~~~~~~~~~~~~~
 
 ## Sampler states
-Sampler states are a special type of parameters that can be set by calling @ref bs::Material::setSamplerState "Material::setSamplerState()". These states are used to control how is a texture read in a shader - for example they control what type of filtering to use, how to handle out of range texture coordinates and similar. Sampler states are created by calling @ref bs::SamplerState::create "SamplerState::create()", while previously filling out the @ref bs::SAMPLER_STATE_DESC "SAMPLER_STATE_DESC" structure.
+Sampler states are a special type of parameters that can be set by calling @ref bs::Material::setSamplerState "Material::setSamplerState()". These states are used to control how is a texture read in a shader. For example they control what type of filtering to use, how to handle out of range texture coordinates and similar. In most cases you don't need to set sampler states as the default one should be adequate. 
 
-In most cases you don't need to set sampler states as the default one should be adequate. Shaders can also read textures without samplers by directly accessing their pixels, but this is not wanted for normal rendering as it ruins image quality due to the lack of filtering and it may not be as performance efficient. 
+Sampler states are created by calling @ref bs::SamplerState::create "SamplerState::create()", while previously filling out the @ref bs::SAMPLER_STATE_DESC "SAMPLER_STATE_DESC" structure.
 
 As an example, lets set up a sampler state that enables trilinear filtering for a texture using it, and then assign it to a material. 
 
@@ -74,7 +74,4 @@ SPtr<SamplerState> samplerState = SamplerState::create(desc);
 // used in the example above. It controls options for the texture set on the gAlbedoTex
 // parameter.
 material->setSamplerState("gAlbedoSamp", samplerState);
-~~~~~~~~~~~~~
-
-# Using a material for rendering
-Once a material is created and parameters are set, it can be used for rendering by attaching it to a **Renderable** component. We will cover them in the next chapter.
+~~~~~~~~~~~~~

+ 70 - 13
Documentation/Manuals/Native/User/startingUp.md

@@ -1,7 +1,28 @@
 Startup and main loop					{#startup}
 ===============
 
-Before any work can be done with Banshee, it must first be started through the @ref bs::Application "Application" interface. 
+**Preparation**
+
+Start by including *BsApplication.h* header into your project. It contains the @ref bs::Application "Application" class which is the primary entry point into bs::f.
+
+Entirety of bs::f API is contained in the **bs** namespace, so you will also likely want to add a `using namespace bs;` directive.
+
+~~~~~~~~~~~~~{.cpp}
+#include "BsApplication.h"
+
+using namespace bs;
+
+int main()
+{
+	// ...
+
+	return 0;
+}
+~~~~~~~~~~~~~
+
+**Start up**
+
+bs::f can then be started by calling @ref bs::Application::startUp "Application::startUp()". By default bs::f always creates a single window on start-up, and the method expects you to provide the initial resolution of the window, window title and an optional fullscreen flag.
 
 ~~~~~~~~~~~~~{.cpp}
 // Start an application in windowed mode using 1280x720 resolution
@@ -9,24 +30,60 @@ Application::startUp(
 	VideoMode(1280, 720), // Window resolution
 	"My app", // Window title
 	false); // True for fullscreen, false for windowed
+~~~~~~~~~~~~~
+
+**Scene setup**
 
-// Set up your scene here
+After the application has been started you can proceed to load necessary resources, create scene objects and set up their components.
 
-Application::instance().runMainLoop();
-Application::shutDown();
+By default bs::f uses an entity/component model for managing its scene. The scene is represented through scene objects which can be positioned and oriented in the scene, on which you attach components that execute some logic. Components can be built-in providing basic functionality like rendering an object, or they can be user-created and execute gameplay logic. You will also load resources like meshes and textures, which can then be provided to components.
+
+We will go into much more detail about components in the next manual, but a quick example below shows how you would add a camera component in the scene.
+
+~~~~~~~~~~~~~{.cpp}
+// Add a scene object containing a camera component
+SPtr<RenderWindow> window = gApplication().getPrimaryWindow();
+HSceneObject sceneCameraSO = SceneObject::create("SceneCamera");
+HCamera sceneCamera = sceneCameraSO->addComponent<CCamera>(window);
+
+sceneCameraSO->setPosition(Vector3(40.0f, 30.0f, 230.0f));
+sceneCameraSO->lookAt(Vector3(0, 0, 0));
 ~~~~~~~~~~~~~
 
-@ref bs::Application::startUp "Application::startUp" expects you to provide the resolution for the primary application window, its title and a couple of optional parameters.
+**Running the main loop**
+
+Once your scene has been set up, you need to start running the main loop by calling @ref bs::Application::runMainLoop "Application::runMainLoop()". The main loop will trigger updates on all the components you have set up, allowing you to execute game-logic.
+
+**Stopping the main loop**
 
-> Advanced: You can perform a more customized startup by filling out the @ref bs::START_UP_DESC "START_UP_DESC" structure and passing it to **Application::startUp**.
+The main loop runs indefinitely until terminated by the user. You may call @ref bs::Application::stopMainLoop "Application::stopMainLoop()" to exit the loop.
+
+**Shutting down**
+
+Once the main loop has been stopped, you will want to clean up any allocated resources by calling @ref bs::Application::shutDown "Application::shutDown()".
+
+**Complete example**
+
+Here's a complete code of what we have so far. The code doesn't do much - it opens up a basic window and adds a camera to the scene. Since we haven't actually added any renderable objects to the scene the camera wont see anything. The code also doesn't respond to any input and therefore doesn't offer any way for the user to stop the main loop.
+
+~~~~~~~~~~~~~{.cpp}
+#include "BsApplication.h"
 
-Following a call to **bs::Application::startUp** you are expected to set up your scene, which we will cover in later manuals.
+using namespace bs;
 
-# Main loop
-Following start-up we run the main game loop by calling @ref bs::Application::runMainLoop "Application::runMainLoop". This is where your game runs, where every frame is updated and rendered.
+int main()
+{
+	Application::startUp(VideoMode(1280, 720),"My app", false);
 
-# Shut down
-Finally, when the user decides to close the application and the main loop exits, we wish to clean up the application by calling @ref bs::Application::shutDown "Application::shutDown".
+	SPtr<RenderWindow> window = gApplication().getPrimaryWindow();
+	HSceneObject sceneCameraSO = SceneObject::create("SceneCamera");
+	HCamera sceneCamera = sceneCameraSO->addComponent<CCamera>(window);
 
-# Scene setup
-You are expected to perform initial scene setup in-between the **Application::startUp** and **Application::runMainLoop**, as we will demonstrate later.
+	sceneCameraSO->setPosition(Vector3(40.0f, 30.0f, 230.0f));
+	sceneCameraSO->lookAt(Vector3(0, 0, 0));
+	
+	Application::runMainLoop();
+	Application::shutDown();
+	return 0;
+}
+~~~~~~~~~~~~~

+ 0 - 9
Documentation/Manuals/Native/User/windows.md

@@ -5,15 +5,6 @@ A window represents the final destination where the application's rendered outpu
 
 ![Render window](RenderWindow.png)  
 
-# Primary window
-When we initialized the application by calling **Application::startUp** in a previous chapter a primary window was created for us by default. You can access this window through @ref bs::Application::getPrimaryWindow "Application::getPrimaryWindow()".
-
-~~~~~~~~~~~~~{.cpp}
-SPtr<RenderWindow> primaryWindow = gApplication().getPrimaryWindow();
-~~~~~~~~~~~~~
-
-> **gApplication()** is just a shortcut for **Application::instance()** we used earlier.
-
 # Creating windows
 You can also create your own windows by filling out the @ref bs::RENDER_WINDOW_DESC "RENDER_WINDOW_DESC" structure and calling @ref bs::RenderWindow::create "RenderWindow::create()".
 

+ 43 - 0
Documentation/Manuals/Native/devManuals.md

@@ -0,0 +1,43 @@
+Developer manuals									{#devManuals}
+===============
+
+- [Architecture overview](@ref architecture) 
+- **Low level rendering API**
+ - [Core thread](@ref coreThread)
+ - [GPU programs](@ref gpuPrograms)
+ - [Non-programmable states](@ref nonProgrammableStates)
+ - [Geometry](@ref geometry)
+ - [Render targets](@ref renderTargets)
+ - [Drawing](@ref drawing) 
+ - [Load-store textures](@ref loadStoreTextures)
+ - [GPU buffers](@ref gpuBuffers)
+ - [Compute](@ref compute)
+ - [Command buffers](@ref commandBuffers)
+ - [GPU profiling](@ref gpuProfiling)
+ - [Working example](@ref lowLevelRenderingExample)
+- **More utilities**
+ - [Modules](@ref modules)
+ - [Advanced memory allocation](@ref advMemAlloc)
+ - [Crash handling](@ref crashHandling)
+ - [Dynamic libraries](@ref dynLib)
+ - [Flags](@ref flags)
+ - [Any](@ref any) 
+ - [Unit tests](@ref unitTests)
+- [Advanced materials](@ref advMaterials)
+- [Threading](@ref threading)
+- [Plugins](@ref plugins)
+- **Renderer**
+ - [Renderer extensions](@ref rendererExtensions)
+ - [Creating a renderer plugin](@ref customRenderer)
+- **Resources**
+ - [Creating new resource types](@ref customResources)
+ - [Creating custom importers](@ref customImporters)
+- **Scripting**
+ - [Exposing code to script API (automated)](@ref scriptingAuto)
+ - **Exposing code to script API (manually)**
+  - [Interacting with the script runtime](@ref mono)
+  - [Script objects](@ref scriptObjects)
+- [Extending the GUI system](@ref customGUI)
+- [Porting to other platforms](@ref porting)
+- [Code style](@ref codeStyle)
+- [Quick reference](@ref quickref)

+ 10 - 15
Documentation/Manuals/Native/index.md

@@ -1,25 +1,20 @@
-Banshee Framework Documentation (Native)						{#mainpage}
+bs::framework Documentation						{#mainpage}
 ===============
 
-[TOC]
+Welcome to the documentation for bs::framework.
 
-Welcome to the documentation for the Banshee Framework.
-
-This documentation contains a set of [manuals](@ref manuals) and an API reference for all native types.
+This documentation contains a set of manuals and a complete API reference.
 
 # Manuals # {#mainpage_a}
-Manuals should be your primary entry point into learning about Banshee. They can be split into two main categories:
- - User manuals - They explain how to use the provided API in order to create an application of your own, guiding you from basics through all the important systems. This is what most people will be interested in.
- - Developer manuals - They will provide you with a view of the general architecture of the framework, as well as the architecture of the more important systems. They will also teach you how to extend/modify various parts of the framework, including adding custom GUI types, script objects, resources, importers, renderers and many more. They are intended for those planning to extend or modify the framework in some way.
-
-[Visit](@ref manuals) 
+Manuals should be your primary entry point into learning about bs::f. They can be split into two main categories:
+ - [User manuals](@ref manuals)  - They explain how to use the provided API in order to create an application of your own, guiding you from basics through all the important systems. This is what most people will be interested in.
+ - [Developer manuals](@ref devManuals) - They will provide you with a view of the general architecture of the framework, as well as the architecture of the more important systems. They give you deeper insight of how everything works, as well as teaching you how to
+ extend/modify various parts of the framework.
  
 # API Reference # {#mainpage_b}
 API reference provides a categorized and hierarchical view of all the framework's classes. 
 
 All classes are categorized into three primary groups:
- - <a class="el" href="group___layers.html">Core API</a> - Contains documentation for the user-facing API of the framework core, categorized per layer. Each layer is built directly on top of the previous one. This is what most users will be interested in. 
- - <a class="el" href="group___internals.html">Internals</a> - Reference documentation for internals of the framework core, categorized per layer. Primarily useful for those modifying the framework but of less relevance for normal users.
- - <a class="el" href="group___plugins.html">Plugins</a> - Reference documentation for all available plugins. Plugins are various interchangeable libraries that contain high level systems built on top of abstractions defined in the framework core. If you are modifying the framework you might be interested in this documentation, but it can be skipped for most normal users.
- 
-You should read the [architecture](@ref architecture) manual for a more detailed breakdown of the architecture.
+ - <a class="el" href="group___layers.html">Core API</a> - Contains documentation for the user-facing API. This represents the main API that normal users will work with. 
+ - <a class="el" href="group___internals.html">Internals</a> - Reference documentation for internals of the framework core. Primarily useful for those modifying the framework but of less relevance for normal users.
+ - <a class="el" href="group___plugins.html">Plugins</a> - Reference documentation for all available plugins. Plugins are various interchangeable libraries that contain high level systems built on top of abstractions defined in the framework core. If you are modifying the framework you might be interested in this documentation, but it can be skipped for most normal users.

+ 33 - 75
Documentation/Manuals/Native/manuals.md

@@ -1,41 +1,28 @@
-Manuals									{#manuals}
+User manuals									{#manuals}
 ===============
 
-# Quick start
-[Getting started](@ref gettingStarted) - This is a short guide on how to create a fully functional Banshee application, aimed to get you up and running quickly, without going into too much detail.
-
-# User manuals
-A complete set of manuals covering all major functionality provided by Banshee, starting with basics and slowly guiding you through more advanced concepts. This should be the primary entry point for new users.
+- Compiling the framework
+- Creating a project
 - [Startup and main loop](@ref startup)
 - [Scene objects and components](@ref scenesAndComponents)
 - **Resources**
  - [Basics and import](@ref resourceBasicsAndImport)
  - [Saving and loading](@ref resourceSavingAndLoading)
-- **Utilities**
- - [Containers](@ref containers)
- - [Strings](@ref strings)
- - [Memory allocation](@ref memory)
- - [Smart pointers](@ref smartPointers) 
- - [Events](@ref events)
- - [File system](@ref fileSystem) 
- - [Math utilities](@ref mathUtilities)
- - [Logging messages](@ref logging)
- - [Measuring time](@ref time)
-- **Graphics**
- - [Windows](@ref windows)
- - [Cameras](@ref cameras)
- - [Importing textures](@ref importingTextures)
- - [Importing meshes](@ref importingMeshes)
+- **Basic rendering**
+ - [Camera](@ref cameras)
+ - [Renderable object](@ref renderingObjects)
+ - [Meshes](@ref importingMeshes)
  - [Materials](@ref simpleMaterial)
- - [Rendering objects](@ref renderingObjects)
- - [Lighting](@ref lights)
- - [Image based lighting](@ref imageBasedLighting)
+ - [Textures](@ref importingTextures)
+ - [Lighting](@ref lights) 
 - **Input**
  - [Input polling](@ref inputPolling) 
  - [Input events](@ref inputEvents) 
  - [Virtual input](@ref virtualInput)
-- [Creating custom components](@ref customComponents)
-- [Serializing objects](@ref serializingObjects)
+- **Gameplay logic**
+ - [Creating custom components](@ref customComponents)
+ - [Serializing objects](@ref serializingObjects)
+ - Non-component approach
 - **GUI**
  - [Sprite textures](@ref spriteTextures)
  - [Basic setup](@ref guiSetup)
@@ -61,60 +48,31 @@ A complete set of manuals covering all major functionality provided by Banshee,
  - [Playing animation](@ref animation)
  - [Bones](@ref bones)
  - [Advanced animation](@ref advancedAnimation)
-- **Advanced**
- - **Shaders**
+- **Advanced rendering**
+ - [Image based lighting](@ref imageBasedLighting)
+ - Indirect lighting
+ - [Renderer settings](@ref renderSettings)
+ - [Offscreen rendering](@ref offscreenRendering)
+ - [Windows](@ref windows)
+ - **Custom materials**
   - [BSL syntax](@ref bsl)
   - [Importing shaders](@ref importingShaders)
   - [Surface & lighting shaders](@ref surfaceShaders)
+- **Utilities**
+ - [Containers](@ref containers)
+ - [Strings](@ref strings)
+ - [Memory allocation](@ref memory)
+ - [Smart pointers](@ref smartPointers) 
+ - [Events](@ref events)
+ - [File system](@ref fileSystem) 
+ - [Math utilities](@ref mathUtilities)
+ - [Logging messages](@ref logging)
+ - [Measuring time](@ref time)
+ - [Cursors](@ref cursors)
+ - [Profiling](@ref cpuProfiling)
+- **Advanced**
  - [Manipulating textures](@ref advancedTextures)
- - [Offscreen rendering](@ref offscreenRendering)
  - [Creating meshes](@ref creatingMeshes)
  - [Advanced startup](@ref advancedStartup)
  - [Advanced RTTI](@ref advancedRtti)
- - [Advanced resources](@ref advResources)
  - [Prefabs](@ref prefabs)
- - [Cursors](@ref cursors)
- - [Profiling](@ref cpuProfiling)
- 
-# Developer manuals
-A set of manuals covering advanced functionality intented for those wanting to extend the engine or tinker with the internals, rather than for normal users. You are expected to have read the user manuals first.
-- [Architecture overview](@ref architecture) 
-- **Low level rendering API**
- - [Core thread](@ref coreThread)
- - [GPU programs](@ref gpuPrograms)
- - [Non-programmable states](@ref nonProgrammableStates)
- - [Geometry](@ref geometry)
- - [Render targets](@ref renderTargets)
- - [Drawing](@ref drawing) 
- - [Load-store textures](@ref loadStoreTextures)
- - [GPU buffers](@ref gpuBuffers)
- - [Compute](@ref compute)
- - [Command buffers](@ref commandBuffers)
- - [GPU profiling](@ref gpuProfiling)
- - [Working example](@ref lowLevelRenderingExample)
-- **More utilities**
- - [Modules](@ref modules)
- - [Advanced memory allocation](@ref advMemAlloc)
- - [Crash handling](@ref crashHandling)
- - [Dynamic libraries](@ref dynLib)
- - [Flags](@ref flags)
- - [Any](@ref any) 
- - [Unit tests](@ref unitTests)
-- [Advanced materials](@ref advMaterials)
-- [Threading](@ref threading)
-- [Plugins](@ref plugins)
-- **Renderer**
- - [Renderer extensions](@ref rendererExtensions)
- - [Creating a renderer plugin](@ref customRenderer)
-- **Resources**
- - [Creating new resource types](@ref customResources)
- - [Creating custom importers](@ref customImporters)
-- **Scripting**
- - [Exposing code to script API (automated)](@ref scriptingAuto)
- - **Exposing code to script API (manually)**
-  - [Interacting with the script runtime](@ref mono)
-  - [Script objects](@ref scriptObjects)
-- [Extending the GUI system](@ref customGUI)
-- [Porting to other platforms](@ref porting)
-- [Code style](@ref codeStyle)
-- [Quick reference](@ref quickref)

+ 1 - 1
Documentation/Manuals/Native/modules.md

@@ -2,7 +2,7 @@ Modules									{#modules}
 ===============
 [TOC]
 
-A @ref bs::Module<T> "Module<T>" is a specialized form of singleton used for many of Banshee's systems. Unlike standard singletons it requires manual startup and shutdown. To use it for your own objects, simply inherit from it and provide your own class as its template parameter.
+A @ref bs::Module<T> "Module<T>" is a specialized form of singleton used for many of bs::f systems. Unlike standard singletons it requires manual startup and shutdown. To use it for your own objects, simply inherit from it and provide your own class as its template parameter.
 
 ~~~~~~~~~~~~~{.cpp}
 class MyModule : public Module<MyModule>