Merge branch 'master' of https://github.com/vsg-dev/vsgTutorial

1_SettingTheScene/01_hello_world/hello_world.cpp

@@ -37,14 +37,14 @@ int main(int, char**)
     // add close handler to respond to pressing the window close window button and pressing escape
     viewer->addEventHandler(vsg::CloseHandler::create(viewer));
 
-    // add a trackball event handler to control the camera view use the mouse
+    // add a trackball event handler to control the camera view using the mouse
     viewer->addEventHandler(vsg::Trackball::create(camera));
 
     // create a command graph to render the scene on specified window
     auto commandGraph = vsg::createCommandGraphForView(window, camera, scene);
     viewer->assignRecordAndSubmitTaskAndPresentation({commandGraph});
 
-    // compile all the the Vulkan objects and transfer data required to render the scene
+    // compile all the Vulkan objects and transfer data required to render the scene
     viewer->compile();
 
 //
@@ -61,7 +61,7 @@ int main(int, char**)
         // record the commands in the scene graph and submit the completed command buffers to the vulkan queue
         viewer->recordAndSubmit();
 
-        // wait for completion of the rendering and present the result color buffer to the Windows swap chain.
+        // wait for completion of the rendering and present the resulting color buffer to the Window's swap chain.
         viewer->present();
     }
 

1_SettingTheScene/BuildingVulkanSceneGraph.md

@@ -4,11 +4,11 @@ title: Building VulkanSceneGraph software
 permalink: /SettingTheScene/BuildingVulkanSceneGraph
 ---
 
-To conclude this chapter we'll look at building the VulkanSceneGraph projects and a minimal standalone **hello world** application.
+To conclude this chapter, we'll look at building the VulkanSceneGraph projects and a minimal standalone **hello world** application.
 
-All VulkanSceneGraph projects, including the vsgTutorial exercises, are written in C++17 and using CMake as the cross-platform build system. To aid integration of the VulkanSceneGraph projects with other software, CMake config files are installed along with headers and libraries.  CMake config files provide details of the libraries, header locations and any compiler definitions that are required when building software that use VulkanSceneGraph libraries and help to avoid issues when working across different platforms and with differences in static and dynamic library builds.
+All VulkanSceneGraph projects, including the vsgTutorial exercises, are written in C++17 and use CMake as the cross-platform build system.  To aid integration of the VulkanSceneGraph projects with other software, CMake config files are installed along with headers and libraries.  CMake config files provide details of the libraries, header locations and any compiler definitions that are required when building software that uses VulkanSceneGraph libraries and help to avoid issues when working across different platforms and with differences in static and dynamic library builds.
 
-The first task is to check out the main repositories and vsgTutorial for its exercises, for brevity we'll assume you have a Debian-based system and install headers, libraries and cmake files locally and set env paths up to find the install locations, this way there is no need to install to system directories. If you have other types of system use one of the alternative build instructions:
+The first task is to check out the main repositories and vsgTutorial for its exercises, for brevity we'll assume you have a Debian-based system and install headers, libraries and CMake files locally and set env paths up to find the install locations, this way there is no need to install to system directories.  If you have other types of systems, use one of the alternative build instructions:
 * Windows - to be written (looking for volunteers to write this.)
 * macOS - to be written (looking for volunteers to write this.)
 
@@ -19,18 +19,18 @@ First we'll set up some environment variable, for ease of use you may wish to pu
 export INSTALL_DIR=~/Install
 export PROJECT_DIR=~/Projects
 export PATH=${PATH}:${INSTALL_DIR}/bin
-export LD_LIBRARY_PATH=${D_LIBRARY_PATH}:${INSTALL_DIR}/lib
+export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${INSTALL_DIR}/lib
 
 # env vars that are used to find example data, and locating where to cache files downloaded from HTTP during database paging
 export VSG_FILE_PATH=${PROJECT_DIR}/vsgExamples/data
 export VSG_FILE_CACHE=${PROJECT_DIR}/vsgFileCache
 
-# only required if you use VulkanSDK rather than installing vulkan from distro repositories
+# only required if you use VulkanSDK rather than installing Vulkan from distro repositories
 export VULKAN_SDK=${INSTALL_DIR}/VulkanSDK
 export PATH=${PATH}:${VULKAN_SDK}/bin
 ~~~
 
-Next install dependencies, under debian these are:
+Next install dependencies, under Debian these are:
 
 ~~~ sh
 # dependencies useful for building the VulkanSceneGraph
@@ -44,7 +44,7 @@ sudo apt-get install libvulkan-dev vulkan-tools vulkan-validationlayers
 sudo apt-get install libassimp-dev libfreetype-dev libopenexr-dev
 ~~~
 
-If you want to use the VulkanSDK instead of distro vulkan package you download it from [LunarG](https://vulkan.lunarg.com/sdk/home):
+If you want to use the VulkanSDK instead of the distro vulkan package, download it from [LunarG](https://vulkan.lunarg.com/sdk/home):
 
 ~~~ sh
 wget https://sdk.lunarg.com/sdk/download/1.3.239.0/linux/vulkansdk-linux-x86_64-1.3.239.0.tar.gz
@@ -87,7 +87,7 @@ To test out examples:
 ~~~ sh
 vsgdraw
 vsgviewer models/lz.vsgt
-vsgdynamictextures
+vsgdynamictexture
 ~~~
 
 ---

1_SettingTheScene/DevelopmentPrinciples.md

@@ -4,50 +4,52 @@ title: Development Principles
 permalink: /SettingTheScene/DevelopmentPrinciples
 ---
 
-The VulkanSceneGraph Project goal is to make the development of high performance graphics and compute application quick and easy.  Vulkan provides an excellent base for achieving high performance but is low-level and complicated to use. Simply wrapping a C API in C++ is not sufficient for application developers needs, a collection of high-level features that make development easy is what is required. The ***Vulkan Made Easy*** tag line was adopted for the vsg-dev github account as a daily reminder of our the projects fundamental goal.
+The VulkanSceneGraph Project goal is to make the development of high-performance graphics and compute applications quick and easy.  Vulkan provides an excellent base for achieving high performance but is low-level and complicated to use.  Simply wrapping a C API in C++ is not sufficient for application developers' needs, a collection of high-level features that make development easy is what is required.  The ***Vulkan Made Easy*** tag line was adopted for the vsg-dev GitHub account as a daily reminder of our project's fundamental goal.
 
-The VulkanSceneGraph library is built upon the Scene Graph concept and is written specifically for Vulkan. Just as Vulkan is the successor to OpenGL, one that has wholly different API and architecture but retains the fundamental goal of providing a low-level, open, cross platform hardware abstraction, the VulkanSceneGarph is successor to the OpenSceneGraph, it also has an entirely different API and architecture but retains the fundamental goal of providing an open, cross patform high performance API for application developers.
+The VulkanSceneGraph library is built upon the Scene Graph concept and is written specifically for Vulkan.  Just as Vulkan is the successor to OpenGL, one that has wholly different API and architecture but retains the fundamental goal of providing a low-level, open, cross platform hardware abstraction, the VulkanSceneGraph is successor to the OpenSceneGraph, it also has an entirely different API and architecture but retains the fundamental goal of providing an open, cross platform high-performance API for application developers.
 
 ## Productivity and Performance
 
 The underlying principles that guided the VulkanSceneGraph development are the desire to enable application developers to be as ***Productive*** as possible while delivering the best ***Performance*** possible.  These two are often competing principles, to deliver both at the same time requires good engineering - one must continually strive to write better class interfaces and implementations, to seek out simple yet flexible and efficient solutions.
 
 The process of refining the software to better meet the needs of application developers won't stop with the VulkanSceneGraph-1.0 release, as the software develops these guiding principles will remain and we'll keep striving to deliver on the mantra Vulkan Made Easy.
 
-As open source middle-ware used by developers we aspire for the software to be not just useful for the functionality it provides, but also as an example of good software, illustrating how to write modern C++ software and avoid the many pitfalls of writing advanced software.
+As open-source middleware used by developers we aspire for the software to be not just useful for the functionality it provides, but also as an example of good software, illustrating how to write modern C++ software and avoid the many pitfalls of writing advanced software.
 
 ## Approach to Development
 
-The VulkanSceneGraph is an open source project in license and practice:
+The VulkanSceneGraph is an open-source project in license and practice:
 * From day 1 all work has been published on github and made available to all under the [MIT](https://github.com/vsg-dev/VulkanSceneGraph/blob/master/LICENSE.md) license.
-* Fully embrace the capabilities of C++ 17, modern CMAke and Github for building software, managing software and communicating.
+* Fully embrace the capabilities of C++ 17, modern CMake and GitHub for building software, managing software and communicating.
 * Take lessons from developing the OpenSceneGraph, elements that are strong are updated and brought into the new scene graph, while flaws are recognized and used as a driver for finding better solutions.
-* To bring in lessons from the wider C++ community the [C++CoreGuidlines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) are used to guide class design and implementation.
+* To bring in lessons from the wider C++ community the [C++CoreGuidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) are used to guide class design and implementation.
 * Spiral Development Model:
-Work follows a cycle starting at the centre and the moving around and outward following a spiral. On the innermost cycles of the spiral work is relatively simple and exploratory, but builds basic elements that later work can build upon, or on the next cycle round the sprial be revisted and refactored and made more capable if the original implementation is found insufficient. Steadily, understanding of the problem domain is built and the software is incrementally  built out in features and robustness.
-* While not formally an [Agile Software Development](https://en.wikipedia.org/wiki/Agile_software_development) project we draws upon it's manifesto:
+
+Work follows a cycle starting at the centre and then moving around and outward following a spiral.  On the innermost cycles of the spiral, work is relatively simple and exploratory but builds basic elements that later work can build upon, or on the next cycle round the spiral can be revisited, refactored and made more capable if the original implementation is found insufficient.  Steadily, understanding of the problem domain is built and the software is incrementally built out in features and robustness.
+
+* While not formally an [Agile Software Development](https://en.wikipedia.org/wiki/Agile_software_development) project we draw upon its manifesto:
     * **Individuals and interactions** over processes and tools
     * **Working software** over comprehensive documentation
     * **Customer collaboration** over contract negotiation
     * **Responding to change** over following a plan
 
 ## Only high value dependencies
 
-The VulkanSceneGraph library only has C++17, CMake and Vulkan as external dependencies. The Vulkan C headers are used rather then the Vulkan C++ header which is unnecessary as the Vulkan scene graph provides its own encapsulation of Vulkan objects in a way that is coherent with how they are used in the scene graph.
+The VulkanSceneGraph library only has C++17, CMake and Vulkan as external dependencies.  The Vulkan C headers are used rather than the Vulkan C++ header which is unnecessary as the VulkanSceneGraph provides its own encapsulation of Vulkan objects in a way that is coherent with how they are used in the scene graph.
 
-For runtime shader compilation support the VulkanSceneGraph library uses the [glslang](https://github.com/KhronosGroup/glslang) library. Originally integrated as an optional external dependency, it is now built internally as a submodule. While gslang support is compiled in by default it can be toggled off by setting the CMake VSG_SUPPORTS_ShaderCompiler variable to 0 before building the source. Compiling glslang within the VulkanSceneGraph library resolved problems with inconsistent 3rd party packaging of glslang, so now users can have seamless experience across platforms.
+For runtime shader compilation support the VulkanSceneGraph library uses the [glslang](https://github.com/KhronosGroup/glslang) library.  Originally integrated as an optional external dependency, it is now built internally as a submodule.  While glslang support is compiled in by default it can be toggled off by setting the CMake VSG_SUPPORTS_ShaderCompiler variable to 0 before building the source.  Compiling glslang within the VulkanSceneGraph library resolved problems with inconsistent 3rd party packaging of glslang, so now users can have a seamless experience across platforms.
 
-During the initial development of VulkanSceneGraph various other 3rd party dependencies, like gm and glfw, were considered for features like maths and windowing, but in each of these cases it was decided to implement the required features within the project rather than add an external dependency.  The reasons for implementing the functionality within the project:
+During the initial development of VulkanSceneGraph various other 3rd party dependencies, like glm and glfw, were considered for features like maths and windowing, but in each of these cases it was decided to implement the required features within the project rather than add an external dependency.  The reasons for implementing the functionality within the project were:
 
 * Coherent class interfaces and naming
 * Coherent memory management
 * Provide classes focused just on the needs of the VulkanSceneGraph users
-* Avoid the glue code required to bring different libraries to work well together
+* Avoid the glue code required to make different libraries work well together
 * Keep memory and CPU overhead to a minimum
 * Keep dependencies to a minimum to avoid ***Dependency Hell***
 * Keep licensing simple and permissive
 
-An example how local implementations can achieve what we need with far less code can be seen looking at the glm maths library. It's a header only library with over 63,000 lines of code.  The VulkanSceneGraph has all GLSL style vector, quaternion and matrix functionality it needs in less than 3,000 lines of code. The VulkanSceneGraph code base has 57,000 lines of code for its headers and source, and it has a scene graph, Vulkan integration, cross plarform windowing, viewer classes, serialization support and much more.
+An example of how local implementations can achieve what we need with far less code can be seen looking at the glm library.  It's a header only library with over 63,000 lines of code.  The VulkanSceneGraph has all GLSL style vector, quaternion, and matrix functionality it needs in less than 3,000 lines of code.  The VulkanSceneGraph code base has 57,000 lines of code for its headers and source, and it has a scene graph, Vulkan integration, cross platform windowing, viewer classes, serialization support and much more.
 
 ---