# HG changeset patch
# User Alfonse
# Date 1320309520 25200
# Node ID e493b17305db44ff1237a8b188ca5990de1bb046
# Parent 6c521d8fb8cc55396c16308b1f40ab9115f67b98
copyediting.
diff --git a/Documents/Positioning/Tutorial 06.xml b/Documents/Positioning/Tutorial 06.xml
--- a/Documents/Positioning/Tutorial 06.xml
+++ b/Documents/Positioning/Tutorial 06.xml
@@ -584,7 +584,7 @@
meaningful and useful depends on what you are doing.
Successive transformations can be seen as doing successive multiplication operations.
For example, if S is a pure scale matrix, T is a pure translation matrix, and R is a
- pure scale matrix, then the shader can compute the result of a transformation as
+ pure rotation matrix, then the shader can compute the result of a transformation as
follows:
vec4 temp;
temp = T * position;
@@ -969,6 +969,11 @@
The order that successive transforms are applied in matters. Matrix
multiplication is not commutative, and neither is object transformation.
+
+ Successive transformations can be used to build hierarchies of objects, each
+ dependent on the accumulated transformations of lower ones. This is done using a
+ matrix stack.
+
Further Study
@@ -997,9 +1002,9 @@
drawn.
- Given the generalized Hierarchy code, remove the matrix stack. Use objects
- created on the C++ stack instead. The node render function would take a
- const& to a matrix rather than a matrix stack reference.
+ Given the generalized Hierarchy code, remove the matrix stack. Use matrix
+ objects created on the C++ stack instead. The node render function would
+ take a const& to a matrix rather than a matrix stack reference.
diff --git a/Documents/Positioning/Tutorial 07.xml b/Documents/Positioning/Tutorial 07.xml
--- a/Documents/Positioning/Tutorial 07.xml
+++ b/Documents/Positioning/Tutorial 07.xml
@@ -967,8 +967,9 @@
is enough to measure the size of atoms in inches at more than 60 miles away from the
origin.
However, you would be sacrificing a lot of performance to do this. Even though the
- hardware can do double-precision math, it loses about 50% of its
- speed in doing so. And why bother, when the real solution is much easier?
+ hardware can do double-precision math, it loses quite a bit of
+ performance in doing so (anywhere between 25% and 75% or more, depending on the GPU).
+ And why bother, when the real solution is much easier?
Let's look at our shader again.
#version 330